项目背景
本APP为面向用户的一款LBS产品。用户反馈APP使用过程中存在启动慢等问题。本文主要针对该原生Android APP启动慢的问题进行分析及解决方案的介绍。
所遇到的挑战
用户反馈的启动慢问题偏主观使用评价，对于专业的技术人员来说，这些反馈评价不够量化，无法为为我们解决问题提供有效的数据支撑。当然用户的负面评价也暴露了我们APP存在的两大问题。
1.监控体系不完善
无论后端服务还是移动端，我们均没有引入全链路追踪框架，导致应用缺乏全面的监控覆盖。当时的情况，我们仅埋点记录了少量系统级监控指标，关键代码路径监控严重不足。
2.代码质量较差
我们的项目历经多代开发维护，随着业务复杂性的升高及人员流动的影响，代码质量参差不齐，代码腐化问题严重，有的子系统代码阅读性极差，代码风格不统一。
解决问题的步骤
我们针对启动慢的问题进行分析后，对两大挑战对症下药，主要的解决步骤如下。
1.完善监控体系
我们经过讨论总结后，面临两个选择，一个是基于开源的Skywalking等APM系统进行定制开发，存在的问题是现有工程师不熟悉该系统，短期内很难短时间补足相关知识等问题；二是采用成熟的APM系统，但这会带来较大的短期资金压力。鉴于我们项目的紧迫性，我们选择了方案二，引入了友盟+应用性能监控平台U-APM。
引入U-APM后，我们能对应用端进行非常详细的监控，比如下图的概览监控。结合U-APM的启动分析能力，我们第一次较为精确地明确了用户启动的耗时及分布。
此外，我们还为服务端引入了ELK套件（ElasticSearch，Logstash，Kibana）和结构化日志，将关键代码路径参数及耗时等信息进行高效输出并汇聚展示。
2.加强代码质量管控
我们以前的代码开发过于注重速度，忽略了质量，虽然有CR（Code Review），但多流于形式，质量把控不严。我们借鉴业界工程效能最佳实践，对代码提交及评审打回率等关键指标进行监控并定期发出报表，对不合格的项目进行通报，并召开专题会议介绍代码质量提升实践。
3.动手解决
有了监控体系后，我们就拥有了明亮的眼睛去观察我们的系统。我们通过对量化后的耗时进行分析，初步判断出瓶颈所在，优先解决主要矛盾。理论上，每个请求都有优化空间，那是不是每个都需要优化呢？答案当然是否定的，因为服务间接口数以千计，如果消耗太多精力在非关键接口上，很容易事倍功半。我们采用的ROI(Return On Investment)的思想，优先解决耗时占比较大、请求频繁的函数调用以取得最大收益。具体来讲有如下几点。
1）安卓应用端问题
初次启动app耗时长，针对Application和Activity的同步内容进行优化，将核心内容页面尽快渲染返回给用户，使用异步任务加载耗时和非核心页面内容。安卓具体的api及原理，详见官网描述https://developer.android.google.cn/topic/performance/vitals/launch-time
2）服务端问题
通过监控，我们发现个别后端服务GC（Garbage Collection）频繁，隔一段时间就会导致Stop the World，引发耗时波动。我们通过对关键代码路径进行监控，结合内存使用情况等进行专项整治，发现问题主要是应用内的本地缓存使用不当导致，大量的临时缓存挤占内存引发了应用波动。
项目总结
在应用U-APM、丰富监控及代码质量提升后，该安卓APP的后期表现渐佳，用户的启动慢的吐槽量已经大幅减少。总的来说，安卓APP启动慢主要有两方面原因，
一是APP自身在手机端的代码设计不够合理，常见的问题在官网均匀最佳实践https://developer.android.google.cn/topic/performance/vitals；二是APP访问的后台服务质量存在优化空间。
针对安卓应用端的优化，Google也有许多实践案例，比如：
作者：么广忠
开源技术爱好者，全栈研发工程师，参与过多个开源项目并主导过多款APP设计开发。
