Android性能优化——启动优化

矫情吗；* 2024-03-17 22:14 24阅读 0赞

App 的启动速度是用户的第一体验，互联网中有一个八秒定律，如果用户等待八秒App 还没打开，70%的用户都会停止等待

## 一、启动分类 ##

官方 App startup time

*  **冷启动**

耗时最多，衡量标准

*  **热启动**

最快。 后台～前台

*  **温启动**

较快。只会重走activity的生命周期，不会走进程的创建以及Application的创建和生命周期

##### 冷启动流程 #####

1.  用户点击
2.  触发IPC 操作
3.  Process.start 进程创建
4.  ActivityThread 是每个单独进程的入口，会有一个main方法，进行消息循环的创建以及handler的创建
5.  bindApplication 通过反射创建Application 以及调用application的生命周期
6.  Activity 的生命周期 LifeCycle
7.  ViewRootImpl 开始真正的界面绘制

> **冷启动之前(这个过程无法干预)**
> 
>  *  启动App
>  *  加载空白Window
>  *  创建进程
> 
> **随后任务**
> 
>  *  创建Application
>  *  启动主线程
>  *  创建MainActivity
>  *  加载布局
>  *  布置屏幕
>  *  首帧绘制
> 
> **优化方向**  
> Application 和Activity 的生命周期

## 二、启动时间的测量方式 ##

> #### adb 命令方式 ####
> 
> #### adb shell am start -W packagename/首屏Activity ####
> 
> 特点：
> 
>  *  线下使用方便，不能带到线上
>  *  非严谨，精确时间
> 
> **手动打点方式**  
> 启动时埋点，启动结束埋点，二者差值  
> 特点：
> 
> 精确，可带到线上，推荐使用
> 
> 避开误区
> 
>  *  启动时间开始的位置在application 中的attachBaseContext
>  *  启动时间结束的位置采用采用Feed 第一条展示
>  *  addOnDrawListener 要求Api 16

> **ThisTime 最后一个Activity启动耗时  
> TotalTime 所有Activity 的启动耗时  
> WaitTime AMS启动Activity 的总耗时**

## 三、启动优化使用到的工具 ##

**traceview，systrace**

*  两种工具互相补充
 *  正确认识工具及不同场景选择合适的工具

traceview

*  优点
    
     *  图形的形式，展示代码执行的时间，调用栈信息等
     *  信息全面，包含所有线程信息
 *  使用方式

> Debug.startMethodTracing(“文件名”)；默认8M大小，如果想要更大，传参bufferSize  
> Debug.stopMethodTracing() 结束  
> 就会生成一个文件，位置在sd卡 ：Android/data/packagename/files

在Android Studio 右边有一个Devices File Explorer 可以很方便的打开手机系统的文件  
添加开启和结束的代码后，然后运行，在存储的位置下，刷新，会生成一个设置的文件名.trace 文件

*  如何分析
 *  ![7b4deb88f2d34c00b9887460c8756f7f.png][]
    
     *  左上是通过代码精确指定的时间范围，左下角有个时间搓，不是特别重要
     *  左下是线程信息，可以看到线程的总数，也可以看到每个线程在具体的时间做了哪些事

右边有四个Tab

>  *  Top Down
> 
> total：总时间
> 
> self :
> 
> children：
> 
> 举例：调用了A函数，整体时间是total，在A函数中调用了一行代码，然后执行B函数，它的selfTime是执行了一行代码的时间，childrenTime就是B函数执行的时间，selfTime和childrenTime之和一定等于totalTime
> 
> 函数的调用列表，点击相应的jump to souse 可以跳入详细的代码中
> 
> **ThreadTime** 一定会变少，CPU执行的时间  
> **Wall Clock Time** 代码发生在这个线程上，真正执行的时间
> 
>  *  Call chat
> 
> 每一行显示的是函数调用的时间段，垂直方法被调用着  
> 系统Api 调用颜色是橙色  
> 应用自身的函数调用是绿色  
> 第三方Api 调用是蓝色
> 
>  *  Flame chat 火焰图
> 
> 倒置的调用图表，会收集相同的调用顺序
> 
>  *  Bottom up
> 
> 谁调用了我，和Top down 是相反的
> 
> **总结：**  
> 运行时开销严重，整体都会变慢这个工具太强大了，会抓去所有线程的所有执行函数以及顺序  
> 可能会带偏优化方向  
> traceview 和cpu profiler  
> traceview 的好处可以在代码中进行埋点，用cpu profiler 进行分析  
> 单纯的用cpu profiler 来抓取精确的启动位置，几乎不可能

systrace

结合Android内核的数据生成html 报告  
Python脚本

