Android性能优化简要笔记

hloong 于 2016-09-19 发布

布局优化

0, UI渲染机制

人眼所看到的流畅画面，需要的帧数在40帧每秒到60帧每秒之间， 最佳的ftp在60左右，在Android中，系统通过VSYNC信号出发对UI的渲染、重绘，其间隔时间是16ms，这就意味着程序的大多数操作都必须在16ms内完成，这个16ms其实就是1000ms中显示60帧画面的单位时间。即1000、60，如果系统每次渲染都保持在16ms之内，那么我们看到的UI将十分的流畅，但这也是需要将所有的逻辑都保证在16ms里，如果16ms不能完成绘制，那么就会造成丢帧的现象，即当前该重绘的帧被未完成的逻辑阻塞，用户便感知到卡顿；

1，include标签
同样的布局抽出用include
解析xml布局时，检测到include就解析然后再解析被include进来的布局的root view元素

2，merge标签

image

如果如上图的布局会多一层嵌套，此时用merge标签来替换FrameLayout2可以减少嵌套

注意：默认一个activity会有一层FrameLayout(base_content)在外层，所以如果include的布局中是FrameLayout则应在activity最外层用merge标签，这样减少了层级

3，ViewStub视图
当布局需要延迟加载，点击可见的时候，采用 viewstub只占位不做具体事，宽高都为0，用户手动设置viewstub的inflate或者setVisibility为Visible时，ViewStub就从父控件移除并加载目标布局，完成视图的动态替换

4，减少视图树层级
能用RelativeLayout一个布局搞定的就不要用多层嵌套； 总结：

1，尽量多使用RelativeLayout，减少层级
2，在ListView等列表组件中避免使用Linearlayout的layout_weight属性，因为Linearlayout采用了weight属性后子view要绘制2次
3，将可复用的组件抽取用include标签
4，使用ViewStub标签加载一些不常用的布局
5，使用merge标签减少布局的嵌套布局

内存优化

0,什么是内存

由于Android的沙箱机制,每个应用所分配的内存大小是有限度的,内存太低就会触发LMK-Low Memory Killer机制。那么到底什么是内存呢?通常情况下我们所说的内存是指手机的RAM,它包括以下几个部分

寄存器(Registers) 速度最快的存储场所,因为寄存器位于处理器内部.在程序中无法控制

栈（Stack） 存放基本类型的数据和对象的引用.但对像本身不存放在栈中,而是存放在堆中 堆内存（Heap）

堆内存用来存放由new创建的对象和数组.在堆中分配的内存，由java虚拟机的自动垃圾回收（GC）管理 静态存储区域(static Field)

静态存储区域就是指在固定的位置存放应用程,子运行时一直存在的数据，java在内存中专门划分了一个静态存储区域来管理一些特殊的 数据变量如静态的数据变量 常量池(Constant Pool)

JVM虚拟机必须为每个被装载的类型维护一个常量池，常量池就是该类型所用到常量的一个有序集合，包括直接常量(基本类型，String)和对其他类型. 字段和方法的符号引用 在这些概念中最容易搞错的就是堆和栈的区分。

当定义一个变量，Java虚拟机就会在栈中为该变量分配内存空间 这部分内存空间会马上被用作新的空间进行分配，如果使用new的方式创建一个变量, 那么就会在堆中为这个对象分配内存空间，即使该时象的作用域结束, 这部分内存也不会立即被回收.而是等待系统Gc进行回收，堆的大小随着手机的不断发展而不断变大.

在过程中.可以使用如下所示的代码来获得堆的大小，所谓的 内存分析,正是分析Heap中的内存状态。

ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getLargeMemoryClass();

1，珍惜Services资源
限制Service最好的方法是使用IntentService，它会在处理完后扔给它的intent任务之后尽快结束自己
启动一个service，系统会为了保留这个Service而一直保留Service所在的进程。持续保留Service会导致APP因RAM的限制而性能糟糕。

2，当UI隐藏时释放内存
当用户切换到其他应用而你的APP不可见，应该释放UI上所占用的所有资源，这个时候可以增加系统缓存进程的能力。
实现Activity里面的onTrimMemory()回调方法，使用该方法监听到TRIM_MEMORY_UI_HIDDEN级别的回调
扩展：http://www.cnblogs.com/xiajf/p/3993599.html

public void onTrimMemory(int level) {  
    super.onTrimMemory(level);  
    switch (level) {  
    case TRIM_MEMORY_UI_HIDDEN:  
        // 进行资源释放操作  
        break;  
    }  
}

3，当内存紧张时释放部分内存
扩展：http://blog.csdn.net/guolin_blog/article/details/42238627
根据onTrimMemory方法中的内存级别来决定释放那些资源：
API14才支持的onTrimMemory，对于低版本，可以用onLowMemory来兼容， onLowMemory相当于TRIM_MEMORY_COMPLETE
Note：当系统开始清除LRU缓存中的进程时，尽管它首先按照LRU的顺序来操作，但是，它同样会考虑进程的内存使用量。因此，消耗越少的进程越容易被留下来。

