一、普遍存在的问题
- Handler内存泄露
- Observer内存泄露
- 四大组件的Context和Application Context 的不合理使用
- 几乎所有的模块都存在过渡绘制,背景设置了两遍:window和activity都设置了背景
- IO操作完成后没有关闭文件,TypedArray使用完没有recycle,Cursor使用完没有close
- String、StringBuidler、StringBuffer不合理使用
- 使用HashMap而不是SpareArray
- for循环没有优化
- 在系统回调中创建新的实例(onDraw、getView)
二、主要性能指标
三、使用到的工具
- Android Studio
- 开发者选项
- LeakCanary
这个工具非常好用,以下是几个实用的链接,很有参考价值。
- MAT
- DDMS
- tinypny、iSparta、7zip
四、关于GC
- GC是在非UI线程中进行的,但GC的过程会暂停所有线程,所以频繁的GC会导致线程阻塞,存在卡顿的问题
- GC的目的可以理解为释放内存
- 一个内存泄露问题会导致与之相关的类都GC不掉,即一个内存泄露问题可能导致上M的内存无法及时回收。
- ART模式下内存分配效率是Dalvik的10倍,GC的效率是Dalvik的2-3倍
- 关于JVM内存管理参考:Android GC 那点事
以上算是总体介绍,下面分几个方面来一一总结归纳:
静态代码分析
步骤:
Android studio->Analyze->Inspect Code...
能够发现的问题:
- Handler内部类导致的Leak
- IO操作完成没有关闭,TypedArray使用完没有recycle
- 布局的性能问题(过渡绘制、更高效的布局建议、useless标签)
- HashMap替换为SparseArray HashMap vs SparseArray
- unused resources
- 系统回调中创建新的实例(onDraw、getView方法中new对象是一件很耗内存的事情,不要这么low哦)
- String、StringBuilder、StringBuffer不合理使用的问题
- More...