本文主要讲述1688小程序随着业务加快节奏，技术上在做什么支撑业务的迭代、互动玩法的多样性；以及面向未来的能力布局。

2.1.1 渲染架构

双线程运行环境

小程序是在应用内的一个嵌入式应用，所以给予到具体的业务应用上有诸多限制：比如更少的内存，更多的运行限制等。为了使得应用在这种捉襟见肘的计算资源下还能接近原生的体验，小程序提出了逻辑层/渲染层双线程分离的方案。

渲染层基于系统的webview实现（微信类小程序还最新提供了skyline渲染引擎，使得体验更接近native），逻辑层基于传统的js实现，这两个线程的通信会经由native客户端做中转，逻辑层发送网络请求也经由native转发。这种实现相比于传统web类应用最大的好处就是使得逻辑层进行复杂运算时不会阻塞渲染层的渲染，大大增加了应用运行的流畅度；缺陷两个线程间的通信全部是异步的，这就导致UI刷新存在部分延时，所以需要通过一些手段尽量减少通信次数、解决刷新的时序问题。

小程序渲染原理

由于小程序特殊的双线程架构以及极小的内存使用空间，小程序很难像传统react应用一样使用类似虚拟dom的方案（一个是因为虚拟dom内存占用较大，一个是因为虚拟dom不论是放在哪一层都存在较多的异步同步）。

小程序后续也支持了类似vue的MVVM双向绑定方案（以微信小程序为例，使用的写法将值绑定起来，不过兼容性较差用得不多），图为小程序的双线程架构天然适合MVC架构方案

2.1.2 体验工程

在1688微信小程序起步的这一年里，我们从开始刀耕火种、一切以业务迭代速度为先，到逐步发掘核心体验问题并优化，沉淀了很多基于小程序的独特体验优化方案。下面将从搜推、商详、旺旺等核心链路进行阐述。

2.1.2.1 搜索推荐

在微信支付链路打通后，由于我们急需快速产生可用的小程序能力，并使其体验达到高可用的水平，第一版搜索推荐诞生了。但是随着业务DAU的缓慢增长，我们发现我们的用户中低端机的占有量仍比较高，并且这版本的搜推列表在下拉加载超过200个商品时就会出现无法忍受的卡顿（甚至无法滚动下去），于是乎从针对列表的性能优化引入，我们进行了一波关于首页的重构（核心还是feeds列表，也顺带修改了其它内容）。

优化前

优化后

最先做的就是规划逻辑的分离。我们首先将一个列表的组成分为了以下几个部分：卡片数据获取层、结果数据映射层、纯列表渲染器、分页刷新控制器、滚动动画控制器；在逐步击破。

数据获取层&映射层

由于我们想要做到之后feeds流的复用，我们为不同场景的feeds流定义了不同的scene，其中不同的scene也映射到了不同的mtop接口和结果转换逻辑，最终产出渲染层可用的统一数据结构。并且这份映射逻辑也会复用在其它模块。经过这份逻辑抽离，我们成功将其应用在所有接口规范不同的feeds模块上，并且可以快速拓展诸多业务逻辑。

列表渲染器

最传统的解决无限滚动feeds流卡顿问题的方案是基于绝对位置计算的虚拟滚动方案。但这种方案无法在小程序中直接使用，因为小程序直接计算高度并使dom发生变化的开销是非常大的，并且feeds的卡片高度也不是确定的。为了在有限次的dom变化中使得在屏dom节点数量可控，这里针对传统的虚拟滚动方案升级优化。

分页刷新控制器、滚动动画控制器

我们将下拉刷新、上拉加载等通用化的逻辑抽离为一个组件，使得后续所有小程序内需要滚动的地方均可直接复用。滚动动画我们从原本的js逻辑控制改为了使用微信提供的animationAPI，这是微信提供的在逻辑层生成指令、在渲染层执行的方法，可以避免动画逻辑需要通信，达到接近原生的效果。

其他逻辑优化

比如将feeds列表的接口做缓存（加快二次加载首屏速度）、加载中骨架屏、组件加载前元素占位等。

优化效果

整体优化前：346个商品节点总数为4388个，且出现长耗时

整体优化后：630个商品wxml节点仅1238个，页面无长耗时、无卡顿

