App启动速度优化

一： App启动方式

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

    1.  冷启动
    App没有启动过或App进程被killed, 总之是系统中不存在该App进程, 此时启动App即为冷启动。

• 冷启动的流程即是App启动流程的全过程, 需要创建App进程, 加载相关资源, 启动Main Thread, 初始化首屏Activity等.

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

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

   

  

  2. 热启动

• 当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动, 系统只是将其从后台带到前台, 展示给用户.

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

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

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

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

二. 哪些地方是App快速启动的敌人

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

• Application的onCreate
• 首屏Activity的渲染

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

三：分析工具Traceview

3.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 方法开始结束时间差(包括等待时间)

3.2 Traceview使用

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