如何评价 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 也给出了较详细的描述，可以相互参照。
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 也给出了较详细的描述，可以相互参照。
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
