移动应用端性能对用户体验有重要的影响,应用启动是用户的第一体验,也是整个app工序的第一道流程。对于我们开发者来说,应用启动过程中需要进行初始化工作以及启动页的UI展示。而对于用户来说,启动时间的长短则严重影响用户的使用体验,间接的影响了用户量。性能优化环环相扣,牵一发而动全身,这时借助友盟+u-apm工具,进行深度错误复现,精准定位问题所在,让我们通过这篇文章来了解一下。
一、今天就先来聊聊,启动速度的那些事
1、冷启动:
从点击应⽤图标到UI界⾯完全显示且⽤户可操作的全部过程。
特点:耗时最多,衡量标准
启动流程:Click Event -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle ->ViewRootImpl
2、热启动:
因为会从已有的应⽤进程启动,所以不会再创建和初始化Application,只会重新创建并初始化Activity。
特点:耗时较少
启动流程:LifeCycle -> ViewRootImpl
因此判断应⽤启动速度的的标准是冷启动的速度,即杀掉应⽤后重新启动的速度,此项主要是和你的竞品对⽐。
不应在 Application 以及 Activity 的⽣命周期回调中做任何费时操作,具体指标⼤概是你在 onCreate,onResume,onStart 等回调中所花费的总时间最好不要超过 400ms,否则⽤户在桌⾯点击你的应⽤图标后,将感觉到明显的卡顿。
二、冷启动分析及优化方向
冷启动涉及的相关任务
冷启动之前
1. ⾸先,会启动 App
2. 然后,加载空⽩ Window
3. 最后,创建进程
需要注意的是,这些都是系统的⾏为,⼀般情况下我们是⽆法直接⼲预的。
随后任务
1. ⾸先,创建 Application
2. 启动主线程
3. 创建 MainActivity
4. 加载布局
5. 布置屏幕
6. ⾸帧绘制
通常到了界⾯⾸帧绘制完成后,我们就可以认为启动已经结束了。
下⾯是官⽅⽂档中的启动过程流程图,显示系统进程和应⽤进程之间如何交接⼯作。实际上对启动流程的简要概括。
我们的优化⽅向就是 Application 和 Activity 的⽣命周期这个阶段,启动中的系统任务我们⽆法⼲预,能⼲预的就是在创建应⽤和创建 Activity 的过程中可能会出现的性能问题。这⼀过程具体就是:
Application 的 attachBaseContext
Application 的 onCreate
activity 的 onCreate
activity 的 onStart
activity 的 onResume
activity 的 onResume ⽅法完成后才开始⾸帧的绘制。所以这些⽅法中的耗时操作我们是要极⼒避免的。并且,通常情况下,⼀个应⽤的主⻚的数据是需要进⾏⽹络请求的,那么⽤户启动应⽤是希望快速进⼊主⻚以及看到主⻚数据,这也是我们计算启动结束时间的⼀个依据。
三、U-APM 在启动优化上的应⽤
以前使⽤友盟统计来分析 App ⽇活、埋点等数据,发现友盟推出的 U-APM,赶紧来尝尝鲜。
U-APM 是友盟+推出的 App 稳定性监控、性能监控和云真机测试平台。通过轻量级的集成接⼊即可拥有实时、可靠、全⾯的应⽤崩溃、ANR、⾃定义异常等捕获能⼒,及卡顿、启动分析等性能能⼒,⽀持多场景、多通道智能告警监控,帮助开发者⾼效还原异常、卡顿⽤户的访问路径和业务现场,缩短故障排查时间。就启动分析这项能⼒来看看, U-APM 都做了什么。
U-APM ⽀持启动趋势分析、慢启动分析、启动奔溃分析。
1、启动趋势分析
启动趋势较为直观的展示应⽤启动耗时的平均值、分位值、区间分布等数据,以及启动阶段的性能分解数据,也能分析出,多版本迭代后,启动时间的分布状况。
2、慢启动分析
有助于开发者追根溯源,该功能展示慢启动情况的占⽐以及慢启动设备列表,您可以在启动设置中⾃定义慢启动的划分,默认⾸次启动/冷启动超过3秒为慢启动,热启动超过1秒为慢启动。
冷启动阶段的慢启动分析,直观表现出慢启动⽐例以及慢启动平均耗时。
慢启动分布,直观表现出,慢启动分布的设备、系统、运营商、版本、渠道、地域。
3、启动崩溃分析
归纳启动阶段中出现的崩溃信息,⽀持划分⾸次启动、冷启动、热启动状态下的崩溃,默认启动耗时上限为8秒,超出时间的崩溃不被划分⾄启动崩溃。这对减少应⽤启动时间,提供了巨⼤帮助,官⽅已提供Demo,供开发者体验。
四、总结
移动端性能优化环环相扣,启动时间优化也是开发者不可避免的方面,有了友盟+u-apm的帮助,让优化工作大大方便起来,u-apm的出现是开发者的友好助手。u-apm还有其他功能,可以登录官方网站体验。