Rax体验还是比较好的，没有DX版本的动态模版加载过程，页面可以做到直出。当时我们也是跑了一段时间，不过随着业务个性化需求的逐渐增多，发现支付宝上一些新的小程序特性无法支持，因为Rax目前处于维护状态，不新增新功能。



同时我们发现Rax这套方案会有构建体积过大的问题，包体积可以达到600KB，同等规模原生小程序只需要200KB，影响加载性能。同时由于它是一个应用层的方案，上层用JSX，然后会转换为vdom，然后将vdom的变化通过setData同步给原生小程序，存在vdom转换到小程序视图的性能损耗。

开发体验也会有一些问题，比如二次构建（Rax构建成小程序的JS文件，小程序JS自身的构建）速度慢，每次保存都要等待一会儿才能看效果。

基于以上问题，我们开始考虑是否可以直接迁移到原生小程序。

Rax不再维护，其实我们是可以换一个跨端框架的，比如Uni-App，Taro，不过经过团队的讨论，最后我们还是选择原生小程序方案。

首先，小程序是没有一个标准化的组织，随着时间推移，各家小程序（微信，支付宝、抖音等）的差异肯定是越来越大，像Rax这类的跨端框架需要“抹平”的成本会越来越高。而且抹平一般会采用交集的方式进行抹平，会导致我们无法利用到各个小程序平台的最全能力。跨端框架拥有“Write Once， Run everywhere”的好处，对于0到1探索阶段的项目比较适合，可以快速铺到各个市场，但是无法适用于每日必抢这类对性能、体验、深入融合各端生态有着高要求的项目，基于此我们还是决定拥抱原生建设下单方案。

在介绍下单方案之前先了解下奥创协议，它的作用是用来描述前端页面的渲染协议，它提供了一套机制，让前端开发只关心渲染，业务逻辑统一收敛到后端，同时它统一了前后端交互的三种方式，render（首屏渲染）、async（异步刷新）和submit（提交）。

这套方案非常适合下单，购物车这类业务逻辑复杂的表单型页面。

举个例子，用户在下单页购买数量加1需要重新计算价格，如果这个逻辑放在前端，后端需要下发限购规则、优惠规则、库存等数据，前端需要按照限购规则判断是否可以加，还需要按照优惠规则重新计算价格，提交的时候后端还需要算一遍，意味着前后端需要写两份相同的逻辑。

随着业务逻辑越来越复杂，两份逻辑需要保持一致变得越来越难做到，将逻辑收敛到后端，前端只关心渲染成为了大势所趋。有了奥创协议，前端只需要按照协议渲染即可，业务逻辑可以收敛到后端。

• 渲染逻辑模块：继承奥创渲染SDK，负责符合奥创范式的渲染逻辑，后面会详细介绍。
• 服务模块：负责跟服务端的数据交互，定义请求和返回处理逻辑
• 业务逻辑模块：处理用户行为触发后的副作用逻辑，比如触发async方法，触发submit方法，组件联动。
• 视图模块：视图层，只负责UI的渲染。
  
  

• 前端奥创渲染SDK

由于业务逻辑收敛到后端，前端基本不会有业务逻辑，不过跟支付宝合作会员购的项目打破了这个规则。

由于后端无法直接调用支付宝查询积分接口，需要从前端来调用，然后拿到积分之后需要在价格区域加上积分信息，如下图红框的积分区域是支付宝积分接口返回的。

会员购场景会下发会员购组件，一个想法就是在会员购组件通知更新组件数据，可以让逻辑收敛到会员组件里，可以让业务逻辑高内聚。

不过这个方案存在异步接口竞态问题，由于会员购组件查询积分是异步的，如果在异步查询过程中用户行为触发了异步接口，不好控制积分查询异步接口和async接口的返回顺序，如果积分查询接口先返回，async接口后返回，就会出现覆盖积分信息的问题。

为了解决上面竞态问题，我们把积分查询逻辑放到请求返回之后做，这样子避免了积分查询数据被覆盖的问题。

随着后续场景的接入，在服务模块处理数据成为了一个研发范式。比如下面支付宝红包也是调用支付宝接口查询的，调用时机是在render和async接口返回之后。

未来可预见的问题：

1. 类似会员积分、支付宝红包等功能场景会越来越多，这些场景都会同时修改一份奥创协议，如何管理好功能点的执行顺序成了比较大的问题。

2. 同时随着更多端接入，每一个端功能点诉求不一致，如何做到功能点快速可插拔也是需要考虑的问题。



解决思路：

提供扩展点，让这些功能点可以通过能力包的方式注册进来。一来通过能力包让功能点的逻辑收敛，更内聚，二来这套下单的范式不受小程序端DSL的影响，后续可以方便应用到其他端。



扩展点主要可分为两个：

1. 业务逻辑处理模块：支持注册不同能力包，能力包包含两部分，一个是组件，一个是组件对应的业务逻辑（核心是联动逻辑）。

2. 服务模块：提供一些生命周期钩子比如请求开始，返回结束，数据渲染完成后等，同时管理各个能力包的执行顺序（可以在能力包里面声明执行优先级）。

具体见下图红色框区域的部分：