冷启动治理-启动框架原理

一、背景
从点击桌面图标到首页渲染完成的平均时间应在3秒以内。为什么是3秒？统计数据表明超过3秒后用户跳失率陡增。
冷启动优化有很多技术手段，百度上都能查到，不再赘述。

二、启动框架简介
启动框架的作用是充分利用前3秒的CPU，即打满CPU.

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）