最近针对手上的项目做了一些Android App启动速度的优化，查阅了一些资料
影响启动速度的原因
高耗时任务
数据库初始化、某些第三方框架初始化、大文件读取、MultiDex加载等，导致CPU阻塞
复杂的View层级
使用的嵌套Layout过多，层级加深，导致View在渲染过程中，递归加深，占用CPU资源，影响Measure、Layout等方法的速度
类过于复杂
Java对象的创建也是需要一定时间的，如果一个类中结构特别复杂，new一个对象将消耗较高的资源，特别是一些单例的初始化，需要特别注意其中的结构
优化的案例如下：
Glide及其他框架
Glide是一个很好用的图片加载框架，除了常用的图片加载、缓存功能以外，Glide支持对网络层进行定制，比如换成OkHttp来支持HTTP 2.0。不过，如果在追求启动速度的情况下，在Splash页或主界面加载某一张图片时，往往是第一次使用Glide，由于Glide没有初始化，会导致这次图片加载的时间比较长（不管本地还是网络），特别是在其他操作也在同时抢占CPU资源的时候，慢的特别明显！而后面再使用Glide加载图片时，还是比较快的
解决方案：Application的onCreate方法中，在工作线程调用一次Glide.get(this)
@Override
public void onCreate() {
super.onCreate();
new Thread(new Runnable() {
@Override
public void run() {
Glide.get(BaseApplication.this);
}
}).start();View和主题
View层级
主要在于首屏/Splash页的Layout布局层次过深，导致View在渲染时，递归加深，消耗过多的CPU和内存资源，阻塞主线程，所以最根本的思路就是解决层级问题，检查一个App的View层级，可以使用Android Studio自带的Layout Inspector工具，如图：
在选择了需要检查的进程及Window（Dialog可能会创建新的Window，但显示的Activity是同一个）以后，就可以看到Android Studio自动进行的Capture的内容了
根据左边View层级显示的内容，分析不必要的嵌套布局，通过改造，即可对View层级进行优化
当然优化布局文件外；我们还可以通过代码构建控件，由于加载解析xml文件也是耗时的
App主题
如果想提高APP的启动速度，尤其是使用Splash的App，务必将第一个Activity的主题设为FullScreen的，这样能有效提高启动速度；启动一个Activity的时候，系统会创建包含一个DecorView的Window，而StatusBar也好，ActionBar也好，都是这个View中的子元素，多了一个View，当然多了一层布局，肯定是耗时的
进一步优化
某些APP，如：微博，能够做到点了图标就立即做出响应，显示出它的Splash页
apktool一下微博的apk，可以发现微博对首页的主题背景，使用了一个drawable来实现
<!-- styles.xml -->
<style name="NormalSplash" parent="@android:style/Theme">
<item name="android:windowBackground">@drawable/welcome_layler_drawable</item>
<item name="android:windowNoTitle">true</item>
<item name="android:windowContentOverlay">@null</item>
<item name="android:scrollbarThumbVertical">@drawable/global_scroll_thumb</item>
<item name="android:windowAnimationStyle">@style/MyAnimationActivity</item>
</style>
<!-- welcome_layler_drawable.xml -->
<?xml version="1.0" encoding="utf-8"?>
<layer-list
xmlns:android="http://schemas.android.com/apk/res/android">
<item android:id="@id/welcome_background" android:drawable="@drawable/welcome_android" />
<item android:bottom="@dimen/login_icon_padding_bottom">
<bitmap android:gravity="bottom|center" android:src="@drawable/welcome_android_logo" />
</item>
<item android:top="@dimen/splash_slogan_margin_top">
<bitmap android:gravity="center|top" android:src="@drawable/welcome_android_slogan" />
</item>
<item android:top="20.0dip" android:right="20.0dip">
<bitmap android:gravity="center|right|top" android:src="@drawable/channel_logo" />
</item>
</layer-list>
由此可见，使用layer-list的形式，可以使一系列的Bitmap按照类似View布局的形式来排布，通过将生成的drawable设置为background的形式，最终并不会生成任何View，极大程度减小View绘制占用的时间，提升启动速度！
对于多线程的思考
在App启动时，为了加快启动速度，通常会使用多线程手段来并行执行任务，充分发挥多核CPU的优势，提高运算效率。此方法固然能够对启动速度的优化，起到一定作用，但实际开发中，有以下几点值得深思：
并发的线程数，多少合适？（效率高但不至于阻塞）
频繁切换线程，是否带来负面影响？（频繁地从主线程扔进辅助线程操作再将结果抛回来会不会比直接执行更慢）
何时并行？何时串行？（有的任务能只能串，有的任务可以并行）
这个时候，拿Android经典的AsyncTask类来说事，再合适不过了！
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
// We want at least 2 threads and at most 4 threads in the core pool,
// preferring to have 1 less than the CPU count to avoid saturating
// the CPU with background work
private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1;
上面的代码是AsyncTask确定线程池数量的部分，其中，核心执行池保证最少2个线程，最多不超过CPU可用核数-1，最大线程池数量为CPU核数的2倍+1
这样配置线程池的目的很简单：防止并发过大，导致CPU阻塞，影响效率
