移动开发路在何方？React Native！
作者｜wingjay
来源｜简书
学习了React Native，移动开发者的未来又多了一种可能......从诞生之日 React Native 就充满了期待和争议，比起疑惑、争论，还不如来好好看看这货究竟是个啥？甚至自己动手来玩一把。
React Native 诞生于 2015 年，名副其实的富二代，主要使命是为父出征，与 Apple 和 Google 抗衡，为开发者带去一套跨平台、动态更新的 Java 框架，口号是：Learn once, write anywhere：Build mobile apps with React。在试图推翻 Android 和 iOS 压制的同时，还提携了一把自家兄弟：React。
从诞生之日 React Native 就充满了期待和争议。期待是无数开发者希望不用忍受频繁发版的噩梦，也不用同时为两个平台开发业务逻辑几无差别的两个 App；争议是 React Native 真的能以一己之力救大众于水火吗？React Native 在跨平台时还能保持良好的用户体验吗？
当然我们知道，这种问题向来都是仁者见仁，智者见智。比起一味的疑惑、争论，还不如来好好看看这货究竟是个啥？甚至自己动手来玩一把。
本文主要针对两类读者：
想要入门 RN 的人，在阅读官方文档前先对 RN 形成一个整体的印象
对 RN 心存好奇，在犹豫是否要入坑的开发者，可以通过本文对 RN 更客观全面的认识
React Native 好在哪?
下面我们来看下 Hybrid 及 React Native 等开发模式包含了哪些常规移动开发所不具备的优势。
跨平台＋动态更新
传统的客户端开发模式是怎样的呢？
Android 与 iOS Team 分别编写客户端代码，打包，分发到 Play Store 和 Apple Store，通过更新 JSON 数据来更新页面。
不过，当客户端发生严重问题而服务器上无法 quick fix 时，就不得不重新发版。
对国外 Android 市场而言还好，因为能通过 Play Store 快速更新；国内 Android 市场则由于分发渠道太杂，很难及时把新版本立即推送给所有用户，当然这也是为何热修复技术在国内盛行而国外冷清的原因；而 Apple Store 则需要一定的审核时间，而且最近又在抓 iOS 热修复框架如 JsPatch、Rollout 等。
相比而言，Hybrid 和 RN/Weex 模式除了能下发 Json 数据来刷新界面内容，更能直接下发业务逻辑代码，直接实现整体 App 的更新。而且，它们不用在乎 Android 和 iOS 两个平台，因为一份 JS 代码写好后，把 JS Bundle 放在服务器上，所有的客户端立即更新。
一般而言，同一款产品的 Android 和 iOS 两端除 UI 有些许不同外，多数业务逻辑几乎完全一致，这便造成了人力的浪费。
而最近 Instagram 的官博 React Native at Instagram 一文中已经提到，利用 RN (React Native 缩写，下同) 开发的 feature 可以实现 85% - 99% 的代码复用率。这意味着我们可以用更少的人力成本来达到相同的效果。
RN vs Weex
实现上面的效果有两种开发框架：混合开发框架 Cordova 和基于 Java 的 React-Native、Weex 框架。
下面我从自己的实践经验出发做些比较，也欢迎读者提出自己看法。
最开始觉得 RN 的学习成本比较大，所以首先考虑了 Weex 框架，据说是阿里巴巴良心出品。不过在尝试后不得不选择了放弃，原因有这几点：
Bug 较多。我们最先测试了最基本的 ListView，在 iOS 运行良好，而同样的 Demo 代码到了 Android 这边的下拉刷新就出现了问题，这使得我们开始警惕；
社区、文档弱，GitHub Issue 基本是中文。当然我毫无歧视中文之意。我认为，一套项目开源是真正意义是希望借助开源社区的力量，一起来完善改进，因此要优先推崇英文，使项目国际化，得到全世界开发者的共同支持，这样才是可持续的模式。而 Weex 的 Issue 里放眼望去基本 90% 都是中文，无论提问者还是项目维护者。这一点直接把国外优秀的开发者拒之门外，也很难让我看到多么长远的未来。下面是摘取的 RN 里的一则中文 issue：
（Issue is for bug report, not for Q&A）
Contributor 差别。因为上面一点，Weex 的 Contributor 只有 91 个人，而 React-Native 的 Contributor 有 1214 人。Contributor 是用来干嘛的？除了支持新功能，还有就是修复 bug 啊。Weex/RN 都是希望一统 Android + iOS 的，这么伟大的目标，这么艰巨的工程，不是几个人可以轻轻松松搞定的。
公司背景（来自YY）。大家都知道 RN 来自 Facebook，Weex 来自阿里巴巴。如果想一窥它们的未来，需要先想一下这种技术对他们各自的意义。大家都清楚，Facebook、Google、Apple 是当今当之无愧的巨头，在移动互联网这波浪潮里，Google 掌握了 Android 法器，Apple 控制了 iOS 神器，Facebook 呢？并没有这些系统级入口。当然 Windows 的经历也让 Facebook 并不那么倾向去开发一个新的移动操作系统来竞争。那怎么办？React Native 应运而生，打出的口号就是： Learn once, write anywhere。什么意思，没错，就是明确告诉你学一次就可以同时开发两个平台了。这一点可一直都是移动端开发人员和创业公司的理想。有人说了，Apple 这么强势，RN 要是太嚣张，分分钟把你禁掉。这时我们就要来看看 RN 的 Showcase 了，哪些 App 应用了 RN 呢？Facebook, Instagram, Airbnb, Walmart, QQ, 京东等，这回 Apple 要禁 RN 就要稍微掂量下这些大厂的意见吧。
当然，我是很希望国内也能推出优质的开源项目来和国外大厂抗衡的，不过真正优质的大型开源项目往往除了开发者的个人能力，和公司的战略和制度关系也很大。
RN vs Hybrid
这里的 Hybrid 开发主要针对 Cordova 框架，其实在放弃 Weex 之后我们还是没考虑 RN，而是转过去了解 Cordova，不过做了大致了解后也放弃了。主要硬伤有两点：
性能短板。大家知道 Hybrid 是基于 WebView 的，在 Android 上的性能缺陷非常明显；而 RN 是利用 JSCore 转化成 Native 运行的，性能相对而言好不少；
用户体验。了解移动产品的人都知道用户体验的重要性，RN 的体验和原生的几乎没有差别，而 Webview 的实现是网页开发思路，体验会相差很大。
性能和用户体验是移动 App 的命根子。
因此，综合考虑下来，我们还是决定相信 Facebook 并采用 RN。
上面我提到了 RN 的一些优势，不过作为开发者更加需要明确其劣势，我总结了下大概有以下几点劣势：
学习成本。Weex 的写法就是类似常规的 Html/JS，对于前端人员来说很容易上手，就算了非前端人员来说也花不了多久。而 RN 是在 React.js 上进行改进形成的一套语法，和常规前端差别较大，因此需要好几天的学习适应。当然我觉得优秀的程序员的基本素质之一就是能快速学习、练习并熟练一种新语言的。我个人的话大概花了两三天的时间已经能完成一套涵盖网络、JS与Native通信的页面了，对于 React.js 语法也上手很快。
安装包 Size。对于 iOS 而言影响不算很大，对于 Android 来说，我尝试后发现引入 RN 会给 apk 带来 6MB 左右的增幅，不过利用 split apk 的技术就能缩小到到 1MB 左右的增幅。
首次加载耗时。大家知道 RN 需要从服务器下载 JS bundle，然后在本地转化成 Native code 运行的，所以在第一次打开 App 时需要花费一些时间进行下载和刷新。当然我们可以在发布 client 时内置一个写好的 js 文件在本地作缓存用。
React Native 运行机制
对于一个用 RN 搭建的移动 App，在启动后会从服务器下载最新的 JS Bundle 文件，然后由本地 JavaCore 引擎对 JS 文件进行解析，并利用 Bridge 映射到对应的 Native 方法和 UI 控件。得到的效果是：
同样的 RN 代码，下发到 Android 和 iOS 不同平台中，会自动调用对应 Native 的 UI 控件，保证了各平台用户体验的连贯性；
开发者就算是移动端小白，只要有 Web 基础，通过编写一套 RN 端代码就可以同时完成 Android 与 iOS App 的开发；
由于可以利用 JS bundle 同时下发数据和业务逻辑，这意味着你可以像 Web 开发一样，实时迭代更新你的移动端 App，无需在了解各自平台的热修复技术；
Native Modules，这是 RN 强大的一个扩展性，允许你通过简单的代码就能实现在 JS 里直接调用你自己的 Native 方法；
Native Components，如果你自己实现了一些复杂的 Native UI 组件，而这些组件尚未被 RN 支持，你可以利用 Native Components 快速把原生组件引入到 RN 中并可以直接在 JS 里更新这些组件的状态。
React Native 适合你吗？
这里借鉴下前段时间旧金山的 React Native 会议上的一些优劣总结给读者以参考。当然不一定对，仅供参考。
RN 的优点：
原生的用户体验
开发者体验好
动态更新代码逻辑
RN 的缺点：
生态系统在搭建中
优质的 App 需要时间打磨
偶尔需要写 Native 代码(也就是 JS + Swift + Java)
适合下面这些人/公司：
你对 JS/React 有一定了解
Web 开发人员比 Mobile 开发人员多
有意愿投资精力给 RN
App 设计不是特别区分 Android 和 iOS
希望热更新
对 React Native 的一些个人感受
我接触 React Native 主要是因为业务需要，PM 希望能够随时改动某块变化较大的模块，常规的开发提交流程往往需要较长的时间，而热修复技术本身并未得到 Google 和 Apple 的官方认可，也就是随时可能因破坏生态安全之名被取缔。
因此才考虑去了解 Hybrid 开发和 JS Native 开发模式，在了解过程中，又由于性能差、用户体验不好而放弃 Hybrid，由于社区不完善、Bug 较多等原因放弃 Weex，最终才选择了 React Native，开始学习 React、JSX等语法。
目前使用下来对 React Native 的一些个人感受：
学习门槛并没有开始想象那么高。大概只花了两三天时间就熟悉了 Java、React 框架、JSX语法，然后就开始着手业务开发。
对 Android App 的影响。React Native 会给 Android 端带来 6MB 左右的 size 增幅，不过在采用了 split apk 后就只有 1MB 左右增幅。
Debug 功能比较完善，至少不用担心发生问题后不知从哪下手。
性能还行。最初担心的是 React Native 性能不好，但自己上手后，并没有明显感觉到很明显的 React Native 对 App 性能的负面影响，无论是 iOS 还是 Android，当然，这一点还在继续考察中。
动态部署真的很不错。以前每次写好代码都要花不少时间来编译运行，而现在只要写一份代码，就可以同时在 Android 和 iOS 实时更新了，这无疑节省了生命。
有待完善。当然，React Native 中确实还存在着不少问题，生态系统也还不够完善。不过我相信，这只是时间问题。
关于React Native一直以来都有很多争议。
不过我想说的是，React Native 所代表的跨平台、动态更新技术已经引起了全世界开发者关注，而且这种技术势必会是未来的需求和潮流。React Native 不一定会成功，但至少目前 React Native 已经是这一领域的领跑者。
而写这篇文章的目的，就是希望告诉更多开发者，React Native 并不完美，但值得一试。
著作权归作者所有，本文有部分删减。
原文链接：/p/b#
本文系 wingjay原创文章，已经授权StuQ公众号转发传播。
想更深入掌握 React Native？往下看
目前，一系列互联网巨头公司已经应用 React Native 来完成 App 开发。比如国外的Facebook、Airbnb、Tesla、Walmart、UberEATS和国内的QQ、手机百度、京东等。
之所以收到大公司青睐，是因为 React Native 有以下几个优势：
ReactNative采用了原生UI组件，相比而言，使用HTML5/Java实现的组件比起原生组件总会感觉差一截。
高代码复用率
比如，Instagram使用 React Native 开发的上述几个新功能在 iOS 与 Android 平台的代码重用率达到 85% - 99%；沃尔玛在 iOS 与Android 平台的代码重用率是95%。因此，开发效率大大提高。
ReactNative大大缩短了文件修改后和看到修改所产生的变化之间所需的时间。也就是说，开发者可以立即看到其对代码所做的最新修改结果。如果你打开了两个窗口，其中一个包含代码，另一个显示代码的结果，你可以在第二个屏幕上立即看到你在第一个屏幕上所做的变化的效果。
为了让大家更好地了解React Native，StuQ工作坊联合腾讯前端高级工程师——莫卓颖，带你由浅入深掌握React Native开发实战技能。
特别地，这次工作坊，我们还请来两位硅谷来的大咖——覃超和陈坤，带你从移动上的技术演变看最新硅谷mobile app的技术选型。
座位有限，点「 阅读原文」抢座~
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。React Native并非原生
发表于 15:50|
来源Metablog|
作者Marcel Weiher
摘要：主张“Learn once, write everywhere”的React Native让开发者用JavaScript开发移动原生应用，但事实却非如此。React Native其中很大一部分利用了原生架构，却也包含了一些非原生架构。
当我们就Apple的“”讨论术语泛滥问题时，Facebook于上个月正式开源的似乎亦是如此。主张“Learn once, write everywhere”，让开发者用JavaScript开发移动原生应用，此景虽好，但事实并非如此。React Native其中很大一部分利用了原生架构，却也包含了一些非原生架构：用视图作为drawing result，而不是drawing source；平行的组件层级结构（component hierarchy）；使用ListView，而不是UITableView；不使用UIButton创建按钮；不使用响应链，但是找到了相似的替代品；最后，使用JavaScript语言来编写。以上列出的种种多多少少体现了React Native的一些优势，但React Native本质上并非原生。另外，React与不久前刚发布的Components框架的基本原理跟苹果关于MVC模式的误解实在是不谋而合：图中所示：控制器（Controller）持续通过视图（View）显示数据并不能体现MVC的具体含义，除非将其理解为“Massive View Controller”。在Components和React Native中，用View（UIView/NSView）将“实现UI的可变状态”替换为“模型（单一）功能”，发挥drawRect::的作用。以后面临的问题不再是创建新的完整框架，而是通过视图显示数据。解决方法是，将画板上的Custom View拖到UI上，执行drawRect::。绘制视图（以及/或者将组件设置为视图状态突变）比drawRect::更凸显状态性，而非削弱。再强调一下，这个解决方案还不错，只是没有循规蹈矩罢了。据我所知，目前热捧React Native的主要是一些Web开发者，他们如今无需学习Objective-C/Swift或Java，就能开发“原生”应用了。不过，React Native究竟是否体验与宣传如一还尚未定论。最后，“react”貌似是指“单向响应数据流”——更让人摸不着头脑的行内话，我想以后会常常遇到。（编译/张新慧 责编/唐小引）文章来源：CSDN移动将持续为您优选移动开发的精华内容，共同探讨移动开发的技术热点话题，涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面，如果您有想分享的技术、观点，可通过电子邮件（tangxy#csdn.net，请把#改成@）投稿。第一时间掌握最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章简介：Hybrid App（混合模式移动应用）开发是指介于Web-app、Native-App这两者之间的一种开发模式，兼具「Native App 良好用户交互体验的优势」和「Web App 跨平台开发的优势」。很多人都知道，React Native 是 Facebook 开源的框架，可以直接用 Javascript 开发原生的APP，本文则会围绕开发中的具体实践问题进行讨论。
此前，我们在多篇文章中提到过 React Native，本次移动精英开发俱乐部又专门围绕 Hybrid App 和 React Native 进行更加深入的讨论，希望能够给我们的开发者同学，提供一些建议。文章系朱雅丽整理， IT 运维管理平台
负责审校。以下为讨论内容：
主持人－东辉：大家好，今天我们的主题是 Hybrid App 和 React Native，欢迎大家踊跃进行发言。
陈伟鹏－雅特iOS：我想知道用了 React Native 的同学，对这种技术的态度和评价？
郭镫鸿：貌似携程、平安科技还有天猫都在使用 React Native，说明还是有市场的。
主持人－东辉：React Native 在 Android 上的表现貌似不太好，坑比较多吧？
龙虾：React Native 的首次加载很慢，有缓存就好一些，其他的还可以，落地的难度就是不知道该客户端开发做，还是前端做。
郭镫鸿：React Native 有效解决了H5的性功能障碍问题，这点很不错。就像 React Native 的理念：leaReact Native once, write anywhere .
James：个人理解，React Native 的推出应该是为了统一移动端的开发模式。
罗飞：大家可以分享一下自己公司用 Hybrid 或 React Native 的现状，都是怎么用的？
利炳根：现状就是：大部分都可以用 React Native 做完，只有少部分需要原生支持。当然，也和我们的项目有关。因为我们现在做得功能都比较简单，我们主要工作都在处理一个问题：一个平台上显示好好的东西，同样的代码，在另一个平台上，就不行了。然后还有就是对不同的屏幕的适配，目前还没遇到特别难的东西，今天看看有没有人用来做大型成熟项目？学习一下经验。
Rory He：React Native 需要技术的学习成本其实更高一些。
frankphper：前端是不是因为 React Native 才变成「钱」端？
Kiss小锦：前几天看到阿里做了开源，效果参考淘宝、聚划算品牌团。 。
其实，移动 APP 开发领域，要极致体验发布就不灵活（Native），要灵活发布就没有极致体验（H5）。有没有一种技术方案可以兼顾极致的体验和灵活的发布？ LuaView 可以完美解决上述两个问题，不过需要学习 lua 语言。
主持人－东辉：大家也可以说实践、使用场景以及收益等问题。
Kiss小锦：使用场景一般是电商做大促活动需要灵活上线。
利炳根： 大家可以看看这里的文档，再买本入门书，一般的项目开发就差不多了。
杜鹏飞千锋安卓：直接用 WebView 和普通网页不更简单么？
郭镫鸿：如果那样的话，性能和功能都有问题。
Shawn：我认为目前 Hybrid 开发形式有三种：
1.原生开发一部分+H5开发一部分，通过 WebView 桥接；
纯 H5 开发，需要本地功能时通过第三方打包工具实现 如 HBuilder+ ；
用 H5 或 JS 开发，但最终编译成 Native 应用，如 ReactNative、APICloud、Cocos2d-js、Unity3D-js 等。还有种形式是 Webview+Runtime ，一般用在H5游戏加速，像腾讯 X5 浏览器、UC 等都内置了 Runtime；
jia_dongxu：可以用 cordova+ionic angular。v2 优化不少移动端，angular 也要出2了，据说优化移动，不知道 ionic2 和 angular2 正式版性能会不会提高很多？
真哥：不过，ionic 在安卓手机上性能不好。
郭镫鸿：ionic 有点卡，iOS 相对好些。
Shawn：移动端性能是个问题，传统的PC 端方案还是不要用在手机上了。
柴明昆：貌似Angular 2.0对Native Apps 的支持和渲染是基于 React Native 的，我们也是某个模块改动需求频繁，最近正在研究评估使用 React-Native。
James：ionic2 nightly 已经有了，ionic2 完全采用angularjs2 ，用的 typescript es6，在性能会很大改善 。angularjs2 对移动端也进行了优化，React Native 目前应该都是大厂或者小范围在使用。
真哥：对dom的操作太频繁，特别是双向数据绑定，不太现实。如果你需要快速迭代，可以考虑React Native，如果特别注重体验和性能，建议用原生。
利炳根：前段时间，有外包公司专门推 React Native，号称基本的东西都已经封装了一遍，如果真的能做到他们宣称的那个程度，开发一般的 APP 超级快。很多一般的 APP，核心的竞争力是业务上的，对 APP 本身倒是不在乎，怎么快怎么来。当然，大家未必乐意做这类开发。
之前有公司，做了一年快速迭代，找到了真的有用户愿意用的业务，才开始优化的，一开始优化，优化完发现没人用，就是个悲剧。
窦静轩：关键是需要自定义，还是需要 Native 开发，所以不会出现谁替代谁。想跑起来一个React Native 的项目没那么容易，还需要基本的 Node 知识 。
我麻不拿到温网冠军就不改名字：这样会不会导致大部分公司愿意用 React Native，从而减少开发成本？
利炳根：当然，这是公司的悲剧，开发人员倒是无所谓的，公司倒了可以去下一家，反正自己技术练到了。我们两天前来的新同事，已经负责 React Native 的动画开发了，总得来说，上手还是很容易的。
Shawn：也就是说大公司追求用户体验，如果不计成本和开发效率的话，还是会用原生来做。
真哥：React Native 也属于一种开发模式了，其实优缺点很明显，React Native 只能调用原生接口，但是不能对原生做扩展，要做扩展只能写 Native，React Native 比 ionic1 好一点，不过现在学习 ionic2 或者 angular2 需要去看看 typescript。
jia_dongxu：React Native 的缺点，Android 体验太差了，非常卡。
利炳根：卡的问题，需要把开发模式关了，会好非常多，然后，页面还是可以适当优化一下的。
窦静轩：如果说有一批人，把市面上流行的组件的都封装了， 并且开源了，那样推广的速度也会很快。
我麻不拿到温网冠军就不改名字：就是说如果需要自定义控件的时候，React Native 做不到？
真哥：是的，React Native 不能做接口开发。
窦静轩：React Native 提供自定义组件的方法，需要 Native 自己开发。
利炳根：把原生封一层给 React Native 用，安卓不是很了解，iOS 这块是非常简单的。当然也可能是因为我做的功能比较简单。
柴明昆：React Native 在使用 View 的时候，这些 View 是要经过本地定制的，并且将相关方法暴露给 JS ，这样 JS 端才能正常使用。
张春明：React Native 是否采用？我一般这么想：能否达到快速迭代，可以适应产品的各种变态修改(控件修改)，有问题容易追踪定位，现阶段更倾向于混合开发，然后各取所需。
Shawn：所以说目前还没有一套完美的方案，也就是说需要原生来做的，我们就用原生好了，H5 优势的地方就用 H5，这才叫混合开发嘛！
郭镫鸿：React Native 在性能和功能上是没有问题的，主要学习曲线比较陡峭，会用的人少。
窦静轩：Hybrid 受限于 WebView 啊，WebView 如果有 Bug 你没辙啊。
龙志辉：天猫的部分业务不是已经用 React Native 改造了吗？
郭镫鸿：天猫对 React Native 进行了封装。
柴明昆：如果没记错的话，QQ 空间的发现模块，就是用的 React Native。
真哥：用什么技术既不影响性能，又达到了功能和提高用户体验？
窦静轩：我觉得用啥在于开发者决策，如果你为了一个广告活动页，去弄 React Native 和Hybrid ，真心不如一个 WebView H5 原生去搞。我是15年趟了一年 Hybrid 的坑，16开始趟React Native 的坑了。
龙志辉：本地加毛玻璃吧！其实编程的思路是一样的，React Native 或者 Hybrid 主要目的很多时候是为了突破客户端审核限制和达到代码复用的目的，避免一个相同的业务写三份代码（Android，iOS，Web）。
郭镫鸿：我发现12306用的动态库也绕开了苹果的审核。
真哥：其实我觉得 React Native 更像一种思想 ，并不只是代表一个框架，学习框架主要是学习作者的思想， 就比如 angular 。
窦静轩：对，是思想，组件式开发。
我麻不拿到温网冠军就不改名字：我觉得 React Native 做某些模块还行，但是如果说完全来代替原生，我觉得是不是太快夸张了？
真哥：其实都是 MVVM，替代不了，只是说能够在相对短的时间没做出接近同等效果对性能影响又不大，「分久必合，合久必分」，现在完全被推翻了，如果统一的话，也许就不会有这么多新的想法了。
龙志辉－iOS：每年 iOS 和 Android 系统更新都会开放一大票新的API，用第三方的始终会慢半拍，性能和用户体验在客户端是放在首位的。
Shawn：你看 Cocos2d 支持 JS 吧，Unity3d 官方推荐用 JS 吧，虽说目前 JS 面向对象不太彻底，你看 ECMAScript6 也发不了，JS 用起来就更爽了，关键是 React Native 默认支持 ES6。
汤涛：我觉得 React Native 或者 Hybrid 方案，适用于强运营类的产品，比如电商类，工具类这种暂时没必要，大家选择技术方案时可以参考。
龙志辉－iOS：不知道微信的应用号会使用什么技术？React Native？
James：微信的应用号用 JS，而且微信有 WebView。
龙志辉－iOS：那还是 Hybrid 啊，如果微信也把 JS 框架开源了，就是第二个 React Native 了。
Shawn：腾讯不会弃标准于不顾的，微信应用号绝对是 H5 崛起的时候。
龙志辉－iOS：其实我觉得 React Native 有点像 Cocos2d-x，把各个平台的组件封装一套，用C++一次编写，就可以移植到各个平台了。
罗飞：非常感谢大家的讨论，由于时间的原因，今天的讨论到此为止。后续我们还可以再进行更多的交流，再次感谢大家。
国内 ITOM 管理平台 致力于帮助企业用户提供全栈式的性能管理以及 IT 运维管理服务，通过一个探针就能够完成日志分析、安全防护、APM 基础组件监控、集成报警以及大数据分析等功能。想阅读更多优秀文章，请访问 OneAPM
阅读(...) 评论()
OneAPM - 端到端的云解决方案！}