android 系统性能优化（70）---Android 性能优化，内存检测、卡顿优化、耗电优化、APK瘦身——详解篇

自2008年智能时代开始，Android操作系统一路高歌，10年智能机发展之路，如今 Android 9.0 代号P  都发布了，Android系统性能已经非常流畅了。但是，到了各大厂商手里，改源码自定系统，使得Android原生系统变得鱼龙混杂。另外，到了不同层次的开发工程师手里，因为开发技术的水平参差不齐，使得应用安装到配置极好的手机上，打开应用依然存在卡顿现象。最后，随着产品内容迭代，功能需求越来越复杂，UI页面也越来越丰富，也成为流畅运行的一种阻碍。性能优化提升用户体验成为开发工程师的使命，那么该如何完成这样一个使命呢？首先，我们需要借助性能检测工具来进行分析。

（五）Android 自带 Lint 工具

使用性能检查工具，可以将自身产品与竞争者产品做对比，可以发现自身产品存在的不足之处。那么，接下来需要思考如何进行制定系统化的优化改进方案。本着人道主义，首先从用户体验的角度去思考，置身处地得把自己当做用户去玩一款应用时候会在意些什么呢？假如饭点将至，需要打开 到家APP进行点餐，首先一定不希望，在浏览商家和菜品列表内容很丰富的时候遇到卡顿现象，然后千挑万选后在期待美食将至的心情下准备下单，突然遇到闪退崩溃那简直想卸载 到家APP的心都有了。其次就是配送员在配送过程中不希望耗电和耗流量太严重。最后就是用户和配送员都希望版本更新的时候安装包希望能小一点。

根据用户的四个方面需求，总结如下：

1. 追求流畅，防止卡顿
2. 追求稳定，防止闪退
3. 追求续航，防止耗损
4. 追求精简，防止臃肿

我们知道一般造成Crash和ANR的原因是什么吗？两者都属于程序异常且都会出现应用崩溃的表现。造成ANR程序无响应的原因主要是在四大组件的耗时操作；而造成Crash的原因却有很多，比如运行时异常的空指针、数组越界、未实例化、强制类型、低内存机制等等，有些时候我们在开发测试阶段都没有出现异常崩溃现象，而发布上线后到了用户手机就会出现各种奇怪闪退，这样无疑会降低用户体验，致使用户想去卸载APP，用户量的流失直接给公司造成经济损失。

首先，我们要去努力实现一个永远 打不死的小强 —— 不会出现Crash闪退的APP。虽然我们无法保证开发完美至极不出现异常，但是可以努力做好异常的捕获。通常我们会使用 try - catch，在发现容易出现崩溃的代码块，主动加上try-catch 预防异常闪退。但是没加try-catch的代码块出现异常还是闪退该怎么办？我们可以通过设置  UncaughtExceptionHandler 捕获全局线程异常，而 在主线程抛出异常时，APP依旧会闪退进程重启。那么可以使用 Cockroach （蟑螂），可以保证不管怎样抛异常都不会闪退，App进程也不会重启。

以上治标不治本，需要不断加强代码的严谨性去减少Crash率。由代码带来的内存泄漏导致内存溢出Crash是最常见的、也是最具技术含量的程序异常。由于Android应用的沙箱机制，每个应用程序都运行在一个进程中，拥有一个独立的Dalvik虚拟机实例，系统默认分配给虚拟机的内存是有限度的。当系统内存太低依然会触发LMK（Low Memory Killer）机制，即闪退、崩溃现象。

不同厂商不同，如：华为mate7，192m ；小米4，128m ；红米，128m 。而在，Android4.0以后，可以通过在application节点中设置属性android:largeHeap=”true”来设置最大可分配多少内存空间就可以突破一定限制。

如果懂得内存如何分配和回收机制，对内存优化会有一定的认识和掌握的话，看下面这个例子，代码如下所示：

1. public class CommUtil {
2. private static CommUtil instance;
3. private Context context;
4. private CommUtil(Context context) {
5. this.context=context;
6. }
7. public static CommUtil getInstance(Context context){
8. if( null==instance){
9. instance= new CommUtil(context);
10. }
11. return instance;
12. }
13. }
14. public class MainActivity extends AppCompatActivity {
15. @Override
16. protected void onCreate(Bundle savedInstanceState) {
17. super.onCreate(savedInstanceState);
18. setContentView(R.layout.activity_main);
19. CommUtil instance = CommUtil.getInstance( this); //
20. }
21. }

    一个工具类 CommUtil.class 使用创建型设计模式——单例模式，在MainActivity.class中引用，那么这个单例对象会持有Activity的实例。然后运行起来 ，再将手机屏幕旋转几下。这样的代码会造成什么错误？

（旋转屏幕的时候 Activity会被销毁重新创建，但是这里的单例会持有销毁Activity的实例就造成内存泄漏）

