跨端实践的思考

局势

在如今各种小程序百花齐放的当下，如果还在坚持用原生小程序语法写各类产品的，那么也就两种情况：一、只有微信小程序产品。二、有大量的冗余人力来开发各类小程序。据不可靠三方数据统计，每月都有 3 万个新生小程序，也就从侧面反映出竞争真的很激烈。目前局势下，依然以微信小程序领跑，其余有支付宝、百度、字节、QQ、360 等等随其后，还有快应用，以及许多新生的平台语言（头部大厂们在背后试运行的各种）。那么如何做到同一产品运行到各个平台上呢？这类问题一直存在，各类头部企业也都还在努力。在这样动荡的环境下，产生了一些不错工具和方案:uni-app、taro、chameleon、mpvue、wepy（不分先后）。

基于 Taro 的实践

各种跨端方案都有优劣，不过多分析，我们团队主要基于 Taro 做了实践（也不分析为什么用 Taro 了）。下面主要大概说明一下整个实践的各种事项：

第一阶段，选定了某一个 Taro 版本（那时还不成熟，问题挺多），做了比较深入的研究和尝试。我们没有选择和社区并行，因为社区会较慢，所以是团队内部基于当时的一个版本做了许多功能的二次开发。

第二阶段，对目前的业务做 Taro 的改造，优先在微信小程序端开始，非常顺利，遇到的问题也都不难解决，然后再改造了 RN 端（这块内容问题是比较多的，不过也都能搞定），然后在收获到跨端开发的好处后，开始尝试在各个不同端复制产品并运行。不算很顺利，但是也算可以通过 Taro 进行支撑。

第三阶段，通过 Taro 对快应用（不太友好的端的典型代表）进行改造，需要投入了比较大的精力去适配，来追赶在微信小程序端的研发进度。

在不同的阶段的背后，团队还做了很多事：1、智能 cli 工具来统一管理多端脚手架的升级。2、统一了分包管理方案。3、统一了构建命令。4、统一了依赖包管理。5、非常多的技术布道。6、非常多的思想文化。

问题

磕磕绊绊的经历过跨端 Taro 化的实践，不能自夸说目前团队内部的跨端模式已经很成熟了，但是已经足以支撑任何新的端的加入。在实践过程中，有很多的问题，有些可能已经被解决了，有些可能有办法去解决，有些可能都不知道是否应该把他定位为问题。

问题一：代码稳定性

跨端开发指的是，写一套代码，能够在各种不同的平台能够运行。不过在真实开发中，会有一些情况，如各个平台的代码发布节奏是不同的，而且可能需求上也存在差异，假如微信 1 号发布需求 1，百度 3 号发布需求 2，快应用 5 号发布需求 3。这个是开发常态，一般会有两种分支方式，一种就是维护三个无关联分支，公共内容组件化；另一种就是主分支上拉 3 个分支，最后开发完了之后做比较复杂的合并操作，需要小心注意合并冲突。

通过一系列的实践，我们最后还是选择了第二种分支方式，虽然操作会复杂一些，但是长期下来，只要保证每一次的操作正确，代码可信赖度高，不容易出现难以收拾的局面。

问题二：跨端兼容

虽然 Taro 框架做了很多跨端兼容的操作，但是各端都在不停的升级，以及各端差异还是有一些不同的，所以还是存在为兼容情况。那么需要通过环境变量的方式，写各端不同的兼容语法。这时候就又会产生两个比较突出的问题：一、开发同学需要去学习，各个不同平台特有的语言，一来花费时间，二来主观臆想就不愿意学一种新语言（觉得浪费时间）。二、长期以往下来，这个代码都是各种不同的兼容语法，一团一团的放着，影响了后期代码的可维护性（实践发现很容易出现问题）。

这个问题应该会一直存在，直到小程序标准出台后，可能会有一定的好转。

问题三：开发分工

这个问题就会上升到团队管理，是以业务线做划分呢，还是以职能做划分。业务线划分则会发现每一个开发需要对所有的不同 DSL 有一定了解，不然出现问题难以解决，比较浪费开发个人精力。职能划分则会发现做一个需求，喊了一大波人，然后各自做各自端的适配，最后工程做合并，会比较乱。

相信还是以业务线划分会相对好一些。

最后

跨端开发在新的一年依然会是火热的话题，在目前的局势下暂时没有完美的解决方案，根据团队内部的实际情况，做相对应的架构体系，依然是最好的方式。许多无法解决的问题，可以做工程化，也可以通过技术布道，做沉淀做规避，来达到对应的效果。