Android进阶——性能优化之Android Monitor、TraceView、Allocation Tracking、Lint的使用
前言
一个好的性能优化，可以让你的软件运行速度上比别人快，出现的卡顿现象少，而且一个好的性能软件，会在系统内存中生存的更久。性能优化最主要的就是对Java内存的管理，即堆内存中的管理，对于Java内存分配的讲解，详细可见我的博客文章
概念介绍
内存泄漏和内存溢出的区别
- 内存泄漏：指程序分配出去的内存不再使用，无法进行回收
- 内存溢出：指程序在申请内存时，没有足够的空间供其使用
成员变量和局部变量内存分配
- 成员变量中的引用和引用对象存在堆中
- 局部变量中的引用存在栈中，引用对象存在堆中
工具的说明
- Android Monitor：用来查看当前设备堆内存的情况，可以通过该工具找到内存泄漏的原因
- Android Monitor之Memory Usage：经过手动的GC之后，可以查看当前Activity的数量，来判断是否泄漏
- TraceView：查看某个方法的CPU执行时间和方法运行时间
- Allocation Tracking：查看内存的饼状图
- Lint：系统自带的检测工具，可以检测内存泄漏的疑点和书写规范等问题
Android Monitor
我们通过一个单例模式的例子产生的内存泄漏来使用Android Monitor
/**
* 单例模式
*/
public class CommUtil {
private static CommUtil instance;
private Context context;
private CommUtil(Context context) {
this.context=context;
}
public static CommUtil getInstance(Context context){
if(null==instance){
instance=new CommUtil(context);
}
return instance;
}
}
/**
* 使用单例
*/
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
CommUtil instance = CommUtil.getInstance(this);
}
}
接着我们旋转三次屏幕，让Activity不断调用onCreate方法，从而导致CommUtil不断被实例化，在Android Monitor的内存监测中也能看得出来内存在增加
1、打开Android Monitor
2、点击Dump java Heap让其产生一份快照
3、找到MainActivity类，查看其实例情况
我们可以看到MainActvity有三个实例对象被引用
- 0号位属于内存泄漏的实例
- 1号位属于垃圾内存，会被GC回收
- 2号位属于当前界面引用的实例
这里需要注意，旋转屏幕3次以上都只会有2个MainActivity。当GC回收的时候会将第0个和最后一个留着，其他的都会被回收
4、点击对象实例，找到引用的对象
5、解决方法
/**
* 使用单例
*/
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
CommUtil instance = CommUtil.getInstance(getApplicationContext());
}
}
这个时候，我们再按照前面的方法查看MainActivity的实例
Android Monitor之Memory Usage
正常的情况下，应用程序按返回键退出程序，并且经过多次手动GC，理论上所有的Activity都会被回收，我们可以通过Memory Usage的信息，查看退出程序后的Activity和View是否依然存在内存中，从此可以判断是否发生内存泄漏。我们主要是通过下面的入口，查看到最后程序退出并经过GC后的剩余情况，这里很明显可以看到内存泄漏了Activity和View，正常的值应该是0
TraceView
我们通过计算斐波拉契列数的例子，学习TraceView的使用
//调用斐波拉契列数
computeFibonacci(40);
public int computeFibonacci(int positionInFibSequence) {
if (positionInFibSequence <= 2) {
return 1;
} else {
return computeFibonacci(positionInFibSequence - 1)
+ computeFibonacci(positionInFibSequence - 2);
}
}
1、打开Android Device Monitor （DDMS），按步骤启动TraceView
2、开始start Method Profiling之后，在主程序中执行斐波拉契列数，等待大概5秒就stop Method Profiling，系统会生成一份分析文件
3、鼠标移动到某一处黑色的地方
4、滑动鼠轮进行放大
5、产看详细信息面板
| 列名 | 作用 |
|---|---|
| Name | 该进程中所调用的函数名称 |
| Incl Cpu Time | 函数占用的CPU时间，包含内部调用其它函数的CPU时间 |
| Excl Cpu Time | 函数占用的CPU时间，但不包含内部调用其它函数所占用的CPU时间 |
| Incl Real Time | 函数运行的真实时间（以毫秒为单位），内含调用其它函数所占用的真实时间 |
| Excl Real Time | 函数运行的真实时间（以毫秒为单位），不包含调用其它函数所占用的真实时间 |
| Calls+Recur Calls/Total | 函数被调用次数以及递归调用占总调用次数的百分比 |
| Cpu Time/Call | 函数调用CPU时间与调用次数的比（该函数平均执行时间） |
| Real Time/Call | 同CPU Time/Call类似，只不过统计单位换成了真实时间 |
6、解决方法
//将递归换为for循环 同时使用缓存 先将结果缓存起来
public int computeFibonacci(int positionInFibSequence) {
int prev=0;
int current=1;
int values;
for(int i=0;iAllocation Tracking
1、打开Android Monitor，找到下面按钮，点击start Allocation Tracking，然后执行我们的程序进行分配内存，最后stop Allocation Tracking，可以看到图片上有一段矩形，就是我们追踪的内存分配部分，等一会会生成一份分析报告
2、在详细报告中打开图形图，可以看到每一层的内存分布情况，后面的内存分配都可以在图形中结合右边介绍找到
Lint
1、采用Lint工具系统会检测出一些简单的内存泄漏，或者是书写规范等等问题，使用Analyze里面的Inspect Code
2、选择整个目录结构即可得到分析报告
常见的内存泄漏例子
1、静态变量引起的内存泄露情况
当调用getInstance时，如果传入的context是Activity的context，只要这个单例没有被释放，那么这个Activity也不会被释放，一直到进程退出才会释放。解决方法就是将传入的context设置为getApplicationContext()即可
public class CommUtil {
private static CommUtil instance;
private Context context;
private CommUtil(Context context) {
this.context = context;
}
public static CommUtil getInstance(Context mcontext) {
if (instance == null) {
instance = new CommUtil(mcontext);
}
return instance;
}
}
2、非静态内部类引起的内存泄露情况
由于非静态内部类对外部类持有应用，且非静态内部类的生命周期和外部类生命周期不一样，就会导致内存泄漏。解决方法就是将非静态内部类设置为静态内部类即可
3、注册的监听未移除引起的内存泄露情况
最常见的是 registerReceiver()、订阅-发布模式
4、资源未关闭引起的内存泄露情况
BroadCastReceiver、Cursor、Bitmap、IO流、自定义属性attribute、attr.recycle()的回收
5、无限循环动画引起的内存泄露情况
没有在onDestroy中停止动画，否则Activity就会变成泄露对象
处理过的内存泄露
1、Handler和Callback内存泄露
在Activity内部创建Handler，由于Activity的生命周期和Handler不一样，所以Handler会内存泄露，解决方法就是将Handler设置为静态类，有时Handler里面会存储Callback等变量，请务必将这些变量设置为弱引用进行存储
2、DCL（双检查锁机制）
DCL的单例需要对单例变量进行volatile修饰，否则JVM会存在指令的重排序优化，导致内存泄露