代码部分经过此次逻辑修改，首页的代码量减少了1000行，并将多份逻辑解耦到多个文件中，为后续不同业务同样功能的接入做铺垫，后续的旺铺、采购车等业务均使用了首页拆分的能力进行优化。

2.1.2.2 商品详情

商品详情是电商应用最核心的页面，其加载速度和使用体验直接影响了其转化到订单的比率，所以针对od页的加载优化是一个比较关键的命题。下面将分别阐述我们针对od的加载速度和使用体验的优化。

优化前

优化后

接口性能

a. 耗时分析

通过OD代码分析、Arthas抓包的方式，进行耗时排查

• 三个耗时瓶颈中，“请求获取领域数据源” 和 “天搭渲染” 为调用上游HSF接口，OD侧优化效果有限。

• 因此，把优化重点放在 “模型上下文填充” 的逻辑里。

b. 优化前逻辑

Builder列表串行升级改造为并行执行

c. 异步pipeline改造

然而，随着OD组件的不断堆积，目前已有四五十个执行不同功能的 Builder，依赖关系错综复杂，无法实现完全并行。新的思路：梳理 Builder 依赖关系，异步 pipeline 改造，根据拓扑排序，实现尽可能的并行

• 首先找到图中所有入度为0的顶点，这些顶点相互之间没有依赖关系，可以并发执行

• 删除相关顶点及所有边，形成一个新的图结构

• 重复前序操作

• 每次单独记录当前层无相互依赖的builder列表

• 最终得到串+并执行任务列表

d. Builder依赖关系梳理

以下是梳理得到的数十个Builder的依赖关系DAG图

最终接口性能整体服务接口优化使原有RT降低了50%；

预载方案

od加载出完整数据的步骤比较简单：接口获取到数据，然后将其经过逻辑处理后渲染出来，完事了。只要数据成功获取到，逻辑处理和渲染都不是什么难题，所以od加载的核心卡点在数据获取上。

前端上使用了接口预读方案。目前商品详情是在od页加载完成后才进行接口读取，从点击推荐页的商品后，到商品页首屏加载完成中间的这个时间，网络层什么都没有做（跳转？跳转也算时间哦）。所以优化的根本原理是利用起来前端路由跳转的这段时间，在发起跳转命令的时刻就进行接口请求。这里使用了小程序的getOpenerEventChannel API，这是一个建立在当前页面和上一页面的事件通道，正是通过这种方式将页面跳转前获取到的数据传递给了当前页。通过这种优化方案我们将od首屏加载时长平均下降了200ms；

动画

在页面内容相同的基础上，最能使得体感更加流畅的方式就是动画。与搜推列表类似，我们从js逻辑动画修改为了使用wxs方案（wxs即为可以在渲染层上直接进行编程的方案，无需通信即可控制元素css状态）。我们修改了如下组件，使其像🍫（广告位招租）一样丝滑

• header栏，根据滚动进度控制透明度和高度

• 主图，根据滚动进度控制高度，实现快速查看到页面详情

• 左上角 后退 按钮，根据滚动进度控制透明度

• 右下角 回到顶部 按钮，根据滚动进度控制透明度

• 轮播图 视频到图片的tab滑动动画

后续优化

其实od加载优化的终极方案就是在进入od前就获取到od的各种核心数据（如商品标题、商品主图等），之后在od页面渐进式地逐步渲染；后续将结合各业务逻辑逐步改造（以推荐列表为例，每一项均需要提前获取到od的一些关键信息优先渲染类似主图、标题、详描等。

2.1.2.3 旺旺消息

不论是售前的询盘，还是售后的服务，均需要与商家沟通这份桥梁。所以我们也针对旺旺的链路进行了优化。这次优化分为两部分，旺旺的消息列表和旺旺的消息详情

消息列表

最早我们小程序的消息列表是h5的版本。但是由于h5只有在曝光后才会开始加载，所以在进入消息列表页时需要进行漫长的等待（足足2s），并且也没有办法及时获取到有多少未读消息，于是乎我们考虑将其升级为原生化的列表。

思路是将消息列表改造为原生化后，我们就可以在应用进入时在后台直接初始化消息列表sdk，这样就可以省去列表获取的时间，也可以在后台实时获取到未读消息数，渲染到消息栏。消息列表的sdk是基于钉钉imsdk实现的，淘天在web上基于imsdk做出过一版封装，于是我们就将其clone了下来，针对小程序做了魔改：比如将基于web的websocket修改为基于小程序的CustomWebSocket、将默认接口的鉴权token获取修改为了基于小程序鉴权改造的mtop接口获取等等。

