Android App优化之提升你的App启动速度之理论基础

系列文:

  1. 背景:Android App优化, 要怎么做?
  2. Android App优化之性能分析工具
  3. Android App优化之提升你的App启动速度之理论基础
  4. Android App优化之提升你的App启动速度之实例挑战
  5. Android App优化之Layout怎么摆
  6. Android App优化之ANR详解
  7. Android App优化之消除卡顿
  8. Android App优化之内存优化
  9. Android App优化之持久电量
  10. Android App优化之如何高效网络请求

1, 欲善其事, 先利其器

论语有云: 工欲善其事,必先利其器. 要想提升App的启动速度, 我们需要先找到拖后腿的点, 要想找到这些点, 我们就需要借助我们的工具了.

前文提到了很多工具, 今天我们使用Traceview来分析我们的启动过程.

1.1 Traceview介绍

Traceview是一个性能分析工具, 主要是分析当前线程情况, 各个方法执行时间等. 如下:

traceview

指标说明:

  • Incl(Inclusive) Cpu Time
    方法本身和其调用的所有子方法占用CPU时间.
  • Excl(Exclusive) Cpu Time
    方法本身占用CPU时间.
  • Incl Real Time
    方法(包含子方法)开始到结束用时.
  • Excl Real Time
    方法本身开始到结束用时.
  • Call + Recursion Calls/Total
    方法被调用次数 + 方法被递归调用次数.
  • Cpu Time/Call
    方法调用一次占用CPU时间.
  • Real Time/Call
    方法调用一次实际执行时间.

一般来说, 我们使用Real Time/Call排序来找出耗时多的方法

有必要解释下CPU Time和Real Time:
CPU Time 方法实际执行时间(不包括io等待时间)
Real Time 方法开始结束时间差(包括等待时间)
参考:http://stackoverflow.com/questions/15760447/what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re/17902682#17902682

1.2 Traceview使用

有两种方式来使用Traceview:
1, 通过DDMS:


start traceview

点击开始时会弹出一个选择trace模式的框, 默认选中"Sample based profiling"即可:

traceview option
  • Sample based profiling(基于样本分析)
    根据采样时间间隔来规律的打断VM来记录方法调用栈(Call Stack), 开销和采样频率成比例.

  • Trace based profiling(基于完整trace数据分析)
    记录每个方法的出入口, 每个方法执行时都开启记录, 无论多小的方法, 因此开销很大.

2, 使用代码:

// 在自己想要开始调试的地方start
Debug.startMethodTracing("GithubApp");

// 在合适的地方stop
Debug.stopMethodTracing();

注: 以上方法开启trace的方式相当于"Trace based profiling", 会记录每个方法的执行. Android 4.4及以上可以调用startMethodTracingSampling()来用代码开启"Sample based profiling"的trace方式.

2, App启动流程分析

要想优化App启动流程, 必先了解其启动过程.
具体过程请参看这篇译文: Android Application启动流程分析.

3, App启动方式

通常来说, 一个App启动也会分如下三中不同的状态:

  • 冷启动
    App没有启动过或App进程被killed, 系统中不存在该App进程, 此时启动App即为冷启动.
    冷启动的流程即为第2节所描述的App启动流程的全过程, 需要创建App进程, 加载相关资源, 启动Main Thread, 初始化首屏Activity等.

    在这个过程中, 屏幕会显示一个空白的窗口(颜色基于主题), 直至首屏Activity完全启动.

    下图展示了冷启动的时间线:


    code start
  • 热启动
    热启动意味着你的App进程只是处于后台, 系统只是将其从后台带到前台, 展示给用户.

    类同与冷启动, 在这个过程中, 屏幕会显示一个空白的窗口(颜色基于主题), 直至activity渲染完毕.

  • 温启动
    介于冷启动和热启动之间, 一般来说在以下两种情况下发生:

    • 用户back退出了App, 然后又启动. App进程可能还在运行, 但是activity需要重建.
    • 用户退出App后, 系统可能由于内存原因将App杀死, 进程和activity都需要重启, 但是可以在onCreate中将被动杀死锁保存的状态(saved instance state)恢复.

通过三种启动状态的相关描述, 可以看出我们要做的启动优化其实就是针对冷启动. 热启动和温启动都相对较快.

4, 哪些地方是App快速启动的敌人

根据冷启动的时间图, 可以看出, 对于App来说, 我们可以控制的启动时间线的点无外乎:

  • Application的onCreate
  • 首屏Activity的渲染

而我们现在的App动不动集成了很多第三方服务, 启动时需要检查广告, 注册状态等等一系列接口都是在Application的onCreate或是首屏的onCreate中做的.

很多第三方平台的SDK文档也都是这么建议的.

5, 结语

明白了App的启动原理, 也知道了App启动过程中哪些地方容易阻塞, 还知道了用什么工具来分析每个方法的执行时间, 那么接下来就很容易做了.

下一篇将完全以实例的方式来说明App启动优化该怎么分析, 怎么做.
请关注系列文~

推荐阅读更多精彩内容