兼容 vs. 性能，寻求舒适的构建姿势
iOS / Android / Web ...
React Native 0.24 / 0.25 / 0.26 ...
如果把“前端”定义为“以交互为核心的程序设计与开发”，那么兼容性问题始终是一个沉重的负担。
IE6 的绝对霸主地位曾经是 Browser/Server 架构击败 Client/Server 架构的关键因素。到了 PC 时代后期，浏览器市场群雄并起，兼容性问题曾经让很多前端开发人员心力交瘁。所幸有矛就有盾，以 jQuery 为代表的前端框架的流行，挽救了大家的信心，不至于被戳得支离破碎。进入 Mobile 时代，前端工程师们所面对的兼容性问题，又远比 PC 时代更为复杂和严峻。
React Native 的出现，使得 iOS 和 Android 两大移动操作系统的开发阵营之间拥有了新的共同语言，但是各自的表述方法仍有相当的差异。同时，React Native 本身仍在快速迭代中，三日不见，刮目相看。对于追求刺激的家伙们而言，当然是高潮迭起，新鲜感爆棚；可对于被繁重的业务需求约束着的开发团队来说，如此喜新厌旧的代价与风险是显而易见的。Moles Packer 既是一个 React Native 项目构建工具，又兼以跨平台前端解决方案 Moles 工具链的一环之身份，在兼容性问题的考量上，尤其需要妥协，不落偏颇。
Moles Packer 目前采取的策略可以归纳为：
输出 = 非兼容的公包（common bundle） + 兼容的业务包（business bundles）
在这里，“兼容”的范畴包括以下两个方面：
- 跨平台，即兼容 iOS / Android / H5
- 适用于不同版本的 React Native 运行时环境
直白地说，你需要为不同的平台、不同的 React Native 进行时环境创建单独的公包，在这些公包的支持下，通过 Moles Packer 构建的业务包可以适用于不同的平台及不同版本的 React Native 运行时环境。1
1. React Native 并不支持 H5 平台，业务包在 H5 平台是通过 Moles Webridge 提供的界面运行的。 ↩