当然，坑远远不止这些，由于小程序只识别es5语法，所以我们将一些不支持es5（也无法通过babel编译到es5）的逻辑干掉了（此处感谢钉钉imsdk的 龙允、闲鱼的前端大佬 灼升 提供的技术支持），并将其打包为一份es5的imsdk.js文件供小程序使用（为什么不借助小程序的编译打包生成，因为我们是基于原生开发）。虽然经过这次修改消息列表做到了秒开，但这使得我们的包体积增加了300kb。至于为什么不能使用动态加载方案，借用小程序跨端框架Taro的一句话：

平台客服&旺旺消息

平台-买家：小程序目前售后还有所欠缺（难退无赔无任何保障），只有电话客服无法举证，无法多次连续与平台沟通，消费者无法解决问题，因此只能投诉到微信平台。处理反馈和投诉只能人工介入，处理不及时会降低小程序的体验分，严重甚至会导致小程序下架。

商家-买家：小程序的旺旺消息非常简陋，只能文本交流，体验不好会非常影响转化。

升级后效果

方案选型

方案1: 小程序原生开发旺旺消息页，由于旺旺卡片数量巨大，有几百种，工作量巨大，旺旺侧团队粗估60人日。

✅方案2: 复用pc的旺旺消息聊天页面，做小程序侧的兼容，主要是登录态和卡片点击功能兼容，工作量主要在于梳理卡片以及前端兼容，分3期逐步兼容卡片进行上线。

• 登录态适配： 为了解决进入旺旺页需要登录的问题，对第三方包@ali/im-sdk-saas进行了登录态适配。对卡片点击跳转的页面进行登录态适配，包括选择订单页面，FAQ页面等。

• 平台客服卡片梳理与兼容： 对平台客服的所有卡片进行了细致的梳理，并特别针对FAQ卡片实现了DX渲染实现。此外进行了交互方面的兼容，对链接进行了拦截控制，比如：商品点击原本是打开新页面，会自动唤客户端，需要禁止，改造为跳转小程序od、选择订单原本是打开新页面，改造为半窗交互、点击卡片“去支付”打开支付页面，然而小程序有可能未进件，支付不了，改造为跳转订单详情

• 聊天消息新增图片发送功能： wap旺旺没有发送图片的能力，因为图床登录态没法适配。因此开发了新的接口，背后用纵横平台存储图片，实现了发送图片聊天的能力。这一功能的实现，为用户提供了更加丰富的沟通方式，提升了沟通效率。

• 卡片展不了的解决方案： 为了解决无法展示卡片时可能引起的用户焦虑，搭建了新的sop流程发送转人工卡片。

2.1.2.4 旺铺

围绕商家私域运营能力，从0-1建设极简旺铺，强化商家分享和私域运营。

sticky效果

难点攻克：原生有下拉刷新的scroll-view内部无法实现sticky效果

产品给出设计稿包括2层吸顶效果，第一层是商品、新品、分类、动态等tab切换吸顶，第二层是新品上新时间吸顶。so easy！实际动手发现根本吸不了顶。

原因是下拉刷新的干扰，启用下拉刷新（refresher-enabled）会动态修改 的结构和样式（例如添加滚动事件或覆盖层），进一步破坏子元素的定位逻辑。

那么方案就来了，一个就是重新实现scroll-view下拉刷新，另一个就是将吸顶元素放到scroll-view外面。

关键流程

1. onTouchStart 手指按下

如果在顶部，没有在下拉中，没有禁用，记录开始位置pageX, pageY。

2. onTouchMove 手指移动

更新下拉条高度，内容区用translate3d进行移动。

更新下拉状态，如果大于下拉阈值，设置为下拉状态，否则设置为收起状态。

3. onTouchEnd 手指放开

松开时高度超过下拉阈值则触发刷新，加载更多数据。

否则设置下拉条高度为0，回弹。

4. 接收外部请求状态

如果请求完成，触发回弹动画。

否则，显示刷新中，设置超时时间，超时结束下拉，触发回弹动画。

最终效果：

回顶部效果

