前言：
京东小程序开放平台是由京东自主研发的开发者开放平台，类似于微信和支付宝的小程序开放平台，提供了丰富的开放能力和完整的小程序开发生命周期所需的功能。开发者可以轻松地使用开发者工具IDE进行开发、调试、预览和代码转换，并在控制台进行线上小程序发布、审核、灰度、AB测试等流程，此外还可以在管理后台监控小程序的异常、性能、业务数据。
小程序作为一种轻量级、便捷、个性化的应用形态，可塑性非常强，其强大功能、低研发成本能够有效助力快送实现跨端。达达快送接入京东小程序项目取得了多方面显著的成果，这也为其他企业在接入小程序时提供了有益的借鉴和参考。
背景：
快送是给商家和个人用户发布同城运单的应用，包含小程序（7个渠道）和app（2个）、PC、h5、开放平台共15个端。
快送概况：
![]()
常规做法每端独立开发一套代码，这样的做法优势定制强分开迭代互不影响，不足：成本高，体验不一致。由于PC和H5基本不迭代，所以优先考虑的是小程序和app这2块是否有机会点。通过跨端来实现提高效率降低研发成本的目的。
1.1 小程序跨端
19年跨端情况：
![]()
由于19年跨端方案不成熟，当时是自研工具通过编译时方案解决小程序跨端，完成了7个小程序统一一套代码。
![]()
![]()
1.2 app引入h5跨端
探索app跨端：
![]()
当时探索了2个方向：h5和flutter
flutter：如果需要使用到主流程，现有功能需要用flutter重新开发一套，迁移成本高。
h5:接入成本低，但是体验差，加载速度慢，所以只用在一些非核心流程和一些活动页面（占15%），无法使用到主流程。
快送app跨端-h5方案
![]()
后续跨端在快送端的方向在哪里？是否还有机会点？
![]()
现在各平台小程序是一套代码，ios和android 95%的迭代还是2套代码。
微信小程序、ios、android 三端是否可以统一一套？攻克主流程最重要的是转化率不能下降
![]()
行动
1.1 方案调研选型
集团跨端平台
基于和京东集团融合的大背景下，我们重点调研了集团的跨端方案。具了解集团有4个跨端方案，如下：
![]()
基于以上调研，我们初步判断小程序方案是比较可行的方案，所以我们对小程序方案做进一步调研。
小程序调研
调研主要分3部分，全面了解、Demo测试性能、线上测试稳定性。
1.京东小程序在京东内部各业务线的使用情况
•有成熟业务和主流程在使用
•有专门的团队维护
| 宿主 |
业务 |
场景 |
接入原因 |
| 京东 |
奢侈品（如：LV） |
在主站app上搜索LV品牌进入LV小程序 |
保持品牌特性 |
| 京东 |
京东快递 |
在主站app上搜索京东快递进入京东快递小程序 |
引流 |
| 京东 |
保险 |
搜索保险，进入买保险小程序 |
保险业务受到国家合规限制，如果在主站内想要满足国家合规要求，需要前后端都做大量改动，成本较高，京东小程序平台是一个开放的开发者平台，本身具有独立性和高度可定制化能力，可以底层本的满足国家合规要求。 |
| 京me |
打印小程序 |
在聊天页面有快捷入口，进入打印设置小程序 |
平台化 |
| 京东健康 |
部分模块（如健康管理） |
在app里面有一些独立业务模块是小程序 |
复用微信小程序能力，也是为了提效接入 |
| 京东到家 |
优惠券页面 |
在我的模块点击优惠券进入优惠券页面是小程序开发 |
优化体验（h5） |
2.通过demo对性能做测试（包括地图效果）
结论：高端和低端机型都是秒开，效果趋近原生体验，特别地图拖拽和加载效果和原生效果是一致的。
3.上线“价格明细”页面收集用户实际数据
由于“价格明细”页面带有地图且使用频率也不低，重点是这个页面不阻塞主流程。用来做线上测试页面最为合适。
结论：第一版降级率5%，但是想要大规范应用降级率需要控制在1%之内，所以对线上情况监控，数据分析等找到问题原因并优化最终降级率控制在0.3%之内。
![]()
1.2 难点攻克
如何让用户完全无感知自己进入的是小程序页面还是原生页面？
市面上小程序模式都是独立形态存在，比如微信小程序的每一个业务小程序都是有完整的业务功能，小程序的加载有一个完整独立的流程，不受宿主App的控制，我们这边期望将小程序嵌入到流程中，不被用户感知，同时希望能够控制小程序中的加载时机，提升加载速度，这就需要快送团队和京东小程序平台团队共同努力，使用一种新的小程序模式，来满足以上两点需求。
![]()
如何尽可能的降低上下游的影响？
由于业务后端和运营平台之前有一些场景是根据端来做一些差异化管理。还有app上的埋点数据和小程序上的埋点是不统一的，数据报表也是分开的。为了减少对系统上下游的影响，我们需要根据不同场景做不同的处理。
![]()
1.3 如何规避风险
如何应对合规风险？新政策变更导致无法使用小程序我们的业务是否出现停摆？
app只维护发单的基础功能做兜底，一季度一兜底，如果情况有变可以快速切换回原生，来规避业务停摆风险。平时原生页面只用作于极端情况下的降级使用。
![]()
进展
目前已经完成调研和详情页的接入，降级率低于1%，业务转化率不下降。从订单详情页为例，我们重点关注4个业务指标“修改订单”、“详情支付”、“取消订单”、“加小费”。这是订单详情页比较核心的4个操作，从使用情况数据来看，业务转化率不下降。
阶段性成果：
![]()
规划
哪些模块适用小程序跨端？从几个维度来考量？
1.是否合规---应用市场审核是否可以通过，如首页如果不是原生的苹果应用市场直接审核不通过。
2.后期是否还会高频迭代---如一路多单都不迭代，没必要迁移小程序
3.流程是否内部闭环---和原生交互越多后续维护成本越高（登陆、支付）
![]()
1.成本：80%的迭代实现3端一套代码，预计节约2HC人力
2.稳定性：缩短线上问题收敛时间--14天缩短到1天
3.效率：缩短新功能验证时间--缩短58%（53天缩短到22天）
![]()
附件：
卡片效果
![]()
原生和小程序体验效果对比：
![]()
作者：京东零售 王慧晶
来源：京东云开发者社区 转载请注明来源
