如何评价 React Native Android
1个回答
展开全部
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 也给出了较详细的描述,可以相互参照。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询