点击回顶部浮球，设置scrollTop为0，滚动到顶部。在滑动的过程中，点击滚动到顶部，会出现白屏，然后一直没有恢复。滚动与设置冲突，在滚动过程中，小程序的渲染线程可能因同时处理 scrollTop 的设置而陷入死锁，导致界面卡死。解决方式是在惯性滚动结束后，再操作修改scrollTop。

2.1.2.5 采购车

随着1688微信小程序完成基础技术架构送代并进入精细化运营阶段，提供基于基础下单链路的采购车功能已成为提升用户使用体验的核心诉求。然而，采购车作为整个电商体系中最为复杂的功能，在微信小程序这种对于应用性能占用节省到极致的场景是一个比较大的挑战。

若直接从0开始建设采购车，成本极其恐怖。经过调研，我们发现1688其它业务的采购车均使用基于AStore（一种快速搭建电商平台的解决方案）的架构，所以我们也将效仿友团队的做法直接进行接入。使用这种方案后，服务端是可以直接复用的（这里感谢 家臻 的技术支持），唯一的卡点在于AStore是不支持原生小程序DSL的。所以我们按照如下的架构针对AStore服务进行了封装。

在关键数据变化时，我们会设置一个缓冲区，将一次功能的所有变化捏合到一起，同时推送给视图层以进行渲染层重绘的触发。这可以减少逻辑层和渲染层之间的通信次数，提升页面渲染性能。

通过这种方案，我们做到了购物车整体的权责分离，各个模块可以按照不同的实现方式进行实现。数据模型层的内部逻辑封装也使得不了解AStore的同学可以通过其它3层快速上手购物车业务的迭代开发。对于购物车功能的升级也可以在层的维度去做，而不需要针对整体功能进行重构。

最终效果如下：

2.1.3 性能&监控

基于「无侵入式切面代理」的核心机制

小程序生命周期代理：通过重写 Page、Component 等原生构造函数，在 onLoad、onShow、onHide 等关键节点注入埋点钩子，实现用户行为轨迹的全链路追踪（如pv, uv, 页面停留时长、组件曝光率）。

API函数劫持：劫持 wx.request、wx.navigateTo 等高频接口，通过Proxy模式实现请求耗时、成功率、路由跳转路径的自动采集，避免手动埋点的代码冗余。

2.2.1 SCRM平台

微信生态丰富复杂，怎么样将微信生态的底层能力与业务相结合，比如公众号的触达、小程序的高效裂变、以及公众号与小程序的相互结合等。如何充分发挥它们的作用？1688微信SCRM平台应运而生。

作为微信生态运营的利器，平台具备像微信网关、消息触达、授权免登、行为分析等能力，将高效助力1688业务连接微信生态，精准触达客户、持续提高运营效果。

鉴权SDK

1688小程序依托于微信内小程序为载体，所有接口需要在内部安全的流程上叠加外部鉴权逻辑，1688小程序在开发过程中需要协同全域业务一起进行开发（商品、搜推、旺铺、购物车、交易、订单等），在开发过程中几乎会涉及全站接口，且会频繁发生接口变更。

传统方案接口走开放平台配置鉴权，中心化配置鉴权方案在大规模高频次接口变更下，一个是影响业务迭代速度，另一个全站流量巨大，走中心化网关增加链路负载，影响整体稳定性。

因此一种去中心化轻量鉴权SDK，在保障业务稳定性的同时，能够持续快速的进行业务迭代。

账号归一

在建设1688小程序和公众号的过程中，遇到几方面问题，一方面是微信内各个触点的身份归一问题，比如找工厂小程序、掌柜上新小程序、1688订阅号等，这些都没有打通，每一个微信用户在不同的触点都有不同的账号身份，无法实现联动，另一方面，微信触点的用户和1688APP账号身份归一的问题，无法识别微信用户对应站内app的身份，在做微信用户运营的时候缺乏数据输入，只能盲推。

因此需要一套身份归一的方案，将1688体系下所有小程序、公众号关联的同时，能和站内用户实现身份归一的映射，不仅将散歩在各小程序的用户聚拢，也能通过站内已有的购物行为实现微信用户的精细化运营，提升可运营规模和转化效率。

整体身份归一流程