（2）Memory Analyzer 工具：

    简单，傻瓜式操作。可以在GitHup官网查阅https://github.com/square/leakcanary，我们可以在Gradle文件里添加依赖。这个工具是Square公司在Github开源的。行业内不是有一句话嘛，Square出品必属精品，主流的库像okhttp、Picasso、retrofit、Dagger等都出自Square之手。说到这不得不让我联想到一位在Android开发领域神一般存在的人物，他就是大名鼎鼎的Jake Wharton（杰克.沃顿），ButterKnife的创造者，也参与贡献了Retrofit, okhttp等。

小结

    过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。 在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。如何 避免过度绘制？

• 布局上的优化。移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片

• 自定义View优化。使用 canvas.clipRect() 帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

    （另外，还可以IDE自带的一款UI绘制检测图形化数据分析工具 Systrace ，4.0版本以上版本可以使用。这里暂不介绍）

1. 减少刷新次数；
2. 缩小刷新区域；

    在移动设备中，电池的重要性自然不言而喻，如果手机没电了应用功能技术实现再怎么牛逼，用户也什么都干不成。对于Android操作系统和设备各大开发商来说，对手机耗电的优化从没有停止过，不断地追求更长的待机时间。而对于开发一款应用来说，绝不可以忽略电量耗损的问题，被归为“电池杀手”的应用，最终的结果无疑是走向被用户卸载的道路。比如，有些应用为了保持应用进程长期在后台存活，使用各种不合理进程保活方案，破坏操作系统“生态平衡”，导致用户电量严重耗损，虽然这种流氓开发行为并不违法吧，但是也属于不道德的行为，也同样会被同行所被鄙视的行为。

    在 Android5.0 以前，关于应用电量消耗的测试即麻烦又不准确，而5.0 之后Google专门引入了一个获取设备上电量消耗信息的API—— Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况。

    最后提供一些可供参考耗电优化的方法：

（1）计算优化。算法、for循环优化、Switch..case替代if..else、避开浮点运算。

        浮点运算：计算机里整数和小数形式就是按普通格式进行存储，例如1024、3.1415926等等，这个没什么特点，但是这样的数精度不高，表达也不够全面，为了能够有一种数的通用表示法，就发明了浮点数。 浮点数的表示形式有点像科学计数法（*.*****×10^***），它的表示形式是0.*****×10^***，在计算机中的形式为 .***** e ±***），其中前面的星号代表定点小数，也就是整数部分为0的纯小数，后面的指数部分是定点整数。利用这样的形式就能表示出任意一个整数和小数，例如1024就能表示成0.1024×10^4，也就是 .1024e+004，3.1415926就能表示成0.31415926×10^1，也就是 .31415926e+001，这就是浮点数。浮点数进行的运算就是浮点运算。 浮点运算比常规运算更复杂，因此计算机进行浮点运算速度要比进行常规运算慢得多。

（2）避免 Wake Lock 使用不当。

     Wake Lock是一种锁的机制， 主要是相对系统的休眠而言的， ,只要有人拿着这个锁，系统就无法进入休眠 意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题，比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了Wake_Lock锁。 系统为了节省电量，CPU在没有任务忙的时候就会自动进入休眠。有任务需要唤醒CPU高效执行的时候，就会给CPU加Wake_Lock锁。大家经常犯的错误，我们很容易去唤醒CPU来工作，但是很容易忘记释放Wake_Lock。

   在Android 5.0 API 21 中，google提供了一个叫做JobScheduler API的组件，来处理当某个时间点或者当满足某个特定的条件时执行一个任务的场景，例如当用户在夜间休息时或设备接通电源适配器连接WiFi启动下载更新的任务。这样可以在减少资源消耗的同时提升应用的效率。

    其实APK大小对应用使用并没有影响，但应用的安装包越大，用户下载的门槛越高。例如，应用版本的迭代更新，特别是当用户在移动网络情况下，又不得不去下载安装包，才能使用产品满足自身需求。因此，开发应该减小安装包大小，使得让更多用户愿意下载产品和体验产品。

（1）安装包的组成结构

• assets文件夹。存放一些配置文件、资源文件，assets不会自动生成对应的 ID，而是通过 AssetManager 类的接口获取。

• res。res 是 resource 的缩写，这个目录存放资源文件，会自动生成对应的 ID 并映射到 .R 文件中，访问直接使用资源 ID。

• META-INF。保存应用的签名信息，签名信息可以验证 APK 文件的完整性。

• AndroidManifest.xml。这个文件用来描述 Android 应用的配置信息，一些组件的注册信息、可使用权限等。

• classes.dex。Dalvik 字节码程序，让 Dalvik 虚拟机可执行，一般情况下，Android 应用在打包时通过 Android SDK 中的 dx 工具将 Java 字节码转换为 Dalvik 字节码。

• resources.arsc。记录着资源文件和资源 ID 之间的映射关系，用来根据资源 ID 寻找资源。

（2）减少安装包大小