4，检查你应该使用多少内存
通过调用getMemoryClass()来获取你的App的可用heap大小。特殊情况下，通过在manifest的application标签下添加==largeHeap=true==的属性来申明一个更大的heap空间，然后通过getLargeMemoryClass()来获取到一个更大的heap size。当然这种主要用于图片视频编辑类APP（需要消耗大量RAM）

5，避免Bitmap的浪费
加载Bitmap时，通过 BitmapFactory.Options采样压缩 ，只需要保留适配当前屏幕分辨率的数据，原图高于分辨率就需要做缩小的动作，因为增加Bitmap的尺寸会对内存呈现出2次方的增加；
扩展：http://blog.csdn.net/yudajun/article/details/9323941

6，使用优化的数据容器
用SparseArray替换HashMap，通常Hashmap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外SparseArray更加高效在于其避免了对key和value的autobox自动封装，也避免了装箱后的解箱。其他替换如：SparseBooleanArray,LongSparseArray Framework里面优化过的容器类。

7，注意内存开销
Enums的内存消耗通常是static constants的2倍，所以要避免在Android上用enums。 在Java中的每一个类都会使用大概500 bytes,每一个类的实例产生的花销是12-16 bytes,往HashMap添加一个entry需要一个额外占用的32 bytes的entry对象。

抽象是好的编程实践，但是代码会被map到内存中，所以如果抽象没有显著提升效率，就避免使用

使用Protocol Buffers 代替 JSON 扩展：
http://www.oschina.net/translate/choose-protocol-buffers?cmp
http://cxshun.iteye.com/blog/1974498
JSON数据有一个缺点：冗余太大–每条数据都包含前缀（如下面的Name和Gender），据统计，JSON数据至少有20%是无效的

[{"Name": "Jane", "Gender": 0}, {"Name": "Waith", "Gender": 1}]

与JSON不同，Protocol Buffers用二进制编码数据，而且数据的格式是事先通过一个后缀名为.proto的文件指定的， 如：

message Person {
  required string Name = 2;
  optional int32 Gender = 3;
}

8，避免使用依赖注入和外部库
针对Guice或者RoboGuice类似的注入框架，这些框架会扫描代码，消耗RAM来map代码；
外部库过多影响效率，能用自己实现的就自己实现，而不是导入一个大而全的方案；

9，使用ProGuard来删除不需要的代码
ProGuard能移除不需要的代码，重命名类，等方法，对代码进行压缩，优化和混淆。

10，对最终的APK使用zipalign 注：GooglePlay不接受没有经过zipalign的APK

11,使用多进程
如果使用不当会增加内存，当APP需要在后台运行与前天一样的大量的任务才可以用多进程
==典型的例子：==
创建一个可长时间后台播放的Music Player，如果整个APP运行在一个进程中，当后台播放 时候，前台的UI资源无法得到释放，这样类似的APP可以切分成2个进程：一个用于UI操作，一个用于后台Service； 可以通过manifest文件中申明android:process属性来实现某个组件运行在另外一个进程的操作：

<servcice  android:name=".PlaySercice"  android:process=":background" />

内存泄漏

0，使用Memory Monitor和DDMS下的Heap可以查看内存使用信息
扩展：http://blog.csdn.net/itfootball/article/details/48712595
1，内存泄漏检测–LeakCanary
扩展：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0509/2854.html

性能优化

0，过度绘制
用户界面卡顿，原因Overdraw–屏幕某像素在同一帧的时间内被绘制多次

View的onDraw方法不要执行大量操作（不要创建新的局部对象，占内存）
View的onDraw方法不要执行耗时操作，也不要执行成千上万的循环（循环抢占cpu时间片，绘制卡顿）

Android中的图形渲染，经过三个阶段：测量onMeasure，布局onLayout，绘制onDraw 通常视图层级越深，测量视图的时间就越长； 在视图渲染期间，每个View都要向它的父View提供自己的尺寸。如果父View发现了任意一个尺寸问题，它就会强制要求所有的子View重新测量。即便没有错误发生，重新测量也可能出现。

例如：为了正确地进行布局，RelativeLayout通常会对它们的子视图进行2次测量，子视图使用了layout_weight属性的LinearLayout也会对它的子视图进行2次测量； 测量和重新测量的代价昂贵，会严重影响渲染速度。想确保应用流畅需要移除那些非必须的View以及减少View层级（面试题必备）

1，使用Hierarchy Viewer
如下图：三个点分别表示，测量，布局，绘制三个阶段耗费的时间
红色表示该View的渲染速度比其他的所有参与测试的节点都慢
黄色表示该View的渲染速度慢于50%以上的其他测试节点
绿色表示该View的渲染速度至少快于一半以上的其他测试节点

image 知道哪些界面渲染比较慢再对症下药

2，数据采集和分析–TraceView
扩展：http://blog.jobbole.com/78995/

参考书目：《Android群英传》《Android开发艺术探索》《Android从小工到专家》