1. 在微信域内一个新用户在关注公众号的时候会获取到公众号的唯一标识：appID（1688公众号），用户在公众号的唯一标识：openID（1688公众号），用户在微信域内的唯一标识：unionID（1688平台）。如果该用户注册了阿里系小程序，通过回调我们会获取到用户的小程序标识appID（1688小程序），用户在小程序内的唯一标识：openID（1688小程序），以及用户在微信域内的唯一标识unionID（1688平台）。通过unionID的映射可以映射到1688公众号、1688小程序同一个用户上并关联起来。

2. 用户在站内登录账号的时候，手机号可以作为用户的唯一标识，利用该手机号可以关联到用户登录小程序的账号，取到用户在1688微信域内的uinionID，从而进一步关联到用户在整个1688微信域内使用的产品，包含不限于（1688小程序、1688企业微信、1688公众号、1688视频号等）。

事件中心

事件中心是用户对于公众号、小程序的所有行为触点控制。基于用户的行为可以定制化做不同的响应处理，因此我们决定建设一个微信事件中心，一方面是处理微信官方事件推送，预授权码，三方授权事件等，另一方面是捕捉用户行为，拦截进行定制化业务处理的关键触点通道，可以基于事件中心做用户行为分析、用户触点推送和业务定制化等多种用户运营策略

触达体系 

在平台基于微信生态多渠道运营的情况下，传统的单一渠道触达方式难以满足用户日益增长的个性化需求，且难以有效提升信息的到达率和用户的参与度，人群特征的差异性决定了不同的沟通方式与渠道对于不同用户的触达效果，因此整个触达体系围绕触达效率、增强用户体验，定义了基于人群特征的多渠道任务触达机制。

触达体系一期实现了最基本的多渠道分人群的触达任务机制，具有两种运作模式（事件驱动，非事件驱动）。

未来触达体系二期会基于“人群”、“渠道”以及“消息”，深度结合AI，提供定制化智能交互方案。通过用户数据深度挖掘用户喜好，通过AIGC丰富消息结构，构建基于用户行为的实时交互和基于内容识别的智能交互两种交互模式，强化触达效率。

域名安全

由于外部微信开放平台的要求，我们请求外部的IP需为固定出口IP，并在微信开放平台侧进行IP白名单配置。目前集团的统一出口IP微动态性的，IP段过多。

在微信平台侧统一了收口IP进行白名单配置才允许访问，另一方面也可以通过统一IP出口做公共层事件处理和转发逻辑，列如token校验、流量网关、消息中心等。

2.2.2 搭建投放

现在集团内存在大量的搭建体系/动线投放解决方案，但是均无法在小程序中直接使用。并且由于小程序没有办法直接动态渲染外部元素，所以基于传统的搭建体系做小程序端的适配也成为了一条死路。为了尽快服务主站大促联动、会场投放等需求，我们提供了基于天搭搭建体系的小程序插件，并自建了小程序原生的投放能力。

天搭适配

站内外大促会场的联动是特别频繁的场景，通常在小程序中通过webview可以直接将活动会场进行嵌入。但是在小程序端还没有办法直接使用，下面是我们针对小程序定制特有解决方案：

• 会场中的商品并未全部开通微信支付。这里我们通过选品规划限定开通微信支付的且符合微信小程序售卖规则的商品，并通过投放位个性化推荐方案透出商品。

• 会场中的商品、店铺默认都跳转到相应的h5。这里我们撰写了一个微信侧的拦截插件，通过拦截a标签的点击和window.open事件的复写来识别相应跳转链接，并通过微信官方提供的jssdk 调用小程序原生的方法跳转到对应页面。

• 会场分享，开发特有插件，专门调用小程序jssdk的postMessage API将需要分享的内容通信到native端缓存起来，并在用户触发分享的时候使用缓存内容。

此外，我们还开发了小程序通用feeds流、小程序所见即所得组件等通用组件，这些组件已经默认接入了微信支付、跳转等能力，可以作为活动会场没有内容时的兜底。下面是我们基于这些能力搭建的最基础的会场。（麻雀虽小，五脏俱全）

动线投放

因为已有的投放平台没办法支持小程序的投放诉求，为了支撑小程序业务的快速迭代，逐步自建小程序体系的投放组件&配置，整体支持以下几种特性：

• 配置化：内容均转换为schema配置存储到服务后台，支持千人千面、优先级、疲劳度、在线时间控制等；小程序唤起时读取这些schema配置进行动态渲染。这样可以使得各种营销需求不依赖小程序发版，做到随配随上。

