- 当下存在的小程序/小游戏
- 已经开放的
- 内测中或将要开放的
- 多平台兼容的问题
- 没有统一标准
- 开发工具黑盒、不统一
- API平台互相不兼容，同一平台前后版本也不兼容
- 业务差异
- 平台规范不同
- 兼容问题总结
- 现有工具
- 小程序开发
- 小游戏开发
- 微信小程序转其它小程序
- 工具小结
- 理论上的兼容方式
- API兼容库
- 开发转换工具
- 多平台入口
- 本方案总结
- 相对实际的方案
- 统一技术栈
- 多平台开发方式
- 老项目迁移
- 总结
目前，小程序/小游戏成为潮流，BAT等大公司纷纷推出了小程序/小游戏，我们的兼容问题，也就提上了日程
当下存在的小程序/小游戏
已经开放的
- 微信小程序/小游戏：https://developers.weixin.qq.com/miniprogram/dev/index.html
- 百度小程序/小游戏：https://smartprogram.baidu.com/docs/introduction/register/
- 字节跳动(头条、抖音)小程序/小游戏：https://microapp.bytedance.com/
- 支付宝小程序：https://open.alipay.com/channel/miniIndex.htm
- 手机QQ玩一玩：https://hudong.qq.com/docs/engine/
内测中或将要开放的
- QQ小程序/轻应用
- QQ浏览器小程序
多平台兼容的问题
没有统一标准
目前虽然都叫小程序，但是都是各家自己实现的格式、api。没有统一标准，也没有组织进行统一协商，都是各行其是，唯一让人高兴的是，基本上都是抄袭微信小程序，大体上概念一致。
开发工具黑盒、不统一
由于没有统一标准，也不开源，开发必须使用厂商提供的开发工具才能开发、预览、提交、发布。导致第三方也是无法解决，最多帮助转换为相应格式。最后的打包、预览动作都需要在厂商指定的开发工具上实践。
API平台互相不兼容，同一平台前后版本也不兼容
比如是微信小程序中，新版本引擎不兼容老版本引擎，为了兼容前后版本本身都需要复杂代码进行兼容（最记忆深刻的例子就是：游戏匣子。跳转其它游戏匣子，新旧版本api不兼容，导致的后果既要使用老方法去绑定所有公众号，又要使用新方法提交白名单）。原本就超级复杂的兼容，现在多平台，互相之间的API差异，多版本差异
业务差异
不仅仅小程序自身的差异，在业务上也有相当大的差异，比如微信小程序中，可以使用微信登录，在百度小程序中明显没有此类业务，需要单独开发。
平台规范不同
不同的厂商对于具体规范不同，比如微信小程序不允许诱导、集中跳转小程序，但是在其它平台并无此类规范。
兼容问题总结
小程序的多平台兼容与兼容多个浏览器完全是不同的概念。举一个，飞机小游戏，当时先做了一个微信小游戏版本，后来要出一个H5版本的，都做了不少兼容工作，难以同时支持H5与微信版本。
与此类似的，还有IOS与Android的app开发，需要兼容，兼容的方案有一套混合APP与RN这样的近原生方案。而现在经过多年实践，那就是只能使用2个平台都支持的API，减少差异才能勉强使用，而且效果一般，越来越多的公司，都在放弃一套代码，多端生成的。而这仅仅是2个平台的兼容就如此困难，我们现在要大于3个平台的兼容，其中的差异性、兼容性困难重重。
现有工具
注：跳动小程序太新，没有工具支持
小程序开发
- mpvue：基于vue的，只支持微信小程序
- taro：基于react，支持H5、百度小程序、微信小程序、支付宝小程序（https://taro.js.org）
小游戏开发
- 白鹭引擎：基于egret.js，支持百度小游戏、QQ玩一玩、微信小游戏、H5
微信小程序转其它小程序
github上能找到几款转换工具，但是实践后，效果很差，基本不能用，不仅仅样式丢失、事件错乱，而且基本难以修复。
工具小结
目前的工具，都是将 vue或者react的代码开发，然后转换为相应平台的小程序，工具承担了转换的功能，但是具体的业务逻辑，与部分API的兼容，工具是无法承担的，比如使用mpvue开发的时候，虽然语法已经是vue的语法，但是还是使用了大量微信小程序的api，这部分API兼容问题，需要自己解决，工具并没有帮我们进行转换。
理论上的兼容方式
不考虑我们团队的开发能力、时间、精力的实际情况，只考虑理论的可行兼容方案
API兼容库
各平台的、各版本的API不完全一致的情况下，为了能正常使用，我们需要自己维护一个兼容库，提炼所有的API，使用各平台的现有方法去实现统一的我们自定义的api，比如统一的ajax请求、dom操作、文件操作，调用照相机等等。
而且我们需要维护详细文档，注明各个API的适配情况，以及可能存在的问题。
同时，我们需要一直关注各个平台的API变动，有了改变，就需要及时更新。
注：目前市面上没有此类现成的兼容库，需要我们自己做
开发转换工具
就是我们需要自己制作类似mpvuetaro 一类的工具，进行文件转换，开发使用vue，生成最终平台的各种文件。
至于为什么不直接使用mpvuetaro现成工具，原因很简单，它还不支持 字节跳动的小程序。或者我们做贡献，补全mpvue/taro 缺少的转换功能
注：这个轮子有点庞大，还是拿别人的进行修改相对更加合理一点
注：2018年12月7日，再去看taro 已经支持 “头条小程序” 了
多平台入口
不同平台，业务不一样，配置不一样，接口域名不一样，入口不一样等等都不太一样，所以需要一个完全不一样的入口，只能说部分一致。所以，我们需要开发时，每个平台多个入口，然后工具去相应入口进行打包。
本方案总结
工程量有些巨大，后期持续维护量也很重的压力，感觉做成开源项目，社区相对更加合理
相对实际的方案
一套代码多个平台的美梦就别想了
统一技术栈
目前要么vue技术栈，要么react技术栈
vue方面，mpvue(https://github.com/Meituan-Dianping/mpvue/issues/1155),已经在做兼容，但是还没有完成
react方面，taro基本支持了，所以，目前来说，使用基于react的技术栈是一个不错的选择
多平台开发方式
如果业务逻辑在所有平台上都没有差别的话，可以尝试一套代码所有平台使用。但是，对于兼容性要求很高，而且需要自己实现各平台的api差异。
所有，我更加建议，各平台都是单独项目，单独代码
具体开发时，可以先做微信小程序版本，然后移植到其它平台，在进行修正代码，同时维护多套代码是有必要的。而且在写组件的时候，分为平台无关组件，与平台相关组件，整体上尽量平台无关，可以复用。
为了更加方便开发服务，可以将组件改为组件库，第三方依赖库方式引入到项目，方便多平台复用
老项目迁移
目前我们小程序的老项目，都是基于mpvue开发的，mpvue没有提供百度小程序打包功能，这部分让我们自己改实在有难度。
所以，如果需要迁移，那只能老老实实的进行重构了，而且vue框架下没有好的工具，整体可能还要使用react进行重构（要么使用小程序本身语法）
总结
多平台兼容很难，不但开发困难，后续维护也是困难，所以不要考虑一套代码产生多端了。历史基本证明了跨平台都是失败的。就算有统一标准的Web，目前跨平台也是有点惨不忍睹。
目前小程序/小游戏都没有统一标准，实际业务上还有区别，建议还是老老实实的，每端都单独做吧。
原文:大专栏 多端小程序、小游戏兼容
原文地址：https://www.cnblogs.com/wangziqiang123/p/11632055.html