Android的性能优化(1)

Android的性能优化简介

Android设备作为一种移动设备,不管是内存还是CPU都收到了一定的限制,过多的使用内存,会导致内存溢出,既OOM,过多的使用CPU资源,一般指大量的耗时任务,会造成卡顿,甚至ANR;
除了性能方面的,我们也应该维护代码的可扩展性和可维护性,

1.1 Android性能优化的方法

1.1.1 布局优化

• 删除无用的控件和层级
• 有选择的使用性能较低的ViewGroup，如果布局中既可以使用Linearlayout也可以使用RelativeLayout，那就是用LinearLayout，因为RelativeLayout功能比较复杂，它的布局过程需要花费更多的CPU时间。
• 有时候通过LinearLayou无法实现产品效果，需要通过嵌套来完成，这种情况还是推荐使用RelativeLayout，因为ViewGroup的嵌套相当于增加了布局的层级，同样降低程序性能。
• LinearLayou的权重属性也是相当消耗性能的,能少用就少用

说明:LinearLayou之所以性能好,是因为他在不适用权重的情况下,只会measure一次,而RelativeLayout和权重会measure两次
采用合适的标签

• include标签
  标签用于布局重用，可以将一个指定的布局文件加载到当前布局文件中。只支持android:layout开头的属性，当然android:id这个属性是个特例；如果指定了android:layout这种属性，那么要求android:layoutwidth和android:layout_height必须存在，否则android:layout属性无法生效。如果指定了id属性，同时被包含的布局文件的根元素也指定了id属性，会以指定的这个id属性为准。
• merge标签
  标签一般和标签一起使用从而减少布局的层级。如果当前布局是一个竖直方向的LinearLayout，这个时候被包含的布局文件也采用竖直的LinearLayout，那么显然被包含的布局文件中的这个LinearLayout是多余的，通过标签就可以去掉多余的那一层LinearLayout。
• ViewStub标签
  ViewStub意义在于按需加载所需的布局文件，因为实际开发中，有很多布局文件在正常情况下是不会现实的，比如网络异常的界面，这个时候就没必要在整个界面初始化的时候将其加载进来，在需要使用的时候再加载会更好。在需要加载ViewStub布局时：

((ViewStub)findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);
  //或者
  View importPanel = ((ViewStub)findViewById(R.id.stub_import)).inflate();

当ViewStub通过setVisibility或者inflate方法加载后，ViewStub就会被它内部的布局替换掉，ViewStub也就不再是整个布局结构的一部分了。

1.1.2 绘制优化

View的onDraw方法要避免执行大量的操作；

• onDraw中不要创建大量的局部对象，因为onDraw方法会被频繁调用，这样就会在一瞬间产生大量的临时对象，不仅会占用过多内存还会导致系统频繁GC，降低程序执行效率。
• onDraw也不要做耗时的任务，也不能执行成千上万的循环操作，尽管每次循环都很轻量级，但大量循环依然十分抢占CPU的时间片，这会造成View的绘制过程不流畅。根据Google官方给出的标准，View绘制保持在60fps是最佳的，这也就要求每帧的绘制时间不超过16ms(1000/60)；所以要尽量降低onDraw方法的复杂度。

1.1.3 内存泄漏优化

内存泄露优化主要分两个方面；
一方面是开发过程中避免写出有内存泄露的代码，
另一方面是通过一些分析工具如LeakCanary或MAT来找出潜在的内存泄露继而解决。
下面是容易引起内存泄漏的场景:

• 静态变量导致的内存泄露
  比如Activity内，一静态Conext引用了当前Activity，所以当前Activity无法释放。或者一静态变量，内部持有了当前Activity，Activity在需要释放的时候依然无法释放。
• 未能正确使用Context
  比如单例模式持有了Activity，而且也没用解注册的操作。因为单例模式的生命周期和Application保存一致，生命周期比Activity要长，这样一来就导致Activity对象无法及时被释放。
• 属性动画导致的内存泄露
  属性动画中有一类无限循环的动画，如果在Activity播放了此类动画并且没有在onDestroy中去停止动画，那么动画会一直播放下去，并且这个时候Activity的View会被动画持有，而View又持有了Activity，最终导致Activity无法释放。解决办法是在Activity的onDrstroy中调用animator.cancel()来停止动画。
