一、前言
1. 移动应用开发的三种主流方式：Native App 、Web App、Hybrid App
2. 三种移动应用开发方式比较
二、混合开发应用场景
使用 Hybrid 开发方式，能集Native 和web两者之优点。一方面，Native 让开发者可以充分利用现代移动设备所提供的全部不同的特性和功能。另一方面，使用 Web 语言编写的所有代码都可以在不同的移动平台之间共享，使得开发和日常维护过程变得集中式、更高效、更经济。
三、使用JS框架开发Native App
虽然Hybrid开发方式解决了Native App开发成本高、升级繁琐、无法快速适应业务需求等问题，但web页面仍然是使用webview来渲染，相比较原生流畅度体验有差距明显，于是随着技术的发展又出现了使用JS引擎来渲染Native的方式开发App，目前这种方式应用较多的框架有ReactNative与Weex。
React Native
简介:Facebook在2015年3月在F8开发者大会上开源的跨平台UI框架
核心理念:Learn once, write anywhere
基于JS开发框架:React Native基于React
WEEX
简介:weex是阿里巴巴公司与2016年6月开源的一种用于构建移动跨平台的UI框架
核心理念:Write once, run everywhere
基于JS开发框架:WEEX基于vue.js
四、ReactNative&WEEX比较
环境配置：
React Native 需要安装Android，iOS开发环境，很多依赖，相对复杂。
Weex需要安装Android，iOS开发环境，安装cli，相对简单。
开发：
React Native倾向于web方式，使用JSX语法，熟悉React后学习相对容易，需要理解Native App 中的一些原理与sdk。
Weex也是倾向于web方式，使用vue.js定义的语法，熟悉vue后学习相对容易，需了解原生sdk。
调试：
React Native 支持虚拟机调试，可以在chrome查看调试信息。
Weex可以在chrome查看，支持节点调试查看，不支持虚拟机调试。
性能：
React Native重心比较多，有较多第三方尝试性能优化方案。
Weex官方内部的项目里使用，性能优化也仅限于官方开发人员。
案例：
React Native比较早，Github上轮子、案例、教程比较多。
Weex起步较晚，使用的大厂少，案例少。
社区：
React Native较早，社区相对成熟，有强大的第三方生态。
Weex较晚，虽已经开放，但第三方代码贡献少，成熟需一段时间。
五、选择React Native来开发APP
React Native 的历史可以追溯到 2013 年的夏天，React Native 是当时 Facebook 的一个黑客马拉松项目。虽然 React Native 很新，但在国外，很多巨头互联网公司已经使用 React Native 完成 app 开发。早在 2015 年，Facebook 就用 React Native 做了他们的第一个跨平台 app——Ads Manager，让在 Facebook 上做广告的数百万用户可以随时管理自己的账户。2016 年初，Instagram 也开始将 React Native 应用到其“推送通知设置”、“编辑个人资料”、“保存”、“评论审核”等功能。
此外，还有 Airbnb、特斯拉（Tesla）、沃尔玛（Walmart）、UberEATS、Bloomberg 等。在国内，天猫、QQ、手机百度、京东等 app 也已加入 React Native 大军。
React Native 之所以可以吸引这么多巨头来应用，是因为其明显的优势——帮助开发者快速开发迭代、提高多平台开发效率，帮助企业节省人力时间。即“Learn once, write anywhere”（仅需学习一次，编写任何平台）
React Native 的优势如下：
原生组件
React Native 采用了原生 UI 组件，相比而言，使用 HTML5/JavaScript 实现的组件比起原生组件总会感觉差一截。
高代码复用率
比如，Instagram 使用 React Native 开发的上述几个新功能在 iOS 与 Android 平台的代码重用率达到 85% - 99%；沃尔玛在 iOS 与 Android 平台的代码重用率是 95%。因此，开发效率大大提高。
热加载
React Native 大大缩短了文件修改后和看到修改所产生的变化之间所需的时间。也就是说，开发者可以立即看到其对代码所做的最新修改结果。如果你打开了两个窗口，其中一个包含代码，另一个使用虚拟机显示代码的效果，你可以在第二个屏幕上立即看到你在第一个屏幕上所做的变化的效果。
架构分工
项目工作工作中常遇见有个棘手的问题 - 一个超级大项目但是时间又很急给 3 人做如何分工？
这个分工看似合理，但是这个“合理”也仅仅站在研发的角度。但是一个完整的项目设计到的角色很多，PM，UI，甚至还有 BD 一类的。这么一看，问题就来了。这个分工每个研发角色都需要和其他各个角色打交道呀。大公司 + 打交道，你懂的。so，酸爽。那怎么办呢？这个可不碎片化哦。那 React 能解决吗？
这个分工让张三和李四逃出了 PM 和 BD 的魔爪，让王五一个痛苦去吧。但是呢，来自 UI 的压力也基本被张三和李四分担了。这个已经很合理了吧，还有优化空间？咱们仔细看一下。 王五是比较累的，因为张三和李四分担了他的不同的功能组件。他在整合业务会和这两人同时打交道。那再来个 Redux？
这下好了，王五负责和 PM，BD 交涉。李四负责做王五和张三的桥梁。张三不管业务，一门心思和 ui 同学搞组件。
这就是 React+Redux 的强大，他能让你在分工的时候追求碎片化到极致。虽然看似代码的行数可能没有精简，但是无形中把人员的关系解耦了。
规范中的自由
看到上面，有的朋友会质疑了。“你这个东西是强拉着和 React 有关系。说白了就是个项目架构和职责的化分问题。我就是用原生的开发也可以这么划分呀。”
理论上是这样没错。但是所谓框架，就是架构设计的选型承载。它已经为你的这种设计提供了很好的功能 api 和工程规划。
React 提供的这些组件的表达方式，Redux 提供的组件和数据之间的绑定方式。虽然看上去表复杂，但它规范后有清晰自由的层级划分。因为这些看似复杂的状态对象，生命周期，动作函数。才使得你在组件内部无论什么样的风格，也不会让组件和组件之间（其实也就是开发者与开发者之间）的逻辑传递有任何阻碍。在这套框架下，组件之间数据共享、action共享，产生的作用就是高代码复用率。
第三方生态
就算结合了上面两点，但是还让你觉得。“无非就是个框架的事儿，不一定非要用 React 呀。” 那接下来我只有弱弱的澄清一下。
确实不一定非要用 React，囧。
据不完全统计，React 有比其他类似框架更庞大的周边生态。开发者都明白，真正能让项目开发过程享受便利的一定是好的框架 + 丰富的库。而这一点，也是 React 对标竞品的优势所在。
PS:文章内容来源于网络，作者仅重新编辑排版，部分内容修改。
