「百度」百度智能小程序框架性能优化实践( 三 ) |HTML|技术|移动互联网|

本文插图
百度智能小程序是开放系统，可以运行在多宿主之上，那如何在多宿主上保证小程序运行体验的一致性呢？
各个宿主集成了我们的小程序框架后，首先要跑 CTS 测试，通过之后才可以拿到小程序列表进行分发。
对于可选能力部分，各个宿主不是所有的能力都需要实现。比如，一些 AI 能力、push 能力。
如果一个小程序用到了可选能力怎么办？
两个办法，一是小程序和宿主之间的双向选择机制，小程序可以选择我要分发到哪些平台，宿主也有权利选择要分发到哪些宿主。二是，小程序做兼容。
Estension 机制

本文插图
上图所示，标红的是 Extension 机制，当宿主有一些定制化的要求时，可以使用此机制。作为宿主，需要做两件事情，一是在 JS 层需要写一套接口；二是在 Porting Layer 接口实现层实现一套能力。如果宿主觉得这个能力是通用的，可以反馈提案，审核通过后，百度小程序团队会将提案合并到开源框架里。
5. 章节小结

本文插图
百度智能小程序框架性能优化实践首先从用户视角看看一个小程序的加载过程。
1. 百度智能小程序加载分阶段过程

本文插图
拿微博举例，如上图所示。

首先小程序被启动后，先是一个 Loading 的过程，上面的 title 和下面的 tab（框架 NA 实现）显示出来。
第二张图片我们定义为 FP（First Paint ）阶段。
第三张图下面有搜索框了，这其实是小程序包里面的内容。它是通过 initdate 接口初始化渲染出来的，此阶段我们定义为 FCP（ First Contentfull Paint ）阶段。
第四张图，是小程序从网上拉到了实时的内容，然后更新到界面，我们将其定义为 FMP（First Meaningful Paint）阶段。
最后一张图，所有的元素都已经拉下来并展示了，用户可以操作任何一个位置，我们将其定义为 TTI (Time to Interative) 阶段。

2. 百度智能小程序（1）性能基线百度小程序在 2019 年底建立了 FMP 指标，它在开发者平台展示的名字为“上屏时间” 。
我们统计了线上的一个 80 分位点，耗时是 1.9s 。什么是 80 分位点？比如，有 100 个请求过来了，然后我们把请求的耗时排序，第 80 个请求的耗时，我们就认为是 80 分位点。
（2）性能历史曲线

本文插图
如上图所示，2019 年百度小程序性能优化的历史曲线。
FP 框架层从接近 3s 一直优化了现在的 1.1s 左右。
百度小程序的目标是让小程序无线接近 NA 体验。
3. 启动流程

本文插图
接下来，我们从开发者角度看，还能优化什么？
我们先看一下启动流程，所有的启动逻辑简单串行罗列（实际是有一些步奏是并行的）。
4. 性能优化开发者能够做的性能优化主要有两部分。一是小程序包的体积，二是业务数据。
接下来，我用三点来说明开发者可以做什么。
（1）包体积优化

本文插图
建议包体积保持在 1M 以内，为什么呢？