更新时间：2023-07-28 17:44:06收藏订阅更新我的文档设置返回文档简介目前支付宝性能的衡量指标是线上所有启动页启动耗时的均值，小程序启动耗时是线上用户体验的重要影响因素之一，会影响用户的使用体验和用户的流失。因此，为了更方便的进行启动耗时分析，全息报告的性能分为启动性能和页面性能两类。启动性能启动耗时支付宝启动耗时支付宝的启动耗时是指从用户点击访问小程序到小程序凯发k8官方网娱乐官方首页完全加载完成的时间，而非 page.onready 事件触发。这样的计算方式会比较接近用户的体感耗时。全息检测启动耗时全息检测启动耗时有两个结果：●本地设备检测结果：指全息检测是当时设备的启动耗时结果。●线上预测结果：指根据本次报告的结果及根因，通过算法预测该版本上线后该启动页的启动耗时。线上启动耗时线上启动耗时是指所有用户从各推广入口进入小程序的启动耗时均值。不同推广入口进入的小程序启动页面可能不同，用户可根据质量洞察里的启动页面及耗时分布，通过启动页设置，模拟不同启动页场景，从而对线上不同启动页进行检测。标准凯发k8官方网娱乐官方首页启动耗时不超过 4500ms。优化手段根据开发可以优化的手段，此处提供通用优化方案、代码包体积检测、页面根因检测3个方面的检测和优化手段。通用优化方案通用接入支付宝提供的通用优化方案，整体提升小程序的启动耗时。目前通用优化方案已升级基础库版本至 2.x。基础库2.x升级全息对小程序基础库版本进行检测，检测小程序是否已接入基础库 2.x 及接入方案。代码包体积检测小程序启动时，需从服务器获取代码包地址并下载解压代码包进行校验。因此，代码包的体积和启动耗时成正比。全息检测提供了以下代码包相关的检测：小程序包大小检测说明：当小程序启动时，支付宝客户端会从 cdn 下载小程序离线包，包大小直接影响了下载耗时，而下载耗时是启动耗时的重要影响因素。标准：●未分包情况下，包总和上限是 2m。●分包情况下，包总和上限是 8m，单个包上限是 2m。注意：这里说的包大小是构建后最终客户端下载的离线包的大小，非源码包大小，具体包大小请以全息检测为准。凯发app官方网站的解决方案：通过分包加载、总包优化来缩减包体积，具体凯发app官方网站的解决方案可查看 。包内图片大小检测说明：代码包内的图片大小会影响包的整包大小，影响包下载耗时，进而影响整体启动耗时。标准：单张建议不超过 100kb。凯发app官方网站的解决方案：●及时清理未使用的图片。●过大的资源文件建议从 cdn 渠道上传，并开启 http 缓存，且需要控制并发加载数量，可使用雪碧图或懒加载进行优化。●合理压缩、剪裁图片大小，或将图片格式转换 webp 或者 svg。具体凯发app官方网站的解决方案可查看 。未引用到的资源检测说明：指代码包里存在的但是并没有引用到的静态资源，无用资源不应出现在包内，会增加小程序包体积大小，从而影响启动速度。标准：未引用的静态资源为0个。凯发app官方网站的解决方案：确定是否真的未引用，如果确实是未引用，请进行删除。页面根因检测该项主要是针对当前的启动页面，从页面的角度进行性能相关指标的检测、根因分析和方案供给。为了更侧重的修复优先级高的问题，未达标的检测项此处通过算法提供了针对当前情况的优先级和预期收益：●优先级： 优先级从高到低为：p0 > p1 > p2，请优先解决高优问题，每个检测项优先级是根据当前报告数据算法动态计算的结果，因此检测项和优先级不是强绑定的，可能随着全息报告的结果会有不同。●预期收益： 算法预测该项解决优化后，预计当前页面的启动耗时提升值，但值得注意的是，由于检测项之间存在关联性，因此多个检测项优化后预期提升值并不等于相关检测项预期收益之和。网络请求耗时检测说明：单次网络请求（如 http），从发起请求到数据返回的耗时，网络请求耗时过长将导致数据等待，延迟首屏初次渲染开始的时间，会让用户一直等待甚至离开。标准：单次网络请求耗时时长不超过 400ms。凯发app官方网站的解决方案：●数据缓存存储网络请求结果。●优化好服务器处理时间。服务端可做 cdn 缓存，做网络请求的预加载（预热），让前端请求能快速响应。●页面资源的域名尽量采用相同域名。●非关键资源应该做好隔离。避免非关键资源加载过慢，导致整个页面渲染不出来。具体凯发app官方网站的解决方案可查看 。图片并发请求数量检测说明：短时间内发起太多图片请求会加重网络带宽压力，且并发请求太多也会导致图片加载慢。标准：同域名耗时超过 300ms 的图片请求并发数不超过 6 个。凯发app官方网站的解决方案：应降低业务的复杂度，减少图片请求的频率。例如使用雪碧图、懒加载、图片开启 http 缓存等，具体凯发app官方网站的解决方案可查看 。图片请求数检测说明：小程序启动阶段网络请求的图片过多，一方面会耗费网络资源，导致网络通道拥挤，网络处理时长增加，另一方面不断加载的图片会导致页面不断重排、重绘引起页面不断抖动，推迟首次可交互的时间。尤其是线上很多小程序实际用户使用场景是非 wifi，容易出现网络不稳定的情况，例如健康码相关的小程序场景。因此此类场景下，如果图片请求过多会导致线上用户的启动耗时比较长。标准：首屏启动完成之前图片请求数应小于 10 个。凯发app官方网站的解决方案：●减少启动阶段的非必要图片请求。屏幕外的图片可以使用 懒加载，如果不确定，可以给所有图片都加上该属性。●对于较小的图片，建议放到代码包里，或者使用雪碧图来减少图片请求数；图片开启 http 缓存控制，下次加载同样图片，直接从缓存读取，从而减少非首次访问的启动耗时。具体凯发app官方网站的解决方案可查看 。图片分屏检测说明：加载当前屏幕中暂时不需要展示的图片，会影响页面加载耗时，增大内存消耗。标准：屏幕外图片加载个数为 0。凯发app官方网站的解决方案：建议分屏懒加载，具体凯发app官方网站的解决方案可查看 。网络请求图片大小检测说明：网络请求图片过大会影响请求耗时，从而影响页面启动耗时，且消耗过多的网络流量，影响资源流耗。标准：不超过 100kb。凯发app官方网站的解决方案：将图片格式转换 webp 或者 svg，根据图片实际尺寸和需要进行裁剪和压缩，或者使用cdn取到上传，并开启缓存，较小的图片建议放到源码包中，具体凯发app官方网站的解决方案可查看 。图片尺寸检测说明：图片太大而有效显示区域较小时会增加内存的消耗，应根据显示区域大小合理控制图片大小。标准：图片宽高都不超过实际显示宽高的 4 倍。凯发app官方网站的解决方案：应根据实际显示尺寸的大小，合理压缩、剪裁图片尺寸。网络请求 url 长度检测说明：小程序网络请求的链路： my.request 请求 <-> 支付宝网络库 <-> 外部网络环境（wifi 3g4g）<-> 服务端。 url 过长会导致以下两种情况： 小程序发送给服务端的数据包过大，会延长数据传输时长和处理时长，最终影响小程序启动耗时；支付宝网络库处理异常（支付宝客户端限制url长度）、服务端处理异常（服务端对 url 长度限制），进而导致请求失败。 因此建议如非必要，减少 url 长度。标准：网络情况 url 长度应不超过 2000 个字符。凯发app官方网站的解决方案：●将 get 请求转换成 post。●对数据进行合理拆分，分页、分级请求和展示，从而减少 url 的长度。具体凯发app官方网站的解决方案可查看 。同步jsapi调用次数检测说明：同步的 jsapi 虽然开发比较方便，但是会有很大的性能损耗。具体表现在同步 jsapi 的调用过多将造成进程的阻塞，影响后续业务逻辑的执行，造成响应变慢，因此原则即是 能不用就不用，非要用 要慎重。优化经验中发现，getsysteminfosync、getstoragesync、setstoragesync、getlocation、getcities 是同步调用的高发区。标准：同种 jsapi 同步执行次数应不超过5次。凯发app官方网站的解决方案：应避免过度使用 sync 结尾的同步 jsapi，同步执行转化成异步执行，具体凯发app官方网站的解决方案可查看 。jsapi重复调用次数检测说明：jsapi 重复调用指的是 jsapi 名称和参数都相同的情况下，多次重复调用请求的情况，最常见的是多次网络请求 request 而其中 url 相同；首屏页面加载中，jsapi 多次重复调用会增加无用耗时，影响小程序整体的启动耗时。标准：同种同参数的 jsapi 可重复调用次数应不超过5次。凯发app官方网站的解决方案：●采用数据 缓存 方式处理前要执行 jsapi 后的结果数据，避免重复调用，对于 getsysteminfo、getsysteminfosync 获取信息后可以用变量来做缓存，后续使用时直接使用变量即可。●不要把 storage 相关 api 作为状态管理工具，可以把信息存在 app 实例上。具体凯发app官方网站的解决方案可查看 。jsapi 并发检测说明：异步并发过高，可能会导致接口调度减缓，甚至阻塞逻辑；例如网络通信吞吐量有限的情况下，部分请求会阻塞、超时，甚至直接以失败返回，影响业务。标准：并发 jsapi 次数应不超过 20次/s。凯发app官方网站的解决方案：●采用数据 缓存 方式处理前要执行 jsapi 后的结果数据，减少调用次数。●减少并发执行次数。例如使用排队等策略，保障高优先级的业务请求。具体凯发app官方网站的解决方案可查看 。js函数执行耗时检测说明：页面打开期间调用的 js 函数较多，如果多个函数执行耗时都较长，那串行起来会更长，会严重影响用户体验。标准：单个函数耗时执行不超过 500ms。凯发app官方网站的解决方案：自检代码，关注函数的循环层级、嵌套，以及定时器的延迟问题。setdata数据量检测说明：小程序运行交互时，在逻辑层和视图层的数据传输过程中，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 js 脚本，再执行脚本传到视图层渲染。故单次调用 setdata 传递的字符串数据大小需要控制。标准：页面单次 setdata 调用，传递的字符串数据量应不超过 256kb。凯发app官方网站的解决方案：减少数据量，避免一次性 setdata 传递过长的列表，或分批处理，具体凯发app官方网站的解决方案可查看 。setdata调用次数检测说明：页面 setdata 调用次数不宜过多，否则会导致 js 线程一直在执行编译和渲染，视图层和逻辑层数据交互阻塞，可能导致用户的事件操作传递到逻辑层不及时，同时逻辑层的处理结果也不能很快的传递到视图层，从而造成用户滑动时的卡顿和操作反馈延时。标准：页面每秒调用 setdata 的次数不超过 20 次。凯发app官方网站的解决方案：●页面级别或组件级别避免频繁触发 setdata 或者 $splicedata。●需要频繁触发重新渲染时，避免使用页面级别的 setdata 和 $splicedata， 将这一块封装成自定义组件，然后使用组件级别的 setdata 或 $splicedata 触发组件重新渲染。●使用 $batchedupdates 合并多次 setdata 请求为一次 setdata，进而减少逻辑层到视图层的更新次数。具体凯发app官方网站的解决方案可查看 。数据请求时机检测说明：小程序运行中，会先触发页面的 onload 生命周期函数，再将页面初始数据（page data）从 worker 传递到 web-view 进行一次初始渲染。 页面初始渲染完成，从 web-view 发出通知到 worker，触发 onready 生命周期函数。 部分小程序会在 onready 中发出请求，导致首屏渲染延缓。标准：页面 onready 中无请求发送。凯发app官方网站的解决方案：将数据请求提前到 onload 中，避免在 onready 中发出请求。页面axml节点个数检测说明：一个过大的 dom 树会引起内存消耗增长，样式计算时间过长，与复杂的样式规则相结合可能会严重减慢渲染速度。标准：页面首次渲染（虚拟）dom 节点总数应不超过 1000，节点树深度不超过 30 层，子节点数不大于 60。凯发app官方网站的解决方案：减少超标节点下的嵌套层级，删除冗余节点或重新布局。对于节点数超标情况，列表建议分批渲染。流量消耗检测说明：减少超标节点下的嵌套层级，删除冗余节点或重新布局。对于节点数超标情况，列表建议分批渲染。标准：流量消耗总大小不超过 2mb。凯发app官方网站的解决方案：可考虑资源合并、压缩等技术方案来降低流量开销。页面性能页面性能是指以页面为维度，检测非启动页性能情况的检测项。检测指标可查看本文档里启动性能下的 页面根因检测。注意： 页面列表是根据用户操作的顺序展示的，页面名称可能会有重复，例如用户操作路径是 启动页 > a > b > a，那页面性能版块里的页面列表同样也是 a > b > a。
