1. 布景

小程序在其诞生后的几年内，凭借其简略、轻量、流畅、无需装置等特色，引来了爆发式的增加。伴随小红书电商事务的开展，咱们洞悉到越来越多的商家和品牌大客户有自己定制化需求场景，传统的电商和薯店存在下面三大问题：

为了处理上述问题，并快速打通依据小红书系统的支付与账号系统。过去的一年内，咱们踏上了自研小程序之路。现在，在小红书店铺主页、笔记概况、品牌专区、开屏均可引发小程序。

小红书小程序品牌协作&案例展现

本文将首要介绍小红书进行小程序自研时的一些事务布景及工程化、容器才能的落地计划，以及运转时针对双线程架构bridge，framework才能的规划。

2. 运转时工程才能建造

2.1小程序”运转时”界说

运转时在不同语言中含义有所不同，但根本能够归纳为「运转在代码履行阶段的代码」，相似vue-runtime,供给了关于页面状态的绑架，生命周期的解析，api的调用能；nodejs供给了JS运转时履行才能等。小程序“运转时”则供给了在不同线程内，凭借Bridge音讯通道，进行逻辑调度的才能。

那么能够根本归纳为：运转在小程序代码履行阶段、用于供给在独立线程中操作其他线程的页面（或视图），正确呼运用户交互行为、并调度用户事务逻辑才能的代码。

2.2小程序根底架构

小红书小程序也是对齐业界经典架构进行建造：

经典双线程架构

经典架构下，运转时首要分为烘托层-Render、逻辑层-Service。Service用于与系统才能进行交互，在安全的JS线程内调度用户事务逻辑。而Render则担任承受烘托指令、进行视图的绘制与用户交互的呼应。逻辑层与烘托层则经过js-bridge进行音讯的通讯，容器则担任承受api指令进行端才能的调用。

之所以需求一个独立的线程来履行JS，其首要目的是为了约束JS灵敏性。为了供给一个可用的JS环境，其实也有比较多的计划。比方，咱们能够运用浏览器内核供给的ServiceWorker，来单独运转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脚本的机遇及音讯发送的顺序即可。

3. 运转时根底才能与结构

容器和工程化才能是小程序运转的基石，但小程序之所以能够做到高效开发、并拥有极强的跨渠道才能和优秀的体会，这也得益于在结构底层供给了完善的组件及模块化才能，更有丰厚的api来满意原生场景下各种系统才能调用的述求。

3.1运转时总架构

这张图首要将运转时架构分为了烘托层、逻辑层和jsBridge：

• 烘托层面向事务供给了组件、沙箱、功用搜集等结构才能，这一层事务是无法接触到的

• 逻辑层则在JsContext内供给了invoke层来与端侧进行数据交互

• 逻辑层经过适配层，完结导航、Render和页面实例的管理

• 逻辑层内核首要用于向事务代码的履行环境，供给Page、Component、behavior这类才能，并预置JSPolyfill来保证事务的js正常运转。

• JSONschema则用于界说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 模块完结小程序内的一切组件，包括内置组件和自界说组件安排管理。

小红书侧在烘托层则是ForkVue结构，经过定制Vue的一些才能来完结页面烘托作业。凭借Vue优秀的组件化才能的来完结Page,Component的烘托作业。在逻辑层，则经过音讯保护一棵类vdom树,来完结视图←→逻辑的映射与绑定关系，整个关系大约如下图所示：

3.4事情系统

有了上述根底才能和双线程架构，运转时还需求完结一套事情系统，让UI界面与用户发生互动。事情一般分为两块，一块是服务于用户的手势交互，比方用户的点击tap,长按longtap等事情，另一块则是烘托层交互组件的回调时刻，比方swiper组件的onChange等回调。

在小程序的事情系统下，咱们把这些用户的手势操作和组件回调，进行阻拦与搜集，全部转入音讯行列转发到逻辑线程。每条音讯带着自己的实例ID，找到逻辑层实例进行对应函数的触发。

3.5bridge才能规划

结构侧凭借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规范协议，来完结线程音讯的转发和音讯类型的校验作业。

一个规范的apischema界说大约是这样：

音讯会在JsContext内完结校验，并在校验通往后以序列化的方法完结上述流程的传递。

3.6数据编译才能与JS沙箱

为什么这里要提下数据编译才能和js沙箱呢。由于小程序双线程的结构下，逻辑层经过setData发起页面更新请求，带着的数组字段在被烘托层对应的组件解析时，需求合作小程序的一些语法特性进行特别转化。

在运转时侧，咱们将字段的解析才能与数据字段的处理，都收拢到沙箱环境中进行字段编译。经过沙箱，咱们能够阻拦事务代码关于变量的拜访，然后完结变量的绑架，并合作完结sjs这类才能的完结。一起，沙箱能够有效避免事务动态注入一些变量或函数，带来的变量拜访逃逸的安全问题。因而，沙箱在小程序语法和变量核算的进程中起到了至关重要的作用。

例如，下面这段代码片段:

在编译侧，咱们会将loader上面代码经过ast进行转化：

经过沙箱，咱们能够阻拦到事务对sjs模块拜访，将拜访属性替换为sjs的模块导出，然后完结相似sjs这样的脚本拓展才能。

4. 功用优化与监控

双线程在线程阻隔计划上，将原本在同一线程内履行的脚本、烘托等作业涣散到多个线程内履行，带来了更好的功用。但假如单个webview线程的烘托负担过重或对设备内存占用过大相同会影响到全体的体会。

