一、背景
从点击桌面图标到首页渲染完成的平均时间应在3秒以内。 为什么是3秒？ 统计数据表明超过3秒后用户跳失率陡增。
冷启动优化有很多技术手段， 百度上都能查到，不再赘述。
二、启动框架简介
启动框架的作用是充分利用前3秒的CPU， 即打满CPU.
image.png
image.png
为什么出现“bad case”的情况呢？ 这是本文要解决的问题。 通常因为在进程启动阶段出现各种锁和信号量， 导致线程间的相互等待。
image.png
上图Wall Duration是142.421ms，但self time是4.251ms。该函数等待时间远远超过自身的执行时间。
三、任务编排
对于大型app在进程启动阶段可能执行几十个初始化函数， 例如网络库、图片库、埋点、控件、各种文件IO等等，它们之间的依赖关系形成了“有向无环图”； 常规的做法是使用锁机制实现依赖关系的调度。
如下图所示，箭头表示上下游依赖关系：
1、函数A和B执行完成后才能执行C；
2、函数C执行完成后才能执行E；
3、C、D执行完成后才能执行F；
4、F、G执行完成后才能执行I；
5、函数H和J无前置依赖；
image.png
为了实现上图的执行时序， 在代码实现方式上大都采用线程池和锁实现多线程调度， 例如常见的CountDownLatch、Lock和Semaphore等等。
使用了锁必然导致CPU线程调度时出现线程阻塞或等待的情况， 即出现wall duration过长的情况。
使用线程池且不使用锁便解决了性能问题， 核心是分阶段治理。 我们看上图的任务编排下， CPU各个内核在同一时刻是否打满了？ CPU空转和等待必然导致整体运行时间变长
image.png
引入阶段的概念， 将原来大的有向无环图拆分成若干个子有向无环图（尽量减少依赖关系）。
拆分依据是各个函数自身的执行周期和上下游依赖关系， 高中低端机型和不同类用户的启动任务编排有区别，引深的讲还会涉及到“端智能”。 基础原理都是上图的任务编排， 哪些任务必须在application阶段执行， 哪些可用在首页idle时执行，哪些可用懒加载（定时器）等等；
四、实现方式（伪代码）
//定义有向无环图的节点
public class Node {
public String key; //唯一标识一个任务， 例如函数名 initNetworkSdk
//每个node可以有0到n个上游或者下游节点
public Set<Node> inComingNodes; //上游节点，用于判断当前节点是否满足可执行条件
public Set<Node> outGoingNodes; //下游节点，当前节点执行完成后判断下游节点是否可执行。
//当前节点执行状态
public int status;
private final int STATUS_DEFAULT = 0; //尚未执行
private final int STATUS_SUCCESS = 1; //已执行成功
private final int STATUS_RUNNING = 2; //正在执行中
private final int STATUS_FAILED = 2; //执行失败
private final int STATUS_SKIPPED = 3; //跳过该节点
}
public class Task {
public String key; //跟Node的key对应
//每个任务继承于task并实现execute函数， 函数体是各种初始化函数
abstract void execute();
}
public class DagStage<R> {
//当前有向无换台的所有节点
private Set<Node> nodes;
CompletionService<R> completionService = new ExecutorCompletionService<R>(exs);
/**
** 函数退出条件是nodes里所有node都执行完成FAIL或者SUCCESS.
** 每次completionService.take().get()后判断一次当前所有node的执行状态
**/
public void processWorks() {
while (可执行node数量 > 0) {
//遍历nodes获取可执行node，即inComingNodes都执行完且当前节点尚未执行
Task task = taskFactory.getTask(node.key); //通过key关联node和task， 实例化对应的任务
completionService.submit(task); //更新node.status为执行中
R result = completionService.get().take();
updateNode(result.key); //通过key找到匹配的node并更新任务执行状态
processWorks(); //继续查找是否有可执行的node
}
}
}
CompletionService的实现目标是任务先完成可优先获取到，即结果按照完成先后顺序排序。 每次执行take()会取队列里取值， 如果没值则阻塞等待到第一条Future实例返回。
image.png
五、小结
1、 使用CompletionService后不再需要使用锁机制实现线程间的相互依赖，并通过判断node执行状态触发执行新的任务；
2、采用分阶段的思想， 原来可能将几十个任务全部丢给线程池执行， 现在按照业务逻辑分拆成若干个阶段， 每个阶段执行一部分函数， 从而减少线程调度和线程间依赖导致的cpu空转问题（wall duration）
网友评论