>  *  使用方式
> 
> • python systrace.py -t 10 \[other-options\] \[categories\]
> 
>  *  官方文档：
> 
> https://developer.android.com/studio/command-line/systrace\#command\_options
> 
>  *  使用案例
> 
> python /Users/Liuzhao.Future/Library/Android/sdk/platform-tools/ systrace/systrace.py -b 32768 -t 5 -a com.optimize.performance -o performance. html sched gf view wm am app
> 
>  *  代码中使用
> 
> 开启：TraceCompat.beginSection(“apponCreate ”)  
> 结束：TraceCompat.endSection
> 
>  *  分析html 文件
> 
> CPU核数跟不同手机是有关系的，有些手机厂商8个核都给你，有的手机8核，但是只给你使用4核
> 
>  *  **总结：**
>     
>      *  轻量级，开销小，埋了哪一点就去做哪一点
>      *  直观反映CPU利用率

cpuTime 和 wallTime

*  wallTime 是代码执行的时间
 *  cpuTime 是代码消耗CPU的时间(重点指标)

> 举例：为什么两者会不一样  
> 锁冲突，比如一个线程执行需要获取锁A，但是锁A被其他线程持有，没有得到释放，而这个线程是一个轻量级的，只占用了cpu 一点时间，所以这个时候cpuTime 就会很短，而wallTime 很长

## 四、如何优雅的获取CPU耗时 ##

需要知道具体哪个方法占用了大量时间

*  常规方式：手动埋点
    
     *  侵入性强
     *  工作量大
 *  AOP方式：Aspect Oriented Programming ，面向切面编程
    
     *  针对同一类问题的统一处理
     *  无侵入添加代码

> Aspect使用
> 
>  *  classpath 'com.hujiang.aspectjx:gradle-android-plugin-aspectjx:2.0.0'
>  *  implementation 'org.aspectjaspectjrt:1.8.+'
>  *  apply plugin: 'android-aspectix'
> 
> 介绍
> 
>  *  Join Points
>     
>      *  程序运行时的执行点 ，可以作为切面的地方
>      *  函数调用、执行
>      *  获取、设置变量
>      *  类初始化
>  *  PointCut
>     
>      *  带条件的JoinPoints
>  *  Advice
>     
>      *  一种Hook，要插入代码的位置
>      *  Before : PointCut之前执行
>      *  After :PointCut之后执行
>      *  Around: Pointcut之前、之后分别执行
>  *  语法简介
>     
>         //Before：Advice，具体插入位置
>         //execution ：处理Join Point的类型
>         //(* android.app.Activity.on**(.))：匹配规则
>         @Before("execution(* android.app.Activity.on** (.))") 
>         public void onActivityCalled (JoinPoint joinPoint) thr
>         ows Throwable {
>             ……
>         }
>  *  使用案例
> 
>     @Aspect
>     public class Performanceaop{
>     
>         Around("call(*com.optimize.performance.PerformanceApp.**(..))") 
>         public void getTime(ProceedingJoinPointjoinPoint){
>             Signature signature=joinPoint.getSignature(); 
>             String name=signaturetoShortString(); 
>             long time=System.currentTimeMillis(); 
>             try {
>                 joinPoint.proceed();
>             } catch(Throwable throwable){
>                 throwable.printStackTrace();
>             }
>             LogUtils.i(msg:name+" cost "+(System.currentTimeMillis() - time));
>         }
>     }
> 
>  *  优点
>     
>      *  无侵入性
>      *  修改方便

## 五、异步优化 ##

*  常规异步优化：使用线程池进行异步优化
 *  启动器（异步启动优化的最优解）

> 常规异步方式
> 
> 常规异步方式需要注意点：
> 
>  *  并不是所有的代码都可以直接异步
> 
> 1.  不符合异步要求：有的任务必须在主线程中执行
> 2.  需要在某阶段完成，在splash界面就要用到异步任务，在执行界面的时候，异步任务还没完成某一些代码必须在某一个阶段完成，解决方案：CountDownLatch 相当于自己加了个锁
> 3.  区分CPU 密集型还是IO密集型任务
> 
> 常规异步方案痛点：
> 
>  *  代码不够优雅
>  *  场景不好处理(依赖关系)，在特定的时间内结束某个任务
>  *  维护成本高
> 
> 启动器方式
> 
> 核心思想：  
> 充分利用CPU 多核，自动梳理任务顺序  
> 启动器流程：
> 
>  *  代码Task化，启动逻辑抽象为Task
>  *  根据所有任务的依赖关系生成一个有向无环图
>  *  多线程按照排序后的优先级依次执行

## 六、延迟初始化 ##

*  常规方案：handler.postDelay
 *  更优方案：对延迟任务进行分批初始化

> 常规方案的问题：
> 
>  *  时机不便控制
>  *  导致Feed卡顿
> 
> 更优方案的优点：利用了IdleHandler特性，空闲执行
> 
>  *  执行时间明确
>  *  缓解Feed卡顿

## 七、总结：启动优化总方针 ##

*  异步 ，延迟，懒加载
 *  技术和业务相结合

## 八、注意事项 ##

*  收敛启动代码修改权限
 *  结合Ci修改启动代码需要Review 或 通知

## 九、其它方案 ##

*  提前加载SharedPreferences

在multidex之前加载，充分利用此阶段CPU  
覆写getApplicationContext返回this

*  启动阶段不启动子进程

子进程会共享CPU资源，导致主进程CPU 紧张  
注意启动顺序，App onCreate 之前是ContentProvider