系列推荐：

Android 性能优化（二）Handler运行机制原理，源码分析 

Android 性能优化（三）认识错误Error和异常Exception及栈轨迹StackTrace

Android 性能优化（四）Crash治理之路，UncaughtException

Android 性能优化（五）Crash治理之OOM，内存泄漏检测工具

Android 性能优化(六)：启动优化的详细流程

---

自2008年智能时代开始，Android操作系统开启一路高歌智能机发展之路。

时至今日Android系统性能已经非常流畅了。到了不同层次的开发者手里，技术水平参差不齐，使得应用安装到配置极好的手机上依然存在体验差的现象。

App性能优化是提升用户体验的永恒主题，也成为工程者最终的使命。       

---

性能优化

从用户体验角度有四个性能优化方向。总结如下：

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

---

防止崩溃

正所谓：“稳定压倒一切。”

应用崩溃有三大原因：ANR（程序无响应）、Exception（异常）、LMK（低内存杀死机制）。

1、ANR：系统规定主线程中不能做过多的耗时操作。一般在Activity中不要超过5秒；BroadCast广播前台10秒，后台60秒；Service前台服务20秒，后台服务200秒。

2、Exception：造成Crash的原因却有很多，比如：运行时异常的空指针、数组越界、未实例化、强制类型、低内存机制等等。通常会使用 try - catch主动预防可能异常的代码。

但是没加try-catch的代码块出现异常还是闪退该怎么办？我们可以通过集成AndroidCrashX，就可以捕获全局线程异常并做好统计日志，最后通过热修复技术修复线上bug，就可以不通过发版就可以改掉线上bug。

3、LMK：由于Android应用的沙箱机制，每个应用程序都运行在一个独立的进程中，各自拥有独立的Dalvik虚拟机实例，系统默认分配给虚拟机的内存是有限度的。当系统内存太低依然会触发LMK（Low Memory Killer）机制，即出现闪退、崩溃现象。

详情查看：Android 一篇讲完Crash治理之OOM及内存检测工具

---

防止卡顿

卡顿的场景通常是发生在用户交互体验最直接的方面。大概分为四个方面，如下图所示。

影响卡顿的两大因素：

• 界面绘制：主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。

• 数据处理：导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。

布局优化

目的就是降低嵌套产生布局树的高度，从而提高UI渲染的效率。

在Android种系统对View进行测量、布局和绘制时，都是通过对View数的遍历来进行操作的。如果一个View数的高度太高就会严重影响测量、布局和绘制的速度。

• 布局复用，使用<include>标签重用layout；
• 提高显示速度，使用<ViewStub>延迟View加载；
• 减少层级，使用<merge>标签替换父级布局；

• 注意使用wrap_content，会增加measure计算成本；

绘制优化

过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。

在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。

• 移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片；

• 使用 canvas.clipRect() 识别可见区域，只在这个区域内才会被绘制。

启动优化

主要针对启动页SplashActivity的优化。分析一些三方库的初始化，一些大数据的处理等。

详细可以查看：Android 性能优化(六)：启动优化的详细流程

刷新优化

减少刷新次数，灵活利用缓存及限时刷新；

缩小刷新区域，局部刷新，避免多余请求；

---

耗电优化

对于Android操作系统和设备各大开发商来说，对手机耗电的优化从没有停止过，不断地追求更长的待机时间。而对于开发一款应用来说，绝不可以忽略电量耗损的问题，被归为“电池杀手”的应用，最终的结果无疑是走向被用户卸载的道路。

常见耗电原因，比如应用为了保持应用进程长期在后台存活，使用各种不合理进程保活方案，导致用户电量严重耗损。

Google的开源Battery Historian，GitHub - google/battery-historian: Battery Historian is a tool to analyze battery consumers using Android "bugreport" files.

    Battery Historian是一款用于检测与电池有关的信息和事件的工具。

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

计算优化

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

避免 Wake Lock

    Wake Lock是一种锁的机制，主要是相对系统的休眠而言的，只要有人拿着这个锁，系统就无法进入休眠意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。

比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了Wake_Lock锁。系统为了节省电量，CPU在没有任务忙的时候就会自动进入休眠。有任务需要唤醒CPU高效执行的时候，就会给CPU加Wake_Lock锁。

大家经常犯的错误，我们很容易去唤醒CPU来工作，但是很容易忘记释放Wake_Lock。

使用 Job Scheduler 

在Android 5.0 API 21 中，Google提供了一个叫做JobScheduler API的组件，来处理当某个时间点或者当满足某个特定的条件时执行一个任务的场景。

例如当用户在夜间休息时或设备接通电源适配器连接WiFi启动下载更新的任务。这样可以在减少资源消耗的同时提升应用的效率。

---

包体积优化

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

安装包的组成结构

• assets文件夹。存放一些配置文件、资源文件，assets不会自动生成对应的 ID，而是通过 AssetManager 类的接口获取。
• 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 寻找资源。

减少安装包大小

1、资源优化。Android 自带 Lint 工具，删除冗余资源，资源文件最少化等

    Android Lint Tool 是 Android Sutido 集成的一个代码规范提示工具，不仅让你及时发现代码种隐藏的一些问题，更能让你养成良好的代码风格。

2、图片优化。比如利用 PNG优化工具 对图片做压缩处理。如果应用在4.0版本以上，推荐使用 WebP图片格式。

3、可以使用微信开源资源文件混淆工具——AndResGuard 。

大约是在2014年4月实现，并在微信5.4中首次使用，一般可以压缩apk的1M左右大。主要是混淆资源ID长度(例如将res/drawable/welcome.png混淆为r/s/a.png)，同时利用7z深度压缩，可以强制压缩类似resources.arsc、png、jpg等。大大减少了安装包体积，提升了反破解难度。而整个过程从解压，到混淆，到重打包耗费时间，大约耗时只需35秒。

4、插件化热修复开发。比如功能模块放在服务器上，按需下载，可以减少安装包大小。

5、避免重复或无用功能的第三方库。例如，百度地图接入基础地图即可、讯飞语音无需接入离线、图片库Glide\Picasso等