本文目录
- react native 相比其他的优势在哪儿
- 如何评价 React Native
- react-native和flutter哪个更有前途
- react native开发app好用么
- 如何评价 React Native Android
- react native适合进行游戏开发吗
- react native 怎么样
react native 相比其他的优势在哪儿
html5现在还占优势的。1、开发方式（1）代码结构： React Native更为合理，组件化程度高（2）UI布局：Web布局灵活度 》 React Native 》 Native（3）UI截面图：React Native使用的是原生组件，（4）路由／Navigation：React Native & Native更胜一筹（5）第三方生态链：Native modules + js modules = React Native modules2、性能 & 体验（1）内存：Native最少；因为React Native含有框架，所以相对较高，但是后期平稳后会优于Native。（2）CPU：React Native居中。（3）动画：React Native动画需求基本满足。（4）安装包体积：React Native框架打包后，811KB。相比热更新，可以忽略和考虑资源规划。（5）Big ListView（6）真机体验：Native 》= React Native 》 H5/Hybrid
如何评价 React Native
React native充分利用了Facebook的现有轮子，是一个很优秀的集成作品，并且我相信这个团队对前端的了解很深刻，否则不可能让Native code「退居二线」。对应到前端开发，整个系统结构是这样：JSX vs HTMLCSS-layout vs cssECMAScript 6 vs ECMAScript 5React native View vs DOM无需编译，我在第一次编译了ipa装好以后，就再也没更新过app，只要更新云端的js代码，reload一下，整个界面就全变了。多数布局代码都是JSX，所有Native组件都是标签化的，这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。不信你可以看看JSX编译后的代码。复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。css-layout也是点睛之笔，前端可以继续用熟悉的类css方式来编写布局，通过这个工具转换成constrain布局。系统只有js-objc的单向调用，就是把原生UI组件的方法通过javascritcore或者webview（低版本iOS）映射到js中来，整个调用过程是异步的，这样的设计令React native可以让js运行在桌面chrome中，通过websocket连接Native code和桌面chrome，极大地方便了调试。对其中的机制Bang的一篇文章写得很详细，我就不拾人牙慧了：React Native通信机制详解 « bang’s blog 。但这样设计也会带来一些问题，后面说。点按操作也被抽象成了一组组件（TouchableXXX），这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因：实时的点按反馈和取消能力。React Native 这套相应机制设计得很完善，能像Native code那样控制整个点按操作的所有过程。Debug相当方便！修改了js以后，通过内建的nodejs watcher编译成bundle，在模拟器里面按cmd+r就可以看到效果。而且按cmd+d，可以打开一个chrome窗口，所有的js都移到了chrome里面运行，所以什么断点单步打调用栈，都不在话下。上面的既是特点也是优点，下面说说缺点，或者应该说：「仍然遗留的问题」，在我看来，这个方案已经超越了Hybird方案。系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。由于最外层是React，初次学习成本高，不像往常的Hybird方案，只要多学几个JS API就可以开始干活了。当然，React的确让后续开发变得简单了一些，这么一套外来的（基于iOS）、残缺不全的（css-layout）在React的包装下，的确显得不那么面目可憎了。另外，React Native仍然很不完善。文档还不全，我基本上是看着他的示例代码完成的demo，集成到已有app的文档也是今天才出来。按照官方的说法，Android版本要到半年后才发布：Blog | React ，届时整个系统设计可能还会有很大的变化。PS，在使用Tabbar的时候，我惊喜的发现他们居然用了iconfont方案，我现在手头的项目中也有同样的实现，不过API怎么设计一直很头疼。结果，我发现他是这么写的：《TabBarItemIOS name="blueTab" icon={_ix_DEPRECATED(’favorites’)}....》在 _ix_DEPRECATED 的定义处，有一句注释： // TODO(nicklockwood): How can this fit our require system?以上。下面是一周前，在React native还没开源的时候，通过反解ipa的一些分析过程，有兴趣的可以看看。------------------------简单粗暴的分割线--------------------背景和调研手段React Native还没开源，最近和组里兄弟「反编译」了Facebook Group（这个应用是用React Native实现的）的ipa代码，出来几百个JS文件，格式化一下，花了几天时间读了一下源码，对React Native的内部核心机制算是有了一个基本了解。React Native的核心实现：先简单说几点，详细的等回头更新。1. React Native里面没有webview，这货不是Hybrid app，里面执行JS是用的JavascriptCore。2. 再说React Native的核心，iOS Native code提供了十来个最基本核心的类（RCTDeviceEventEmitter、RCTRenderingPerf等）、或组件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，组成二十来个基本组件（Popover、Listview等），交由上层的业务方来使用（THGroupView）。3. 就如他们在宣传时所说，他们实现了一套类似css的子集，用来解决样式问题，相当复杂和强大，靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件，应该是采用facebook/css-layout · GitHub的C语言版本实现的（在ppt中我们看到了类似flex-direction: column一类的代码，这个正是css-layout支持的语法）。4. 在React Native中，写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题，写Native Code的工程师解决的是「提供核心组件，提供足够的扩展性、灵活性和性能」的问题。React Native的设计考虑：ReactJS对React Native有着直接的影响（我没在生产环境中用过React，只看过代码&用过Angular，如果有误请指出）ReactJS里面有这样的设计：1. ReactJS 的大工厂入口createElement返回的不是某个实体DOM对象，而只是一个数组2. 通过源码中 ui/browser/ 目录中的代码，将这个数组转换成DOM3. 底层的渲染核心是可以更换的另外，Facebook自己有JSX，css-layout等开源项目，基于这些，如果要做一个用 JS来开发Native app的东西，很自然就想到了一套最有效率的搞法：1. 将 ui/browser 里面的代码替换成一套 Native 的桥接JS（实际上，iOS版是通过injectGenericComponentClass方法，将核心组件的方法注入到JS里面 ），就直接复用React的MVVM，自动将数据映射到Native了2. Native code里面实现三组核心API，一组提供核心组件的API（create、update、delete），一组事件方法（ReactJS里面的EventEmitter ），一组对css进行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。这样，用上了ReactJS本身的所有核心功能和设计思路，Native的开发也足够简单。那，React Native是什么？其实这东西从Native开发来说，相当于重新发明了一个浏览器渲染引擎并且套一个React的壳，从Web开发角度来说，就是把原来React的后端换成了Native code来实现，就跟Flipboard最近搞的React Canvas 一样： Flipboard · GitHubreact-canvasReact Native的优势和劣势：：优势相对Hybird app或者Webapp：1. 不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题2. 有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用3. 可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。优势相对于Native app：1. 可以通过更新远端JS，直接更新app，不过这快成为各家大型Native app的标配了…劣势：1. 扩展性仍然远远不如web，也远远不如直接写Native code（这个不用废话解释了吧）2. 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。更新1：添加了React对React Native的影响。更新2：基本确定其使用了 css-layout，添加了对React Native的总结更新3: React native已经开源了： React Native，只有iOS版。我写了几个demo，简单看了看objc代码并和开源前的我们的一些结论（见后文）交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。更新4: 补充了几条优势和与前端开发的对照
react-native和flutter哪个更有前途
目前来说react-native使用者及生态更好，flutter发展的更快1、目前使用react-native的公司及项目非常多，其中不乏有很多大公司及项目，而且react-native目前生态非常的好2、flutter目前非常的火，发展非常的迅猛，性能非常不错但是问题也是很多的
react native开发app好用么
一个资深iOS开发者对于React Native的看法当我第一次尝试ReactNative的时候，我觉得这只是网页开发者涉足原生移动应用领域的歪门邪道。我认为一个js开发者可以使用javascript来构建iPhone应用确实是一件很酷的事情，但是我很快放弃了自己去使用它的念头。毕竟我因为爱好而从事ios原生开发多年，并且目前为止已经很熟悉这一套开发专业工具。我已经创造了一些我引以为傲的iOS应用——一些使用Object－C和Xcode构建的应用，通常人们都是这么做的。这两样工具是苹果公司提供的、用来开发iOS应用的，所以，我和其他的苹果开发者都在用。并且当两年前苹果公司发布Swift时，我也毫不犹豫地去尝试它。Swift依旧被使用在Xcode中，并且依旧是苹果公司推荐的开发方式，所以我很快地深入，并且毫不费力地学会了这门语言。我满足于我的苹果生态系统圈。React Native看上去只是一个小小的乐子，在我的脑海中，一切原生应用必须被 原生 地开发。对正要开始掌握 原生 开发方式的我来说，学习javascript（我并没有这方面的经验）和一种几乎全新的构建app的方式简直是荒废时间。时间快进到几个月过后，我可以打保票说，我再也不会使用Objective－C或者Swift来开发iOS应用了。我们接手了一个新的移动应用开发项目，我大概的看了一下设计和需求。正当我要点开Xcode那漂亮的蓝色图标新建一个新的工程时，我们的交互设计师，Adam走过来说，“我们用React Native来做这个东西吧。”他解释说，这个项目合同的一部分明确提及了要给这个应用做一个安卓版本。尽管React Native并不支持安卓，我们知道Facebook正积极地在这方面研究。理论上来说，如果我们用RN构建了这个应用的iOS版本，很多部分能够直接工作在以后的安卓版本上。好吧，我并不乐意。我觉得我已经站在了iOS开发能力的顶峰，现在却要我把这一切全部丢弃。在不可避免的学习曲线面前，我怀疑我是不是能够及时地发布一个高质量的产品。但除此之外，我更加质疑RN是否有能力成产一个高质量的产品。现在看来，我甚至没有觉得这样的质疑是不公平的。当时RN作为一个Beta版本刚被公布不久，文档欠缺，开源库和组建的数量稀少，演示代码或者Stack Overflow上的参考几乎没有。我连看都不想看它一眼。但是我这种闭塞的态度只会带来更多的不良后果。我的第一道坎是学习Flexbox，RN制作UI布局的方式。从最基础的界面构建器开始，纯粹使用代码来布局UI几乎击溃了我的自信。我挣扎着去构建最基础的视觉效果。但不仅仅是UI——任何事情都变的不一样。这对于我是最大的挑战。”每当我止步不前或者不理解的时候，我就告诉自己“如果用Objective－C我能够在五秒钟之内解决它”。每当我发现了RN中的一个BUG（并且bug的数量非常大），我就会想，“oc中根本不会有这种bug，我为啥一定要和RN斗智斗勇呢？”整整两个星期，我都在工作中痛苦挣扎。我对自己的感觉从一个杰出的iOS开发者变成了一个从未写过一行代码的人。这很受挫折，直到我花费了整整一个礼拜理清了思路。我后退一步，认识到Adam对RN做了许多研究。作为我的交互知道，我不得不信任他，相信他没有把我领入一条错误的道路。我发誓我要在周一投入工作，埋头苦干，假装Objective－C和Swift从来没有存在过，并解决这个项目。学会去喜欢React几周之前，我们向App Store提供了第一个React Native应用。对于应用的最终表现结果我真的非常自豪，并且我迫不及待的要开始构建下一个项目了。在仅仅一个月多一点的时间里，我完全踏上了RN的贼船，是什么改变了我的想法呢？React 范例在React中，所有UI的组件都被放置在render（）方法中，并且被state状态控制。你的render（）方法定义了UI在各种状态是如何展现的。当调用setState()的时候，React会找到需要改变的部分并替你修改。想象一个简单的视图，拥有一个“Hello World”标签和按钮。每点击一下按钮，标签会在“Hello World”和“Goodbye World”之间切换。在Objective－C中，我在按钮的句柄中需要一些难堪的if声明，就像下面一样。 if(){label.text =@”GoodbyeWorld”;}else{label.text =@”HelloWorld”;}这样很有用，但是这种UI代码和我第一次创建这个标签的地方（可能在代码中，也可能在界面构建器里）完全脱节。在React中，我们会在state状态中定义一个buttonClicked的bool变量，在render()函数中，标签看起来会是这样的:《Text》{this.state.buttonClicked ? ‘Hello World’ : ‘Goodbye World’}《/Text》并且我们的按钮句柄也会非常简单this.setState({buttonClicked:!this.state.buttonClicked});所有和可视化相关的代码都在同一地方，并且由状态控制一切。这使得理解和修复这段代码变的非常容易。Flexbox这就是我一开始非常痛恨的UI布局工具，现在变成了RN中我最喜欢的事物之一。我承认一开始非常难以掌握，但一旦你开始使用，它把 为多种不同尺寸屏幕构建UI这件事 变的机器快速和简单。我曾经对Xcode中的可视化界面器十分热衷，相比于Flexbox，它的自动布局还是国语复杂。Flexbox使用的CSS式样式使得样式重用变的和复制粘贴一样简单。其中最棒的事莫过于允许你在一瞬间将样式值改变到完美。Live/Hot Reload没错，想看看按钮右移5像素的样子就和command＋s一样简单。React Native能够被设置为在iPhone模拟器中自动重绘当前画面而不重建Xcode工程。这非常厉害因为你不仅可以通过避免重新编译儿节省时间，你还能够调整一个深度嵌套在应用中的界面，调整UI而不用回到最初的界面。Android现在依旧没有发布，但就快了——这一定会非常神奇。在最初我对于ReactNative犹豫不决是因为我已经习惯于做原生的iOS开发。对此我从没有过任何的抱怨。但是我也做过原生的安卓开发，这并不让人开心。React Native在安卓上会变的很瘦欢迎，同时我也在期待它的发布。这会改变移动应用开发的现状，通过使用相同的代码来部署两个平台的应用。回顾想念 Xcode我还是会想念Xcode，或者说是一个IDE器。我已经有了一个很好的RN开发设置，但这并不容易，Sublime Text和一大堆的插件让我有了语法高亮。sublime能够完成同一个文件中基于变量的自动补全，但始终少了一些Xcode自动补全的稳健性。我还是不得不一直查询开发者文档做参考。小缺点，比如键入React.PropTypes.f IDE并不会告诉我我到底在找func还是function，这很让人困惑。我也怀念Xcode的版本控制——允许我一一比较我上一次git提交的版本和现在的版本，甚至还允许我基于行撤销一些特别的改动。我意识到第三方程序能够帮助我完成这些，但是对IDE来说最棒的事情就是将这些囊括到一个包中。（译者使用VSCode可以解决这些问题）为了运行RN项目，我需要终端运行npm，Chrome用来debug，sublime来代码，最终还需要Xcode来运行这个项目并打开模拟器。在大项目中，这些都是细小的抱怨，但是当我面对RN的时候这依旧是缺点。对于Nuclide（Facebook的新IDE）我抱有很高的期望，希望它能结束所有的这些缺点。桥接Facebook还没有也不会去提供所有iOS转向React Native的API，所以对于那些缺失的片段他们提供了桥接js的方法。当我第一次深入RN的时候，这方面的文档非常的糟糕。每当我意识到我需要连接某些事物的时候，我差点就对RN放弃了，因为这些事情早就能够在Objective－C中正常运作。但是当她们更加详细地解释了桥接过程，提供优秀的实例之后，这就无所惧怕了。它仍然是一个麻烦，但是我能够预见到开源社区和nom上会有所有的桥接方案。事实上，大多数的iOSAPI已经存在了。漏洞，文档，开源社区大概所有我最初关于RN的抱怨现在都已经消失殆尽，如果我从今天开始学习它的话。漏洞每天都在被修复，新版本每一周都在迭代。文档还需要加把劲，但比以前好多了。Facebook和开源社区对于研发这个框架变的十分严谨。人们开始聚集在Github和Stack Overflow上探讨它。如果你是一个正在考虑尝试RN的iOS开发者，你要知道你不是一个人在战斗。RN非常棒，你应该带着开放的态度拥抱他。不要像我一样吧自己局限在温室里。走出温室，世界才刚开始。
如何评价 React Native Android
React Native实际上是基于前端的，在Android上的表现很一般。但是其优势就是一套代码多终端运行。节省了成本。要说如何评价，我觉得要看应用场景。对于一些简单的，业务逻辑不复杂的App，可以使用React Native来开发，因为快捷，并且开发一套AndroidIOS都能用，很方便。但是缺点很明显，运行效率不够高，因为不是原生开发，所以点击事件，包括列表渲染，在数据量稍微多一点的情况下，用户体验可能不是太好。所以现在国内行情就是，绝大部分还是原生开发，极少数的企业App会使用React Native来做
react native适合进行游戏开发吗
我就用react native做了个游戏，你可以在苹果app store 搜 studious bear 中文名叫 学霸熊，下载来看看效果。我用的是GitHub上一个澳大利亚人写的游戏引擎，叫react-native-game-engine，在我的游戏的credits里面有标注，我和他交流过，一个挺不错的人。里面用的物理碰撞模型则来自matter-js，你也可以上网搜一下，很多h5网页游戏也经常用到。然后我来谈谈我的看法吧，怎么说呢，只能适用于某些动画以及交互和响应简单的游戏吧。例如我做的这个游戏，我感觉我已经在性能允许的范围内，把我想实现的东西以及用户体验的平衡发挥到极致了。感觉就是为了照顾性能制肘太多了，场景一复杂有时会有掉帧现象，发热有点严重，动画不能做的太多，很多我想实现的东西没办法去实现，做不了进一步深入的东西。还有就是开发的时候，如果是做静态的画面，勉强用debug模式还行，要是做动态的画面尤其是你游戏做复杂后，debug模式根本就跑不起来，卡得要死，我用的是iphone 6s真机，你用模拟器的话就不用再想了（我用的是macbook air开发，机器好可能会快很多），所以很多时候我只能发布release版本测试，尤其一关关卡做完后，慢慢调整，改一次就发布一次，因此导致我的开发时间很长，严重影响效率。但是发布release版本测试还是挺流畅的，闪退情况也很少发生。安卓机我想体验的话简直会是灾难，尤其是低端机，所以这个游戏我也没再开发安卓版本。
react native 怎么样
React.native是目前唯一靠谱有前途的移动跨平台解决方案。搞移动跨平台，解决方案已经有过很多了。Xamarin, Cordova, 基于webView的PhoneGap, 还有一大票各种创业公司的方案。它们都很垃圾。原因很简单：为达成“一次编写到处运行”的目的，这些方案不得不对两个主要平台（iOS和Android）的SDK做进一步的抽象，这意味着它们只能兼容两个平台共有的组件，结果就是写出来的app只能做到最平庸的用户体验。特别是微软的Xamarin，连自家的Windows Phone都搞不好，还给Apple和Google的SDK做包装，那能好么？基于Web的方案就更不用说了，本质就是拿HTML套个壳外加一些原生写的插件。React.native的高明之处在于：它并不追求一次编写到处运行，它放弃了全部代码跨平台这一不切实际的目标。RN的目标很实际：用同一门语言（Javascript），同样的高层架构（Virtual DOM）和设计模式（component-based），针对不同平台分别作出最佳的用户体验。这也就是RN中“native”一词的含义。在实际开发中，要做到最佳用户体验，针对iOS和Android应该要分别编写UI代码的。实际上RN也鼓励这么做。Android是Android，iOS是iOS，web是web，三者有不同的界面语言和用户习惯，凭什么要一样呢？但除却UI，业务逻辑、data object、web call等等却是可以一样的。再加上采用了同一门语言和设计模式，RN在生产力上非常有竞争力。从另一方面看，Flux设计模式反过来也被原生开发社区接受，Redux库在Java和Swift上都有翻版原生实现，所以你不一定要用RN写app，但你还是可以借鉴采用React的设计模式。React项目对于整个开发社区的影响很正面，比PhoneGap这种催生了一大票廉价app码农的垃圾技术正面多了。另外，纯Javascript的开源库也可以直接应用到ReactJS／ReactNative中，这也进一步提升了生产力。
