[译] 非死book：我们是如何构建第一个跨平台的 React Native APP

   <p>英文原文（国内或许不能访问）： <a href="/misc/goto?guid=4958969200471977301" rel="nofollow,noindex">https://code.非死book.com/posts/1189117404435352/</a></p>    <p>早些时候，我们介绍过 <a href="/misc/goto?guid=4958968546187888752" rel="nofollow,noindex">iOS版的React Native</a> . React Native带来的是用web方式的React - 自声明式的UI组件和快速的开发迭代来完成手机平台的功能，然后为了保持速度、保真性、并达到原生的体验。今天我们很高兴发布 <a href="/misc/goto?guid=4958869360442056133" rel="nofollow,noindex">React Native的Anroid版本</a> .</p>    <p>在非死book我们已经应用React Native在发布的产品有超过一年的时间了。几乎是整整一年之前，我们的团队开始规划开发 <a href="/misc/goto?guid=4958967427245971668" rel="nofollow,noindex">广告管理APP</a> 。我们的部门是创建一个新的APP来让数百万的非死book广告主来管理他们的账号并能创建新的广告。在完成的时候,这不仅仅是FB的第一个全React Native APP而且是第一个跨平台的APP.在这篇文章里，我们希望能和你分享我们是如何构建这个APP,React Native是如何让我们更快的，还有这个过程中我们的经验。</p>    <h2>选择React Native</h2>    <p>不久前，React Native还是一项新的技术，还没有被一款正式的产品应用过。并且开发这样一个新的APP会有很大的挑战，它超过了潜在的好处。</p>    <p>首先，我们初始的团队里有三个产品工程师已经对React很熟悉。另外，这个APP需要处理大量复杂的商业逻辑和精确的处理不同的广告格式、时区、日期格式、货币、汇率等等诸如此类。而大部分已经用JavaScript来实现了。全部用Objective-C编码并稍后用java实现Android版本的想法也并没有被赞成，而且也并不高效。第三，用React Native将会很容易来实现大部分的UI，可以实现带数据的列表、表格、图表。产品工程师可以很快的实现这些效果，用React就可以了。</p>    <p>当然，一些特性的实现存在着挑战 - 比如，图片的编辑，用来让广告主缩放和剪切图片；地图视图，用来让广告主设定地理范围。另外一个是面包屑导航，帮助广告主来可视化的知道自己的层级位置。这些都提供机会让我们来推动这个平台的发展。</p>    <p><img src="https://simg.open-open.com/show/b360494a0c707bd8c0fa6162387e38a7.png"> <img src="https://simg.open-open.com/show/9ee8cb931757a72287839d17dc11a467.png"></p>    <h2>首先实现广告工具的iOS版本</h2>    <p>我们的团队觉得首先开发iOS版本，也是为了和React Native的iOS版本校准一致。我们从后面的几个月时间里从3个增加到8个工程师。新加入的成员对React并不熟悉 - 其中也并不熟悉JavsScript - 但是他们都渴望构建一个伟大的手机应用来服务广告主，并且他们成长的非常快。</p>    <p>有经验React Native的iOS工程师帮助我们实现一些他们并没有在React Native中实现的特性，像提供访问相册。他们也帮助我们和其它FB已经存在的APP在使用的iOS库做关联，像认证、分析、崩溃报告、网络和推送提醒。这让我们的团队可以关注在产品上。</p>    <p>除了上面提到的，我们可以使用以前就写好的JavaScript类库。像 <a href="/misc/goto?guid=4958965462526757079" rel="nofollow,noindex">Relay</a> ,一个通过 <a href="/misc/goto?guid=4958965475550930336" rel="nofollow,noindex">GraphQL</a> 来传递数据到React应用的FB框架.另外的一系列库用来处理国际化和本地化，它能很聪明的实现时区和货币的调用。这些库的加载是在一个JSON的配置文件里，包括APP用到的iOS的本地关联文件，仅仅暴露很少的native代码。这让我们的库几乎不需要修改就能使用。</p>    <p>我们遇到的最大的挑战就是导航。为了导航广告主的广告和活动，我们想使用面包屑导航条。指引广告的创建流程，我们需要一个导向式的导航条。在最上面，非常重要的是需要使用合适的动画和手势操作，否则这个APP看起来还是像一个经过美化的website.</p>    <p>我们的解决方案是使用 <a href="/misc/goto?guid=4959644529417851698" rel="nofollow,noindex">导航组件</a> ，是一个用React Native来实现的可定制化的组件。本质上，它是一个追踪一系列React组件的组件。它可以在组件之间基于按钮点击和按下时进行动画切换。它也具有可插拔式的导航组件，让我们来实现iOS风格的导航视图，以面包屑的方式来导航广告和活动，指引创建流程的步骤。这个导航条组件还能获取到动画的进度以及根据需要来调整动画的频率。这意味这所有动画，包括视图和导航条都可以通过JS来处理，而且测试的结果是仍然能够达到60fps.</p>    <p><img src="https://simg.open-open.com/show/837f7e090a55c7e2cec1eb50a122a1fe.gif"></p>    <p>只有一种情况下动画才会卡顿，就是当JS线程被一个大的操作占用时。当我们遇到这种情况时，基本上都是执行大量的数据获取操作造成的。必然的，当导航到新页面时需要加载大量的数据。当网络足够快是，动画可以很容易的被执行。我们的解决方案是延迟数据的获取直到动画执行完毕，这时就使用到了 <a href="/misc/goto?guid=4959644529520990541" rel="nofollow,noindex">InteractionManager</a> 组件，同样是React Native的一部分。我们首先动画到一个新的视图，然后再用Relay来执行数据加载进程，这样就能自动的让需要的React组件实现自动渲染了。</p>    <h2>开发Android版本</h2>    <p>当iOS版本的广告管理工具接近开发完成时，我们开始着手Android版本的APP.移植React Native的Android是最好的方式来完成这个工作。幸运的是，React Native团队已经在上面做了很多的工作。自然的，我们想尽可能的复用更多的代码，因为大部分的视图都很相似。当然，也有一些地方需要做Android个性化处理来和iOS版本有所区别，比如，导航的元素或者是调用本地的UI元素像日期选择、开关等等。</p>    <p><img src="https://simg.open-open.com/show/e9b72724167c8802f884cfea6b02f799.gif"></p>    <p>幸运的是，React Native包的黑名单特性和React的抽象结构帮助我们最大化的重用代码来实现跨平台的功能。在iOS版本里，我们打包的时候忽略所有后缀名为.android.js的文件。对Android的开发，忽略掉所有后缀名为.ios.js的文件。现在我们可以实现同样的组件来同时应用Android和iOS，也可以个性化的编码在不同平台。替换掉 if/else 这种方式来判断平台，我们尝试重构每个平台的特定UI，这样就可以有Android和iOS的不同实现。在构建Android版本的过程中，大约85%的代码可以被复用。</p>    <p>另外一个挑战是怎么管理源代码的问题。Android和iOS的代码库在非死book两个不同仓库。广告管理工具的iOS源代码在iOS仓库，Android版本的代码在Android的代码库。举例来说，像iOS版本的代码，我们想用一些非死book的Android的依赖库，这些库却在Android的代码库存放。另外，Android的APP所有的编译工具，自动化，以及引入的其它插件都在Android的仓库。基于上面，Android的这些app要求重构这些已经存在的iOS代码来抽象具体平台的组件来调用各自的文件。我们是可以直接合并两个版本的代码到一起。但是这种方式却是我们不能接受的。</p>    <p>最后，我们决定指定iOS库为事实上的源代码库，因为iOS版本已经相对稳定。我们设定了定时任务许多次一天来同步iOS的JavaScript到Android的代码库。我们不鼓励在Android版本提交JavaScript代码，如果提交也是在iOS版本同步的提交一份。如果同步代码发现代码有差异，会记录一个任务用来进行后续的检查。</p>    <p>我们让iOS仓库的JavaScropt打包成可以在Android版本上运行的代码。这样我们的产品开发人员就可以接触到尽可能多的JavaScript代码而没有原生代码，也可以直接在iOS仓库直接修改和调试两个版本的代码。但是如果要构建Android的APP还是需要在Android仓库来执行，同样的操作也会在iOS APP - 测试两个平台的不同需要大量的额外工作。为了提高JavaScript开发者的工作流程，我们同样构建了脚本来下载合适的来自整合服务器的原生文件。对于大部分开发者来说就不需要复制一份Android的代码库了 - 他们就可以在iOS代码库开发完整的JavaScript代码，并且能比在非死book的web流程中更快速的进行迭代。</p>    <h2>我们学到的</h2>    <p>React Native团队开发的进程和我们的APP一起，并且和他们一起调试本地化组件和API。这些组件将会为每个构建APP的人带来帮助。尽管我们必须自己来构建一些组件，用React Native代替纯原生的方式仍然是有价值的。我们不得不需要写这些组件，虽然在未来的一段时间里也可能不会被其它团队再次使用。</p>    <p>学到的另外一课是在分开的iOS和Android代码仓库工作是一件困难的事情，尽管使用了大量的工具和自动化。在构建APP的过程中，非死book用过这样的模式，我们所有构建的自动化和开发进程都建立并围绕着它。然而，对于产品来说，用一份共享的JavaScript代码库，这种方式并不好。幸运的是，非死book已经对所有平台都 <a href="/misc/goto?guid=4959644529624640529" rel="nofollow,noindex">统一了代码库</a> - 只需要一份JavaScript的拷贝，同步那样的方式已经成为了过去。</p>    <p>另外学到的是关于测试。当做了修改，每一个工程师一定要在所有平台仔细测试，这个过程很容易出现人为的错误。但是开发一个跨平台的APP而且是用一套代码，这些是必须的。即便如此，由于测试不足导致的成本，远大于用React Native开发的成本和能重用跨平台代码的成本。请记住，这里说的不仅仅是产品工程师；同样包括React Native平台的Objective-C和Java工程师.他们的工作不是限制在原生语言。同样包括JavaScript - 举例来说，组件API和部分分享部分的实现。ISO工程师一般来说不必一定要测试修改后的Android的代码，对应Android工程师也是一样。这种文化缺陷需要我们用时间和努力来消除，随着时间的推移，我们会越来越稳定。</p>    <p>在每次修改整合版本的时候我们也会标记问题。这些标记的东东可以获取iOS版本的问题，同样的对Android也适用，我们连续的整合版本不会在iOS修改的时候来运行Android的测试，反过来也一样。这样工程师就可以更多精力来解决问题，并且不用经常的来重启APP.</p>    <p>随着上面说的和做的，我们的债算还完了 - 我们可以运行非死book的第一个完全的React Native APP在两个平台上，具有原生体验，同样的JavaeScript工程师团队。他们当中有些还并不熟悉React, 但是他们在5个月之后就开发出了具有原生体验的iOS版本，之后三个月，我们又发布了Android版本。</p>    <p>来自： https://segmentfault.com/a/1190000005091857</p>