测量小程序的性能，而不是宿主的
小程序意味着：您的代码运行在别人开发的 App 中，依赖一个您无法控制的运行时，跑在一台您无法选择的硬件上。其中每一点都会带来测量上的问题。
实际测到的是什么
如果把性能采集的范围设为宿主 App，得到的数据包括：宿主自身的界面、网络请求、埋点及其后台的全部活动，再加上您的小程序。您的代码只占其中一部分，而且无法分辨占比。
因此，这个数字不能作为基线，不能跨会话对比，也不能在别人认为您的小程序过重时作为依据。
解决方法是把范围收窄到小程序自身的进程。多数宿主会为每个小程序单独启动一个进程，以此实现小程序之间以及小程序与宿主之间的隔离。附加到该进程后，CPU、内存和帧率反映的才是您的代码。
仍有部分开销不属于您
即使范围设置正确，仍有一部分开销是结构性的：
- 运行时启动。 在您的第一行代码运行之前，宿主需要先启动小程序容器。这段时间计入会话，但您无法优化。
- 桥接开销。 JavaScript 每次调用原生能力都要跨越一次边界。这部分开销并非为零，而且在您自己的代码中看不到。
- 宿主的渲染管线。 您描述视图，由宿主决定如何绘制。帧率取决于一个您无法分析的渲染器。
- 共享的内存上限。 宿主与其中所有小程序共享同一个 App 的内存配额。小程序被终止，完全可能是其他代码导致的。
区分这几类开销是这项工作的主要难点。包含容器启动时间的冷启动数据，不能公平衡量您的代码；若以此为准，可能会花一周时间去优化一个无法改动的部分。
值得测量的指标
冷启动、热启动及两者的差值。 运行一次，结束进程，再运行一次。差值大致是缓存发挥作用的部分，底线大致是结构性开销。
一次往返中的内存。 进入小程序、使用、退出、再次进入。如果底线每次都在抬高，说明您正在一个与他人代码共用的进程中泄漏内存，最终可能被归咎于他人，并导致所有代码一起被终止。
列表滑动的帧率。 小程序最常见的投诉是滑动性能，原因几乎总是节点过多或图片尺寸不当。
网络流量，而非请求数。 您可能看不到请求本身，但可以看到字节数。一个打开就下载 5 MB 数据的小程序，从外部就能看出问题。
关于硬件
小程序的用户群明显偏向老旧设备，这往往正是小程序存在的原因：它是比安装 App 更轻量的选择。因此，您手边的旗舰机在这里比平时更不具代表性。
请使用能找到的最低端设备测试。一个在新款手机上运行正常、在四年前的机型上却无法使用的小程序，恰恰没有实现它被设计出来要解决的问题。
数据存放在哪里
宿主 App 的沙盒中存放着小程序的存储数据。查看这些数据，可以一次性解答一整类原本只能猜测的问题：缓存是否写入、包是否更新、本地数据库大小是否符合预期、下载的资源是否完整。
通常的注意事项在这里更加重要：这是宿主的沙盒，其中除了您的数据，还有其他小程序的数据。请只查看自己的数据，只获取能回答问题的部分，用完即删。
如何呈现结论
当您需要向宿主平台团队说明小程序的开销时（这一天迟早会到来），有说服力的材料包括：
- 进程级的采集数据，而非宿主级
- 注明设备型号的冷启动与热启动数据，并附上设备状态
- 改动前后同一项测量的两次结果
宿主后台面板上的一个数字只是讨论的起点；在明确设备上按进程采集的结果，才是答案。