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

为了便于阅读, 应邀将Android App性能优化系列, 转移到掘金原创上来.
掘金的新出的"收藏集"功能能够用来作系列文集了.性能优化

这篇咱们聊聊App启动的事儿.工具

1, 欲善其事, 先利其器

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

前文提到了不少工具, 今天咱们使用Traceview来分析咱们的启动过程.优化

1.1 Traceview介绍

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

指标说明:线程

  • 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 方法开始结束时间差(包括等待时间)
参考:stackoverflow.com/questions/1…code

1.2 Traceview使用

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

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

  • 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彻底启动.

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

  • 热启动
    热启动意味着你的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启动优化该怎么分析, 怎么作.请关注系列文~

相关文章
相关标签/搜索