导读：为什么选择 React Native

在所有的技术选型之前都有一个为什么。

为什么我选择了 React-Native？选择这个技术到底给我带来了什么样的技术福利？如果你正在考虑 React-Native，或者还在研究选择什么样的技术实现自家的 App，不妨看看这个课程，说不定你就有了不一样的感受。

注：React-Native 以下简称 RN。

优点

选择 RN 之前我也看过了其他的几种技术，之前也使用过其他的技术做 App，比如 HBuilder 的框架，非常的方便、非常的好用、什么都不需要管，但是开发完之后发现性能很差，做一个稍微复杂点的项目就非常上火，后来切了原生，但是使用 Java 做开发也有非常多的问题，开发效率很低。

后来我选择了 RN，它使用 JS 更新虚拟 DOM，通过一个桥接器将需要更新的结果通知到 UI 层，让 Native 执行 UI 的改变。简单来说，就是用 JS 做驱动开发一个类原生的 App，所有的渲染都是和原生一样的，一下子就将原生开发和 JS 开发连接起来。通过这么一个模式，将传统的 Java 者 OC 开发转变成了简单易懂的前端 JS 开发，这是移动开发的一大进步，避免了一个 App 多个平台多套代码的尴尬，同时提升了开发效率，将移动开发带入了一个新的层面。

性能相似

很多人说 RN 的性能比不上原生的 App，这个说法是要看具体的场景。

在一般的应用场景下 RN 的表现和原生 App 是没有太大的差别的，一个 App 也不会到处都是复杂的交互效果。一些简单的点缀动画再加上列表图片等才是一个 App 最常见的内容，这种情况下它们之间的表现是一样的。

RN 本身只是使用 JS 处理了 UI 渲染之前的一些逻辑，在最终的渲染上其实使用的还是原生的逻辑，尤其是渲染完成之后更是和原生的没有半点区别。

我们的案例是一个电商项目，主要渲染逻辑是首页的自定义模板、无限加载的列表等。目前最大的性能瓶颈其实是在事件的优化上，优化之后用户已经感知不到和原生的区别了，我们会在后面的部分提到性能优化，将一个粗糙的 App 通过简单的方法提高 10 倍性能，再通过另外一个稍微复杂的方法减低内存占用。

开发效率高

通常情况开发一款 App 需要发布在 Android 和 iOS 两个平台，导致的结果就是一个 App 有两个团队、两套代码，界面几乎一样，为什么不能使用一套代码呢？之前也有大神使用各种手段达成这个目标，但是并不是很理想。

由于使用熟悉的 React 和 JSX 的模式，开发者只需要有前端知识就可以很迅速的上手一个 RN 项目，如果再学一些实战的例子，稍微复杂一些的项目也难不倒各位前端开发者。

Debug 超级方便，一边开发一边看效果再也不是梦。

快速热更新

RN 生成的 JS 文件，只要不涉及原生功能的增减，已经发布的 App 完全不需要重新安装即可完成新版功能的上线，用户只需打开 App 就能体验到最新的 App，省去了下载重装的各种麻烦，把 App 的更新做到了和网页更新一样的方便快捷。

使用 RN 就能达到既有原生的所有能力，又有类似浏览器上的快速更新能力，同时还可以接入各种定制好的网页，将 App 的自由度提高到一个非常高的地步。

大公司背书

RN 的开发者是 Facebook，背靠大树好乘凉，社区更疯狂，Facebook 本身也在尝试使用 RN 技术开发自己的 App，RN 一定会越来越完善，截止写这篇文章的时候 RN 已经更新到了 0.53.0。

RN 本身也是开源的，所有的源代码都是可以看到的，社区的讨论也是比较热烈的，现在可能中文文档还比较少，未来随着开发者的努力，这些坑都会填起来的。

其实最开始的时候也没有想很多，仅仅是冲着 RN 可以快速开发，上线快体验好，经过了这么长时间的开发，我更加喜欢 RN 的这种开发方式，项目中也填了各种各样的坑，后面就用一个实际的例子来展示 RN 是怎样开发的吧。

RN 的缺点

升级快

RN 本身其实还处于测试版，开发组经常会升级 RN，解决一些遗留或者隐藏的 bug，在这个过程中就导致了 RN 本身升级非常快，开发者在使用 RN 开发 App 的过程中应该尽量提高自己的版本，不需要一直是最新的，只要能够跟的上 Facebook 的节奏即可。

自己搞定的问题也是可以合并入 RN 的源代码里的，不要一味的等 RN 更新，有些问题自己解决更方便，建议会 Android 或者 iOS 同学自己动手。

