Android性能优化

1.性能优化方法

过多地使用内存会导致程序内存溢出，即OOM
过多地使用CPU资源，一般是指做大量的耗时任务，会导致手机变得卡顿甚至出现程序无法响应的情况，即ANR

1.布局优化

• 首先删除布局中无用的控件和层级，其次有选择地使用性能较低的ViewGroup
  很多时候需要嵌套增加层级，这时候采用RelativeLayout，避免布局层级的增加；如果层级数较少，可以使用FrameLayout 和LinearLayout等简单高效的ViewGroup。如果布局中既可以使用LincearLayout 也可以使用RelativeLayout,那么就采用LinearLayout,这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。

• 布局优化的第二种手段是采用< include>标签、< merge>标签 和ViewStub。< include>标签主要用于布局重用，< merge>标签一般和< include>配合使用，它可以降低减少布局的层级，而ViewStub则提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率

  • < include>标签 将一个指定的布局文件加载到当前的布局文件，只支持android:layout_开头的属性.如果< include>标签指定了android:layout_*这种属性,那么要求android:layout_width和android:layout_ height 必须存在，否则其他android:layout_*形式的属性无法生效
  • < merge>标签一般和< include>标签一起使用从而减少布局的层级。
  • ViewStub继承了View,它非常轻量级且宽/高都是0,因此它本身不参与任何的布局和绘制过程。ViewStub的意义在于在使用到的时候按需加载所需的布局文件，提高了程序初始化时的性能。使用后ViewStub会被内部的布局替换掉，然后就不再是整个布局结构的一部分了，并且不支持< merge>标签
  • 加载ViewStub中的布局文件：

((ViewStub) findViewById(R.id.stub import)).setVisibility(View.VISIBLE) ; 
或
View importPanel = ( (ViewStub) findViewById(R. id.stub import)).inflate() ;

2.绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作

• onDraw 中不要创建新的局部对象，这是因为onDraw方法可能会被频繁调用， 这样就会产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁gc,降低了程序的执行效率。
• onDraw 方法中不要做耗时的任务，也不能执行成千上万次的循环操作

3.内存泄露优化

内存泄漏(Memory Leak)：程序在申请内存后，无法释放已申请的内存空间
内存溢出(out of memory)：指程序在申请内存时，没有足够的内存空间供其使用。

• 静态变量导致的内存泄漏
  • 详情：一个静态变量又是非静态内部类会一直持有对外部类的引用，导致外部类Activity无法被回收。
  • 解决办法：将内部类设为静态内部类或独立出来，使用context.getApplicationContext()。
• 单例模式导致的内存泄漏
  • 详情：单例模式下传入的参数是Activity的context，即活动的对象被单例模式所持有，而单例模式的生命周期和Application一致，所以Activity无法释放
  • 解决办法：TestManager.getInstance( ). registerListener(context.getApplicationContext())
• 属性动画导致的内存泄漏
  • 详情：在Activity中播放无限循环动画且没有在onDestroy中去停止动画,那么动画会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候Activity的View会被动画持有，而View又持有了Activity, 最终Activity 无法释放。
  • 解决方法：在Activity的onDestroy中调用animator.cancel（ ）来停止动画。
• Handler导致的内存泄漏
  • 详情：Message持有对Handler的引用，而非静态内部类的Handler又隐式持有对外部类Activity的引用，使得引用关系会保持至消息得到处理，从而阻止了Activity的回收。
  • 解决办法：使用静态内部类+WeakReference弱引用；当外部类结束生命周期时清空消息队列。
• 线程导致的内存泄漏
  • 详情：AsyncTask/Runnable以匿名内部类的方式存在，会隐式持有对所在Activity的引用
  • 解决办法：将AsyncTask和Runnable设为静态内部类或独立出来；在线程内部采用弱引用保存Context引用。
• 资源未关闭导致的内存泄漏
  • 详情：未及时注销资源导致内存泄漏，如BraodcastReceiver、File、Cursor、Stream、Bitmap等。
  • 解决办法：在Activity销毁的时候要及时关闭或者注销。
    • BraodcastReceiver：调用unregisterReceiver()注销；
    • Cursor，Stream、File：调用close()关闭；
    • Bitmap：调用recycle()释放内存（2.3版本后无需手动）。
• Adapter导致的内存泄漏
  • 详情：不使用缓存而只依靠getView() 每次重新实例化Item，会给gc制造压力。
  • 解决办法：在构造Adapter时使用缓存的convertView。

4.响应速度优化

响应速度优化的核心思想是避免在主线程中做耗时操作，将这些耗时操作放在线程中去执行，即采用异步的方式执行耗时操作。响应速度过慢更多地体现在Activity 的启动速度上面，如果在主线程中做太多事情，会导致Activity启动时出现黑屏现象，甚至ANR。Android 规定，Activity 如果5秒钟之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR，而BroadcastReceiver 如果10秒钟之内还未执行完操作也会出现ANR。

5.ListView 优化

主要分为三个方面:首先要采用ViewHolder并避免在getView中执行耗时操作;其次要根据列表的滑动状态来控制任务的执行频率，比如当列表快速滑动时显然是不太适合开启大量的异步任务的;最后可以尝试开启硬件加速来使Listview的滑动更加流畅。Listview的优化策略完全适用于GridView。

6.Bitmap 优化

主要是通过BitmapFactory.Options来根据需要对图片进行采样,采样过程中主要用到了BitmapFactory.Options 的inSampleSize参数

7.线程优化

采用线程池，避免存在大量的Thread -------线程池参考

8.性能优化建议

• 避免创建过多的对象 ；
• 不要过多使用枚举，枚举占用的内存空间要比整型大；
• 常量请使用static final来修饰；
• 使用一些Android特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能；
• 适当使用软引用和弱引用；
• 采用内存缓存和磁盘缓存；
• 尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄露。

2.ANR日志的分析方法

3.内存泄漏分析工具MAT

4.设计原则

命名规范
代码排版上要留出空白区分代码块，同类变量的声明要放在一组，两类变量之间要留出空白作区分
注释要求