小红书自研小程序：电商体验与效果优化的运行时体系设计

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

为了解决上述问题，并快速打通基于小红书体系的支付与账号体系。过去的一年内，我们踏上了自研小程序之路。目前，在小红书店铺主页、 笔记详情、品牌专区、开屏均可唤起小程序。

品牌合作

案例展示

本文将主要介绍小红书进行小程序自研时的一些业务背景及工程化、容器能力的落地方案，以及运行时针对双线程架构 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 的初始化, 同时会加载小程序的基础库代码。

脚本注入结束后，容器会立即通知「运行时逻辑层框架」进行依赖分析、并准备初渲染数据。