一、前言

随着微信小程序的逐渐火爆，百度、支付宝等平台纷纷推出各自的小程序平台。面对众多平台，携程第一时间上线了自己的小程序。在带来巨大流量的同时，也带来了更多的工作量。如何保证各个平台小程序的质量、迭代速度以及减少工作量成为我们思考的问题。

二、概述

本文将根据携程火车票小程序团队从微信小程序转百度小程序的实践过程以及最终的实践成果，从以下几个方面来进行阐述：

为什么要进行微信小程序转百度小程序
微信转百度小程序的思路
转化调整过程中遇到的问题以及解决方案
实践成果及后续展望

三、为什么要进行微信小程序转百度小程序

在百度平台的小程序开放后，我们基于微信小程序的业务版本，快速投入资源，上线了第一版功能较为简单的小程序，去对市场进行试探。

经过了一段时间的观察，发现百度小程序的流量很可观，觉得有必要对百度小程序做对应的优化。我们当时面临的情况如下：

①因为需要保证微信小程序的质量，我们必须使用原生微信小程序进行开发。

②主流的小程序转换方式：如使用类似Taro、remax等框架，需要进行完整的开发，这需要投入很多的资源，且基于①的原因，我们无法复用到微信。

③使用百度原生语言开发：和②一样，在投入资源的情况下，可复用性不高。

④需要考虑后续扩展到其他小程序平台。

⑤微信小程序和百度小程序具有一定的相同点。

⑥使用内嵌H5没有原生API支持，部分功能受限(支付、分享等)。

⑦我们的主要工作在于自己的业务模块，基础构件已由框架同事全部支持。

基于上述情况，我们决定尝试用现有的微信小程序代码直接转换为百度小程序代码。

四、微信转百度小程序的目标及思路

4.1 微信转百度小程序的目标

参考技术社区的转换方案，结合我们自身的需要，我们拟出初步目标：支持微信小程序一键转换为百度小程序，且支持迭代转换。

4.2 微信转百度小程序的思路

一键转换工具我们选择了开源工具wx2swan ,在工具的介绍中，开发者提到了下面这句话：

工具帮你迁移80%的代码，可能只节省你50%的工作量。

而在初步实践中，也验证了开发者的观点，减少这50%的工作量也成了我们工作的重中之重。

在具体讨论时，我们主要有两个方案：

1）微信小程序代码转换后，进行代码搬运。

在转换后的代码上进行修改，配合百度小程序平台带来的某些差异进行处理。这种方案是我们最先提出的，但是该方案存在两个缺点。

①搬运代码进行修改，工作量较大，业务流程很有可能存在较多隐患，出现bug时，排查解决等也会耗费很多的时间；

②解决了我们当前的需要，但是当后面需要继续迭代百度小程序时，又会面临①中的问题，无法减轻更多的工作量。

我们团队继续讨论其他可行性，于是出现了第二个方案。

2）结合百度小程序的差异，基于现有的微信代码进行修改。

这个方案基本思路就是抹平两个平台的差异，做到微信小程序一套代码，转换后基本甚至完全可以在百度上运行。同样的，该方案的缺点我们也进行了分析。

①工作量大，需要在微信代码的基础上，一个一个页面的去趟"坑"，如某些api的使用，页面展示差异等，并需要提出解决方案；

②业务流程、功能策略在两个平台上的差异需要做一定的修改，如分享、活动入口等。

但是该方案可以避免①中的持续迭代带来工作量问题，我们选择了该方案。

五、转化调整过程中遇到的问题以及解决方案

5.1 平台差异性抹平

这一部分的工作主要在API和平台某些特性如UI上。

特性(UI)上差异处理如下：

icon-font使用base64方式差异，百度小程序不支持woff2:统一使用了truetype

@font-face {font-family: "xxx-iconfont";
  src: url('data:application/octet-stream;bas...') format('truetype');
}

