前言

除了朗姆酒，你还可以了解分析和研究过程。今天早读文章由腾讯云@今提交，公众号：腾讯云监管。

@，腾讯医疗健康前端开发工程师，腾讯前端监控PMC成员，主要负责小程序监控系统的设计和开发。

正文由此开始~~

听说代码没有尽头，我也不会输。前端性能优化没有终点。只要坚持监控和优化，总会有“0.1S”的下降。

背景

腾讯医药是一家医药电商平台，专注于为C端用户提供方便、快捷、安全的在线药品购买服务。目前已引进多家品牌/连锁药店，支持B2C和O2O购药模式，药品及各类保健品丰富多样，价格实惠，质量保证，专业的服务品质，为消费者购药、用药保驾护航。

近期，腾讯医药微信小程序上线新冠抗原检测试剂后，日访问量增加，用户在线体验卡反馈严重，急需前端性能优化。经过多方考量，历经多年打磨的腾讯云前端性能监控（Rum）。

腾讯云前端性能监控（Rum）是专注于WEB和小程序的一站式前端监控解决方案。前端性能监控重点关注用户页面的性能和质量，并联动腾讯云的应用性能观察，实现前后端一体化监控。用户只需将SDK安装到自己的项目中即可。通过简单的配置，即可实现对用户页面质量的全面监护，真正实现低成本使用、无入侵监控。

接入腾讯云前端性能监控（Rum）后的优化效果展示：

监测方案介绍 1、指标定义介绍

根据小程序官方的建议，我们将小程序的性能分为启动性能和运行时性能：

启动表现：小程序的启动过程以“用户打开小程序”为起点，小程序“首页渲染完成”。小程序“首页渲染”的标志是首页页面。事件触发。

运行时性能：小程序的性能直接决定了用户使用小程序功能的体验。如果运行时性能出现问题，很容易出现页面滚动卡顿、响应延迟等问题，影响用户的使用。如果内存太高，就会出现黑屏、闪退等问题。

1.1 启动性能

下面以小程序首页为例。我们从框架端和用户端来分析一下启动过程：

上述小程序开始执行时序后，从开发者角度可以优化的空间是以下几个步骤：

综上，起始性能指标综合如下：

1.2 运行性能

运行时的性能指标可以概括为以下两类：异常类、体验类：

综上，经营绩效指标整合如下：

2、监测方案

目前小程序的监控是定制+Rum的解决方案：

关于自定义报告部分如下：

定制报告：采用劫持方案，代码侵入性小、可控；目前大致分为4种：

在研究分析过程中，我们遇到了以下问题：

问题1：监控数据保存时间无法满足需求。

我们希望保存更长时间的监测数据。数据控制数据一方面是为了保存数据的持续时间，另一方面是为了方便功能扩展，比如数据分析、报警等。在Rum原有功能的基础上，增加了新的数据持久化方案；通过Rum开放接口获取数据后，将数据转化为可视化界面。

为了满足业务定制的需求，我们获取了Rum的一些监测数据，并制定了如下评分机制。

最终指标如下：

总体启动时间性能：小程序总启动时间=基本环境准备+打包耗时时间+代码注入时间+首次渲染时间消耗；

优化流程

Rum性能评分对比和微信体验评分对比结果列出了以下表现较差的指标；

开始表演

经营业绩

通过上面列出的指标，优化的重点方向是：耗时、界面耗时、时间。

1. 袋子体积优化

开发者工具的代码依赖分析和代码质量查看包情况；

具体操作：

主包体积从1.75MB优化至1.30；

下降约26%；启动时间大约减少；

2.第一次渲染优化

首页是电子商务的门户，具有较多的加载功能。第一屏调用10多个业务接口和日志等报表。接口堆积队列导致加载缓慢。同时我们也发现首页实现上还存在一些不合理的地方，比如业务接口数据整合、日志上报等。

具体操作：

2.1 优先选择骨架屏，提高首次渲染效果；通过构造骨架屏生成对应的骨架，嵌入到首页中，优先选择骨架屏部分，在界面不调整后渲染真实数据；

<import src="./home.skeleton.wxml"/>
<template is="home.skeleton" wx:if="{{loading}}" />

2.2 精简首屏数据，加载屏幕；

一个。聚合接口：首页发现十多个接口调用，且接口渲染数据过多且过于分散，聚合成两个接口；

b.分屏加载：从第二屏加载第一屏；

c.队列上报：每个报表上报一次，可以对队列进行上报；

关键代码：

// 静态数据，临时方案
// 静态数据，临时方案
const {
firstScreenData,
tabData } = require('./staticData.js');
/**获取页面数据*/
fetchHomeData() {
this.fetchFirstScreen(); //首屏：首页数据聚合到firstScreen中；
this.getHomeTabData(); // 次屏：推荐商品聚合到getHomeTabData；
},
/**获取首屏数据*/
fetchFirstScreen() {
homeFirstScreen().then((res) =>{
this.initFirstScreen(res);
this.createIntersectionForNav();
}).
catch(() =>{
this.firstScreenFallBack();
});
},
/**FirstScreen 数据降级*/
firstScreenFallBack() {
this.initFirstScreen(firstScreenData);
},

