前言

今天想停下代码，写点脑袋里不断浮现出来的一些看法。

也就是最近在微博和知乎上老看到“互联网寒冬”的说法。要么是看到啥公司薪水无法如期发放了，要么是看到别人说什么“裁员了，没有交接，签字然后电脑还了就走人，不到1小时”。在临近年关的时候，这种消息总是格外充满寒意，让人有一种唇亡齿寒的感受。

启动模式

要准确的测量APP的启动时间，首先我们要了解APP整个启动过程。启动过程，一般可以分为以下三类：

爱奇艺Android客户端启动优化与分析

从上图可以看出，启动过程中，Cold的模式下，生命周期中做的事情最多，启动的时间最长，因此，我们以冷启动来衡量APP启动时间。启动过程中，如何判断哪些生命周期影响启动速度呢？

启动过程

我们知道，APP的启动和运行，就是Linux系统创建进程和组件对象，并在UI线程中处理组件消息的过程。

启动过程图:

App的启动过程，可以划分为三个阶段:

3.1 创建进程

当APP启动时，如果当前app的进程不存在，便会创建新的进程；App主进程启动后，如果启动某个组件，并且该组件设置了android:process属性，组件所运行的进程不存在，也会创建新的进程。

需要注意的是，如果在启动阶段，初始化的组件中，包含了多个进程，便会创建多次进程，BindApplication操作也会重复执行多次

3.2 创建UI线程及Handler

进程创建后，会通过反射，执行ActivityThread入口函数,创建Handler，并在当前线程中prepareMainLooper,并在Handler中接收组件的消息，我们来看一下Handler中处理的消息：

LAUNCH_ACTIVITY,启动，执行Activity
RESUME_ACTIVITY,恢复Activity
BIND_APPLICATION,启动app
BIND_SERVICE,Service创建, onBind
LOW_MEMORY,内存不足，回收后台程序

sMainThreadHandler中，处理的消息很多，这里只罗列了，可能在启动阶段可能会执行的操作，这些操作都是运行在Main Thread中，对启动而言，属于阻塞性的。

Activity生命周期，自然需要在启动阶段执行，但，对于Service的创建，Trim_memory回调，广播接收等操作，就需要重点考虑，其操作耗时性。

3.3 Activity运行及绘制

前两个过程，创建进程和UI线程及Handler，都是由系统决定的，对APP开发者而言，并不能控制其执行时间，在本阶段，执行BindApplication,和Acitivity生命周期，都是可以由开发者自定义。

Activity执行到onResume之后，会执行至ViewRootImpl，执行两次performTraversals,第二次traversal操作中，会执行performDraw操作，同时通知RenderThread线程执行绘制.

从启动的三个阶段，我们可以看出，启动启动时间的长短，决定因素在于，主线程中所做事情消耗的时间的多少，所以，我们的优化工作主要集中在，排查主线程中耗时性的工作，并进行合理的优化。Android手机，系统的资源是有限的，过多的异步线程，会抢占CPU，导致主线程执行时间片间隔增大。同样的，内存消耗状态，GC频率，也会影响启动的时间