如何评价 React Native Android
React Native项目成员Tom Occhino发表的React Native: Bringing modern web techniques to mobile（墙外地址）详细描述了React Native的设计理念。Occhino认为尽管Native开发成本更高，但现阶段Native仍然是必须的，因为Web的用户体验仍无法超越Native：
1. Native的原生控件有更好的体验；
2. Native有更好的手势识别；
3. Native有更合适的线程模型，尽管Web Worker可以解决一部分问题，但如图像解码、文本渲染仍无法多线程渲染，这影响了Web的流畅性。
Occhino没提到的还有Native能实现更丰富细腻的动画效果，归根结底是现阶段Native具有更好的人机交互体验。笔者认为这些例子是有说服力的，也是React Native出现的直接原因。
图3 - Occhino在F8分享了React Native（Keynote）
Learn once, write anywhere
“Learn once, write anywhere”同样出自Occhino的文章。因为不同Native平台上的用户体验是不同的，React Native不强求一份原生代码支持多个平台，所以不提“Write once, run anywhere”（Java），提出了“Learn once, write anywhere”。
图4 - “Learn once, write anywhere”
这张图是笔者根据理解画的一张示意图，自下而上依次是：
1. React：不同平台上编写基于React的代码，“Learn once, write anywhere”。
2. Virtual DOM：相对Browser环境下的DOM（文档对象模型）而言，Virtual DOM是DOM在内存中的一种轻量级表达方式（原话是lightweight representation of the document），可以通过不同的渲染引擎生成不同平台下的UI，JS和Native之间通过Bridge通信（React Native通信机制详解 « bang’s blog）。
3. Web/iOS/Android：已实现了Web和iOS平台，Android平台预计将于2015年10月实现（Blog | React）。
前文多处提到的React是Facebook 2013年开源的Web开发框架，笔者在翻阅其发布稿时，发现这么一段：
图5 - 摘自React发布稿（2013）
1. 加亮文字显示2013年已经在开发React Native的原型，现在也算是厚积薄发了。
2. 最近另一个比较火的项目是Flipboard/react-canvas · GitHub（详见 @rank），渲染层使用了Web Canvas来提升交互流畅性，这和上图第一个尝试类似。
React本身也是个庞大的话题不再展开，详见facebook/react Wiki · GitHub。
笔者认为“Write once, run anywhere”对提升效率仍然是必要的，并且和“Learn once, write anywhere”也没有冲突，我们内部正在改造已有的组件库和HybridAPI，让其适配（补齐）React Native的组件，从而写一份代码可以运行在iOS和Web上，待成熟后开源出来。
持续更新...
二、规划
下图展示了业务和技术为React Native所做的改造：
图6 - 业务和技术改造图6 - 业务和技术改造
自下而上：
1. React Node：React支持服务端渲染，通常用于首屏服务端渲染；典型场景是多页列表，首屏服务端渲染翻页客户端渲染，避免首次请求页面时发起2次http请求。
2. React Native基础环境：
2.1. Framework集成：尽管React Native放出了Integration with Existing App文档，集成到现有复杂App中仍然会遇到很多细节问题，比如集成到天猫iPad客户端就花了组里iOS同学2天的时间。
2.2. Networking改造：主要是重新建立session，而session通常存放于http header cookie中，React Native提供的网络IO fetch和XMLHttpRequest不支持改写cookie。所以要不在保证安全的条件下实现fetch的扩展，要么由native负责网络IO（已有session机制）再通过HybridAPI由JS调用，暂时选择了后者。
2.3. 缓存/打包方案：只要有资源从服务器端加载就避免不了这个话题，React Native也是如此，缓存用于解决资源二次访问时的加载性能，打包解决的是资源首次访问时的加载性能。
3. MUI是一套组件库，目前会采用向React Native组件补齐的思路进行改造。
4. HybridAPI是阿里一组Hybrid API，此前也在多个公开场合（如传感器 @杭JS）分享过不再累述，React Native建立了自己的通信机制，看起来更高效（未验证），改造成本不大。
5. 最快的一个业务将于4月中上线，通过最初几个业务改造推动整体系统的改造，如果效果如预期则会启动更大规模的业务改造。
更多详细规划和进展，以及性能、稳定性、扩展性的数据随后放出。
三、风险
1. 尽管Facebook有3款App（Groups、Ads Manager、F8）使用了React Native，随着React Native大规模应用，Appstore的政策是否有变不得而知，我们只能往前走一步。
* 更新：
2015.7.28 AppStore审核政策调整：允许运行于JavascriptCore的动态加载代码，下图是此前的审核政策，对比加亮部分的改变。
2. React Native Android 已于2015.9.15发布，第一个使用RN开发的Android App（Facebook Adverts Manager）6.29已上架Play了。
3. iOS6 javascriptCore.framework 为私有，如在iOS6上使用有拒审风险。（http://stackoverflow.com/questions/23514579/javascriptcore-framework-availability-on-ios），可以通过JavaScriptCore-iOS · GitHub这个库代替，涉及改动较多，只在实验阶段支持了iOS6。
4. ListView 性能问题需要持续关注（ListView renders all rows? · Issue #499 · facebook/react-native · GitHub）
React Native相对于Webview和Native的优势和劣势 @berg 也给出了较详细的描述，可以相互参照。
React Native常用组件在Android和IOS上的不同
1.1.1只指定font,不指定height
在这种情况下，Text组件在两个平台上显示都正常。
可以看到，在垂直方向上，Text组件要比字高，上下都留有富余的空间，这样显示出来美观。但如果仔细看，就会发现Android平台的显示下方所留的控件比IOS平台的显示下方所留的空间要小一些。在IOS平台上，上下富余的空间基本相等；而在Android平台上，上方富余空间的高度大概下下方空间的1.5倍。
1.1.2 只指定height，不指定fontSize
在这种极端情况下，不论height是何值，fontSize的值都是13。
1.1.3 fontSize等于height
在这种情况下，IOS平台和Android平台的表现不同。在IOS平台上，字的上方还有空间，但字的最下一部分没有显示出来。在Android平台上，这种情况更严重。
1.1.4 height大于fontSize
在IOS平台上，当height等于fontSize的1.2倍时，显示效果与只指定fontSize、不指定height类似。如果height继续增大，此时Text组件中显示字符的上方空间保持不变，而下方空间会随着height的增大而增大。
在Android平台上，当height等于fontSize的1.35倍时，显示效果与只指定fontSize、不指定height类似。如果height继续增大，此时Text组件中显示字符的上方空间保持不变，而下方空间会随着height的增大而增大。
1.2 边框在两个平台上的不同表现
在样式中设置边框，比如“borderWidth:1”。
在IOS平台上，能够出现预想的边框效果。
在Android平台上，边框不会出现。
为了实现在Android平台上Text组件有边框，需要用一个View组件包裹Text组件。而这个View组件只需要有一个样式boderWidth。这种方式可以适用于两个平台。
