在所有的技术选型之前都有一个为什么。
为什么我选择了React-native？选择这个技术到底给我带来了什么样的技术福利？
如果你正在考虑RN，或者还在研究选择什么样的技术实现自家的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需要发布在安卓和iOS两个平台，导致的结果就是一个APP两个团队两套代码。界面几乎一样，为什么不能使用一套代码呢？之前也有大神使用各种手段达成这个目标，但是并不是很理想。
由于使用熟悉的react和jsx的模式，开发者只需要有前端知识就可以很迅速的上手一个RN项目。如果再学一些实战的例子，稍微复杂一些的项目也难不倒各位前端开发者。
debug超级方便，一边开发一边看效果再也不是梦。
快速热更新
RN生成的js文件，只要不涉及原生功能的增减，已经发布的APP完全不需要重新安装即可完成新版功能的上线。用户只需打开APP就能体验到最新的APP，省去了下载重装的各种麻烦。把app的更新做到了和网页更新一样的方便快捷。
使用RN就能达到既有原生的所有能力，又有类似浏览器上的快速更新能力。同时还可以接入各种定制好的网页，将APP的自由度提高到一个非常高的地步。
大公司背书
RN的开发者是facebook，背靠大树好乘凉，社区更疯狂。FB本身也在尝试使用RN技术开发自己的APP，RN一定会越来越完善。截止写这篇文章的时候RN已经更新到了0.53.0。
RN本身也是开源的，所有的源代码都是可以看到的。社区的讨论也是比较热烈的。现在可能中文文档还比较少，未来随着开发者的努力，这些坑都会填起来的。
其实最开始的时候也没有想很多，仅仅是冲着RN可以快速开发，上线快体验好。经过了这么长时间的开发，我更加喜欢RN的这种开发方式，项目中也填了各种各样的坑。后面就用一个实际的例子来展示RN是怎样开发的吧。
RN的缺点
升级快
RN本身其实还处于测试版，开发组经常会升级RN，解决一些遗留或者隐藏的bug。在这个的过程中就导致了RN本身升级非常快，开发者在使用RN开发APP的过程中应该尽量提高自己的版本，不需要一直是最新的，只要能够跟的上FB的节奏即可。
自己搞定的问题也是可以合并入RN的源代码里的。不要一味的等RN更新，有些问题自己解决更方便。建议会Android或者ios同学自己动手。
动画难
这里的难指的是复杂的动画在开发中很难去优化。尤其是开发者懂前端但是不懂原生的情况下。好在常见的APP也不需要多么复杂的动画。一般使用位移变换就足够了，太复杂的动画建议使用RN的svg组件来做。
webview难用
RN自带的webview跟浏览器有一定的差别。APP经常要打开一些网页，可能在开发的时候一切正常，但是到了RN里面就会有一些奇怪的问题，主要还是受到系统浏览器的影响，会有一些兼容方面的问题。这种情况下不如微信使用自己研发的浏览器，可以畅快的使用ES6之类的新技术。
需要原生支持
简单的东西和界面的展现已经完全放手给了开发者。但是还是有一些功能只能原生去实现，如果原生部分的开发者对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最终调用的还是系统的组件，虽然FB已经很努力了，但是在某些时候还是会有兼容性需要处理。
组件
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来开发自己的项目，那就看下去吧。我们将从简单的界面开发，数据更新等开始逐步深入。后面涉及到性能优化、自定义原生部分等。
