唐巧：谈谈React Native
唐巧的技术博客
一个新框架的出现总是为了解决现有的一些问题，那么对于现在的移动开发者来说，到底有哪些问题React Native能涉及呢？本文作者唐巧从人才稀缺、代码复用等角度详谈了自己对于React Native的理解。
几天前，Facebook在React.js Conf 2015大会上推出了React Native。我发了一条微博（），结果引来了 100 多次转发。为什么React Native会引来如此多的关注呢？我在这里谈谈我对React Native的理解。一个新框架的出现总是为了解决现有的一些问题，那么对于现在的移动开发者来说，到底有哪些问题React Native能涉及呢？人才稀缺的问题首先的问题是：移动开发人才的稀缺。看看那些培训班出来的人吧，经过3个月的培训就可以拿到8K甚至上万的工作。在北京稍微有点工作经验的iOS开发，就要求2万一个月的工资。这说明当前移动互联网和创业的火热，已经让业界没有足够的开发人才了，所以大家都用涨工资来抢人才。而由于跨平台的框架（例如PhoneGap、RubyMotion）都还是不太靠谱，所以对于稍微大一些的公司，都会选择针对iOS和Android平台分别做不同的定制开发。而JavaScript显然是一个群众基础更广的语言，这将使得相关人才更容易获得，同时由于后面提到的代码复用问题得到解决，也能节省一部分开发人员。代码复用的问题React Native虽然强调自己不是“Write once, run anywhere”的框架，但是它至少能像Google的那样，在Model层实现复用。那些底层的、与界面无关的逻辑，相信React Native也可以实现复用。这样，虽然UI层的工作还是需要做iOS和Android两个平台，但如果抽象得好，Logic和Model层的复用不但可以让代码复用，更可能实现底层的逻辑的单元测试。这样移动端的代码质量将更加可靠。其实React Native宣传的“Learning once, write anywhere”本身也是一种复用的思想。大家厌烦了各种各样的编程语言，如果有一种语言真的能够统一移动开发领域，对于所有人都是好事。UI排版的问题我自己一直不喜欢苹果新推出的AutoLayout那套解决方案，其实HTML和CSS在界面布局和呈现上深耕多年，Android也是借鉴的HTML的那套方案，苹果完全可以也走这套方案的。但是苹果选择发明了一个Constraint的东西来实现排版。在企业的开发中，其实大家很少使用Xib的，而手写Constraint其实是非常痛苦的。所以出现了一类的开源框架来解决这类同行的痛苦。我一直在寻找使用类似HTML + CSS的排版，但是使用原生控件渲染的框架。其实之前就做了这方面的事情。所以我还专门代表InfoQ对他进行过采访。BeeFramework虽然开源多年，而且有2000多的star数，但是受限于它自身的影响力以及框架的复杂性，一直没有很大的成功。至少我不知道有什么大的公司采用。这次Facebook的React Native做的事情相比BeeFramework更加激进。它不但采用了类似HTML + CSS的排版，还把语言也换成了JavaScript，这下子改变可以称作巨大了。但是Facebook有它作为全球互联网企业的光环，相信会有不少开发者跟进采用React Native。不过也说回来，Facebook开源的也不一定都好，比如就被Facebook放弃了，但是不可否认three20作为一个框架，在那个时期的特定价值。所以React Native即使没有成功，它也将人们关注的焦点放在了移动开发的效率上了。很可能会有越来越多相关的框架因此涌现出来。MVVMMVVM在Web开发领域相当火热，而iOS领域的虽然很火，但是还是非常小众。究其原因，一方面是ReactiveCocoa带来的编程习惯上的改变实在太大，ReactiveCocoa和MVVM的学习成本还是很高。另一方面是ReactiveCocoa在代码可读性、可维护性和协作上不太友好。而Web开发领域对MVVM编程模式的接受程度就大不相同了，在Web开发中有相当多的被广泛使用的MVVM的框架，例如。相信React Native会推动MVVM应用在移动端的开发。动态更新终于说到最 “鸡冻人心” 的部分了。你受够了每次发新版本都要审核一个星期吗？苹果的审核团队在效率上的低下，使得我们这一群狠不得每天迭代更新一版的敏捷开发团队被迫每 2 周或 1 个月更新一次版本。很多团队上一个版本还没审核结束，下一个版本就做好了。React Native的语言是基于JavaScript，这必然会使得代码可以从服务器端动态更新成为可能。到时候，每天更新不再是梦想。当然，代码的安全性将更一步受到挑战，如何有效保护核心代码的安全将是一个难题。总结不管怎么样，这确确实实是一个移动互联网的时代，我相信随着几年的发展，移动互联网的开发生态也会积累出越来越多宝贵的框架，以支撑出更加伟大的App出现。作为一个移动开发者，我很高兴能够成为这个时代的主角，用移动开发技术改变人们的生活。愿大家珍惜这样的机会，玩得开心～本文转载自：，作者：唐巧（），iOS大V，资深iOS开发者和Blogger，现任猿题库iOS开发工程师。（责编/唐小引）
CODE官方微信
扫描二维码关注
微信号：CSDN_CODEwrite native apps with React.js？
Titanium () 就是和 React Native 一样的逻辑，用 js 调用原生控件。这样很好，解决了界面体验问题。不过也有没解决的问题。他们无法代替原生的 API，很多效果，开源的控件，都要用原生的代码来实现。简单的 app 没什么问题。遇到复杂的 app，还是原生代码来的靠谱。
UPDATE: React native已经开源了： ，只有iOS版。我写了几个demo，简单看了看objc代码并和开源前的我们的一些结论（见后文）交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。本文首发于Div.io： ，最近我们也会持续分析他，并且也在Android上做类似的实现，观点会迭代，文章会更新。React native充分利用了Facebook的现有轮子，是一个很优秀的集成作品，并且我相信这个团队对前端的了解很深刻，否则不可能让Native code「退居二线」。多数布局代码都是，所有Native组件都是标签化的，这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。不信你可以看看JSX编译后的代码。复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。css-layout也是点睛之笔，前端可以继续用熟悉的类css方式来编写布局，通过这个工具转换成constrain布局。系统只有js-objc的单向调用，事实上就是把原生UI组件的方法映射到js中来了，Bang有一篇文章写得很详细，我就不拾人牙慧了： 。但这样设计也会带来一些问题，后面说。点按操作也被抽象成了一组组件（TouchableXXX），这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因：实时的点按反馈和取消能力。 这套相应机制设计得很完善，能像Native code那样控制整个点按操作的所有过程。上面的既是特点也是优点，下面说说缺点，或者应该说：「仍然遗留的问题」，在我看来，这个方案已经超越了Hybird方案。系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。由于最外层是React，初次学习成本高，不像往常的Hybird方案，只要多学几个JS API就可以开始干活了。当然，React的确让后续开发变得简单了一些，这么一套外来的（基于iOS）、残缺不全的（css-layout）在React的包装下，的确显得不那么面目可憎了。另外，React Native仍然很不完善。文档还不全，我基本上是看着他的示例代码完成的demo，集成到已有app的文档也是今天才出来。按照官方的说法，Android版本要到半年后才发布：PS，在使用Tabbar的时候，我惊喜的发现他们居然用了iconfont方案，我现在手头的项目中也有同样的实现，不过API怎么设计一直很头疼。结果，我发现他是这么写的：&TabBarItemIOS
name="blueTab"
icon={_ix_DEPRECATED('favorites')}
在 _ix_DEPRECATED 的定义处，有一句注释： // TODO(nicklockwood): How can this fit our require system?以上。下面是一周前，在React native还没开源的时候，通过反解ipa的一些分析过程，有兴趣的可以看看。------------------------简单粗暴的分割线--------------------背景和调研手段React Native还没开源，最近和组里兄弟「反编译」了Facebook Group（这个应用是用React Native实现的）的ipa代码，出来几百个JS文件，格式化一下，花了几天时间读了一下源码，对React Native的内部核心机制算是有了一个基本了解。React Native的核心实现：先简单说几点，详细的等回头更新。1. React Native里面没有webview，这货不是Hybrid app，里面执行JS是用的
JavascriptCore。2. 再说React Native的核心，iOS Native code提供了十来个最基本核心的类（RCTDeviceEventEmitter、RCTRenderingPerf等）、或组件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，组成二十来个基本组件（Popover、Listview等），交由上层的业务方来使用（THGroupView）。3. 就如他们在宣传时所说，他们实现了一套类似css的子集，用来解决样式问题，相当复杂和强大，靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件，应该是采用的C语言版本实现的（在ppt中我们看到了类似flex-direction: column一类的代码，这个正是css-layout支持的语法）。4. 在React Native中，写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题，写Native Code的工程师解决的是「提供核心组件，提供足够的扩展性、灵活性和性能」的问题。React Native的设计考虑：ReactJS对React Native有着直接的影响（我没在生产环境中用过React，只看过代码&用过Angular，如果有误请指出）ReactJS里面有这样的设计：1. ReactJS 的大工厂入口createElement返回的不是某个实体DOM对象，而只是一个数组2. 通过源码中 ui/browser/ 目录中的代码，将这个数组转换成DOM3. 底层的渲染核心是可以更换的另外，Facebook自己有JSX，css-layout等开源项目，基于这些，如果要做一个用 JS来开发Native app的东西，很自然就想到了一套最有效率的搞法：1. 将 ui/browser 里面的代码替换成一套 Native 的桥接JS（实际上，iOS版是通过injectGenericComponentClass方法，将核心组件的方法注入到JS里面 ），就直接复用React的MVVM，自动将数据映射到Native了2. Native code里面实现三组核心API，一组提供核心组件的API（create、update、delete），一组事件方法（ReactJS里面的EventEmitter ），一组对css进行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。这样，用上了ReactJS本身的所有核心功能和设计思路，Native的开发也足够简单。那，React Native是什么？其实这东西从Native开发来说，相当于重新发明了一个浏览器渲染引擎并且套一个React的壳，从Web开发角度来说，就是把原来React的后端换成了Native code来实现，就跟Flipboard最近搞的React Canvas 一样： react-canvasReact Native的优势和劣势：：优势相对Hybird app或者Webapp：1. 不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题2. 有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用3. 可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。优势相对于Native app：1. 可以通过更新远端JS，直接更新app，不过这快成为各家大型Native app的标配了…劣势：1. 扩展性仍然远远不如web，也远远不如直接写Native code（这个不用废话解释了吧）2. 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。更新1：添加了React对React Native的影响。更新2：基本确定其使用了 css-layout，添加了对React Native的总结
先说结论：必有作为，但绝不会是一家独大，甚至很难成为主流。用过 React 会知道，React 的核心概念是「DOM Representation」，在开发者和 DOM 中间构建一个中间件，然后通过高效的算法来 diff 两次 Virtual DOM 渲染的差异，然后在最小范围内更新 DOM，在大部分情况下——注意是大部分不是所有——这种做法都是足够高效的，但是对于精细的需求、动画控制等——比如在移动设备上做一个跟随 touchmove 的元素，还要各种 transition 等等——场景 React 会显得力不从心，或者很笨拙。但是抛开这些太过复杂的需求，React 是有能力满足大部分的业务场景的。再说 React Native，这几天不停看见媒体用「Web 开发要 XXX」一类的题目来发稿，真是吐槽无力。React Native 根本都不算 Web 开发好不好——Webview 都没了还 Web 个 bird 啊...React Native 继承了 React 在 JavaScript 的扩展语法 JSX 中直接以声明式的方式来描述 UI 结构的机制，并实现了一个 CSS 的子集，这把「DOM Representation」的概念外扩成了「UI Representation」，由于不是操作真实 UI，就可以放到非 UI 线程来进行 render——所有做客户端 UI 开发的都应该知道 UI 线程是永远的痛，无论你怎么 render，render 的多低效，这些 render 都不会直接影响 UI，而要借由 React Native 来将改变更新回 UI 线程。由于目前没有任何示例代码，也看不到更细节的实现机制介绍，所以以下部分为猜测。如果 React Native 沿袭 React 的机制，就会同样是把两次 render 的 diff 结果算出来，然后把 diff 结果传递回主线程，在最小范围内更新 UI。所以，核心是以下三点：1. 在非 UI 线程渲染 UI Representation2. 高效的 diff 算法保证 UI update 的高效3. 没错，由于中间件的机制，React 很有可能成为一个跨平台的统一 UI 解决方案，可以理解为 UI 开发的虚拟机？声明式 UI 开发，简单快捷，必然大有作为。精细控制无力，复杂应用场景无法很好满足，必然受限。最后再说一句...不是能写 JavaScript 就叫 Web 开发...============================================看了 的答案后来补充。这个答案作为补充或扩展来回答「React + Flux 模型」是非常好的，但问题是「React Native」。React Native 的亮点是解决了在 Native 中使用声明式来开发 UI 的渲染效率问题，而不是软件架构和工程模型的问题，无论是 iOS 还是 Android 固有的模型也是非常好的。为啥 FE 会在乎这个？因为 FE 最习惯用声明式来开发 UI，而这么多年想参与到 Native 开发中的目标都没能达成，就是受制于最终的运行效率。React 作为一个 View Component 封装解决方案来讲，同 Polymer 以及 AngularJS 中 Directive 并没有本质区别，只是用不同的思路来封装 View 而已，用 React 也不一定非得用 Flux 模型，React 替换 Backbone.View 组件，用纯朴的 MVC 模型来描述也是 okay 的。但是当 component 很多且互相嵌套时，就需要有一个合理的模型来描述通信机制，优雅且高效，那就是 Flux 模型了。前年 React 刚发布，还没有提出 Flux 时，我们在终端产品中开始小范围尝试 React 就遇到了 component 之间通信麻烦或者不合理的问题，当时的解决方案是全局实例化了一个继承 Backbone Event 的对象作为 event hub，所有的 component 都在其上来 reg 和 trigger 事件。现在看来，就是简化版的 Flux 模型。不过我确实有一点遗漏的内容，React 的 DOM Representation 或者 React Native 的 UI Representation 的每个 component 都有一个 state 用来描述状态，而 component 某种意义上来说就是一个状态机，因此渲染结果是幂等的。近些年 Web 前端的开发越来越多的受到工程复杂度上升导致整体性能下降的困扰，所以最近几年的新型框架大多有一些独特的机制来提升性能，而这些机制大多是从 Native UI 或者游戏开发中借鉴来的，比如 AngularJS 中的数据 dirty check 机制，比如 React.js 中 Virtual DOM 的 diff 机制，这些特点同以前的前端框架或库相比，真的是非常特殊且先进的改进，往往也会成为这个框架或库的亮点之一，对 FE 来讲当然就是新鲜玩意啦。最后，Facebook 在 PHP 中直接写 HTML Tag 那东西叫 XHP，对应是 JSX 扩展语法，和 React 关系也不大...
I love software.几个小时前，上，Facebook 发布了 React Native，可以基于目前大热的开源 JavaScript 库 React.js 来开发 iOS 和 Android 原生 App。而且 React Native 已经用于生产环境——Facebook Groups iOS 应用就是基于它开发的。Facebook 也已确认，这个项目很快将会开源。&
根据 ProgVille 的文章，React Native 的原理是，在 JavaScript 中用 React 抽象操作系统原生的 UI 组件，代替 DOM 元素来渲染，比如以&View&取代&div&，以&Image&替代&img&等。&
在幕后，React Native 在主线程之外，在另一个背景线程里运行 JavaScript 引擎，两个线程之间通过一批量化的 async 消息协议来通信（有一个专门的 React 插件）。&
UI 方面 React Native 提供跨平台的类似 Flexbox 的布局系统，还支持 CSS 子集。可以用 JSX 或者普通 JavaScript 语言，还有 CoffeeScript 和 TypeScript 来开发。有评论说，React 的 UI 层模型要比 UIKit 好很多。&
更好的是，由于基于 Web 技术，开发起来可以像在浏览器里那样随时在仿真程序中查看应用运行情况，刷新一下就行，无需编译，爽吧。&
只是不知道这种架构下 App 的性能、流畅度如何。
更多详情可以参考会议视频：&