如何评价ReactNative？

React native出来也快一周了&＃xff0c;我写了几个demo&＃xff0c;简单看了看objc代码并和开源前的我们的一些结论&＃xff08;见后文&＃xff09;交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。

react native充分利用了Facebook的现有轮子&＃xff0c;是一个很优秀的集成作品&＃xff0c;并且我相信这个团队对前端的了解很深刻&＃xff0c;否则不可能让Native code「退居二线」。

对应到前端开发&＃xff0c;整个系统结构是这样&＃xff1a;

• JSX vs HTML
• CSS-layout vs css
• ECMAScript 6 vs ECMAScript 5
• React native View vs DOM

1. 无需编译&＃xff0c;我在第一次编译了ipa装好以后&＃xff0c;就再也没更新过app&＃xff0c;只要更新云端的js代码&＃xff0c;reload一下&＃xff0c;整个界面就全变了。
2. 多数布局代码都是JSX&＃xff0c;所有Native组件都是标签化的XML&＃xff0c;这对于前端程序员来说&＃xff0c;降低了不少学习成本&＃xff0c;也大大减少了代码量&＃xff0c;不信你可以看看JSX编译后的代码。
3. 复用React系统&＃xff0c;也减少了一定学习和开发成本&＃xff0c;更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json&＃xff0c;然后由Native将这个数据映射成真正的布局视图。
4. css-layout也是点睛之笔&＃xff0c;前端可以继续用熟悉的类css方式来编写布局&＃xff0c;通过这个工具转换成constrain布局。
5. 系统只有js-objc的单向调用&＃xff0c;就是把原生UI组件的方法通过javascritcore或者webview&＃xff08;低版本iOS&＃xff09;映射到js中来&＃xff0c;整个调用过程是异步的&＃xff0c;这样的设计令React native可以让js运行在桌面chrome中&＃xff0c;通过websocket连接Native code和桌面chrome&＃xff0c;极大地方便了调试。对其中的机制Bang的一篇文章写得很详细&＃xff0c;我就不拾人牙慧了&＃xff1a;http://blog.cnbang.net/tech/2698/ 。但这样设计也会带来一些问题&＃xff0c;后面说。
6. 点按操作也被抽象成了一组组件&＃xff08;TouchableXXX&＃xff09;&＃xff0c;这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因&＃xff1a;实时的点按反馈和取消能力。http://facebook.github.io/react-native/docs/gesture-responder-system.html#content 这套相应机制设计得很完善&＃xff0c;能像Native code那样控制整个点按操作的所有过程。
7. Debug相当方便&＃xff01;修改了js以后&＃xff0c;通过内建的nodejs watcher编译成bundle&＃xff0c;在模拟器里面按cmd&＃43;r就可以看到效果。而且按cmd&＃43;d&＃xff0c;可以打开一个chrome窗口&＃xff0c;所有的js都移到了chrome里面运行&＃xff0c;所以什么断点单步打调用栈&＃xff0c;都不在话下。

上面的既是特点也是优点&＃xff0c;下面说说缺点&＃xff0c;或者应该说&＃xff1a;「仍然遗留的问题」&＃xff0c;在我看来&＃xff0c;这个方案已经超越了Hybird方案。

1. 系统仍然&＃xff08;不得不&＃xff09;依赖原生组件暴露出来的组件和方法。举两个例子&＃xff0c;ScrollView这个组件&＃xff0c;在Native层是有大量事件的&＃xff0c;scrollViewWillBeginDragging&＃xff0c; scrollViewWillEndDragging&＃xff0c;scrollViewDidEndDragging等等&＃xff0c;这些事件在现有的版本都没有暴露&＃xff0c;基本上做不了组件联动效果。另外&＃xff0c;这个版本中有大量组件是iOS only的&＃xff1a;ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS&＃xff0c;反过来看&＃xff0c;剩余的都是一些抽象程度极强的基本组件。这样&＃xff0c;用户必须在不同的平台下写两套代码&＃xff0c;而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。
2. 由于最外层是React&＃xff0c;初次学习成本高&＃xff0c;不像往常的Hybird方案&＃xff0c;只要多学几个JS API就可以开始干活了。当然&＃xff0c;React的确让后续开发变得简单了一些&＃xff0c;这么一套外来的&＃xff08;基于iOS&＃xff09;、残缺不全的&＃xff08;css-layout&＃xff09;在React的包装下&＃xff0c;的确显得不那么面目可憎了。

另外&＃xff0c;React Native仍然很不完善。文档还不全&＃xff0c;我基本上是看着他的示例代码完成的demo&＃xff0c;集成到已有app的文档也是今天才出来。按照官方的说法&＃xff0c;Android版本要到半年后才发布&＃xff1a; http://facebook.github.io/react/blog/#when-is-react-native-android-coming &＃xff0c;届时整个系统设计可能还会有很大的变化。

PS&＃xff0c;在使用Tabbar的时候&＃xff0c;我惊喜的发现他们居然用了iconfont方案&＃xff0c;我现在手头的项目中也有同样的实现&＃xff0c;不过API怎么设计一直很头疼。结果&＃xff0c;我发现他是这么写的&＃xff1a;

