小程序进阶之路：跨平台开发避坑指南( 五 ) _小程序

5 踩坑记录

负一屏的 UA 和快应用中不同如果有与 UA 相关的配置需要注意。

对于调试时更新了 rpk 之后，实际打开对应更改没有体现时，可以尝试清除对应卡片容器的 cache，同时保证该容器有相应的读取存储的权限。

对于同一个业务，由于各厂商适配不同及平台不同，需要多处代码编写，但基本业务逻辑基本一致，唯一不同是 UI 展示，所以在一开始还是需要抽离数据逻辑，不同厂商给不一样的 UI 展示即可。

四淘票票小程序构建演进
我们做了很多的小程序，对多端同构也做了一些尝试。
1 从一端到多端
1) 起步：小程序原生开发
2018 年，随着小程序平台爆发，我们首次踏出了淘宝域内，进行了头条小程序的尝试。这次尝试，使用的是原生的小程序 DSL 语法编写。为了方便复用已有的 H5 样式，加入了 Gulp，用来编译 Less 。
这种开发方式轻快，但是同时也暴露出了很多问题：

包体积很难控制。

原生 DSL 没有任何复用性，并且需要重新学习。

无法使用 NPM，一些很常用的社区包，团队基础工具链无法使用。

机型兼容性不好，没有 babel 支持。

2) 摸索：两个端，一套代码？
在开发百度小程序的过程中，吸取了第一次的教训，加入了 webpack 来做一层编译，一是解决了包引入问题，二是加入了 babel 插件，解决 JS 兼容性问题，开启 CommonChunk 插件，解决包大小问题。
总体上，从输出一端变为输出两端，所以出现一些差异。对这些差异，编写了一个插件，对业务层抹平。比如微信端引入 index.wx.js，头条端引入 index.tt.js 。
脱离了刀耕火种，开发效率明显提升，但是还不够好，视图层还是两份，而且以后每新增一端就要新拉出来一份。
3) 优化：走向社区，跨多端
在开发头条和百度小程序时，业内也已经有了在小程序 DSL 上封装的框架，但是当时看都不是很成熟，基本都是专注于一个平台，没有什么跨端能力，就没有用到生产环境，而是持续关注更新近况。
2019 年进军微信小程序，再次看市面上的框架，发展的很快，同时也注意到跨端开发这个需求点，选择了 Taro 作为主力框架。这种框架横评就不展开了，市面上很多，简单说几个选择 Taro 的原因：社区相对活跃、支持渐进式切换、TS、react like 。
a) 平滑迁移
Taro 支持渐进式切换，也就是 Taro 和 DSL 混写的能力，所以迁移成本可以接受。我们先将首页 Taro 化，后面慢慢迭代将所有的页面都切换为了 Taro，这里值得一提的是，Taro 的跨端差异化处理和我们之前的处理思路一样，因此 Util 迁移起来几乎 0 成本，成本主要集中在视图层。
b) 好处是什么，缺点在哪里
使用 Taro 的好处是解决了我们之前遇到的主要问题，是一个一揽子解决方案。
同时这种上层框架在扩展新端时成本低，机动性很高，框架提供了新平台包，适配成本低。
当然也遇到了一些新的问题，比较严重的是调试，因为代码被转译过一次，同时不支持 Soucemap，导致 debug 时体验很差。
2 多端差异
多端必然会有一些差异，业务的差别、端上 API 的差异等，比如微信上的分享能力，抖音上的抖音拍摄器，百度的 feed 流等。最终落在业务上，差别可以分为三部分，输出不同的页面、不使用同的组件(有的端使用原生组件)，细到不同的逻辑。
1) 输出不同的页面
在使用 Taro 时发现不支持，想到可以使用 babel-preval 来编译时输出页面配置，这样包体积也不会受影响，最后我们也反哺回社区。
使用不同的组件，不同的逻辑。根据端上不同的组件我们使用的最多的是多态模式，底层组件对外暴露相同的接口，端上调用时不需要考虑端上的差异，在 import 层会根据不同的端来引入不同的具体组件。
2) 端上逻辑
如果是一些简单的逻辑差异，可以直接使用环境变量来做控制，走不同的逻辑。这种方式针对小一些的逻辑还可以，不过这种代码一多，就不容易维护。
3) 针对维护性的建议
这里推荐几种维护性比较强的差异处理方式：