星球狂想战队|React 迁移的利与弊，耗时三年，向 2017年

2017年，可汗学院（）开始在iOS和Android应用中使用ReactNative 。到了今年，这一迁移工程终于来到了终点，可汗学院应用中的所有页面都转到了ReactNative上。
2017年，可汗学院之所以开始这一实验，主要是基于以下考虑：
iOS和Android应用的设计几乎是一致的，交互设计、功能和内容都没什么区别。维护两个代码库是很困难的事情，尤其是这两个代码库还具有不同的数据设计、错误和开发新功能时的考虑要素。学院的移动开发团队很小，因此迁移工作不会涉及大批工程师。学院的网站已经在使用React了，因此学院的开发团队具备相应的专业知识，以及帮助迁移的概念和工具。【星球狂想战队|React 迁移的利与弊，耗时三年，向】下面具体讲一下维护两个代码库所要面临的挑战。
不同的平台上会出现不同的错误。当然， ReactNative也会有这种情况，但是出现概率就小得多了。开发新功能需要针对两个平台分别考虑设计、工程和测试工作。这意味着你至少需要两名工程师（iOS和Android），并且他们最好共同工作——对于像可汗学院这样小规模的团队来说这是很大的负担。功能和设计一旦构建好后就很难调整，因为每次调整都需要在两个平台上各来一次。平台之间的架构差异很大。可汗学院的iOS代码库比Android代码库大四岁。 iOS有Swift、ReactiveCocoa、Cartography和CoreData 。 Android则有自己的一组依赖项和数据流设计。这些差异累加起来，让平台之间的功能复用变得很复杂，对比两个平台的代码也不容易，于是团队相当于被平台分割成了两部分。开始迁移整个迁移过程基本上分为三个阶段：探索、跨越和灭绝。
在探索阶段（2017年初），团队开始在原生代码和Javascript代码之间架起桥梁，并开始使用ReactNative构建一些页面。几乎所有的网络、数据、业务逻辑和所有“客户端后端”内容都是通过桥梁传递的。这一阶段的工作涉及很多样板，因此非常繁琐。
跨越阶段（2017年中至2018年中）自然是最困难的。学院团队正式决定转向ReactNative ，但离终点还有很远的距离。这时候，团队需要考虑三件事：原生iOS、原生Android和React原生代码。工程师要做出一项更改时需要考虑两个（或更多）范式，并且有很多东西要学习！
灭绝阶段（2018年中至2020年中）从学院的“流主题树”项目开始，该项目历时数月，将内容数据库（学院的许多课程、视频、文章和练习内容）从大型原生数据库（例如CoreData）完全迁移到了轻量级、用Javascript编写的缓存库。至此，学院的客户端内容数据库转入了ReactNative ，于是不需要在构建的桥梁上传递那么多内容了，并且可以开始删除许多原生代码。到今年的v7.0版本，应用的最后一个原生页面也会升级到ReactNative ，同时统一了手机和平板电脑的导航设计。
原生和ReactNative的混合体开发团队将ReactNative用于“页面内容” ，而将原生代码用于这些页面的导航用途。这是为了物尽其用，并让应用尽量提供原生级的体验。
应用的绝大多数“业务逻辑”都存在于页面内容中（例如“首页”标签中卡片的内容，或“书签”标签中的下载规则）。相比之下，标签栏或导航栏的内容在很大程度上不依赖业务逻辑。
但是，用ReactNative编写的导航栏和导航控制器和原生版本还是有一些差异，这些差异加起来还是很可观的。原生导航控制器提供了正确的滑动后退手势，以及用于推/弹出动画的正确动画timing 。原生导航栏可轻松处理带刘海的iPhone 。在原生UIViewController中包装的页面也更符合开发习惯。（有很多库试图模仿系统的标准导航栏，但它们都无法满足可汗学院团队的需求。）
这个迁移项目的一条原则是迁移后的应用依旧要有原生级的体验，当然小问题总是会有的，但以此为代价，团队在许多方面为应用带来了明显的改进。