性能监控的意义
小程序在建设初期，并没有对于性能感知的能力。
小程序基于双(多)线程架构运行，并附带商业化属性发展，因此厂商需要针对框架整体性能进行监控，并能够感知到业务项目的各项指标，最终根据业务项目的各项性能指标产出性能健康度，用于衡量项目健康度及质量管控。开发阶段的性能感知能力也可以帮助我们及时发现一些错误操作而导致的性能问题。
本文主要记录下小程序性能监控设计的过程
性能监控梳理
小程序架构对于性能的关注点，大概划分下面的五个方向出来：
运行时性能指标的建设
在运行时阶段，更加关注容器、渲染及框架的各项指标。这些指标的下降或者预警，很有可能是业务的一些不规范操作导致的。
收集维度
小程序的优化通常都是以页面维度，逐页优化。因此小红书小程序提供了以页面维度的数据监控和告警能力。
关键指标
针对首开、框架速度及操作体验，可以从下面指标的阈值来反应
| 指标 | 描述 |
|---|---|
| FP(First paint) | 测量页面第一次绘制所需要的事件 |
| FCP(First contentful paint) | 测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间 |
| LCP(Largest contentful paint ) | 测量页面第一次绘制所需要的事件 |
| FMP(first meaning paint) | 测量页面从开始加载到最大文本块或图像元素在屏幕上完成渲染的时间 |
| 页面启动时间（pageLoadTime） | 初始化数据 (sendInitialData) 发送到 FMP 发生的时间 |
| 上屏时长(onScreenTime) | 用户点击到触发 FMP 的耗时 |
| 容器启动时长(container_startup_total_time) | 容器初始化 v8 、webview 总耗时 |
| 长任务(long-task) | 运行时阶段执行有长达 50ms 以上任务发生时的指标 |
这些指标代表了单个页面启动阶段的关键数据指标。可通过下面的启动流程来明确指标所代表
小程序的架构下，当用户点击后，native 会下载相关资源包，包含基础库 + 用户资源包。native 将业务逻辑和渲染逻辑分别在 v8 / js-core 、webview 容器中执行。后续则依赖 js-bridge 在线程中进行通讯及逻辑处理。线程隔离带来的优劣势这里不赘述。
收集方式
小程序依然遵讯 web 开发规范。对于基础指标，使用 performanceObserver 可帮助拿到各类指标的阈值。
对于逻辑层性能点位，可借助逻辑层框架的 plugin hook 进行各项点位进行数据统计：
interface FrameworkPlugin {
...
appWillCreated(): void
pageSendInitialData(initialData: any): void
...
}
统计后，通过 bridge 发送到指定的渲染层页面中进行收集
告警方式
各项指标收集后，会经过 observer 进行处理与计算，当达到设置的阈值时，会通过 warning 形式上报的控制台，进而提醒开发者框架发生性能问题，并给出优化意见
可通过 printMetricInformation 来查看当前所收集的指标明细
对于开发者本身，也可以通过 getPerformance 的 api 来获取对应框架性能指标，从而不断提高小程序的体验。
