原副标题：聚润暗鞘小流程：B2C新体验与效用强化的运转时管理体系结构设计
2022-11-21 12:29:30 译者：宋均益
一、大背景如是说
小流程在其问世后的一两年内，凭借着其单纯、高性能、简洁、无须加装等特征，惹来了爆发式的增长。充斥聚润B2C销售业务的发展，他们洞悉到愈来愈多的店家和国际品牌大客户有自己订制化需求情景，传统的B2C和薯店存在上面三大难题：
为了解决上述难题，并加速贯通如前所述聚润管理体系的缴付与帐号管理体系。过去的一年内，他们走上了暗鞘小流程之路。目前，在聚润店面网页、 讲义详细情况、国际品牌专署、科亮均可唤醒小流程。
责任编辑将主要如是说聚润展开小流程暗鞘时的一些销售业务大背景及产业化、罐子潜能的破冰计划，以及运转时特别针对双缓存构架 bridge，framework 潜能的结构设计。
二、运转时工程建设潜能建设
2.1 小流程 “运转时” 表述
运转时在相同词汇中涵义有所相同，但基本上能归纳为「运转在标识符继续执行期的标识符」，类似于 vue-runtime, 提供更多了对于网页状况的挟持，开发周期的导出，api 的初始化能；nodejs 提供更多了 JS 运转时继续执行潜能等。小流程 “运转时” 则提供更多了在相同缓存内，借助于 Bridge 消息地下通道，展开方法论运维的潜能。
那么能基本上归纳为：运转在小流程标识符继续执行期、用于提供更多在分立缓存中操作方式其他缓存的网页（或快照），恰当积极响应使用者可视化行为、并运维使用者销售业务方法论潜能的标识符。
2.2 小流程基础构架
聚润小流程也是对齐业界经典构架展开建设：
经典双缓存构架
经典构架下，运转时主要分为 渲染层 – Render、方法论层 – Service。Service 用于与系统潜能展开可视化，在安全的 JS 缓存内运维使用者销售业务方法论。而 Render 则负责接受渲染指令、展开快照的绘制与使用者可视化的积极响应。方法论层与渲染层则通过 js-bridge 展开消息的通讯，罐子则负责接受 api 指令展开端潜能的初始化。
之所以需要一个分立的缓存来继续执行 JS，其主要目的是为了限制 JS 灵活性。为了提供更多一个可用的 JS 环境，其实也有比较多的计划。比如，他们能使用浏览器内核提供更多的 Service Worker ，来单独运转 service 层 JS 标识符。或者他们能使用多个 webview 实例来分别承载双端 js 的继续执行环境。
2.3 罐子构架实现
按照经典构架的结构设计，他们需要在三端 (iOS、android、小流程开发者工具) 提供更多面向两线程的罐子计划。在相同的罐子环境下，渲染层和方法论层选用的计划会存在一定差异，聚润三端选用罐子的分布如下：
虽然运转环境存在一定差异，但罐子对于基础库和销售业务脚本的加载顺序是基本上一致的。他们能将整个启动阶段拆解为上面几个期：
首先，当使用者点击时，会经历一个基本上的启动过程。
在这个启动流程的背后，会对应着上面提到渲染层 webview 罐子被加载出来。于此同时，在使用者看不到的地方，罐子会展开方法论层 v8/JsCore 的初始化, 同时会加载小流程的基础库标识符。
脚本注入结束后，罐子会立即通知「运转时方法论层框架」展开依赖分析、并准备初渲染数据。
渲染层接受到 initialData 消息后，会展开后续渲染操作，使用者即刻看到了网页的内容 至此，初渲染的流程基本上结束。
当然，实际的罐子的启动过程中的流程会更加复杂，整个启动流程能用上面的这张图来表示：
黑色、蓝色、橙色分别代表了 端侧、方法论层、渲染层三个缓存
实际情景中，罐子还面临更多的挑战，比如如何确保双缓存的是否 ready，再展开消息的推送等。核心在于，他们通过相同缓存的罐子，完成了网页渲染行为的控制。
能看到，上述启动流程中罐子侧分别在 Render 和 Service 分别注入了 page.render.js 和 service.js 的销售业务标识符。那么如何展开销售业务标识符构建，来分别在双缓存下继续执行呢？这就需要依靠前端产业化的潜能来实现了。
2.4 实现基础构架的产业化潜能
通过前端产业化潜能，他们能对资源展开分类构建，聚润小流程使用 webpack 作为产业化构建工具。通常，小流程的构建分两块，一块是特别针对基础库的打包，一块是特别针对销售业务组件的构建。
基础库的打包需要构建基础库标识符，产出分别用于提供更多运转时框架潜能的render.base.js及service.base.js
而销售业务组件的构建，则相对复杂。一个原生小流程组件或网页通常包含上面四个文件：
通过拆分多个文件，他们能在构建时指定入口依赖，将对应的依赖打入所需要的模块内，在工程建设构建时，需要对文件展开分类打包：
他们使用 loader 作为 webpack 的 entry 入口展开构建，每个页面都会作为一个 entry 分立打包。这使得从行为上来说小流程更像一个 MPA(多页应用)。入口侧会展开 app.json 的校验，对配置以网页维度来展开导出，特别针对小流程销售业务标识符，会分别构建出 page.render.js 和 service.js 分别交给相同的缓存展开加载（如上图）。
构建会将标识符打包成 UMD 格式文件，当在相同缓存内继续执行基础库脚本时，部分脚本会自动继续执行，端侧只需要关注罐子加载 Js脚本的时机及消息发送的顺序即可。
运转时基础潜能与框架
罐子和产业化潜能是小流程运转的基石，但小流程之所以能做到高效开发、并拥有极强的跨平台潜能和优秀的新体验，这也得益于在框架底层提供更多了完善的组件及模块化潜能，更有丰富的 api 来满足原生情景下各种系统潜能初始化的述求。
3.1 运转时总构架
·这张图主要将运转时构架分为了渲染层、方法论层和jsBridge：
·渲染层面向销售业务提供更多了组件、沙箱、性能收集等框架潜能，这一层销售业务是无法接触到的
·方法论层则在 JsContext 内提供更多了 invoke 层来与端侧展开数据可视化
·方法论层通过适配层，完成导航、Render和网页实例的管理
·方法论层内核主要用于向销售业务代码的继续执行环境，提供更多 Page、Component、behavior ·这类潜能，并预置 JS Polyfill 来确保销售业务的 js 正常运转。
·JSON schema 则用于表述 api 标准结构和定义，并通过 js-bridge 层完成端潜能初始化与通讯
3.2 基础潜能分布
为了丰富小流程的基础潜能，初期他们盘点了业界的功能矩阵，尽可能丰富聚润小流程的基础潜能，目前运转时的基础潜能分布如下：
灰色部分为暂未支持的潜能
其中包含了:
·App, Compnent, Page 等基础潜能
·网络、文件系统，设备等 API 潜能
·xhs-view, xhs-button 等面向销售业务的组件潜能
·目前，矩阵列出的功能，在聚润小流程基础库 ≥ v3.32.x 版本上已经得到支持。
3.3 双缓存框架潜能建设
熟悉小流程语法的同学都知道，小流程能通过 Page、Component 来展开非常灵活的组件化开发。通过 selectComponent 、triggerEvent这类功能能非常方便的展开 子 → 父 或 父 → 子 实例的追溯，这就要求框架侧需要维护组件之间的依赖关系。
实现这种构架有多种思路，相同厂商的做法也相同。譬如微信在 Page 管理体系和 Component 自表述组件的实现上就采用了相同的结构设计。微信在渲染侧通过Exparser模块完成小流程内的所有组件，包括内置组件和自表述组件组织管理。
聚润侧在渲染层则是 Fork Vue 框架，通过订制 Vue 的一些潜能来完成网页渲染工作。借助于 Vue优秀的组件化潜能的来完成 Page, Component 的渲染工作。在方法论层，则通过消息维护一棵类 vdom 树 , 来完成快照 ←→ 方法论的映射与绑定关系，整个关系大概如下图所示：
3.4 事件系统
有了上述基础潜能和双缓存构架，运转时还需要实现一套事件系统，让 UI 界面与使用者产生互动。事件通常分为两块，一块是服务于使用者的手势可视化，比如使用者的点击 tap, 长按 longtap 等事件，另一块则是渲染层可视化组件的回调时间，譬如 swiper 组件的 onChange 等回调。
在小流程的事件系统下，他们把这些使用者的手势操作方式和组件回调，展开拦截与收集，全部转入消息队列转发到方法论缓存。每条消息携带自己的实例 ID，找到方法论层实例展开对应函数的触发。
3.5 bridge 潜能结构设计
框架侧借助于 bridge 地下通道能非常方便展开消息的转发。但实际上，一条消息需要经过多次序列化和反序列化，才能到达“目的地”。聚润小流程的 bridge 侧是如何实现的呢？
他们以渲染层事件消息举例，当渲染层收到一条点击 消息，会经过如下几个期：
相同罐子下，对 webview 内核消息的拦截机制相同，ios 使用 messageHandler, android 则使用 console 地下通道拦截消息，但内核底层对消息的处理流程基本上一致。
这个过程能单纯描述为以下几个环节：
·Render 侧发送 postMessage 消息，此时消息需要经过一次序列化转成字符串
·浏览器拦截到消息，反序列化成 JSONObject 并发送到 Naive 罐子侧
·罐子开始展开跨缓存事件分发，并转发消息到 service
·Service 运转环境将消息反序列化成 string，并转成 JS 数据类型，传到 Service 所在的 JsContext 中
·JsContext 中 invokeCallback 函数被初始化
·至此，render 消息已成功转发至 service 层
能看到，这个过程非常复杂，不仅要完成消息的转发，还要完成 jsonObject 和 js 数据类型的互转。为了在两个缓存内方便的完成这种互调，并保证 bridge 的安全线，他们分别在双端分别实现了 handleMessage 和 postMessage 的封装，通过 schema 来表述 bridge 和 api 标准协议，来完成缓存消息的转发和消息类型的校验工作。
一个标准的 api schema 表述大概是这样：
消息会在 JsContext 内完成校验，并在校验通过后以序列化的方式完成上述流程的传递。
3.6 数据编译潜能与 JS 沙箱
为什么这里要提下数据编译潜能和 js 沙箱呢。因为小流程双缓存的框架下，方法论层通过setData 发起网页更新请求，携带的数组字段在被渲染层对应的组件导出时，需要配合小流程的一些语法特性展开特殊转换。
在运转时侧，他们将字段的导出潜能与数据字段的处理，都收拢到沙箱 环境中展开字段编译。通过沙箱，他们可以拦截销售业务标识符对于变量的访问，从而实现变量的挟持，并配合完成 sjs 这类潜能的实现。同时，沙箱能有效防止销售业务动态注入一些变量或函数，带来的变量访问逃逸的安全难题。因此，沙箱在小流程语法和变量计算的过程中起到了至关重要的作用。
例如，上面这段标识符片段:
在编译侧，他们会将 loader上面标识符通过 ast 展开转换：
通过沙箱，他们能拦截到销售业务对 sjs 模块访问，将访问属性替换为 sjs 的模块导出，从而实现类似于 sjs 这样的脚本拓展潜能。
性能强化与监控
双缓存在缓存隔离计划上，将原本在同一缓存内继续执行的脚本、渲染等工作分散到多个缓存内继续执行，带来了更好的性能。但如果单个 webview 缓存的渲染负担过重或对设备内存占用过大一样会影响到整体的新体验。
于此同时，缓存隔离也带来了通讯的损耗，对于一次消息需要经过多次序列化和反序列化，消息序列化的损耗与转发也对性能有着直接的影响。
因此，小流程的性能优化相同于传统的 web，需要从框架、地下通道、罐子三方面来考虑。
4.1 bridge 消息运维机制
bridge 消息地下通道的繁忙程度，会在很大程度上影响小流程的性能表现。通过上面对于 bridge 消息转发机制的如是说也能看出，频繁的借助于 bridge 展开消息转发，意味着消息要不断展开序列化和反序列化的操作方式。
实际情景中，数据量小于64KB时，时长基本上在10 – 40ms内。传输时间与数据量上呈现正相关关系，传输过大的数据将使这一时间显著增加，因此减少传输数据量是降低数据传输时间的有效方式。
但是如果数据量较小，确在短时间内多次使用 bridge ，也会导致地下通道过于繁忙。聚润在 bridge 侧，通过一定消息运维潜能，将特定情景下的消息展开聚合，确保一次序列化尽可能在不影响序列化性能的情况下，多携带一些消息到对应的缓存内。
4.2 渲染层任务运维与优先级队列
前面他们曾经提到，双缓存大背景下，小流程的更新机制与事件系统全部都是通过消息展开处理的，但消息本身的收发都存在一定的延时性，这就注定了小流程是一个异步通讯的世界。那么在一个异步多缓存的情景下，缓存之间“生产“和“消费“的消息的速度会因性能、稳定性等因素而不一致，这时，他们便要借助于消息队列的思想来管理他们的消息:
有了消息队列，他们能更好的管理框架层抛出的消息体，但小流程框架内，除了更新消息和事件消息外，还有相同的消息体会与这些框架消息抢占消息地下通道。比如，框架收集相同的 render 缓存 webview 内的性能指标，这些性能消息会与事件消息共享同一队列。但有些情景下，事件消息的优先级要远高于性能指标消息。
此外，相同的渲染层 render 实例的消息所拥有的优先级也相同，比如 A、B 网页在同一时间段内，因其“栈顶的地位”会因使用者操作方式而不断变化，此时栈顶网页的框架消息优先级高于 B 网页的框架消息优先级，在底层。他们使用 二叉堆 结构来维护优先级队列。
4.3 罐子预加载
小流程的启动分为冷启动和热启动, 从使用者的角度看：
冷启动：如果使用者首次打开，或小流程销毁后被使用者再次打开，此时小流程需要重新加载启动，即冷启动。
热启动：如果使用者已经打开过某小流程，然后在一定时间内再次打开该小流程，此时小流程并未被销毁，只是从后台状况进入前台状况，这个过程就是热启动。
通常在罐子侧的强化，就是特别针对冷启动来展开。那么罐子的预载，顾名思义，就是在合适的时间提前预载小流程罐子，预载的同时，会提前展开基础库的下载和渲染罐子（webview）的加载。
通过前置罐子的初始化时机，来达到加速换起小流程，提高首屏的强化效用。这是小流程这类罐子技术计划常用的优化策略。
4.4 性能监控与告警
性能强化的同时，框架侧需要对销售业务标识符的性能和行为有一定感知潜能。在底层，他们通过 aop 的方式，建设了一套监控和插件机制。在开发期，能感知到销售业务各项指标的健康状况，销售业务能接收到底层框架给出的性能告警信息，并通过告警信息中的修复建议，特别针对性的展开强化。
销售业务侧，则能通过 performance api 拿到这些性能指标，来展开基础性能数据的收集与上报。
性能告警会结合性能标准阈值来给出提示和修复建议，未来在审核期也会结合这些指标展开小流程健康度的洞悉。
4.5 ServiceTiming 与 RenderTiming
除了卡顿、渲染指标外，为了满足高级开发者洞悉平台的性能信息的需要，他们对罐子和框架在启动期的关键节点，都预留了性能点位。开发者能通过 performance.serviceTiming和performance.renderTiming 来分
各个缓存内所预留的性能点位和其在启动期中的位置如下图所示：
五、总结
以上就是聚润小流程运转时计划的原理导出。
小流程本身是一个依托宿主流量管理体系衍生出的技术管理体系，它的价值往往紧贴应用主体的流量，而应用主体本身，又依赖小流程的灵活性及低成本的特征加速完成流量的转换。社交、缴付与搜索，这些都是互联网产品提供更多的服务形态，各大厂商都是结合使用者的需求和行为差异展开更开放、安全的技术计划探索，聚润亦是如此。聚润依靠使用者产生内容，而内容产生商品，那么结合各类消费情景，如店面、讲义等都能通过小流程罐子加速展开交易链路闭环。
未来，他们也将在相同的国际品牌和赛道上，寻找更多的服务商与国际品牌大客户店家与他们一起，共同丰富聚润的商品服务供给，增加聚润商业收入。技术上，他们则会不断对齐业界，强化技术构架，在提高框架性能的同时，建立完善的服务市场、巡检机制等来帮助聚润服务商与自开发店家细致、高效的开发与管理自己的小流程。
小流程是一个比较庞大的技术管理体系，如果你觉得责任编辑对你有帮助，欢迎点赞转发。他们后续会根据反馈继续展开如是说更多的技术建设细节。也欢迎访问他们的小流程官方网站与他们交流：
·聚润小流程如是说：https://miniapp.xiaohongshu.com/docs/guide/miniIntroduce
·聚润社区专业号：https://pro.xiaohongshu.com/
·你也能通过 https://github.com/redengineer/redmini 与他们展开交流
六、译者信息
哈笛
商业技术组 – 小流程团队成员（[email protected]），目前负责聚润运转时相关技术开发工作。
