优化目标
作为客户端开发工程师，要始终把用户体验放在重要位置，尽可能开发运行稳定、用户体验好的应用。
可从以下几个方面不停优化应用：
- APP体验流畅，不存在卡顿问题
- 省电，省流量
- 运行稳定，不闪退(减少闪退、ANR)
- 安装包大小尽可能小，降低推广难度
卡顿优化
应用经常卡顿，定会影响用户体验，如果不是必须要安装使用您的应用，谁也不想再次打开，所以要尽全力保证应用流畅运行。
可能造成应用卡顿的情景有：
- UI嵌套层级过多或绘制不必要的视图背景
- 主线程处理太多耗时任务
- 数据处理占用CPU，主线程获取不到CPU资源
- 频繁触发GC，线程频繁停滞运行
Android 系统每隔 16ms 发出 VSYNC 信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。在理想情况下，60 FPS 就感觉不到卡，这意味着每个绘制时长应该在16 ms 以内，但是 Android 系统很有可能无法及时完成那些复杂的页面渲染操作，就会造成卡顿。
卡顿优化方案总结
- 尽量减少UI布局层次，去掉不必要的嵌套
- 自定义UI避免在绘制过程频繁创建对象
- 暂时不需显示的视图可使用ViewStub，仅在需要显示的时候加载
- 层级相同时尽量使用绝对位置布局，而不是RelativeLayout
- 不要在主线程进行数据解析或其他耗时的任务
- 尽量减少页面刷新次数，针对列表多尝试item刷新，而不是全部刷新
- 尽量不要在循环中创建大内存对象
- 不再使用的资源要主动释放，不能完全依赖系统GC
- 数据处理方面可考虑采用缓存，避免重复计算
使用工具：
开发人员选项 -> GPU呈现模式分析 -> 在屏幕上显示为条形图
绿线代表16ms，要确保1s内达到60fps，你需要确保这些帧的每一条线都在绿色的16ms标记线之下。
开发人员选项 -> 调试GPU过度绘制 -> 显示过度绘制区域
原色：没有过度绘制
蓝色：1 次过度绘制
绿色：2 次过度绘制
粉色：3 次过度绘制
红色：4 次及以上过度绘制电量优化
对应用来说，电量的使用是不能忽略的问题，如果应用耗电太多，很容易被用户卸载。
耗电的原因多种多样，仅总结比较常见的优化方案：
- 将一些不需要及时使用的资源放到充电时候处理，使用JobScheduler
- 合理使用WakeLock(应用申请了WakeLock，在释放之前，系统不会休眠，即使在灭屏的状态下，应用执行的任务依旧不会被系统打断)
- 网络上数据大量传输，尽量传输压缩后的数据
- 尽量避开浮点运算，特定情况下使用移位操作代算术运算
流量优化
应用消耗过多流量，也会引起用户的不满，因此我要尽一切可能减少对用户数据流量的消耗。
一般有以下几种方案：
- 对于无需频繁刷新的数据，本地缓存，设置过期时间，避免多次无效请求
- 对于暂时不会用到的资源数据，可在WI-FI网络环境下自动下载；在移动网络环境下且未下载时用到相关资源告知用户下载所需流量，用户点击确认下载，否则使用本地默认替代方案
- 对于有时效性的数据，可考虑在客户端实现带过期时间的缓存，缓存有效期内避免多次请求网络数据
内存优化
开发过程中，如果内存使用不当，极易造成内存泄漏，引发OOM问题，总结了以下内存泄漏常发生的情景及解决方案
泄漏情景
- 单例模式中引用Context，使用过后没有主动释放资源
- 资源对象使用过未关闭，如文件、Stream、数据库连接等
- 注册的事件在页面关闭时未销毁
- 非静态Handler导致Activity未被回收
- 容器中的对象未清理导致内存泄漏
优化方案
- 再适合的场景使用不同的引用类型
- 使用图片资源时，使用恰当尺寸的图片
- 资源对象使用后主动关闭及释放资源
- 使用静态内部类代替匿名内部类
稳定性优化
Android 应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：
- 提高代码质量，开发过程中交叉Review
- 借助代码静态扫描工具，如 Android Lint等
- crash上报，在开发和灰度阶段暴漏问题，正式发布前修复
APK大小优化
安装包越大，应用推广难度越高，所以尽一切可能对自己的应用瘦身。
可采取以下方案：
- 一些资源文件放到服务端，需要时下发
- 对图片资源进行无损压缩，如tinypng等
- 删除无用代码及不再使用的资源
总结
性能优化是一个循序渐进的过程，并不是一两天就能搞定，所以从日常开发中做起，每天积累，开发更稳定的应用，给用户提供更好的体验。