• 环境间隔离：预发环境/正式环境间是互相隔离，这提供了配置完成后的测试方式，也可以及时发现配置问题。

• 部分配置坑位定制：由于部分内容存在强定制场景，仅依赖平台提供的可视化配置可能无法满足需求，这时候就需要技术同学介入，通过组件化的方式嵌入整体的配置中。

通过上面的配置逻辑，我们实现了配置的按时上下线、分渠道人群的投放、小程序不同坑位的适配。下面是小程序接入1688 3.24拿货节 大促后的小程序效果：

目前我们的modal框、首页辐条等功能全部是在小程序侧实现若干模板后通过配置注入的，也就是静态渲染方式。之后我们会考虑开发一份动态渲染引擎，实现动态化渲染方案（目前还在方案讨论阶段）。

2.4.1 微信支付能力

1688微信小程序通过直连方案使用微信支付，实现1688场景内线上交易闭环能力，从而1）提高微信内广告投放最终交易下单效率，2）达成线下交易线上化，3）针对私域创造分享裂变玩法拉动用增缩短交易路径。

2.4.2 商家进件能力

建设优化商家进件链路的，进件成功率S1-S2由40%提升到70%。

同时升级商家私域运营能力，由全店进件，升级为品/商进件解耦，提供商家私域运营能力，提升商家进件意愿，降低进件注销率。

2.4.3 平台营销能力

建设微信域直连方案下的平台营销能力，在微信支付建立资金运营账户，发放渠道专享红包在微信渠道的补差核销和退回。针对1688微信小程序的平台出资的权益能力建设，建成后通过权益分别运营人群、货盘、玩法等，构建完整的建预算、立模版，用户端发放、交易核销、退货权益回收完整的全链路能力，带来业务新增量。

2.4.4 商业化外投能力

小程序缺失商业化广告能力，因此考虑接入广告引擎，可提效广告效果，以及带来整体商业化收入提升；现有广告承接链路由H5转为小程序，用户体验提升，带来持续活跃的同时，小程序用户规模和GMV也会随之提升；

承接商业化广告能力效果，包括微信域信息流广告（QQ，朋友圈，腾讯视频等）、微信搜一搜广告、抖音广告。

v1- H5承接

v2- 信息流广告

v2- 信息流广告

2.4.5 分享唤端能力

沉淀整个APP小程序分享唤端能力，使用微信小程序承接流量相比传统H5页面，具有以下核心优势，尤其在用户转化、社交裂变和商业闭环方面更为突出：

1、入口更浅，转化路径更短：用户点击分享卡片能直接打开小程序，无需跳转浏览器，减少页面加载和流失风险；用户可将小程序添加到“我的小程序”或桌面，后续访问无需重复搜索，提升复购率。

2、原生体验，流畅度高：小程序代码包预加载到微信本地，首屏速度比H5快3-5倍，弱网环境下优势更明显；支持下拉刷新、长按菜单、扫码等系统级交互，操作体验接近原生APP，避免H5的卡顿感。

3、一键调起微信支付，支付成功率比H5高30%以上（无需输入密码或跳转）；直接获取用户微信绑定的手机号、地址（需授权），降低填写门槛；无缝使用客服消息、订阅通知，提升用户触达效率。

1688APP分享链路流程图

H5承接分享 VS 小程序承接

H5承接

小程序承接

如上文所述，我们目前的小程序由于只投放在微信平台，所以使用的原生DSL直接进行开发的。为了响应1688技术部的跨端协同战役，以及为了之后更加快速地沉淀卫星小程序and将1688小程序投放在支付宝、抖音等平台，我们将在这个财年将小程序修改为跨端化的DSL。下面将阐述我们的技术选型之路以及如何迁移产生第一个小型demo，如果大家有什么更好的想法也欢迎在评论区交流：

3.1.1 技术选型

规划阶段的第一件事就是技术选型。小程序跨端化在前端业界是一个比较常见的命题，业界和集团内部也出现了许多解决方案。目前，小程序跨端的解决方案按照不同的跨端方法论分为两种类型：

• 编译时方案：通过撰写特殊的编译器将高级语言（React、Vue等DSL）转换为各个小程序平台的原生语言（wxml，axml等），为静态方案（严格来说，也存在轻量级的运行时垫片）

