native,react,有计划发展PC端么_科教百科_小白陪你求知网
native,react,有计划发展PC端么
编辑: 小白陪你求知网 &&&来源:用户发表&&&发布时间:&&&点击次数:41
谁了解native,react,有计划发展PC端么,谢了。
【知识探讨】
现在前端怎么样？React-Native需求量大吗
1. 靠谱的前端从来都是大需求，相当难找。 2. 看场合， Responsive Design 足以应付大多数 web 应用，需要上 React Native 的并没有那么多。
ReactNative是未来趋势，作为Android开发者的我，...
只能说我的理解是未来10年内，纯android开发还是有市场的，毕竟原生的会提供很多的帮助。这个趋势你可以了解一下，技术怎么变都无所谓，重要的是你有编程的意识
ReactNative和OC开发应用，哪个门槛更低
oc和RN是不同的技能树，学到后面面临的境况是一样的。比如说平台特性推送机制，iOS高级动画，CoreData做画板类的应用，复杂组件。 门槛是很前期的东西，我理解就是UI编程和布局，autolayout肯定比flex模型难掌握，oc以前比js难学，现在两个语言...
ReactNative有什么优势？能跟原生比么
关注React Native有一段时间了，最初是被它极具科技感的logo和干爹Facebook的大名鼎鼎所吸引。 截止目前来看，感觉React Native更多的只是一个愿景（learn once write anywhere），Facebook推出的RN就像是一针兴奋剂，对于广大JavaScript出身想...
科教百科相关
更多相关内容
本站内容来自网友发布，本站无法保证其部分内容的正确性，请用户一定仔细辨别。
[] &&[联系QQ：885&971&98] &
沪ICP备号&使用&React&Native&开发原生&App&各种疑问汇总
OSCHINA 第 80 期高手问答（6月29日- 7月5日）我们请来了 &（王利华）为大家解答关于
Native 开发原生 App
方面的问题。
原文地址：http://www.oschina.net/question/314&
王利华， ，携程框架研发部，无线框架高级研发工程师，主要负责携程
HTML5 框架 UI 组件开发及其性能优化、React-Native 的研究和探索、Canvas-UI 的相关研究、Node.js
相关系统研发；擅长 Node.js、JavaScript 以及前后端分离实践。 年，在高德地图研发中心工作，负责
JavaScript API 研发和布道以及 Web App 的 Node.js 服务端研发。热爱生活，热爱开源。
React Native一经推出，就获得众多开发者的关注。React Native
使得 JavaScript 能够开发真正的 APP, 它不仅有着与原生应用相媲美的体验，同时拥有着 web
应用的优势和开发效率。React Native 鲜明的特点就是组件化，一个应用都是多个组件构成；同时为了更高的效率，React
Native 采用了内存 Dom tree Diff 计算，优化了 view 的渲染效率和体验。使用 JavaScript
开发跨终端的应用是未来的趋势。
7 月 18 日杭州源创会的第五个主题就是由 带来《使用 React Native 开发原生
App》主题演讲，杭州的朋友可以点击这里报名参加活动。
：React-Native请问是基于什么设计模式开发的？
：设计模式硬套倒也想不出，基本3个层面：（1）语言层面：js
& jsx，这个对前端人员比较熟悉。（2）核心层面：使用javascript内核引擎 ＋ oc原生组件
（3）使用组件开发app，就像搭积木一样。
：React-Native一般使用什么软件工具开发？？
：这个xcode
：这个需要什么基础？还有就是以后的发展您是怎么看的？会代替原生还是和原生相辅相成？
：（1）基础：前端基础，例如：js、jsx、flexbox以及熟悉ios的组件即可。（2）前景：现在最大的优势就是热更新；对于需要及时更新的部分，可以采用react－native（3）目前：相辅相成；未来的话，我希望更多是大部分替代原生
：组件的属性和方法够多够灵活吗？
React-Native 的第三方库还不是很丰富，需要 oc
的支持和暴露，当然这只是目前。组件的方法不是很多，但是很好的处理了一个UI组件的渲染生命周期，足以控制组件；组件可以自定义和扩展，所以属性是可以灵活使用。具体的可以关注3个比较重要的属性：props、state、ref.
：哦，目前国内还没有系统和教程，等有了系统的教程我也学习一下，可以先试用试用，毕竟是新出来的。
：这里有个入门教程可以看一下：/vczero/react-native-lession
：目前react-native对于android的支持还没有，预计是十月份。我也大概看了下ios的demo效果：js服务端修改，客户端（app）立马显示效果。我想知道的是我们现有app都是用的原生组件来编写，如果后续要进行业务重构的话，react-native可以重构哪类业务，有什么弊端和优点？
：(1)可以将已经封装的原生组件暴露出来给React-Native使用；(2)因为Recat-Native还是有些坑的，哪一门技术和语言没坑呢，踩完就好，可以像天猫一样，重构营销页面开始（更新方便）。这样呢，既能熟悉踩坑熟悉api，又能渐渐重构。
：对于跨平台应用来说，react
是否可以替代目前的开发框架，要实现真正意义上的统一，还有哪些关键点需要解决？
：这个统一谈不上了，至少react-native还不支持android，因为倒不是android的支持是件多么难的事儿，主要是因为android平台的不统一，定制成分较高，引擎的性能参差不齐。跨平台而言，更多强调的是js能够编写跨平台应用，体验也能够和原生相媲美。关键React-Native的发展还需要facebook团队在android上的发力，同时也需要更多的同仁将oc的接口和功能暴露处理，以弥补一些不足。
：phonegap
能开发原生应用吗？
：所有原生应用功能都是可以通过phonegap扩展调用的。
：想知道，这个与
phonegap 的比较，包括开发效率，学习曲线，用户体验，工具的完善程度等
：phonegap 和
react-native 还是不同。react-native 内部在 iOS7 版本以上采用的是 js core engine
解析的，在版本上是降级使用 webview。React-Native 针对前端开发者上手难度应该不是很大，主要熟悉 flexbox
布局、jsx 语法、react-native api。
：我所知道的是 react
现在的学习资料百度谷歌能够搜到的都是 iOS 的，有许多资料顺便提了下 Android 没有像 iOS 那么仔细
：React-Native 目前主推的是 iOS，后面我们一同期待
android 吧
：您好。我想问一下，目前使用 React-Native
有那些局限，React-Native 更适合开发那些应用？
：React-Native
还是有些坑需要踩的，现在 github 上也能看到 Recat-Native 源码库都有不少开发者在提bug，更新的也很快。目前
React-Native 做一些内部 app 还是可以的；目前对动画的支持不是很高，这个可以在一些 app
中做一些优雅降级；更适合开发那些动画效果要求不是忒高、组件功能要求相对较少（如果团队中有 oc 的开发者可以忽略）的
app。很多坑，我们团队现在都在踩。
：React-Native
实现的应用能否实现增量更新？如果能，苹果商店会限制此类应用吗？
：可以实现增量更新；大家都知道天猫已经上了一个活动页，至少目前来看，apple
是不会限制的。相信大公司应该有大公司的胸怀。
：React-Native 是在 React
的基础上设计的（也许描述的不对），对于前端来说，纯业务组建（不涉及 ui，仅仅是逻辑）能否在 ios，android，web
：你说的很对，react-native 是 react
基础上设计的，这是当时 facebook 两个团队做的事情，reactjs 先出来的。如果是语法层面，不设计
UI，是可以共享的。android 的话，我们一起期待吧。、
：从官方的视频看到，React Native 提倡的是 Learn
once, write anywhere，这不是是预示着多个平台还得每个写一遍，不知道共享度能有多少
：目前我们框架团队正在努力做这件事。希望打通
react-native和react.
：React-Native 和 react 的代码可以复用吗
：目前我们团队也在做这件事，想要完全的复用还是很难的。需要做就是将一个方向大通，比如
react 转native。那么就会遇到如需要将 div、img 等封装成 react-native 的 View、Image
组件；同时 css 样式的改变和css-layout
的打通也是比较耗时的工作。后期，我会在大会上分享我们团队正在做的这件事。
：最近由于工作原因也开始关注类似的终端开发,最开始了解的是sencha
touch,能不能做一下两者的对比?
：这个可比性不大呀。sencha touch 就像 jquery
mobile 一样的框架支持 h5，可以配合 phonegap 一起使用；react-native 可以是开发原生的 app，是在
native 层面。
：请问 React-Native
的目前推广和应用局限性有哪些？谢谢~
：React-Native技术的推广可以从公司内存app试水；边踩坑边开发，React-Native的局限性除了平台因素，就是对开发者要求较高。当然开发效率来说，应该是很快的。如果团队中有object-c成员，相对而言，上手就会轻松很多
：Dom tree Diff 是什么鬼？
具体是怎么运算的呢？ 尤其是提高效率上&
：举个栗子：以前我们需要给一个评论点赞，需要更新该评论下的赞，赞的用户昵称信息，我们暂且叫做视图重渲染吧，比如使用jquery,
$('#container').empty().....render()。那么react做了一件什么事呢？react构建的是虚拟的dom，通过内部属性的改变通知虚拟dom进行内存计算（与旧属性的虚拟dom进行一次比较，即diff），将计算后的结果直接更新在界面上，不要我们手动管理视图。内存换效率。
具体的可以看下这篇文章 https://facebook.github.io/react/docs/glossary.html
：React-Native开发出来的app和原生的app的性能有区别吗?
：react-native开发效率高于
react-native效率和体验高于react-native整体性能跟native差距不大
：我想问下，react native
应该是支持热跟新吧，就是通过服务端来控制界面，这样就不要老提交苹果审核了，但是我不确定支持吗？还有就是他和原生开发有什么区别？原生能做的它都可以吗？
：远程的热更新是ok的，因为执行的是jsbundle，jsbundle是打包完成的js文件；原生做的它都可以么？－－至少可以通过各种途径去实现，React-Native
iOS版本目前也是公测中。
Native我们公司也一直再跟进，刚开源就搞起了，现在在产品中使用了，因为怕被拒，所以没有使用动态发布。目前来看只适合做UI，复杂的业务逻辑都得需要Native的配合，使用过程中发现Native中业务的变化无法主动告知JS端，变通做法是JS端不断轮询，不知道大神有何高见？
：React-Native做业务逻辑还是很ok的，你可以尝试下。我们这边开发的内部应用也在使用React-Native,看了下代码，基本的逻辑完全是可以的
使用sendDeviceEventWithName应该可以解决问题，具体的可以看这：/facebook/react-native/search?utf8=✓&q=sendDeviceEventWithName&type=Code&
想了解更多 React Native？赶紧报名杭州源创会吧：http://www.oschina.net/question/713&
原文地址：
http://www.oschina.net/question/314&
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。Facebook 于日推出react native for Android 版本， 加上2014年底已经开源的IOS版本，至此RN （react-native）真正成为跨平台的客户端框架。
Facebook 于日推出react native for Android 版本， 加上2014年底已经开源的IOS版本，至此RN （react-native）真正成为跨平台的客户端框架。本篇主要是从分析代码入手，探讨一下RN在安卓平台上是如何构建一套JS的运行框架。
RN 这套框架让 JS开发者可以大部分使用JS代码就可以构建一个跨平台APP。 Facebook官方说法是learn once, run everywhere， 即在Android 、 IOS、 Browser各个平台，程序画UI和写逻辑的方式都大致相同。因为JS 可以动态加载，从而理论上可以做到write once, run everywhere， 当然要做额外的适配处理。如图：
RN需要一个JS的运行环境， 在IOS上直接使用内置的javascriptcore， 在Android 则使用webkit.org官方开源的jsc.so。 此外还集成了其他开源组件，如fresco图片组件，okhttp网络组件等。
RN 会把应用的JS代码（包括依赖的framework）编译成一个js文件（一般命名为index.android.bundle), , RN的整体框架目标就是为了解释运行这个js 脚本文件，如果是js 扩展的API， 则直接通过bridge调用native方法; 如果是UI界面， 则映射到virtual DOM这个虚拟的JS数据结构中，通过bridge 传递到native ， 然后根据数据属性设置各个对应的真实native的View。 bridge是一种JS 和 JAVA代码通信的机制， 用bridge函数传入对方module 和 method即可得到异步回调的结果。
对于JS开发者来说， 画UI只需要画到virtual DOM 中，不需要特别关心具体的平台, 还是原来的单线程开发，还是原来HTML 组装UI（JSX），还是原来的样式模型（部分兼容 )。RN的界面处理除了实现View 增删改查的接口之外，还自定义一套样式表达CSSLayout，这套CSSLayout也是跨平台实现。 RN 拥有画UI的跨平台能力，主要是加入Virtual DOM编程模型，该方法一方面可以照顾到JS开发者在html DOM的部分传承， 让JS 开发者可以用类似DOM编程模型就可以开发原生APP ， 另一方面则可以让Virtual DOM适配实现到各个平台，实现跨平台的能力，并且为未来增加更多的想象空间， 比如react-cavas, react-openGL。而实际上react-native也是从react-js演变而来。
对于 Android 开发者来说， RN是一个普通的安卓程序加上一堆事件响应， 事件来源主要是JS的命令。主要有二个线程，UI main thread, JS thread。 UI thread创建一个APP的事件循环后，就挂在looper等待事件 , 事件驱动各自的对象执行命令。 JS thread 运行的脚本相当于底层数据采集器， 不断上传数据，转化成UI 事件， 通过bridge转发到UI thread, 从而改变真实的View。 后面再深一层发现， UI main thread 跟 JS thread更像是CS 模型，JS thread更像服务端， UI main thread是客户端， UI main thread 不断询问JS thread并且请求数据，如果数据有变，则更新UI界面。
对于JS开发者来说， 整个RN APP就只有一个JS文件， 而开发者需要编写的就只有如上部分。主要是四个部分：
require 所有依赖到的组件， 相当于java中的import 或者 c++ 中的include。
var AwesomeProject = React.createClass 创建APP， 并且在render函数中返回UI界面结构（采用JSX ), 实际经过编译， 都会变成JS 代码， 比如 变成 React.createElement(View,{style:{flex:1}},
var styles = StyleSheet.create({， 创建CSS 样式，实际上会直接当做参数直接反馈到上面的React.createElement
AppRegistry.registerComponent('AwesomeProject', () =& AwesomeProject); 以上三个更像是参数，这个才是JS 程序的入口。即把当前APP的对象注册到AppRegistry组件中， AppRegistry组件是js module。
接着就等待Native事件驱动渲染JS端定义的APP组件。
对于Android 开发者， 普通安卓程序入口是Activity.onCreate()方法 ， 主要有三个对象
ReactRootView, Android 标准的FrameLayout对象，另外一个功能是提供react 世界的入口，函数startReactApplication实际调用attachMeasuredRootView触发react世界的初始化。
MyReactPackage， 配置当前APP 需要加载的模块，RN 的JS框架会在初始化阶段就会把native的模块按照配置加载到JS数据结构中（MessageQueue), 从而才能在JS 层即可直接判断native是否支持某个模块。支持三种类型模块配置， native module(实际就是不需要操作View结构的API), view managers(实际是映射到virtual DOM中的View组件)， JS module 。
ReactInstanceManager， 构建React世界的运行环境，发送事件到JS世界， 驱动整个React世界运转。 通过builder可以创建不同的React环境， 比如内置js 路径， 开发环境dev的js名字，是否支持调试等。doInBackground会加载指定的JS文件, onPostExecute会调用runApplication接口运行JS APP。
ReactRootView第一次onMeasured计算完成， 然后会利用ReactInstanceManager创建 ReactContext上下文环境。重要的是初始化bridge以及加载js文件， 利用JSBundleLoader方法加载index.android.bundle. 如图
此刻进入JS 世界, 开发者的js 语句连同react js框架层被执行。该步骤最终语句是执行AppRegistry.registerComponent注册一个APP组件，但还没有到开始渲染。
当运行环境准备完毕， 则调用bridge方法运行上步注册的APP组件，触发一连串JS 和 Native相互通信，配合事件驱动， 从而完成native世界的渲染。如图利用bridge方法运行上面注册的JS APP组件的runApplication方法：
所有的APP在操作系统中， 最终都会使用一个事件循环来运行。
一般来说，JS 开发者只需要开发各个组件对象，监听组件事件， 然后利用framework接口调用render方法渲染组件。
而实际上，JS 也是单线程事件循环，不管是 API调用， virtural DOM同步， 还是系统事件监听， 都是异步事件，采用Observer（观察者）模式监听JAVA层事件， JAVA层会把JS 关心的事件通过bridge直接使用javascriptCore的接口执行固定的脚本， 比如"requrire (test_module).test_methode(test_args)"。此时，UI main thread相当于work thread, 把系统事件或者用户事件往JS层抛，同时，JS 层也不断调用模块API或者UI组件 ， 驱动JAVA层完成实际的View渲染。JS开发者只需要监听JS层framework定义的事件即可。如图即JS thread 的消息队列循环：
分析代码可知，消息线程创建于ReactContext环境初始化时， MessageQueueThread.java当中， 该消息队列主要接收系统事件（如 Vsync、timer、doFrame、backkey）、UI事件（如键盘弹起、滚动等）以及 callback事件(JS 的回调函数)。
如图即ReactRootView往JS 传递键盘弹出的事件：
而对于Android 开发者， Android 已经为APP创建一个默认的 Main Looper， 不管是Android System 还是JS 事件都是发送到Main thread通过UI渲染出来。如图即是MessageQueueThread.java直接使用主线程Looper。
跟普通APP不同是，此时JS thread相当于work thread， JS会把对应的事件或者数据通过bridge发送到UI thread。 如图即是native Java层收到的JS事件的处理函数：
RN框架最主要的就是实现了一套JAVA和 JS通信的方案，该方案可以做到比较简便的互调对方的接口。一般的JS运行环境是直接扩展JS接口，然后JS通过扩展接口发送信息到主线程。但RN的通信的实现机制是单向调用，Native线程定期向JS线程拉取数据， 然后转成JS的调用预期，最后转交给Native对应的调用模块。这样最终同样也可以达到Java和 JS 定义的Module互相调用的目的。
JS调用java 使用通过扩展模块require('NativeModules')获取native模块，然后直接调用native公开的方法，比如require('NativeModules').UIManager.manageChildren()。 JS 调用require('NativeModules')实际上是获取MessageQueue里面的一个native模块列表的属性, 如：
使用_genModules 加载所有native module到 RemoteModules数组。RemoteModules每项都是一个映射到native module的JS对象。
调用RemoteModules 的方法， 实际是把moduleID、methodId、args放入三个queue保存。
至此， JS端调用完毕， queue中数据要等待Native层通过bridge来取。
native层会在一定条件下触发事件， 通过bridge调用callFunctionReturnFlushedQueue
和 invokeCallbackAndReturnFlushedQueue ，得到的返回值就是这三个queue。
bridge会把这三个queue交给parseMethodCalls解析， 然后通过JNI回调函数转发到Java层
m_callback 函数是在bridge初始化的时候设置到c++层, 如：
然后在回调函数中，陆续调用ReactCallback对象的call方法，weakCallback就是java层初始化bridge时传入的NativeModulesReactCallback对象，也就是ReactCallback的子类。
到此，转入Java层. 从native module配置表中，取到对应module和method，并执行。
之前ReactInstanceManager 中运行JS APP组件，JAVA 是调用catalystInstance.getJSModule 方法获取JS 对象，然后直接访问对象方法runApplication。实际上getJSModule 返回的是js对象在java层的映射对象。
java层可以调用的JS模块主要在CoreModulesPackage.createJSModules方法配置，有：
如果调用JSModules对象的方法，则会动态代理跳转到(mBridge).callFunction(moduleId, methodId, arguments);
接着调用ReactBridge中声明的JNI 函数，
public native void callFunction(int moduleId, int methodId, NativeArray arguments);
通过JS 的require和 apply函数拼接一段JS 代码， 然后用javascriptCore的脚本运行接口执行，并得到返回值。
这样就在JS引擎中运行了一段JS代码并得到返回值，实现了JAVA层到JS层的调用。每次有JAVA对JS的访问， 则在返回值中从JS层的messageQueue.js中抓取之前累积的一堆JS calls。因为JAVA层要把时间同步、 系统帧绘制等事件传递给JS， 因此queue中的JS calls都会在很短的时间内被抓取。
1、 模块扩展(native module)
官方文档操作：
2、 组件扩展（UI component）
官方文档操作：
因为react模块加载主要在ReactPackage类配置，因此扩展可以通过反射、外部依赖注入等机制，可以做到跟H5容器一样实现动态插拔的插件式扩展。比如API扩展， 通过外部传入扩展模块的类名即可反射构造函数创建新的API：
@OverridepublicList createNativeModules(ReactApplicationContext reactContext){
List modules = new ArrayList();
modules.addAll(Arrays.asList(
new AsyncStorageModule(reactContext),
new FrescoModule(reactContext),
new NetworkingModule(reactContext),
new WebSocketModule(reactContext),
new ToastModule(reactContext)));
if (mModuleList != null && mModuleList.size() & 0) {
for (int i = 0; i & mModuleList.size(); i++) {
Log.i("MyReactPackage", "add Module:" + mModuleList.get(i));
Class c = Class.forName(mModuleList.get(i));
Class[] parameterTypes = {ReactApplicationContext.class};
java.lang.reflect.Constructorconstructor=c.getConstructor(parameterTypes);Object[] parameters ={reactContext};
NativeModulemodule= (NativeModule)constructor.newInstance(parameters);modules.add(module);
}catch (Exception e){
Log.i("MyReactPackage", "add Module Exeception:" + e);
e.printStackTrace();
离线包支持。 目前RN官方支持内置APK打包以及dev server在线更新。而实际上，一般的容器都会实现一套离线包发布平台。大致的实现方案是自定义一个JSBundleLoader，对接到应用管理发布平台。
分离react 框架代码和应用业务代码。目前官方的生产工具是把框架代码和业务代码弄成一个bundle。 但框架代码很大，需要共用， 因此要分离出框架代码单独前置加载。 应用业务代码变成很小一段JS代码单独发布。如果每次都加载框架代码， 启动业务代码会比较慢，一个helloworld都需要4秒左右。初步实践方案是把ReactInstanceManager设置成全局变量共享，在Native APP 启动初始化或者第一次进入RN APP时初始化ReactInstanceManager。这个可能会导致多个RN APP全局变量冲突。
离线包更新主要依赖应用管理发布平台，大致可以做到跟H5离线包一致。
一般说的是图片资源比较多， RN 使用控件显示图片，如：
通过source属性设置图片资源路径， 映射到native层：
因此不管是离线包内资源还是系统资源，只要能转换成Android 统一资源定位URI对象，即可获取到图片。
如果是静态资源，则直接URI统一定位。如果是动态资源， 比如要通过网关获取到base64格式的图片，则需要native扩展特别接口。
1、 可能瓶颈
*因为bridge,
JS和 JAVA是异步互通，如果实现复杂多API的逻辑，可能会导致部分效率损耗在多线程通信。JS 异步的编程方式多多少少带来一些不便。*因为bridge,
可能某些场景做不到及时响应。比如帧动画的实时控制。*Android版本刚推出不完善，并且目前RN版本还在不停的更新中， 可能存在暗坑。*加入JS引擎， 内存的控制比较麻烦，会比普通native增加不少。
2、 待研究
动态注入的API插件实现方案，能跟h5容器共用实现。
因为RN已经具备很多的灵活， JS也可以做到很多大型控件，所以native UI扩展需要定义JS 和 native边界， 哪些是JS 实现， 哪些是native实现。
动画的实现方式。
H5容器和RN容器融合方案
write once, 完全跨平台。
JS 层支持 Fragment manager
如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@ 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】数据库技术天团集体亮相，分享一线生产实践经验，告诉你踩过的坑、走过的路，都是老司机，靠谱！干货分享，不可错过！&&
充分利用阿里云现有资源管理和服务体系，引入中间件成熟的整套分布式计算框架，以应用为中心，帮助企业级客户轻松构建并...
阿里云依据网站不同的发展阶段，提供更合适的架构方案，有效降低网站的开发运维难度和整体IT成本，并保障网站的安全性...
提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过Docker容器来进行应用生命周期管理。
2017杭州云栖大会火热抢票
Loading...天猫Web架构/Pad客户端负责人：如何评价 React Native？
招聘信息：
作者：Facebook在3.26 F8大会上开源了React Native（），本文是对React Native的技术背景、规划和风险的概述。组里的同学于4.2完成了天猫iPad客户端“猜你喜欢”业务的React Native改造（4月中发版）。本周开始陆续放出性能/体验、稳定性、扩展性、开发效率等评估结果。图1 - 4.2已完成React Native改造的业务一、背景为什么需要 React Native？"What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web."摘自3.26 React Native的发布稿（），加粗的关键字传达了React Native的设计理念：既拥有Native的用户体验、又保留React的开发效率。这个理念似乎迎合了业界普遍存在的痛点，开源不到1周github star破万，目前是11000+。图2 - 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通信（）。3. Web/iOS/Android：已实现了Web和iOS平台，Android平台预计将于2015年10月实现（）。前文多处提到的React是Facebook 2013年开源的Web开发框架，笔者在翻阅其发布稿时，发现这么一段：图5 - 摘自React发布稿（2013）1. 加亮文字显示2013年已经在开发React Native的原型，现在也算是厚积薄发了。2. 最近另一个比较火的项目是（详见 @rank），渲染层使用了Web Canvas来提升交互流畅性，这和上图第一个尝试类似。React本身也是个庞大的话题不再展开，详见。笔者认为“Write once, run anywhere”对提升效率仍然是必要的，并且和“Learn once, write anywhere”也没有冲突，我们内部正在改造已有的组件库和HybridAPI，让其适配（补齐）React Native的组件，从而写一份代码可以运行在iOS和Web上，待成熟后开源出来。二、规划下图展示了业务和技术为React Native所做的改造：图6 - 业务和技术改造自下而上：1. React Node：React支持服务端渲染，通常用于首屏服务端渲染；典型场景是多页列表，首屏服务端渲染翻页客户端渲染，避免首次请求页面时发起2次http请求。2. React Native基础环境：2.1. Framework集成：尽管React Native放出了文档，集成到现有复杂App中仍然会遇到很多细节问题，比如集成到天猫iPad客户端就花了组里iOS同学2天的时间。2.2. Networking改造：主要是重新建立session，而session通常存放于http header cookie中，React Native提供的网络和XMLHttpRequest不支持改写cookie。所以要不在保证安全的条件下实现fetch的扩展，要么由native负责网络IO（已有session机制）再通过HybridAPI由JS调用，暂时选择了后者。2.3. 缓存/打包方案：只要有资源从服务器端加载就避免不了这个话题，React Native也是如此，缓存用于解决资源二次访问时的加载性能，打包解决的是资源首次访问时的加载性能。3. MUI是一套组件库，目前会采用向React Native组件补齐的思路进行改造。4. HybridAPI是阿里一组Hybrid API，此前也在多个公开场合（）分享过不再累述，React Native建立了自己的通信机制，看起来更高效（未验证），改造成本不大。5. 最快的一个业务将于4月中上线，通过最初几个业务改造推动整体系统的改造，如果效果如预期则会启动更大规模的业务改造。更多详细规划和进展，以及性能、稳定性、扩展性的数据随后放出。三、风险1. 尽管Facebook有3款App（Groups、Ads Manager、F8）使用了React Native，随着React Native大规模应用，Appstore的政策是否有变不得而知，我们只能往前走一步。2. React Native Android 预计2015年10月才发布，这对希望三端（Web/iOS/Android）架构一致的用户而言也算个风险。3. iOS6 JavascriptCore为私有API（），如在iOS6上使用有拒审风险。4. ListView 性能问题需要持续关注（）React Native相对于Webview和Native的优势和劣势 @berg 也给出了较详细的描述，可以相互参照。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量3187点击量3024点击量2959点击量2917点击量2670点击量2601点击量2511点击量2338点击量2323
&2016 Chukong Technologies,Inc.
京公网安备89