前言
移动应用优化是产品中非常重要，也是比不可少的一环。
Android app优化主要包含size优化，性能优化，重构等。
- size优化，app减负是必不可少的一环。
- 性能优化，提升UX体验的重要途径（当然Spec的定义也会直接影响UX）。性能优化主要关注
- 重构：业务复杂度提示，需要重构提高易测性和扩展性，降低耦合
其中性能优化又是特别重要的一环
性能主要关注：
- launch time
- 渲染
- 内存
- 耗电和网络
- 卡顿
- 数据库优化
- 进程存活率
下面是针对Android端应用来阐述的优化解决方案。
方案
方案的核心：客户端搭配服务器端实现细致的监控，一起实现闭环的解决方案：监控，大数据统计和分析，回馈研发，解决，发布再到监控。
最终的目标做到合理优化，数据的量化。 更重要是如何建立合理的框架避免发生问题，或者是能及时的发现问题。
文章的最后还说明了发布和测试需要注意的一些事项
监控
服务器端应该监控的模块有：
- app基本统计信息（app版本，用户活跃度，地区，设备信息，页面活跃度，安装量，留存，功能使用等）
- 异常监控(包含Crash,ANR）
- 内存监控（例如有版本的平均内存，已经版本增幅的数据可以清晰看到量化的效果；包含OOM监控）
- 耗电监控
- 缓存监控
现在主流监控平台基本都实现了1 app统计信息和2 异常监控（例如友盟，GA，Bugly，Testin），这里不做赘述。
有些平台有做内存，电量，流量监控。例如：
- 网易的Emmagee： CPU、内存、流量、电量等
- 腾讯的GT： CPU、内存、流量、电量、帧率/流畅度等等
- 腾讯的APT：CPU，内存检测，内存构成分析
- 科大讯飞的iTest： 记录特定应用的性能消耗情况，包括cpu、内存、流量、电量等信息
不过缓存监控，截止现在暂时没发现可以接入的平台。腾讯Bugly有针对自己的手Q做这些监控，不过没有公开（记录时间2018/4/11)
1. size优化
备注：这里没有设计so的优化，待以后有实战了再更新
2. 性能优化
2.1 launch time
参看
2.2 渲染
渲染操作通常依赖于两个核心组件：CPU与GPU。CPU和GPU的工作，潜在的问题，检测的工具和解决方案图：
参看
2.3 内存
明显的内存问题
比较明显的内存问题，例如
- 明显的MemoryLeak
- 必发的内存不合理分配
- 内存抖动
- GC引起的性能问题（例如循环单元里面执行了创建对象操作，短时间内发生大量的内存上涨和降低事件）
我们可以用一些工具和技术监测分析以及代码，逻辑优化来解决
参看下面三篇
更深入的内存分析
比如偶发或长期操作才可能出现的不明显内存问题，就需要更深入的内存分析。这个需要搭配服务器端的细致监控app平均内存，平均OOM率，以及版本间增幅等相关的深入分析，就需要搭配服务器端。
需要结合内存监控和缓存监控来分析和解决这部分内存和OOM.
这部分公司现在条件限制，待有实战在更新。
2.4. 耗电和网路
2.5 卡顿
2.6 数据库优化
笔者的项目暂不需要，待以后实作会补充上来。
一些建议可以参看：性能优化之数据库优化
主要是索引优化，使用事务，sqlite优化，异步单线程等
2.7 进程存活率
参看这里Android进程保活招式大全
如何避免性能问题
在优化的同时，要知道更重要是如何建立合理的框架避免发生问题，或者是能及时的发现问题
- 合理的框架，避免资源没有释放问题。例如我们项目中使用的AppUniform, MVP的P会在destroy时自动释放
- 例如独立电量管理框架，自动释放内存
另外程序的Code Style要尽量遵循性能优化：要点
压力测试
- monkey > 18小时，生成报表：crash，ANR，内存图表等
- 建议使用Espresso，UiAutomator，AndroidJunitRunner，JUnit4等创建测试用例
方案发布
正式方案发布需要特别注意下面的几项：
- 严密的质量测试和压力测试
- 尽量阶梯式发布 0.02， 0.5
- 实时监测发布后的状态
小结
1.不要过早的做性能优化，app先求能用再求好用。在需求都还没完成的时候，花大量时间在优化上是本末倒置的 2.优化要用实际数据说话，建议借助测试工具进行检测。
总之，要合理优化，数据量化。而且搭配服务器做大数据统计和分析是非常必要的。