app的启动流程非常的复杂,能真正搞懂又可以给别人讲明白的很少，作为开发来讲，我们以app启动开始，看那些是可以进行优化的，启动流程就用一张简单的流程图来替代，因为我们的重点是在于启动优化,目的是如何可以让用户更快速的打开页面,有更极致的用户体验。
这张图画的比较简单，但是也可以反映一定的问题。第一点app启动过程中首先要绑定Application，回到application的生命中期，然后在通过消息机制和反射创建activity，从而加载activity的各个生命周期方法，oncreate---->onreusume----->onPause-----onStop-----onDestory等,真正对于用户来讲view可见是在onresume的生命周期中实现的。为什么？可以看下activity的源码，虽然是在oncrate中通过LayoutInflater创建了布局,单并不是可见的。那么作为开发来讲,如何提高页面的加载速度就是一个可以优化的关键点。从上述分析中至少我们可以的到两点。
- 绑定application的时候比较耗时.
- 布局解析是件耗时的事儿.
- 通常app加载的时候回首先加载启动activity,然后再跳转到main,这个过程实际上走了两个activity的生命周期
那么针对以上三点我们就可以对app进行优化处理。其中核心的就是减少耗时操作。但是耗时操作能不能不进行呢？这显然是不行的，因为涉及到很多的初始化操作。那么现在给出优化意见。
- 本Application的onCreate中减少耗时操作，从而减少主线程的执行时间，其中比较重要的是减少io的耗时操作。所有的io操作都涉及到了文件的读和写,相对于代码的执行来说，io操作是非常耗时的。所以可以在Application中开启服务或者子线程来初始化一些必要的操作。
- xml布局文件是通过Layoutinflater加载的,其内部本质上就是根据标签tag进行的xml解析操作。简单点，为什么说我们的布局文件可以在activity中显示,根本原理就是个xml文件解析。所以，xml文件大小和布局层次觉得了整个layout文件的渲染时间，所以不要把所有的功能放到一个activity中完成，布局文件层次不可嵌套太多，最多不应超过3层。
- 欢迎页可以用一个fragment来代替，将欢迎页的activity与main合为一个，减少activity的创建和生命周期的执行。
前两条实现比较简单，就不浪费篇幅去描述了，看下第三条，这里我们使用ViewStub来延迟加载布局,已达到两个activity合二为一的效果。使用viewstub主要作用就是解决android的布局嵌套问题，通过viewstub的inflate()方法来延迟加载布局，viewstub空间在布局中不占位置，解析布局的时候不会讲viewstub中的layout加载进去，这样就真正意义上的讲两个布局融合为一了，当然，不能使用传统的方式，通过hander延迟加载viewstub中的布局，这样不能真正意义上做到延迟加载，延迟时间会减小。例如：通过hander延迟2s加载两一个布局，从oncreate到onresume是耗时的，这样延迟加载的时间必然会小于2s。所以这里我们可以使用view的延迟加载方法，只有你想不到，没有android做不到的。基本上所有的事儿，google工程师们都给你做了。
//view渲染完之后立即执行
getWindow().getDecorView().post(new Runnable() {
@Override
public void run() {
viewStub.inflate();
hander.sendEmptyMessageDelayed(1, 2000);
}
});上面的代码很容易就看明白，在view渲染完毕之后，调用viewstub中的inflate延迟加载布局，其实后面还有我项目中的一步操作，2s后移除开屏图片。这样就真的做到布局的融合，启动效率也是最高的。
adb shell am start -w packageName/packageName.LuchAty
这个命令可以查看app的启动时间。自己做过的demo启动时间优化后,较之前速度可以提高百分之10左右。之后我会上传demo。