0%

App启动优化实战

最近在做App启动优化,参考了一些文章,就最近做的一些事做一个总结输出。

1.重要性

比如正常App在启动性能很好能提高首页的曝光和点击,提高转化率。还比如扫码支付,微信和支付宝的打开时间就会影响用户的使用和留存。

2 启动分析

首先我们需要分析App启动过程中的几个阶段。

2.1 启动过程

  • 首先是点击图标,创建App进程。
  • Application的创建。
  • 闪屏Activity的创建。
  • 首页数据渲染

2.2 启动问题分析

1 启动任务耗时分析

1)通过日志方式输出启动任务耗时,发现初步的耗时任务进行优化。

启动任务耗时log

2)在解决初步明显的问题后,需要对任务进行精确分析,这个时候就需要采用工具统计方法耗。

  • Traceview 可以获取方法的调用堆栈;

  • systrace 可以很方便地追踪关键系统调用的耗时情况,但是不支持应用程序代码的耗时分析;

只有准确的数据评估才能指引优化的方向,这一步是非常非常重要的。我见过太多同学在没有充分评估或者评估使用了错误的方法,最终得到了错误的方向。辛辛苦苦一两个月,最后发现根本达不到预期的效果。

Traceview的方式有两种

  • 方式一: 通过Android Studio Profile 开启启动trace method,开启后run app你会发现巨卡,而且出来的app method数据非常不准。另外release 版本没办法跑profile。

    open_android_studio_trace_method

  • 方式二: 通过java 代码进行trace method ,而且这种方式可以跑release模式。在app 启动到首页数据渲染完成分别埋点, stop后会生成一个trace文件,在 sdcard/App/包名/file文件下面。导出文件到电脑使用Android Studio Profile文件打开。

    1
    2
    3
    Debug.startMethodTracingSampling(traceName, 0, sampleInterval);

    Debug.stopMethodTracing();

通过trace文件分析启动方法耗时。

app_start_trace

对于一些隐藏的逻辑、主线程解析网络数据也可以分析出来

data_accept

2 启动任务打散

结合Systrace可以查看cpu和iO的使用信息。

CPU duration xx ms,wall duration xxx ms!大量的等待执行时间。

systemtrace

trace_data

将启动任务分为多个阶段,找到那些让系统高负载的模块,再打散到各个时间点去,错峰运行。

1)启动到首页渲染完成

2)渲染完成后

3)闲时
app_start_sq

3 启动任务依赖

任务ABC,其中BC依赖A, 当不编排的时候BC执行都需要等待A,有个任务线程是空等待的,其实可以先初始化A,再初始化BC。

启动依赖图

那有时候不明显的依赖关系如何排查。其实也可以通过trace method, trace会统计出所有线程的执行堆栈、对于不同线程执行重复的堆栈可以判断为重复依赖。

启动框架设计

4 数据预处理

简单说下背景。首页现有的逻辑:

  • 加载打底数据;

  • 请求网络数据,请求回来,再次刷新界面。

加载打底数据是为了防止白屏;但是打底数据上屏之后,又会发起网络请求,有新数据下来后,重新刷新界面,就是我们常说的二刷,二刷很影响实际的用户体验,相信大家都深有感触。

5 其他

二进制重排
首页和welcome页面合并

3 总结

其实个人认为把基础技术和业务优化好能解决99%的问题。我们最终的优化数据。
trace_data