.ifont-add:before {
  font-family: 'xxx-iconfont';
  content: "\e7f8";
}

for循环和判断条件一起使用时，百度小程序会生成空dom:for循环使用block嵌套

<block wx:for="{{arr}}" wx:for-item="s" wx:key="{{index}}">
    <view class="cls"wx:if="{{some condition}}" data-index="{{index}}" bindtap="taptap">
        <view class="cont">{{s.name}}</view>
    </view>
</block>

百度小程序中swan不支持位运算：移至至js中
百度小程序中swan 运算符 < <= 导致页面展示异常：已反馈至百度开发者中心，暂时改写
…其他不再赘述

JavaScript层的处理

这一部分工作由框架同事提供，主要包含以下两个方面：

劫持Page/componet。提供统一的Page示例和Componet实例，来与各小程序的生命周期进行兼容。
通过注入wx/swan，劫持api，统一挂载到全部的对象上。对于我们业务BU的使用，只需要通过globalAPI.API的方式调用即可。

5.2 wxs改写

wxs是微信小程序特有的脚本语言（不同于JavaScript），可使用在wxml中，部分场景下可以快速且优雅的解决问题，但是具有一定的限制，比如该部分和JavaScript代码隔离，且不能调用小程序提供的API等。

在转换百度时，该功能不能正常使用，所以我们放弃了该功能，逻辑全部在JavaScript中实现。

5.3 H5数据传递

部分业务流程中，如果需要跳转至H5页面，且需要H5传递数据，则H5页面需引入百度sdk。

5.4 业务差异化处理

这一部分我们定义了全局的平台判断：

        //根据appid判断各平台
      //channel代表平台
      //requestChannel用于请求头，便于标识服务端识别
      switch (appId) {
          case baiduAppid:
                config.channel = 'Baidu';
                config.requestChannel = "RequestChannel.Baidu";
                break;
            default:
                config.channel = 'WX';
                config.requestChannel = "RequestChannel.WX";
                break;
        }
        //定义全局平台属性，方面调用
        config.isCtripApp = config.channel === 'WX';
        config.isBaiduApp = config.channel === 'Baidu'
        Object.assign(global.config, config)
    }

在具体业务场景时，我们通过判断平台，来做不同的表现。

PageInit:
this.data = {
    isBaiduApp:global.config.isBaiduApp
}
UseIt:
if(this.data.isBaiduApp){
    //do your business
}

另一部分，在网络请求中，我们也是在header中追加了平台的信息，以方便后台服务进行业务控制：

header: {
    'request-type': `${global.config.requestChannel}`
  }

5.5 工作流的制定

为了不影响微信小程序的工程，我们使用git分支进行操作。

—>首次开发
基于release_wx新建develop_baidu分支;
对于百度小程序的适配，全部在develop_baidu分支进行;
使用develop_baidu进行转换，生成的代码拷贝至百度小程序仓库并提交;
—>迭代开发
release_wx merge至develop_baidu分支;
对于有修改的代码进行检查
使用develop_baidu进行转换，生成的代码拷贝至百度小程序仓库并提交;

六、实践成果及后续展望

根据之前设定的目标，微信小程序调整后基本完成的预期的目标：

在微信小程序代码的基础上，支持一键转成百度小程序，且可进行持续的迭代更新。

而在此过程中，我们摸索出来的较为稳定的开发方式、流程，是我们对其他小程序推进更新的有益尝试。

按照此方式，我们业已完成了对快应用的适配，并有计划推广至其他平台。也期待对于和我们一样，在以微信小程序开发为主，其他平台尝试转译的同学有一定帮助。

作者介绍：

张海明，携程火车票研发部开发经理。2015年加入携程，从事火车票Android、ReactNative和小程序相关研发工作。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s/29bXbqAKzZoNfGtQt1CgMg

创作场景

微信小程序一键转百度小程序，携程火车票团队是这样做的