动画难

这里的难指的是复杂的动画在开发中很难去优化，尤其是开发者懂前端但是不懂原生的情况下，好在常见的 App 也不需要多么复杂的动画，一般使用位移变换就足够了，太复杂的动画建议使用 RN 的 SVG 组件来做。

WebView 难用

RN 自带的 WebView 跟浏览器有一定的差别，App 经常要打开一些网页，可能在开发的时候一切正常，但是到了 RN 里面就会有一些奇怪的问题，主要还是受到系统浏览器的影响，会有一些兼容方面的问题，这种情况下不如微信使用自己研发的浏览器，可以畅快的使用 ES 6 之类的新技术。

需要原生支持

简单的东西和界面的展现已经完全放手给了开发者，但是还是有一些功能只能原生去实现，如果原生部分的开发者对 RN 不太了解可能会给 App 带来不可预知的 bug，好在大多数开源看只需要执行 Link 命令就可以把原生部分也安装好。

技术都会有优点和缺点，选择合适的技术才能给项目带来长久的生命力。

其他技术

Weex

核心思想上，这两家其实并没有什么区别，Weex 也可以算是站在 RN 的肩膀上起步的，目前活跃度不高，大多数是在观望中。

开发框架

Weex 使用 Vue，熟悉 Vue 的开发者可能会更熟悉。

RN 使用 React，都是 Facebook 出品，框架融合上会更方便一些，它们都是组件化开发，都属数据绑定，都有虚拟 DOM，社区同样活跃，使用人数也都非常多。

学习成本

React 的 JSX 初期会比较难上手，CSS 的写法也跟前端的样式写法不一样，Weex 使用模板的形式，直接 html+css 开发，上手会稍微简单一些。

异步

Weex 只支持 callback 的形式，RN 支持 promise 的形式，这些都是可以解决的，不是什么问题。

社区

RN 开源早，有 Facebook 支持，社区的组件库已经比较丰富，社区活跃度比较高。Weex 开源晚，社区活跃不高，以阿里系比较多。

Flutter

Flutter 是 Google 推出的一个跨平台（Android 和 iOS）移动开发框架，使用的是 Dart 语言。

Flutter 的目标是用来创建高性能、高稳定性、高帧率、低延迟的 Android 和 iOS 应用，并且开发出来的应用在不同的平台用起来跟原生应用具有一样的体验。不同的平台的原生体验应该得到保留，让该应用看起来同整个系统更加协调；不同平台的滚动操作、字体、图标 等特殊的特性应该和该平台上的其他应用保持一致，让用户感觉就像操作原生应用一样。比如，返回图标 Android 和 iOS 是不一样的；滚动内容滚动到底的反馈也是不一样的。

兼容

Flutter 不使用系统提供的组件，自己实现了一套渲染机制，所以在性能优化、跨平台方面表现优秀。实际体验上，性能比 RN 要高不少。

RN 最终调用的还是系统的组件，虽然 Facebook 已经很努力了，但是在某些时候还是会有兼容性需要处理。

组件

Flutter 内置了对 Material Design 的支持，给开发者提供了丰富的 UI 控件库选择，同时所有的组件都有扩展，保持了很高的灵活性。

RN 通过 React 也做到了组件式开发，跟 Flutter 相比，多了一个桥接器的转换，性能上肯定不如 Flutter。

开发语言

Flutter 使用 Dart 实现，Dart 号称要完全取代 JS，不过目前离这个目标还非常远，初期上手还是有一些难度的。

RN 使用 JS 开发，做过前端的都非常熟悉，上手很容易。

Flutter 现在还在实验阶段，不排除 Google 使用别的框架替换它的可能性，Dart 语言也处于成长阶段，只有 Google 的浏览器在支持，或许在 Flutter 持续发展到一个阶段之后，才会有很多支持者。

在写文章的时候 Google 放出了第一个测试版，感兴趣的可以下载下来玩玩儿。

相比于其他几种技术，RN 是目前社区最活跃，开发效率最高的一种选择，选择 RN 也是需要在一个比较短的时间内能够完成 App 的开发。尤其现在前端开发者可以非常容易的从网页开发转到 App 开发上。对于我们包含 App、微信、小程序这样的三个平台更是需要 RN 这样的技术，一个团队就可以维护项目的持续增长。

如果需要 RN 来开发自己的项目，那就继续往下看吧，我们将从简单的界面开发、数据更新等开始逐步深入，后面涉及到性能优化、自定义原生部分等。