Activity启动速度极限优化

结论：加载时间从436ms-->96ms(优化率78%)

github: https://github.com/long8313002/ActivityOptimization

 

 

概述

        本文主要是和大家探讨一下，极限减少页面加载耗时的可能性，在这里我们尽量追求方案的通用。而本文论述的方案，非互联网上的主流方案，独此一家，先到先得！

 

 

 

主流方案

       本文不会花太多篇幅讨论这些主流方案，另外这些方案在百度也很容易可以找到，不过这些方案也都有一个共同的特点，它们不是很通用，需要针对具体的业务具体进行分析。我所知道的主流方案如下：

• 主线程避免耗时操作、建议异步化（异步化也会导致业务复杂度提高）
  • 优化页面布局，减少多层嵌套、提高扁平度（难度大、收益低）
  • 延迟加载不必要元素（大多数页面都没有懒加载条件）
  • 避免过多的线程、推荐线程池
  • 优化xml布局解析过程中反射创建View的耗时（略黑科技、通过复写onCreateView来实现手动创建View，减少了反射的耗时，实测效果微乎其微，现在反射已经很快了）

 

 

 

耗时分析

        我们一起来分析下页面加载耗时，因为我们讨论的是一个通用方案，所以我们定义一个存加载布局的页面，没有任何业务逻辑（业务逻辑导致的加载耗时属于漏洞）。首先，我们先写一个巨复杂的XML（4000行）：

 

现在我们需要拿到，页面加载各个地方耗时的数据，测试代码如下：

 

 

       当第一帧开始绘制，我们算Activity的加载结束，因为onDrawListener在绘制前会被调用，所以这种统计方式会忽略掉绘制耗时，具体数据如下：

 

 

 

 

针对过程优化

 

 

创建过程

通过数据可以看出来，布局创建是最耗时的阶段（291ms），占比总耗时66%，创建阶段主要耗时的有这几个步骤：io读取xml、解析xml、创建视图对象。

 

优化逻辑：采用异步预加载的方式、先在子线程创建好视图，当使用的时候可以省去加载解析xml的时间：

 

 

优化后数据如下：

 

结论：

 

优化结果：布局创建时间从291ms--->4ms（优化率99%）

总加载时间从436-->163（优化率63%）

 

 

 

测量过程

测量过程耗时占比也比较客观，有43ms之多（26%），虽然“准备时间”的耗时多于测量，但是这部分主要是WMS和ViewRootImpl之间通信的消耗，我们无法直接进行优化。

 

优化逻辑：采用异步预先测量的方式进行优化，因为视图在进行过测量后有自己的缓存机制，这部分可提前构建缓存来进行优化。

 

android源码（View.measure）

 

优化代码

 

 

优化后数据

 

 

结论

 

优化结果：布局测量时间从47ms--->10ms（优化率80%）

总加载时间从163ms-->96ms（优化率42%）

本文地址：https://blog.csdn.net/long8313002/article/details/108470737