移动APP启动慢解决实践

项目背景

本APP为面向用户的一款LBS产品。用户反馈APP使用过程中存在启动慢等问题。本文主要针对该原生Android APP启动慢的问题进行分析及解决方案的介绍。

所遇到的挑战

用户反馈的启动慢问题偏主观使用评价,对于专业的技术人员来说,这些反馈评价不够量化,无法为为我们解决问题提供有效的数据支撑。当然用户的负面评价也暴露了我们APP存在的两大问题。

1.监控体系不完善

无论后端服务还是移动端,我们均没有引入全链路追踪框架,导致应用缺乏全面的监控覆盖。当时的情况,我们仅埋点记录了少量系统级监控指标,关键代码路径监控严重不足。

2.代码质量较差

我们的项目历经多代开发维护,随着业务复杂性的升高及人员流动的影响,代码质量参差不齐,代码腐化问题严重,有的子系统代码阅读性极差,代码风格不统一。

解决问题的步骤

我们针对启动慢的问题进行分析后,对两大挑战对症下药,主要的解决步骤如下。

1.完善监控体系

我们经过讨论总结后,面临两个选择,一个是基于开源的Skywalking等APM系统进行定制开发,存在的问题是现有工程师不熟悉该系统,短期内很难短时间补足相关知识等问题;二是采用成熟的APM系统,但这会带来较大的短期资金压力。鉴于我们项目的紧迫性,我们选择了方案二,引入了友盟+应用性能监控平台U-APM。

引入U-APM后,我们能对应用端进行非常详细的监控,比如下图的概览监控。结合U-APM的启动分析能力,我们第一次较为精确地明确了用户启动的耗时及分布。
移动APP启动慢解决实践_第1张图片

此外,我们还为服务端引入了ELK套件(ElasticSearch,Logstash,Kibana)和结构化日志,将关键代码路径参数及耗时等信息进行高效输出并汇聚展示。

2.加强代码质量管控

我们以前的代码开发过于注重速度,忽略了质量,虽然有CR(Code Review),但多流于形式,质量把控不严。我们借鉴业界工程效能最佳实践,对代码提交及评审打回率等关键指标进行监控并定期发出报表,对不合格的项目进行通报,并召开专题会议介绍代码质量提升实践。

3.动手解决

有了监控体系后,我们就拥有了明亮的眼睛去观察我们的系统。我们通过对量化后的耗时进行分析,初步判断出瓶颈所在,优先解决主要矛盾。理论上,每个请求都有优化空间,那是不是每个都需要优化呢?答案当然是否定的,因为服务间接口数以千计,如果消耗太多精力在非关键接口上,很容易事倍功半。我们采用的ROI(Return On Investment)的思想,优先解决耗时占比较大、请求频繁的函数调用以取得最大收益。具体来讲有如下几点。

1)安卓应用端问题

初次启动app耗时长,针对Application和Activity的同步内容进行优化,将核心内容页面尽快渲染返回给用户,使用异步任务加载耗时和非核心页面内容。安卓具体的api及原理,详见官网描述https://developer.android.goo...

2)服务端问题

通过监控,我们发现个别后端服务GC(Garbage Collection)频繁,隔一段时间就会导致Stop the World,引发耗时波动。我们通过对关键代码路径进行监控,结合内存使用情况等进行专项整治,发现问题主要是应用内的本地缓存使用不当导致,大量的临时缓存挤占内存引发了应用波动。

项目总结

在应用U-APM、丰富监控及代码质量提升后,该安卓APP的后期表现渐佳,用户的启动慢的吐槽量已经大幅减少。总的来说,安卓APP启动慢主要有两方面原因,一是APP自身在手机端的代码设计不够合理,常见的问题在官网均匀最佳实践https://developer.android.goo...;二是APP访问的后台服务质量存在优化空间。

针对安卓应用端的优化,Google也有许多实践案例,比如

移动APP启动慢解决实践_第2张图片

PLAY ALL

Android Performance Patterns

个人简介:

么广忠,开源技术爱好者,全栈研发工程师,参与过多个开源项目并主导过多款APP设计开发。

你可能感兴趣的:(appios)