• 运行时方案：通过提供一个运行时垫片（类似React的虚拟dom引擎），将React语法编译为js后直接运行在这个垫片上，为动态方案（严格来说，也存在部分逻辑的静态编译）

下面提供了原生、编译时、运行时3个方案的优劣比较：

综上所述，我们决定采用运行时方案进行改造。目前业界比较成熟的方案有三种：由DCloud公司提供的uni-app框架、由京东提供的Taro框架、由阿里集团提供的ice3框架。以下为这三种框架的优劣比较：

综合考虑采用taro方案，社区活跃，相对其他方案有以下优势：

1. dsl支持react，匹配集团主流react框架，可以接入集团研发体系及基建能力；

2. 支持混编，基于taro框架实现在不影响现有需求迭代的情况下，将原生小程序平滑切换至跨端方案；

借着本次跨端改造的机会，支持快速跨端的Taro组件库应用而生，我们需要集百家之长，抽象出组件库的几大特性

• 分包的。鉴于微信小程序treeshake效果较差，我们索性将不同组件分为不同的npm包，按需使用。集团内的O2正好提供了基于lerna的tnpm多包发布体系，完美适配！

• 样式规范是通用的。这样做是因为将来我们会快速产出各种垂直类小程序，这些小程序的样式主题等均会产生区别；并且我们也服务了诸多老年客户，大字版小程序似乎也成为了一个强诉求。所以我们根据设计师的designtoken抽离出了一份统一的样式变量列表，业务方只需维护一份变量列表即可实现不同样式的组件。组件侧为了方便使用，借助了cva这个库实现样式的逻辑化，业务侧只需传入不同的参数即可快速生成样式规范统一的组件。

基于此，我们诞生了一个demo项目，其中使用rollup作为组件打包的手段。通过postcss的样式分离逻辑，这样我们将组件库的样式和交互逻辑完全地拆开了。以下为基础button按钮组件的代码：

/* eslint-disable id-length *//** 因为大小这个东西变量名确实是短的，所以缩短些  */import { View, Text } from '@tarojs/components';import { cva } from 'class-variance-authority';import React from 'react';
// 样式规范部分const variants = {  size: {    l: 'taro-button-l',    m: 'taro-button-m',    s: 'taro-button-s',    xs: 'taro-button-xs',  },  fill: {    solid: '',    outline: '',  },  type: {    primary: '',    minor: '',    assist: '',    notallowed: '',  },  disabled: {    y: 'taro-button-disabled',    n: '',  },};const buttonStyle = cva(['taro-button'], {  variants,  compoundVariants: (Object.keys(variants.fill) as (keyof typeof variants.fill)[])    .map((fill) => {      return (Object.keys(variants.type) as (keyof typeof variants.type)[])        .map((type) => {          return {            fill,            type,            className: `taro-button-${fill}-${type}`,          };        });    })    .reduce((acc, cur) => acc.concat(cur), []),  defaultVariants: {    size: 'm',    fill: 'solid',    type: 'primary',    disabled: 'n',  },});
/// 组件逻辑部分const Button = (props: IButtonProps) => {  const {    onClick,    className,    disabled,    type,    logkey,    title,    style,  } = props;
  return (<View    className={buttonStyle({      ...props,      className: className,      type,      disabled: disabled ? 'y' : 'n',    })}    style={style}    onClick={onClick}  >    <Text className="title">{title}Text>  View>);};

同时，我们对于样式是否为类似tailwindcss的原子化类、是否类似shadcn-ui一样完全将样式和逻辑解离开来等问题在持续思考，也欢迎大家来进行讨论。

微信生态 ≠ 小程序，它由一系列丰富的产品和工具组成，包括 微信群 / 朋友圈 / 公众号 / 小程序 / 微信支付 / 企业微信 / 视频号 / 直播 等，生态各环节的 场景、流量、信息 可互通，可以满足对用户全生命周期的运营动作，并基于社交关系链和信息传播，实现对买家画像、商买关系更细致的洞察。

基于此背景，后续scrm微信生态将整合微信多种矩阵产品形态，构建跨平台、一体化的技术架构，以实现用户在生态内生命周期管理、多场景数据协同及业务流程自动化，为全域用户运营、私域流量沉淀、场景化服务能力提升等方面提供技术能力支撑。