• 资源未释放
  数据库的cursor,io流,广播等没有及时关闭等,都会引起内存泄漏
• handler和AsyncTask等
  需要在onDestory()的时候,调用各自的结束方法,或者使用弱引用
• 内部类引起的
  内部类持有外部类的引用,改用静态内部类就可以

1.1.4 响应优化速度和ANR日志分析

响应速度优化的核心思想就是避免在主线程中去做耗时操作，将耗时操作放在其他线程当中去执行。Activity如果5秒无法响应屏幕触摸事件或者键盘输入事件就会触发ANR，而BroadcastReceiver如果10秒还未执行完操作也会出现ANR。

当一个进程发生ANR以后系统会在***/data/anr的目录下创建一个文件traces.txt***，通过分析该文件就能定位出ANR的原因。

1.1.5 列表优化和bitmap优化

ListView/GridView优化：

• 采用ViewHolder避免在getView中执行耗时操作
• 其次通过列表的滑动状态来控制任务的执行频率，比如快速滑动时不是和开启大量异步任务
• 最后可以尝试开启硬件加速使得ListView的滑动更加流畅。
  Bitmap优化：主要是想是根据需要对图片进行采样显示，根据显示的大小,进行图片的压缩,用完之后及时回收,对图片进行缓存;

1.1.6 线程优化

使用线程池进行对线程的管理,使用线程池可以很方便的对线程的生命周期,创建销毁等进行管理

1.1.7 其他的优化

• 避免创建过多的对象，尤其在循环、onDraw这类方法中，谨慎创建对象；
• 不要过多的使用枚举，枚举占用的内存空间比整形大。Android 中如何使用annotion替代Enum
• 常量使用static final来修饰；
• 使用一些Android特有的数据结构，比如 SparseArray 和 Pair 等，他们都具有更好的性能；
• 适当的使用软引用和弱引用；
• 采用内存缓存和磁盘缓存；
• 尽量采用静态内部类，这样可以避免非静态内部类隐式持有外部类所导致的内存泄露问题。

1.2 内存泄漏分析工具MAT

MAT全程Eclipse Memory Analyzer, 是一个内存泄漏分析工具. 下载后解压即可. 下载地址http://www.eclipse.org/mat/downloads.php. 这里仅简单说一下. 这个我没有手动去实践, 就当个记录, 因为现在Android Studio可以直接分析hprof文件.

可以手动写一个会造成内存泄漏的代码, 然后打开DDMS, 然后选中要分析的进程, 然后单击Dump HPROF file这个按钮. 等一小段会生成一个文件. 这个文件不能被MAT直接识别. 需要使用Android SDK中的工具进行格式转换一下.这个工具在platform-conv文件夹下

hprof-conv 要转换的文件名 输出的文件名文件名的签名有包名.

然后打开MAT通过菜单打开转换后的这个文件. 这里常用的就有两个

• Histogram: 可以直观的看出内存中不同类型的buffer的数量和占用内存大小
• Dominator Tree: 把内存中的对象按照从大到小的顺序进行排序, 并且可以分析对象之间的引用关系, 内存泄漏分析就是通过这个完成的.
  分析内存泄漏的时候需要分析Dominator Tree里面的内存信息, 一般会不直接显示出来, 可以按照从大到小的顺序去排查一遍. 如果发生了了泄漏, 那么在泄漏对象处右键单击Path To GC Roots->exclude wake/soft references. 可以看到最终是什么对象导致的无法释放. 刚才的操作之所以排除软引用和弱引用是因为,大部分情况下这两种类型都可以被gc回收掉,所以基本也就不会造成内存泄漏.

同样这里也可以使用搜索功能, 假如我们手动模拟了内存泄漏, 泄漏的对象就是Activity那么我们back退出重进循环几次, 会发现其实很多个Activit对象.

1.2.2 LeakCanary的使用

使用MAT工具分析内存,难度大,效率低,所以就有了LeakCanary开源库;
这个库的使用步骤:

1. gradle配置该库
2. 在Application中初始化
3. 在Activity的onDestory()方法里,创建RefWatcher对象,进行检测

每当有内存泄漏的时候,就会弹出通知栏,显示内存的状态

参考书籍

• Android开发艺术探索
• Android进阶解密
• Android移动性能实战