APP性能优化系列-异步优化与拓扑排序（二），移动开发者平台

}

});

executorService.submit(new Runnable() {

@Override

public void run() {

initJPushInterface();

}

});

executorService.submit(new Runnable() {

@Override

public void run() {

initShareSDK();

}

});

try {

latch.await();

} catch (InterruptedException e) {

e.printStackTrace();

}

// Debug.stopMethodTracing();

}

这样就行了，只有当initBugly执行完毕才能继续跳转页面，当然值得补充的是，之所以要加门栓，是因为在onCreate方法里面，可能还有其他必须在主线程才能初始化的其他耗时任务，而initBugly可以不需要在主线程里面初始化，但是又必须得初始化完毕才能跳转页面。所以为了不再增加时间，才启动线程池+门栓去初始化

好了，既加快了速度，又可以保证一些不需要在主线程优化而又启动之前必须初始化完成的任务不出问题，

但是尼，这么写，有点Low，而且如果有的耗时方法存在关联，比如必须先执行完A，根据A的返回值，再执行B，然后根据B的返回再执行C，那么必须串联的话，我们该如何优化尼？

5.第三次改造（启动器）

---

先看图，目的就是进行任务分类

看了图，是不是略微明白了？我们的任务基本就是这样的，有的必须要在所以任务之前初始化，有的必须要在主线程初始化，有的可以有空在初始化，有的必须要在有的任务执行完毕再初始化，比如激光推送需要设备ID，那么就必须要在获取设备ID这个方法执行完才能执行，所以我们要对耗时任务先分类。

于是有了上图

• head task : 我们会把一些必须先启动的task放到这里

• 主线程：将必须要在主线程中初始化的task放入这里

• 并发：将非必须在主线程中初始化的task放入这里

• tall task: 一些在所有任务执行完毕之后才去初始化的放入这里，比如一些log打印等

• ilde task: 通过字面就知道了将一些可以有空再初始化的task放入这里

好了分好类了之后，我们发现如果用常规的方式去做，比如线程池