一、前语
小程序功用是指小程序在微信APP或许其他宿主APP中加载和呈现的速度，以及小程序对用户交互的呼应程度。功用欠缺的小程序烘托和呼应速度较慢，甚至会呈现无法正常翻开小程序的情况，在不同程度上极大地影响了用户体会，然后导致用户丢失。
京东购物小程序跟着更多事务不断的更新迭代，发动功用逐渐下降，微信后台翻开率仅86%，每天有几百万的丢失。跟着互联网人口盈利的结束，增质变缓，如何通过技能手段提高发动功用成为重中之重，以便更好地留住来之不易的增量用户，进一步助力事务的成长。
二、功用目标与衡量
运用功用目标来评价小程序的加载速度是十分必要的，咱们回顾一下京购小程序页面加载的几个要害阶段：
这几个要害阶段的含义如下：
| 阶段 | 含义 |
|---|---|
| loadPackage | 小程序代码包下载 |
| First Paint (FP) | 页面初次制作 |
| First Contentful Paint (FCP) | 初次有内容的制作 |
| First Meaningful Paint (FMP) | 初次有含义的制作 |
| Largest Contentful Paint (LCP) | 页面最大内容制作，达到可交互状况 |
在以上的几个阶段傍边，咱们最为注重的是，用户从点击小程序开始到页面最大内容制作 (LCP) 的总耗时。
而烛龙监控渠道现已为京购小程序开发者们供给了功用监控目标，咱们能够通过烛龙监控渠道看到对应流程的耗时来作为衡量，小程序发动流程如图：
其中要害的几个监控目标字段和对应含义如下：
| 字段 | 含义 |
|---|---|
| _perf_downloadPackage | 代码包下载耗时 |
| _perf_evaluateScript | 逻辑层 JS 代码注入耗时 |
| _perf_firstRender | 页面初次烘托耗时 |
| _perf_route | 页面切换耗时 |
| _perf_firstContentfulPaint | 初次内容制作时刻（FCP） |
| _perf_appLaunch | 小程序发动耗时 |
| _perf_largestContentfulPaint | 最大内容制作时刻（LCP） |
烛龙监控渠道依据以上几个目标权重和每个目标分值加权平均，计算用户体会值评分（UEI），如图：
三、如何进行功用优化
3.1 代码包体积优化（旨在减少小程序初始化耗时）
从上面的京购小程序发动流程图来看，在app.onLauch履行之前，首要耗时阶段为代码包下载和代码注入。而代码包下载和代码注入的时长，均和小程序逻辑代码体积有关。一般来说，小程序代码包越大，逻辑层代码体积也越大，因而初始化耗时也更长。这儿咱们运用到以下技能：
3.1.1 独立分包
「独立分包」能够独立于主包和其他分包运行。从独立分包页面进入小程序时，不需求下载主包。
开发者能够按需将某些具有一定功用独立性的页面装备到独立分包中。当小程序从普通的分包页面发动时，需求首要下载主包；而独立分包不依靠主包即可运行，能够很大程度上提高分包页面的发动速度。
咱们针对于京购小程序主页，利用独立分包开发了京购极速版主页，并逐渐投放在发现购物进口。通过和正常包对比，极速版主页的发动耗时全体下降了420ms，优化了14.5%的发动耗时，以上收益来自于Android侧的大盘优化作用。
3.1.2 分包异步化
「分包异步化」将小程序的分包从页面粒度细化到组件甚至文件粒度。这使得原本只能放在主包内页面的部分插件、组件和代码逻辑能够剥离到分包中，并在运行时异步加载，然后进一步下降发动所需的包巨细和代码量。
分包异步化能有效处理主包巨细过度胀大的问题。
咱们针对于邻近生活圈频道页面，通过运用分包异步化将主包组件移至分包，将邻近生活圈所占主包空间从126kb下降至39kb，极大地下降了主包代码体积；公共components，通过主页、购物车、我京等模块的共同努力，通过分包异步化从203kb减肥到31kb；分类tab，通过分包异步化138kb减肥到6kb，也特别感谢包含“根底事务研发部”等兄弟部门对减肥工作的协助和支撑。
3.1.3 分包预下载
在运用「分包加载」后，虽然能够明显提高小程序的发动速度，可是当用户在运用小程序过程中跳转到分包内页面时，需求等待分包下载完成后才能进入页面，造成页面切换的推迟，影响小程序的运用体会。分包预下载便是为了处理初次进入分包页面时的推迟问题而规划的。
值得注意的是，独立分包和分包预下载能够合作运用，对于独立分包，也能够预下载主包。
咱们针对于邻近生活圈频道页面将组件进行分包异步化引进之后，下降了邻近生活圈频道各个楼层组件烘托的速度，因而咱们通过在主页装备预下载分包组件的方法，通过提早下载邻近生活圈分包组件，处理初次进入邻近生活圈页面组件烘托推迟的问题。
3.2 代码注入优化
3.2.1 按需注入
咱们能够通过小程序装备，有挑选性地注入必要的组件代码：
{
"lazyCodeLoading": "requiredComponents"
}
「按需注入」启用后，小程序仅注入当时访问页面所需的自定义组件和页面代码。未访问的页面、当时页面未声明的自定义组件不会被加载和初始化，对应代码文件将不被履行，以下降小程序的发动时刻和运行时内存。
值得注意的是，插件包和扩展库现在暂不支撑按需注入。如果需求实现插件按需加载，能够考虑将插件置于一个分包，并通过「分包异步化」的方式异步引进。
3.2.2 发动过程中减少同步API的调用
在小程序的发动过程中，会进行代码初始化并顺次同步履行App.onLaunch,App.onShow,Page.onLoad,Page.onShow等生命周期函数，在此期间应尽量减少或不调用同步API。
咱们常见的容易在初始化阶段调用的同步API有：
-
getSystemInfo/getSystemInfoSync，可尝试运用异步版别APIgetSystemInfoAsync替代； -
getStorageSync/setStorageSync，应只用来进行数据的持久化存储，不应用于运行时的数据传递或大局状况管理。
3.3 首屏烘托优化
页面首屏烘托的优化，旨在让用户更早的看到有内容的页面制作（FCP）或许有含义的页面制作（FMP）。
3.3.1 防止引证未运用的自定义组件
在页面烘托阶段是，会初始化读取当时页面装备和大局装备中运用usingComponents引证的自定义组件，以及组件所依靠的其他自定义组件，引进未运用的自定义组件会影响页面初始化烘托耗时。
因而，当组件不被运用时，应及时从usingComponents中移除。
3.3.2 精简首屏数据
页面初次烘托的耗时与页面的杂乱程度呈正相关。在京购小程序许多事务场景傍边，小程序烘托的页面高度是超过一屏的，但在用户初次进入页面时，超出屏幕的页面内容并没有实践性的含义，因而咱们只需求优先烘托出可视范围内的内容即可。当页面首屏烘托结束后，再继续异步烘托剩余的页面内容。
因而，咱们能够对页面初次烘托的内容做一定的取舍，即：
- 如果页面从上到下是由多个独立的组件组合而成的，那么咱们能够针对不在首屏范围内的组件进行推迟加载；
- 如果页面是由某个列表项翻开构成的，例如主页的feeds流，那么咱们能够通过自动控制列表项的长度进行分页加载，在滑动至接近于底部时再进行更多列表项的加载和烘托。
需求注意的是，与页面烘托无关的数据尽量不放在data傍边，防止影响页面烘托耗时。
3.3.3 提早首屏数据恳求
因为网络恳求都需求一定的时刻，但咱们小程序页面烘托的数据却常常需求依靠服务端的接口回来，在服务端接口回来数据之前咱们页面就可能是空白的或许骨架屏。
为了尽可能早发出中心数据恳求，咱们能够采用微信小程序供给的才能：数据预拉取。
「数据预拉取」使得咱们能够在小程序发动时，由微信客户端通过微信后台提早向咱们服务器拉取中心事务数据，当代码包加载完成时，咱们在京购主页通过wx.getBackgroundFetchData拿到预拉取的数据，便能够更快地烘托出咱们的主页，减少用户等待时刻，详细中心流程如图所示：
3.3.4 缓存恳求数据用于初始烘托
除掉上述的数据预拉取才能，微信小程序供给了wx.setStorage、wx.getStorage等API来进行本地缓存的读写。
咱们在京购主页中，将上一次读取到的直出接口的数据存储在缓存傍边，以便用户在下次初始化主页时，优先从缓存中读取主页直出数据用来快速烘托页面全体视图，待接口实在回来后再进行页面更新。
3.3.5 骨架屏
「骨架屏」用于页面烘托之前，通过一些灰色的区块大致勾勒出页面的概括占位，待页面数据加载完成后，再替换成实在的内容。骨架屏能够有效地防止页面在恳求过程展示白屏，防止用户误以为加载失败而退出小程序；且能够防止不同楼层异步烘托的过程中上下跳动，影响用户体会。
3.4 发版更新频率等其他优化
3.4.1 合理规划版别发布
通过小程序更新机制能够得知，小程序在发动时如果检测到版别更新，会从头获取小程序的根底信息、从头生成初始烘托缓存等操作，然后影响页面发动耗时。过于频繁的发版更新频率可能会导致用户每次从头翻开小程序都需求进行小程序的更新，使得平均发动耗时变长。
因而咱们应提早做好版别规划，控制版别发布更新的频率。
3.4.2 优先运用本地版别设置
通过「优先运用本地版别设置」，判别某些较新的小程序版别无需强制用户更新到最新版别。能够在小程序管理后台「设置」-「功用设置」-「优先运用本地版别设置」进行设置，设置后，当用户运用小程序时，客户端会优先翻开本地版别代码包。若用户本地版别不低于该版别，则优先运用本地版别，后台异步更新最新版别的代码包。若低于该版别，则优先更新到最新版别。
四、总结和展望
4.1 功用优化总结
看到这儿，在了解了京购小程序的功用目标和发动流程后，咱们现已能够很容易地从烛龙监控渠道中，查看咱们所担任事务对应的页面功用数据，及时发现咱们页面的一些功用问题并及时进行优化。
当然，除掉以上论述的几点前端功用优化战略之外，咱们也能够通过考虑与服务端约好新的数据格式，防止服务端传输无效数据导致呼应内容体积过大等思路进行探究。
在通过咱们上述多种优化后，从微信官方后台we剖析中的数据能够看出，京东购物小程序的翻开率从原先的86%提高到90%以上，相比优化之前每天减少近百万用户丢失。
下图是内测阶段京东购物小程序优化前后的真机体会对比，从烛龙监控渠道上看，主页全体冷发动耗时从4800ms左右降至2500ms以下。现在线上灰度过程中，用户随机50%射中优化后版别，后续会依据事务数据评价，逐渐提高灰度份额，全面提高用户体会。
4.2 未来展望
基于咱们当时在功用优化路上的探究和实践，结合实践线上的统计数据剖析，在后续咱们也仍会针对于「页面初次烘托」等耗时占比较大的流程进行深化的实践，在「烘托功用优化」层面做更多的尝试，从精简事务数据层面、尝试新的烘托引擎Skyline等等，为客户供给更加友好流畅的运用体会。
作者：京东零售黄宏峰
来源：京东云开发者社区 转载请注明来源