于此一起，线程阻隔也带来了通讯的损耗，关于一次音讯需求经过屡次序列化和反序列化，音讯序列化的损耗与转发也对功用有着直接的影响。

因而，小程序的功用优化不同于传统的web，需求从结构、通道、容器三方面来考虑。

4.1bridge音讯调度机制

bridge音讯通道的繁忙程度，会在很大程度上影响小程序的功用体现。经过上面关于bridge音讯转发机制的介绍也能够看出，频频的凭借bridge进行音讯转发，意味着音讯要不断进行序列化和反序列化的操作。

实践场景中，数据量小于64KB时，时长根本在10-40ms内。传输时刻与数据量上呈现正相关关系，传输过大的数据将使这一时刻明显增加，因而削减传输数据量是降低数据传输时刻的有效方法。

但是假如数据量较小，确在短时刻内屡次运用bridge，也会导致通道过于繁忙。小红书在bridge侧，经过必定音讯调度才能，将特定场景下的音讯进行聚合，保证一次序列化尽可能在不影响序列化功用的情况下，多带着一些音讯到对应的线程内。

4.2烘托层任务调度与优先级行列

前面咱们从前说到，双线程布景下，小程序的更新机制与事情系统全部都是经过音讯进行处理的，但音讯自身的收发都存在必定的延时性，这就注定了小程序是一个异步通讯的世界。那么在一个异步多线程的场景下，线程之间“生产“和“消费“的音讯的速度会因功用、稳定性等要素而不一致，这时，咱们便要凭借音讯行列的思想来管理咱们的音讯:

有了音讯行列，咱们能够更好的管理结构层抛出的音讯体，但小程序结构内，除了更新音讯和事情音讯外，还有不同的音讯体会与这些结构音讯抢占音讯通道。比方，结构搜集不同的render线程webview内的功用目标，这些功用音讯会与事情音讯共享同一行列。但有些场景下，事情音讯的优先级要远高于功用目标音讯。

此外，不同的烘托层render实例的音讯所拥有的优先级也不同，比方A、B页面在同一时刻段内，因其“栈顶的地位”会因用户操作而不断变化，此刻栈顶页面的结构音讯优先级高于B页面的结构音讯优先级，在底层。咱们运用二叉堆结构来保护优先级行列。

4.3容器预加载

小程序的发动分为冷发动和热发动,从用户的角度看：

• 冷发动：假如用户首次翻开，或小程序毁掉后被用户再次翻开，此刻小程序需求从头加载发动，即冷发动。
• 热发动：假如用户现已翻开过某小程序，然后在必定时刻内再次翻开该小程序，此刻小程序并未被毁掉，仅仅从后台状态进入前台状态，这个进程便是热发动。

一般在容器侧的优化，便是针对冷发动来进行。那么容器的预载，顾名思义，便是在适宜的时刻提前预载小程序容器，预载的一起，会提前进行根底库的下载和烘托容器（webview）的加载。

经过前置容器的初始化机遇，来达到快速换起小程序，进步首屏的优化作用。这是小程序这类容器技能计划常用的优化战略。

4.4功用监控与告警

功用优化的一起，结构侧需求对事务代码的功用和行为有必定感知才能。在底层，咱们经过aop的方法，建造了一套监控和插件机制。在开发阶段，能够感知到事务各项目标的健康状况，事务能够接收到底层结构给出的功用告警信息，并经过告警信息中的修复建议，针对性的进行优化。

事务侧，则能够经过performanceapi拿到这些功用目标，来进行根底功用数据的搜集与上报。

功用告警会结合功用规范阈值来给出提示和修复建议，未来在审阅阶段也会结合这些目标进行小程序健康度的洞悉。

4.5ServiceTiming与RenderTiming

除了卡顿、烘托目标外，为了满意高档开发者洞悉渠道的功用信息的需求，咱们对容器和结构在发动阶段的关键节点，都预留了功用点位。开发者能够经过performance.serviceTiming和performance.renderTiming来别离获取到各个关键阶段的时刻戳信息。

各个线程内所预留的功用点位和其在发动阶段中的方位如下图所示：

5. 总结

以上便是小红书小程序运转时计划的原理解析。

小程序自身是一个依托宿主流量系统衍生出的技能系统，它的价值往往紧贴运用主体的流量，而运用主体自身，又依托小程序的灵敏性及低成本的特色快速完结流量的转化。社交、支付与搜索，这些都是互联网产品供给的服务形状，各大厂商都是结合用户的需求和行为差异进行更开放、安全的技能计划探索，小红书亦是如此。小红书依托用户发生内容，而内容发生产品，那么结合各类消费场景，如店铺、笔记等都能够经过小程序容器快速进行买卖链路闭环。

未来，咱们也将在不同的品牌和赛道上，寻找更多的服务商与品牌大客户商家与咱们一起，一起丰厚小红书的产品服务供给，增加小红书商业收入。技能上，咱们则会不断对齐业界，优化技能架构，在进步结构功用的一起，建立完善的服务市场、巡检机制等来帮助小红书服务商与自开发商家详尽、高效的开发与管理自己的小程序。

小程序是一个比较庞大的技能系统，假如你觉得本文对你有帮助，欢迎点赞转发。咱们后续会依据反应持续展开介绍更多的技能建造细节。

6. 作者信息

哈笛

商业技能组-小程序团队成员，现在担任小红书运转时相关技能开发作业。