App启动优化调研及方案

序言

我目前任职于一家专做服装批发的互联网公司,做的APP叫做一手APP用户量在千万级,日活在20万左右月流水上亿。但目前App的启动耗时较久,启动过渡动画等体验较差。所以,专门对启动优化方面做了调研,并输出调研方案和解决方案。优化前后也有对比图输出,详见第2大点第3小点,优化效果立秆见影。但这只是启动优化的第一阶段,以及整个性能优化系列的某一个知识面,后续还会继续深入做优化。

一、 启动优化的作用。

启动时间过久,会影响新老用户体验。

  1. 新用户。降低新用户的留存率和应用评分。
  2. 老用户。对老用户的使用造成烦扰,用户使用频率越高,影响程度越重。
二、商城App与主流/竞品App的启动对比。
  1. 测试机型:荣耀v20,无后台应用。(不同机型与使用状况,会影响启动时间)
  2. 测试方式Logcat过滤Displayed值,多次打开取平均值
  3. 启动耗时对比

在这里插入图片描述

  1. 测试总结
  • 一手App在启动时间上,与竞品批批网不相上下。但比竞品蘑菇街的启动时间大了1倍有余。比主流App,微信、饿了么等,也多了不止1秒。
  • 批批网和蘑菇街,双击返回键,退出应用程序时,没有直接杀死应用。而一手App,直接杀应用。
  • 批批网,再次打开时,优先展示了闪屏页,用时在150ms左右。
  • 蘑菇街,再次打开时,因为之前只是退入后台,用时0ms。
  • 一手App,等同于冷启动的时间。
三、 一手启动现状分析。
  1. 冷启动。
  • Release模式下,启动时间,+1s686ms ~ +2s127ms
  • Debug 模式下,启动时间, 在4s500ms左右。其中,application初始化各工具、SDK占用时长约为1s500ms。闪屏页,占用时长约为1s。这两部分,在当前模式下,理论最大化可降低时长为2.5s。粗略猜测,按折半算,在Release模式下,可减少时长约为1250ms。则冷启动时长,可降低到1s以下。
  1. 基于第1条,进行实测。Release下注释掉application初始化、闪屏页的onCreate()部分:
    启动时间,大幅降低:+1s800ms ----> +398ms

  2. 双击退出优化:参考蘑菇街、批批网的处理方式,可极大的提高APP在短时启动的响应速度。

四、启动优化的目标。

因为启动优化工作,不易处理,但易于影响到现有功能。因此,在目标制定上,应采取先稳后快的思路。优先保稳,尽量做到在优化后,不影响到现有功能。所以,预计按如下目标推进。

  • Lancher 点击到 Splash打开 做到秒开。
  • splash到 主页打开可操作 能继续减少(待定,看业务)
五、从Launcher到App启动(简述)。

了解应用是如何启动,将有助于我们对应用启动的优化工作。我们的安卓手机桌面,叫Launcher,它实际上也是一个应用。当我们点击桌面上的应用icon时, Launcher会开始执行应用启动,流程简述如下:

  1. Launcher在Launcher进程负责将启动应用的请求转发给AMS。
  2. AMS在SystemSever进程负责安全检查、启动应用的参数封装、通知Zygote进程创建应用进程、转发启动应用请求(并携带启动应用所需的参数)给应用进程。
  3. ActivityThread在应用进程,用AMS传过来的参数,启动根Activity,此时应用已被启动,对用户可见。
六、App的启动状态。
  • 冷启动
  • 系统进程。
  1. 加载并启动应用。
  2. 立即启动一个空白window。
  3. 创建应用进程。
  • 应用进程。
  1. 创建应用对象。
  2. 创建应用的UI(主)线程。
  3. 创建main activity。
  4. 加载main activity的view。(onCreate)
  5. 测试布局。(onMessure/onLayout)
  6. 执行main activity的view的绘制。(onDraw)
  • 冷启动,测验方法。(-S表示如果APP在运行,则杀死APP,再启动)
  1. 采用上文说的,过滤logcat。
  2. 测验SplashActivity的冷启动耗时,可以在AS的Terminal执行以下命令:
    adbshell am start –S –W com.yishouapp.fumi/.activity.SplashActivity
    这里是以商城app为例,并且已将SplashActivity在AndroidManifest.xml里面
    配置成启动页,才可以生效。
  3. 在Ternimal窗口会显示启动状态、耗时等信息。
    在这里插入图片描述
  • 热启动
    将应用进入后台,数据还保存在内存中。此时,再启动应用。应用会从后台被拉到前台,省去了冷启动时的一系列操作,启动时间大幅减少。(PS:可用内存过低时,部分数据可能会被回收,热启动时,会被重新创建,但启动时间仍然明显低于冷启动)

  • 测验SplashActivity的热启动耗时,需要2步。(结果查看,同冷启动)

  1. 先打开商城app,停留在SplashActivity页面,并将APP退入后台。
  2. 在AS的Terminal执行以下命令:
    adb shell am start –W com.yishouapp.fumi/.activity.SplashActivity
    这里是以商城app为例,并且安装了商城app,并且将SplashActivity在AndroidManifest.xml里面配置成启
    动页,才可以生效。
  • 温启动
    温启动,是介于冷启动与热启动之间。比冷启动快,但比热启动慢。温启动的场景,举个例子,当你双击返回退出应用后,又马上启动它。这时候,应用进程还在,但其它数据都被销毁了。这时候,应用必须重新创建所有activity的资源,相当于重新走一遍onCreate。亦或是系统杀死了你的应用进程,但应用的数据保存在instanceStateBundle对象里面,且未被销毁。在重新创建应用时,可以利用这个对象,快速的恢复界面。但复现温启动的场景比较困难,暂时没有发现可复现步骤。

    温启动的2种场景简述。
    1)应用进程没了,但数据还在。
    2)数据没了,应用进程还在。

七、优化方案。
  1. 延迟第三方SDK的初始化。(初始化是否一定要在UI线程?)
  2. 延迟非必要资源的加载,包括网络请求。
  3. 启动页的UI绘制优化、线程调度优化、GC优化。
  4. 提高应用的保活度,避免冷启动。
  5. 重点优化Application和第一个Activity,两个类的onCreate方法。
  6. 子线程式初始化SDK,这种方式,有两个注意点,一个是要确保SDK是可以在子线程初始化。另一个是要确保在使用SDK的功能前,SDK已经完成初始化,因为子线程式的初始化,是一个异步操作。
八、优化工具。
  1. Redex. (存在风险)
九、调试辅助。

为了真实的模拟启动时间,建议在release模式下进行,但release模式下,打包速度会极慢。建议,在gradle里面,加入关闭代码检查task,二次编译时,可以极大的减少编译时间。我测试出来的效果(编译时长):4m500s —> 2m。

 tasks.whenTaskAdded { task ->
    if (task.name == "lintVitalPpRelease") {
         task.enabled = false
      }
 }
十、参考资料。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值