结论：加载时间从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%）