拿一张分屏加载流程图和底部：

收入对比如下：

3. 优化

不同的小程序渲染层和逻辑层是独立于Web端的。两端不能共享内存级别的数据。每个逻辑层更新渲染视图都需要通过数据管道进行传输。不过在小程序的开发中，是最频繁的。如果使用不当，将会极大地影响用户体验。

监控渲染耗时的关键代码：

API提供相关数据。通过提供并可计算耗时，获取源数据，然后通过JSON转换为字符串，并根据JS引擎的16进制产生计算数据大小。

3.1 定位发现问题

1、Rum上报后定位问题可以定位到页面性能中的定位问题。

2.通过我们每天对RUM数据的分析，当前在小程序页面上花费时间较长的页面。

3.2 基于Rum存在的问题分析

问题1：直接一个大对象，导致时间很长。

const categorys = [...catList];
const currentCategory = categorys.length > 0 ? categorys[0].category_code: null;
const secondCategorys = categorys.length > 0 ? [...categorys[0].children] : [];
const currentSecondCategory = secondCategorys.length > 0 ? secondCategorys[0].category_code: null;
const drugListArray = [];
categorys.forEach((item) =>{
if (item.children.length > 0) {
item.children.forEach((subItem) =>{
drugListArray.push({
code: subItem.category_code,
drugList: [],
sortIndex: 0,
sort: 1,
isDisplay: false,
});
});
} else {
drugListArray.push({
code: item.category_code,
drugList: [],
sortIndex: 0,
sort: 1,
isDisplay: false,
});
}
});
this.setData({
categorys,
currentCategory,
secondCategorys,
currentSecondCategory,
drugListArray,
});

接口返回的数据量如下：

耗时最长的页面就是一个例子。项目中大部分毫秒级的页面都是由一个非常大的对象引起的。

解决方案：处理较小的数据，或者实现前端渲染。不要同时渲染太多产品。

问题2：多个不合理的

官方建议：

不要在for循环的方法中使用它！

上面的例子中，操作是在for循环中进行的，多次的内容是没有用的。

解决办法：移至for循环，数据处理完毕后再统一操作。

没有合并。

解决办法：逻辑上合并的可以合并，减少不必要的调用。

包含大量非渲染数据。

接口中请求数据：

前端渲染所需数据

据分析，前端并没有过滤渲染所需的数据，而是全部执行。

解决方案：接口数据量大时，渲染数据过滤。没有完全使用，传输的数据是可用的。

经过上述优化后，耗时消耗较之前优化为170.60ms，下降了25%；

根据朗姆酒区域监测数据，北方用户界面优化

优化接口消耗分布的时间优化：

问题原因是PHP层有3个TKE节点，分别是天津、南京、广州； C++层只有一个广州节点。因此，来自天津和南京的请求最终会调用位于广州节点的C++服务；

解决方案：逐步延迟北方的PHP接入层节点

优化后，接口消耗分散，北方接口消耗时间明显减少：

通过折图查看平均耗时收入：

比较

3月份评分机制建立后发现，页面评分平均分在83分左右；

决定在页面开始优化，持续优化后，页面评分呈现上升趋势；

后续几个月质量监测地址稳定在92点左右；

与腾讯健康、医码等小程序的性能数据相比，电商小程序还有一些需要优化的地方。优化点如下：

按需注入：启用按需注入后，小程序只注入当前访问页面所需的自定义组件和页面代码。未声明的自定义组件和未访问过的当前页面不会被加载和初始化，相应的代码文件也不会被执行。

初始渲染缓存：不必等到逻辑层初始化，可以更早启动渲染视图，基础库需要2.11.1开始支持。

预拉取数据：预拉取可以在小程序冷时通过微信后台从第三方服务器拉取业务数据。当代码包加载时，可以更快地渲染页面，减少用户等待时间，从而增加小小，从而增强小小，从而增强小小，从而增加小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小，从而增强小小。程序的打开速度。

分包异步：使用异步加载模块还可以减少代码包的下载时间和JS的注入时间。

后续履约保证

性能优化是一个长期战线；要做好后续防护和预防优化工作。

1、严格控制主包代码。

开发：可以遵循水线配置包阈值，超过阈值就走开；

线上：页面评分机制增加包大小指标；

2、孝行

电影码库CR组合码流规则配置：

3、总结高效写作文档，定期补充。

质量跟踪流程：

4、质量后续优化。

短时间内不可能立即看到效果的优化，所以需要以周为单位进行分析。并且不需要立即发布，遵循每周迭代；

优化得分

中、95、99分性能数据：

朗姆酒官方网站：

关于本文