name&＃61;"blueTab"icon&＃61;{_ix_DEPRECATED(&＃39;favorites&＃39;)}
....>

在 _ix_DEPRECATED 的定义处&＃xff0c;有一句注释&＃xff1a; // TODO(nicklockwood): How can this fit our require system?

HOW?

以上。

下面是一周前&＃xff0c;在React native还没开源的时候&＃xff0c;通过反解ipa的一些分析过程&＃xff0c;有兴趣的可以看看。

背景和调研手段

React Native还没开源&＃xff0c;最近和组里兄弟反编译了Facebook Group&＃xff08;这个应用是用React Native实现的&＃xff09;的ipa代码&＃xff0c;出来几百个JS文件&＃xff0c;格式化一下&＃xff0c;花了几天时间读了一下源码&＃xff0c;对React Native的内部核心机制算是有了一个基本了解。

React Native的核心实现&＃xff1a;

先简单说几点&＃xff0c;详细的等回头更新。

1. React Native里面没有webview&＃xff0c;这货**不是Hybrid app**。
2. 再说React Native的核心&＃xff0c;iOS Native code提供了十来个最核心的类&＃xff08;RCTDeviceEventEmitter、RCTRenderingPerf等&＃xff09;、或组件&＃xff08;RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等&＃xff09;&＃xff0c;然后由React Native的JS部分&＃xff0c;组成二十来个基本组件&＃xff08;Popover、Listview等&＃xff09;&＃xff0c;交由上层的业务方来使用&＃xff08;THGroupView&＃xff09;。
3. 就如他们在宣传时所说&＃xff0c;他们实现了一套类似css的子集&＃xff0c;用来解决样式问题&＃xff0c;相当复杂和强大&＃xff0c;靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件&＃xff0c;个人猜测是采用CSSLayout的C语言版本实现的。
4. 在React Native中&＃xff0c;写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题&＃xff0c;写Native Code的工程师解决的是「提供核心组件&＃xff0c;提供足够的扩展性、灵活性和性能」的问题。

React Native的设计考虑&＃xff1a;

ReactJS对React Native有着直接的影响&＃xff08;我没真正在生产环境中用过React&＃xff0c;只用过Angular&＃xff0c;下面的观点可能有偏差&＃xff09;

ReactJS是这么设计的&＃xff1a;
1. ReactJS 通过createElement返回的不是某个实体DOM对象&＃xff0c;而只是一个数组
2. 通过源码中 ui/browser/ 目录中的代码&＃xff0c;将这个数组转换成DOM

另外&＃xff0c;Facebook自己有JSX&＃xff0c;CSSLayout等开源项目&＃xff08;自己去github上找介绍吧&＃xff09;

有了React再考虑React Native&＃xff0c;很自然就想到了一套最有效率的搞法&＃xff1a;
1. 将 ui/browser 里面的代码替换成一套 Native 的桥接JS&＃xff08;实际上&＃xff0c;iOS版是通过
injectGenericComponentClass方法&＃xff0c;将核心组件的方法注入到JS里面 &＃xff09;&＃xff0c;不就用上React的MVVM&＃xff0c;自动将数据映射到Native了么
2. Native code里面实现三组核心API&＃xff0c;一组提供核心组件的API&＃xff08;create、update、delete&＃xff09;&＃xff0c;一组事件方法&＃xff08;ReactJS里面的EventEmitter &＃xff09;&＃xff0c;一组对Style进行解析&＃xff08;貌似是用的CSSLayout的C语言版本&＃xff09;以及返回Style的ComputedStyle&＃xff08;React Native里面叫meatureStyle&＃xff09;

这样&＃xff0c;用上了ReactJS本身的所有核心功能和设计思路&＃xff0c;Native的开发也足够简单。

React Native的优势和劣势&＃xff1a;&＃xff08;非最终结论&＃xff0c;可能会更新&＃xff09;&＃xff1a;

React Native的优势&＃xff1a;
相对Hybird app或者Webapp&＃xff1a;

1. 不用Webview&＃xff0c;彻底摆脱了Webview让人不爽的交互和性能问题
2. 有较强的扩展性&＃xff0c;这是因为Native端提供的是基本控件&＃xff0c;JS可以自由组合使用
3. 可以直接使用Native原生的「牛逼」动画&＃xff08;在FB Group这个app里面&＃xff0c;面板滑出带一点果冻弹动&＃xff0c;面板基于某个点展开这种动画随处可见&＃xff0c;这种动画用Native code来做小菜一碟&＃xff0c;但是用Web来做就难上加难&＃xff09;。

相对于Native app&＃xff1a;

1. 可以通过更新远端JS&＃xff0c;直接更新app&＃xff0c;不过这快成为各家大型Native app的标配了…

劣势&＃xff1a;

1. 扩展性仍然远远不如web&＃xff0c;也远远不如直接写Native code&＃xff08;这个不用废话解释了吧&＃xff09;
2. 从Native到Web&＃xff0c;要做很多概念转换&＃xff0c;势必造成双方都要妥协。最终web要用一套CSS的阉割版&＃xff0c;Native要费劲地把这个阉割版转换成native原生的表达方式&＃xff08;比如iOS的Constraint\origin\Center等属性&＃xff09;&＃xff0c;两边都会不爽。