历时 1 年，上百万行代码！首次揭秘手淘全链路性能优化（一）

导读：自阿里在 11 年提出 All in 无线之后，手淘慢慢成长为承载业务最多，体量巨大的航母级移动端应用。与之相应的，手淘离轻量，快速，敏捷这些关键词却越来越远，启动慢，使用卡逐步成为用户使用过程中的主要体验问题。为此，手淘的技术团队启动了极速版项目，其目标是还给用户一个更加流畅的淘宝。整个项目历时近 1 年，横跨几十个团队，经历了数百次的数据实验，涉及代码上百万行，最终使得手淘的性能有一个质的飞跃。

下面，我们一起来看手淘团队在性能优化过程中的一些思考和实践。

启动框架的思考

▐ 启动框架在手淘的意义

启动性能，是用户在使用 APP 过程中的第一感观，可见是相当重要的。相信很多同学都能说出一些常规的手段，比如只加载必要的模块，延迟加载等。从大的策略上说，是没有问题的，也是手淘做启动性能优化的一个方向，也得了一些效果，但仍存在一些问题。

前面提到，手淘承载的业务非常多，为了更好支撑业务，使用了动态化技术及一些非常复杂的策略，就首页本身依赖的模块和任务就非常多，相互关系也复杂，只加载必要任务，仍然是一笔不小的开销。于是，为了更加极致的优化，我们不得不继续思考性能优化的本质。

通常我们为了更快的达到目标，把与目标无关的事情，提到完成目标之后，通过减少执行代码从而减少执行时间的方式，叫着软优化。相对的，对于提升系统的吞吐效率，对于相同的代码用更少的执行时间完成，叫着硬优化。硬优化是面向硬件资源，包括 CPU，内存，网络，磁盘 IO 等的调度，减少等待时间，最大化利用硬件资源，保持系统负载在合理范围内。

这次优化我们有一个大的原则，要求基本不能影响业务需求，也就是要在不减任何业务代码的情况下进行优化。

对手淘而言，因为启动包含很多基础 SDK，SDK 的初始化有着一定的先后顺序；业务 SDK 又是围绕着多个基础 SDK 建立的。

那么如何保证这些 SDK 在正确的阶段、按照正确的依赖顺序、高效地初始化？怎么合理调度任务，才不至于让系统负载过高？如何最大化利用设备的性能，承接越来越多的业务？

其实启动框架就是一个任务调度系统，是手淘启动的“大管家”。各个业务模块我们称之为启动任务，管家要做的事情就是把它们的关系梳理得明明白白，有条不紊，合理安排位置、调度时间，同时提升硬件资源的利用率。

▐ 启动框架的思路

总结下来无非就是两点：一是 如何保证时序 ；二是 怎么控制拥塞，提高吞吐，充实不瞎忙。我们先看一组实验数据，在并发下面的 IO 性能。

启动任务 高并发 IO 耗时 低并发 IO 耗时

由表上的数据可以看到降低 IO 的并发，整体的执行时间大幅降低。

我们借鉴了很多任务调度系统。比如谷歌新出的 WorkManager，再比如 Spark 的 DAGScheduler。

从 Spark 的 DAGScheduler 中领悟到它的核心思想，面向阶段调度（Stage-Oriented Scheduler）：把应用划分成一个个的阶段（Stage），再把任务（Task）安排到各个阶段中去，任务的编排则是通过构建 有向无环图（DAG），把任务依赖通过图的方式梳理得 井井有条。因为它分阶段执行，先集中资源把阶段一搞定，再齐心协力去执行阶段二，这样即能控制拥塞，又能保证时序，还能并发执行，让设备性能尽可能得到发挥，岂不美哉：

本文转载自淘系技术公众号。

原文链接：https://mp.weixin.qq.com/s/PiqnHezWKWUU0byEhrboRg