注：小程序启动的各流程不是串行的，会尽可能的并行。 计算总启动耗时不能简单的分阶段加和 。
启动性能
运行环境准备
小程序的运行环境包括小程序进程、客户端原生部分的系统组件和 UI 元素（如 导航栏、tabBar 等）、渲染页面使用的 WebView 容器、开发者 JavaScript 代码的运行环境、小程序基础库等等。
部分环境（如 JavaScript 引擎、小程序基础库）需要在执行小程序代码之前准备完成，其他的会在启动过程中并行进行。运行环境的准备时间相对较长（尤其是在低端设备上），会对小程序启动产生严重影响。
运行环境准备耗时较长，如果启动时没有命中预加载的环境，对小程序的启动耗时会有明显影响。耗时长短与平台、设备性能、预加载比例有关。
-
由于系统功能和启动流程实现的差异，通常安卓系统运行环境准备耗时要远高于 iOS。
-
低端机系统资源比较紧张，预加载的环境会更容易被系统清理，导致预加载比例偏低。
-
预加载比例越高，平均启动耗时一般可以越低。
这部分逻辑完全由微信客户端控制，开发者目前无法直接进行优化。
小程序相关信息准备
在用户访问小程序时，微信客户端需要从微信后台获取小程序的头像、昵称、版本、配置、权限等基本信息，以对小程序进行必要的版本管理、权限控制和校验等。为了在保证信息实时性的前提下，尽量降低对启动耗时的影响，这些信息会在本地缓存，并通过一定的机制进行更新。
在用户首次访问 小程序、小程序版本更新 或使用长期未使用 的小程序时，信息的获取和更新会影响小程序的启动耗时，耗时长短主要与网络环境有关。
从大盘来看，小程序版本发布时，会导致启动时需要同步请求的比例上升，进而导致平均启动耗时的上涨 。因此，建议开发者合理规划版本发布。
这部分逻辑完全由微信客户端控制，开发者目前无法直接进行优化。
代码包准备（开发可优化）
小程序启动时，需要根据用户访问的页面，从微信后台获取代码包地址，从 CDN 下载小程序代码包，并对代码包进行校验。根据小程序页面所在分包和使用的插件不同，一次启动可能需要下载多个代码包或插件包。
下载耗时是启动耗时中的重要瓶颈，在用户首次访问小程序或小程序版本更新时，代码包的下载会对启动耗时造成影响。耗时长短与网络环境，代码包压缩后大小，以及是否命中增量更新有关。
考虑到包大小对用户体验的影响，平台限制单个小程序代码包的大小上限为 2M。代码包上限的增加，对于开发者来说能够实现更丰富的功能，但对于用户来说也增加了流量和本地空间的占用。为了保证启动速度，开发者应该尽可能的控制启动时用到的代码包大小。具体方法可以参考《代码包体积优化》。
小程序代码注入（逻辑层）
小程序启动时需要从代码包内读取小程序的配置和代码，并注入到 JavaScript 引擎中。在主包代码注入过程中，会触发小程序的
App.onLaunch和App.onShow生命周期。如果小程序使用了插件或扩展库，在注入开发者代码之前，还会先注入对应插件和扩展库的代码。
小程序代码的注入耗时直接影响小程序的启动耗时。耗时长短与代码复杂度、同步接口调用和一些复杂的计算 有关。如果未启用「按需注入」，耗时还会与启动使用到分包内的页面和自定义组件总数有关。
由于「首页渲染」需要使用逻辑层发送的数据，如果小程序代码注入耗时过长，会延迟「首页渲染」开始的时间。建议开发者参考《代码注入优化》章节进行优化。
小程序代码注入（视图层）
开发者的 WXSS 和 WXML 会编译成 JavaScript 代码注入到视图层，包含页面渲染需要的页面结构和样式信息。
我们采用和「小程序代码注入（逻辑层）」相似的方式优化注入耗时。
视图层和逻辑层的小程序代码注入是并行进行的。
小程序代码的注入耗时直接影响小程序的启动耗时。耗时长短与当前页面结构复杂度和页面使用的自定义组件数量 有关。如果未启用「按需注入」，耗时还会与启动使用到分包内的页面和自定义组件总数有关。
由于「首页渲染」需要使用视图层的页面结构和样式信息，如果小程序代码注入耗时过长，会影响渲染数据从逻辑层到达视图层的时间，影响「首页渲染」的耗时。
虽然开发者不能直接修改视图层生成的 JS 代码，但是可以通过使用「按需注入」、移除未使用的自定义组件等方式降低这部分耗时。
首页（初次）渲染
在逻辑层小程序代码注入完成后，小程序框架会根据用户访问的页面，进行页面组件树初始化，生成首屏渲染相关数据 发送到视图层，并依次触发首页的 Page.onLoad, Page.onShow 生命周期。
首屏渲染相关数据包括 Page 初始化参数中 data 属性值，和部分比较早发出的 setData 数据（哪些 setData 可以计入首页渲染与渲染层和逻辑层之间的初始化时序相关，目前没有可以保证一定能够计入的情况）。
在完成视图层代码注入，并收到逻辑层发送的首屏渲染相关数据后，结合从初始数据和视图层得到的页面结构和样式信息，小程序框架会进行小程序首页的渲染，展示小程序首屏，并触发首页的 Page.onReady 事件。
如果开启了「初始渲染缓存」，「首页渲染」可以直接使用缓存完成，不依赖逻辑层的初始数据，降低启动耗时。
小程序框架层面，以 Page.onReady 事件触发标志小程序启动过程完成。
首页渲染耗时是启动过程的最后一环，直接影响小程序的启动耗时。耗时长短与页面结构复杂度、参与渲染的自定义组件数量 有关。建议开发者参考《首屏渲染优化》章节进行优化。
如果启用了「按需注入」，部分组件代码注入会被延迟到本阶段执行，导致阶段耗时上涨，但总耗时一般会下降。
首屏内容展示
「首页渲染」完成后，小程序启动流程完成，Loading 消失，此时一般情况下用户应该能立刻看到首屏内容。
但是如果首页的主体内容依赖网络请求（例如 wx.request）等异步来源，用户并不一定能立刻看到有意义的完整界面，可能看到的仍然是白屏界面。需要等待网络请求异步返回后，调用 setData 进行页面更新，才能呈现真正的页面。
通常情况下，开发者也会选择先展示「骨架屏」来避免白屏，以优化用户体验。
异步 setData 触发绘制的首屏内容展示不一定会计入启动耗时统计，但是会延迟用户看到页面内容的时间，影响用户体验。建议开发者参考《首屏渲染优化》章节进行优化。
优化：
其他：