使用JS开发原生iOS应用 --React Native
查看次数：3005
下载次数：0
上传时间：
React Native库是Facebook的最新开源项目。开发者可使用JavaScript和Facebook的React库开发原生的iOS和Android应用程序。同时Facebook还开源了Nuclide--一个针对React Native、web以及原生移动开发的IDE。Nuclide基于Atom构建，并且有活跃的社区作为支持。
React Native使用Javascript将app编译为原生的应用程序视图，提供了用户熟悉的iOS和Android设备上的外观和体验。React Native并不像你此前使用过的web封装包，其代码表现几乎和原生的应用程序一样。
附件偏大，请在此下载：
您还没有登录！请或
下载过该代码的还下载了
本周热门下载
&2017 Chukong Technologies,Inc.
京公网安备89中国领先的IT技术网站
51CTO旗下网站
一个“三端”开发者眼中的React Native
作为一个iOS开发者，我的经验大概有2年左右，虽然不是专业选手，但是一个App开发需要涉及到的东西基本都接触过，坑也趟过不少，其实iOS开发的体验还是不错的，熟练了以后构建App还是很快的，不过里面也有不少麻烦的地方
作者：来源：前端乱炖| 17:15
三端的三观
大家别拍我，起这么个diao渣天的标题是为了吸引你进来，大家不要太在意用词。先介绍下我自己，我是一个普普通通的开发者，平常喜欢自己捣鼓技术，所以涉猎比较广，一些不太常用只是摸过几腿的技术就不说了，至少现在每天都摸的技术大概有三端：前端，服务端，客户端。这篇文章是我作为一个&三端&开发者角度对React Native的一点点看法，不会太具体，但是希望对大家的认识能有个不同角度的指导。
作为一个iOS开发者，我的经验大概有2年左右，虽然不是专业选手，但是一个App开发需要涉及到的东西基本都接触过，坑也趟过不少，其实iOS开发的体验还是不错的，熟练了以后构建App还是很快的，不过里面也有不少麻烦的地方，例如：
代码量大（那长长的方法名）
布局麻烦（特别是AutoLayout，光理解这个概念就要好几天，而且很难用）
编译调试耗时（比android快很多，但是还是很慢）
OC语言和Cocoa框架有些冗余的地方（一堆堆的属性和继承过来的方法）
用代码定义样式麻烦（Cocoa给UIView加点阴影边框设置字体等，那代码不忍直视）
有时候定位问题也挺难，动不动就报个 main thread的报错，完全下不了手（可能是我没掌握好方法）
pods管理代码，安装个代码等半天，有时候还要翻墙，很不稳定，跟npm之类的没法比。
而对于前端来说，还会对ios的开发有些其他的疑问，例如：
要是能用CSS写样式就好了
要是能实时调试界面样式就好了
要是支持闭包就好了
要是回调写起来跟JS一样方便就好了（指OC中的block）
要是代码跟JS一样简洁就好了
而React Native其实正是迎着这些问题而上，然后结合三端的优点，搞出来的一个移动端开发框架。
且来看下他有哪些动人之处。
美丽动人的RN
我拿起React Native的第一次，就被它彻底打动了，抛开他的语法，对于前端来说奇奇怪怪的jsx（后面会讨论），它的确解决了我作为一个三端工程师在不同技术端切换的时候备受的一些困扰，所以那天晚上，我完全没睡着，翻来覆去的，然后跑到朋友圈发了句：&激动人心的技术，未来的发展方向&。第二天早晨，提前一两个小时就醒过来，继续写了几句RN，那酸爽，那心情。可能作为一个纯粹的前端或者纯粹的ios开发，很难理解，但是对于一个游走在三端的工程师，我看到了一个真正意义上的统一方案，而且，它足够简单。
React Native的上手很快，去看一下它的文档，总共就一点点：入门，组件，功能。每个页面都短短的一两页，的确就是这么简单。不过这里我并没有打算把这篇文章写成一篇入门教程，所以并不会教你如何构建一个简单的RN应用。
大概总结来，React Native让我觉得值得一提的动人之处：
1. 把Cocoa里面的controller和view统一成了component，其实RN里只有component这个组件概念，既可以扮演页面级别的组件（controller），也可以扮演一个模块级别的组件（UIView)。入门门槛降低了很多。
2. 动态绑定，这个React的基本功能，被带到了客户端开发中来，数据和视图是动态绑定的，数据发生变化，视图会跟着变化，很多操作视图的代码都可以省略了。
3. 引入了类似于CSS（一个子集）的样式管理，可以内嵌到模块，也可以全局使用，定义样式变得非常简单通用。
4. 引入了Flexbox布局，把iOS本身复杂的AutoLayout简化，使用很方便，学习起来也更简单。
5. 引入了方便的npm管理，有大量现成的nodejs包可以用（例如moment，underscore等常用模块），还可以把自己项目模块搞到内部npm上做通用组件，另外，npm上还有不少别人写的React Native的插件。例如下面这个。
6. 第三方组件里有一个可以把icon font引入项目的组件，可以在任何显示图标的地方直接用icon font显示，灰常方便。
7. 调试很方便，一次编译后，每次改了js代码，只需要在模拟器里command+R即可重新加载代码。有问题会直接报错，里面有代码行数等详细信息。
8. 完整封装了各种js内置的方法，例如：setTimeout，setInterval，XMLHttpRequest，localstorage，console.log等，都是用oc原生方法封装的。
9. 引入ES6的支持，可以使用各种新特性，例如最常用的箭头函数，解决this作用域乱套的问题。
一口气列举出这么多动人的地方，React Native这姑娘还真是不一般，简直校花级别。（小插曲，我觉得React性格就是个姑娘，感性而简单，而Angularjs则像是一位硬汉，笨重但是踏实而且很全面）。不过，人无完人，现阶段ReactNative也有不少缺点，有些缺点可能会非常制约他的发展，急需改进，不过还好RN目前只是开发阶段，并不是正式版，该有的都会有的。
并非完美无瑕
我看来，目前ReactNative至少有这么几个比较大的问题：
组件不全，第三方组件也不全，遇到某些特殊功能，需要捣鼓很久，例如摄像相关的，文件读写，文件上传之类的组件。
性能并非媲美原生，还是有一些损耗的，特别是交换大数据的时候，例如读取相册。
只有iOS版，限制了在某些公司生产环境的使用。Android版不知道目前什么状态。
iosOS和Android代码并非通用，有可能会需要维护两套，或者在代码内做一些判断。
并非网上大家说的，写一次代码，多端通用，网页版和客户端版完全不是一个概念，只有部分代码可重用。
把代码都打包到bundle里面，不知道苹果对这种开发方式是否会不太喜欢，甚至拒绝上线。
实际开发的时候，还是需要了解底层原理，自己开发跟原生桥接的组件，这个对普通前端来说是一个很大的挑战。
有些问题，随着时间的推移会慢慢解决，有些问题，则很难说，例如开发方式的问题。
对前端开发和客户端开发意味着什么？
React Native一出来，有的人一头钻进去开始研究，大部分人却只是稍作了解，然后就投入到了论战的圈子里。例如大家对React的jsx开发方式的批判，对React组件化开发方式的批判。其实还是那个问题：任何脱离场景的技术讨论都是耍流氓。React并非万能药水，它的出现不是要大一统整个前端界的所有问题，它事实上只是为了解决一小类问题，所以不要指望你的产品能够用React来解决那些他并不擅长的问题。而对于ReactNative来说，其实我觉得这正是体现React价值的一个非常吻合的一个场景。React在这个问题中扮演的角色，就是上面讲到的他解决的那些问题，足够多，而且很完美，这就是他存在的价值，不容否认。
所以，大家要从理性的角度去看待新技术，不要一味排斥，不要套用现有的思维和场景。当你用这样的态度去看RN，你就能看到他的优点和缺点，自做抉择。
我从一个前端的角度来看ReactNative，有这样的感觉：
它不是万能药水，只是一种高效的解决方案，不要期望它为你解决了所有问题，要不要使用，还是需要根据场景衡量，而不是脱离开来说它是好的或者是坏的。
事实上，目前看来，客户端开发更适合写RN，因为要了解客户端的那套开发理念，对前端来说成本挺高，而对于客户端开发，成本只是理解一个语言。
RN跟Html5没有冲突，二者场景并不一样，它要取代的是本来客户端开发的部分工作，而不是H5页面，因为在这些场景下它并没有明显优势。
对于遇到瓶颈的前端来说，它是一个很好的扩展自己技术栈的方向，有得玩，而且很好玩。
从一个客户端开发的角度来看：
用ReactNative的确简化了很多OC开发中的繁琐步骤，比Swift也是更胜一筹。
JS、React社区的活跃度很高，有很大的开源组件开发空间，是一个不错的参与开源社区的机会，大家很需要一些桥接原生的新组件。
NPM真的是太方便快速了！社区里无数可用的工具库，在OC的世界里可不常见。
RN是前端侵占客户端开发的触角么？其实很难说，它跟NodeJS一样，试图侵入另一个领域，但是深入是非常难的，大部分人浮于表面，反而帮你承接了最恼人的顶层业务部分。
不过你应该会觉得js真不严谨，而且回调很蛋疼，闭包很奇怪，作用域很难理解。也许是时候抛开自己旧时代对js的理解了，现在ES6也是一门很先进的语言了。
未来的开发模式？
最近只是在试水，踩坑，然后我真的准备在公司里把这个事情推动起来，因为我觉得它的确是有意义的，对开发效率有非常明显的提升，不过现阶段还只能是尝试，毕竟它没有发布正式版，然后还只有ios。不过踩坑也是为了积累，正式版发布后我们就可以快速切入了，到时候就会走的快人一步。
不过可以想象一下未来在生产环境的开发模式，跟NodeJS用来做中间件类似，其实RN最后应该会扮演一个承接前端业务的角色，这部分开发工作，可以是前端来做，也可是客户端来做，主要是用基础组件完成业务开发，其实就类似于中间件的形式。
而客户端开发的主要工作是构建基础组件，封装一些原生桥接的组件供RN使用，基本上是通用组件，应该是一个全公司级别的客户端架构组的概念。
前端做表层业务 + 客户端做底层组件支持。Perfect，还真是有点期待呢！
不扯蛋，埋头去学
不要总是试着去评论一个技术，而是在大家都在学习的时候赶紧迎头赶上去，学习总不会白白浪费的，你看那些大牛，虽然他们以前学习的技术一直在不断被淘汰，但是他们啥时候掉过队。
【责任编辑： TEL：（010）】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条外电头条原创原创
24H热文一周话题本月最赞
讲师：5人学习过
讲师：29人学习过
讲师：5人学习过
精选博文论坛热帖下载排行
本书将实时系统、实时统一建模语言、实时系统的统一开发过程和Rational Rose RealTime建模环境有机地结合起来，以案例为基础，系统地介绍了...
订阅51CTO邮刊react native的痛点与优势
o &nbsp,&nbsp&nbsp,&nbsp&nbsp,&nbsp&nbsp,&nbsp
着自己对react native开发的深入，对于其一些痛点和优势也有着更深的体会
react native的痛点
由于还不是稳定版本，版本更新太快，大概两周会有一个新的版本。更新新版可能会出现不兼容的问题，有时候需要手动解决。
支持的组件不全面。大部分厂商并不支持react native。一些支持的现在一般也处在不稳定版本。比如截止到rn版本0.35，js版的本地数据库组件只有realm支持，现在realm版本为0.15，很多功能不全。
程序的性能。现在普遍都说比原生的性能要差，但是差多少没有一个具体的衡量。直观的感觉是复杂的页面在一些配置较低的手机上会有肉眼可见卡顿的感觉。
虽然大多界面可以同时生成ios和android的，但一些涉及到底层的东西需要在ios和android单独开发，然后在js层进行调用。
学习成本高。要学习，还需要涉及到ios，android开发相关知识。相比较而言，一个用过react的前端开发，写rn应该上手更快。
关于react native的开发现在并没有一些best practice，也没有真正很有经验的人，很多只能摸索。对于小团队来说，试错成本有点高，一旦卡在一些问题上，网上解决方案很少，容易耽误了整体的进度。招聘有相关经验的人也较难。
react native优势
组件化开发，复用率高，组件丰富以后，ui开发较快，前端式开发。
同时支持android和ios的ui界面。
可以方便的进行代码热更新。
Learn once,write anywhere，未来js可能会有更大的通用性，比如现在微信小程序的开发技术和react native十分相似。现在还有用react native开发，开发
可以和原生页面互相调用，作为一部分嵌入到一个已有的原生app中。
它是一种介于在webview和原生开发之间的解决方案，它想要实现像web一样灵活，像原生一样的性能，虽然现在还都没有达到，但是它是一种有可能接近这个目标的解决方案。
待续。。。
关于伯乐小组
这里有好的话题，有启发的回复和值得信任的圈子。
新浪微博：
推荐微信号
（加好友请注明来意）
- 好的话题、有启发的回复、值得信赖的圈子
- 分享和发现有价值的内容与观点
- 为IT单身男女服务的征婚传播平台
- 优秀的工具资源导航
- 翻译传播优秀的外文文章
- 国内外的精选博客文章
- UI,网页，交互和用户体验
- 专注iOS技术分享
- 专注Android技术分享
- JavaScript, HTML5, CSS
- 专注Java技术分享
- 专注Python技术分享
& 2017 伯乐在线5385人阅读
& &&&最近工作中接触到React-Native框架，对其进行一些技术分析，结合之前了解的H5的一部分，加上自己做了很久的原生开发（十几个android app、sdk，包括2个ios）, 总结下目前了解到的这三种移动端应用开发方式的特点和试用范围，作为个人知识的记录，也作作为公司内部互相学习的分享。
一、原生开发
& & & & &原生开发是系统自带的app开发方式，也是大部分人最熟悉app开发的技术，如android、ios、wp。
&&&&&原生开发依然是开发者采用最广泛的开发方式，优点十分显著。相比其他开发方式而言，原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可是方便实现各种设计效果。
& & &原生开发的缺点在逐渐的开发、运营过程中显现出来。开发成本高，不同平台需要定制不同的app，也就是android定制apk，ios定制app，开发人员需要多平台多语言，人力成本、时间成本较多，通用性差；上线时间不稳定，需要审核，特别是苹果审核机制，审核时间长短不一，对内容还有控制，国内Android APP市场（百度手机助手，应用宝，360市场等等）也有类似的问题；版本控制能力差，版本发布到达率无法控制，多个版本更新发布，修复bug，无法保证及时送达到用户手中；获得新版本需要重新下载安装，虽然目前有增量升级方式逐渐改变，但是随之而来的其他问题如增量升级多版本控制也是个很头疼的问题；
& & &总结：原生开发虽然有各种缺点，但是在目前所有的开发技术中原生是最成熟，有效，也是开发人数最多，开源库最广泛的。对APP要求各方面性能、响应要求高，人员充足，完整开发、测试流程，适合原生APP开发。
二、H5开发
& & &H5开发是Html5开发的app，本质上运行在手机浏览器中的页面，一般使用app做一个壳套用浏览器运行H5的页面，由于H5的特性也有很多app使用半原生半H5的hybird app 开发模式。
& & &H5有许多优点，特别针对原生开发的缺点。如： 直接在网页上调试和修改，几乎不用考虑用户机型和适配的问题，针对原生开发的平台碎片化、开发人力成本、时间成本高；版本升级优势，网页的升级与用户无关，用户无需下载更新安装，保证实时送达到用户手中；上线时间稳定、快速，不需要通过开发市场的审核，有收入分成的开发市场更是可以绕过收入分成。除此以外在视频媒体方面H5表现也十分优秀的。
& & &H5的缺点有许多，当新技术出现时候许许多多的人都在吹嘘它的优点，到真正实用时才对它的缺点正视。H5加载大图片的时候性能会下降，大量用户访问同一个H5应用时性能会下降，响应速度比不上原生app，上网速度也不及原生app，H5不能自动处理动画上反复交互（网页游戏），需要借助css3、javascript。H5本质上是网页，无论是离线的还是在线的，它本质上是通过浏览器呈现到用户面前的网页，在手机上模拟得像app，网页的缺陷它无可避免。1.软、硬件的支撑问题，现在早已不是问题，这里讲出是由于2012年左右当时H5火起来时，我在FF公司看到宣讲H5时，当时许多的手机依然无法支持h5，几年过去了这个问题基本不存在了；2.性能问题，这才是H5最大的问题，原生开发对性能的支持远超H5，在用户体验上，H5的app绝对是占据下风的，app反应速度、流畅度等；3.功能问题，对某些硬件摄像头、陀螺仪、麦克风等硬件支持较差，频繁调用这些硬件，H5不容易扩展，调用速度也不如人意。
& & &&总结：纯H5 app适合小游戏、媒体、视频、营销产品、介绍等功能，大部分大型app属于原生、H5混合的hybird app。
& & &H5话题的延伸。年H5大火，有许多人认为可以替换原生开发，成为一种“write once,run anywhere”的开发模式，但是在许多公司的案例中就遭遇了失败，但是仅仅过去了3-4年，硬件设备的更新，软件的支持，H5又一次以不同的面目再一次火起来。这个过程十分让人唏嘘。HTML5已经出来很多年了，早在2010年，乔布斯在封杀Flash的言论中，就预言HTML5将取代Flash成为下一波技术浪潮。就算不关心技术的朋友，去翻翻手机也能感受到在pc端一直以来占据统治地位的Flash在手机端几乎不见踪影，这是从2010年以来苹果公司与Adobe公司的战争开始，苹果背后无数开发人员支持研发HTML5技术，让HTML5技术得以普及开来。2011年Adobe自己也放弃了Flash移动端的研发工作，HTML5已经被移动浏览器广泛支持，Flash已经落后于时代了。很多大公司都在推动HTML5的发展，但是也有滑铁卢，Facebook的扎克伯格是最惨痛的教训，他想要用HTML5的web
app来打破ios和android的垄断，实用HTML5来代替原生App。在这件事上facebook失败了，具体表现在2013年前facebook在移动端的产品的市场表现非常一般，最后无奈宣布回归原生app的开发。Facebook在html5的试错大大打击了HTML5的实用性，但是HTML5自身的厚积薄发还是让这项技术没有没落。
&&&&&手机硬件的提升和HTML5本身的完善，使得基于HTML5的应用表现更好，iPhone对HTML5的支持更加完善，Google也完成了移动端Chrome浏览器向Chromiumnie内核的切换，大幅提升对HTML支持。很多基于HTML5的应用都在试图替代原生app，但是由于技术限制，用户体验远远不如原生app，但是某些方面HTML5提供了比原生App更好的体验，但这种体验的基础不是单纯的替代原生App，而是做一些最适合HTML5的细分应用，比如小游戏、媒体和营销类的产品。这些细分的方向能够最大程度发挥HTML5跨平台、开发成本低、开发速度快的优点，在整体产品体验上远超过原生app。HTML5和原生app并不是对立的，反而原生app需要HTML5去解决一些核心的问题，让整个移动市场更有效率。很多公司在努力推动HTML5技术，但是让HTML5重新焕发生机的是微信，利用朋友圈的私密社交，以及HTML5自身的跨平台、低成本开发、速度快等特性，不少公司利用HTML5技术在朋友圈做了一次又一次的营销。微信本身没有在HTML5技术上有什么创造性的推动，而是在HTML5的应用场景上做出了自己的不同尝试，形成了附着微信这个超级app的HTML5应用场景。HTML5的优点跨平台、低成本开发、开发速度快等优点不是最终站稳市场的根源，最终成就它的还是它自身比原生app更加优秀的特质，比如小游戏、媒体、视频、营销产品等等。目前许多app都采用hybird
app 开发（微信、支付宝等等），在h5适合的地方展示，在其他地方使用原生开发，以规避缺点，发扬优势。
三、react-native框架
& & &介绍react-native之前，需要先提下react，react 是facebook在2013年开源的网站ui开发的js库，react-native是用react 进行原生app开发的框架，让广大开发者使用js和react开发应用，提倡组件化开发。react-native提供一个个封装好的组件让开发者使用，也可以相关嵌套形成新的组件。使用react-native可以维护多种平台（Web，Android和IOS）的同一份逻辑核心代码来创建原生app。从代码上看结构类似，细节有差别，facebook强调的是“learn
once,write everywhere”，应用前端使用js和React来开发不同平台的ui，下层核心模块编写复用业务逻辑代码，提高应用的开发效率。
& & &react-native的原理。react-native的优点和H5类似，跨平台、低成本开发、开发速度快、动态发布、一套类似代码维护三个平台。代码结构如下图：
程序结构上，有两个工程分别是ios 、android，编译后回在相应文件夹中生成apk和app，界面代码是选中的index.android.js和index.ios.js，右侧的JS代码在这两个JS文件中几乎一模一样。
它与web app很类似，但是绝对不是web app，查看开源代码，你不会发现webview的使用，也就是本质上react-native的app不是web app 或者hybird app，而是原生控件。那它是怎么实现的呢，react-native的原理如下图：
原理上看react-native在js端和java端互相有个映射关系，通过两端的配置表来实现，java端和js端持有同一张表，通信时靠这张表的各个条目的对应进行的。上面提到了facebook实现了组件让开发者调用，就是通过js的配置表调取原生控件，java调用js也是类似的情况。所以当我们使用复杂控件时，可以自己实现java代码，添加入配置表中，即可自定义心新的映射关系，让我们js调用自定义的复杂控件
, 当然web 、ios、androi需要实现不同的控件代码，只是js端的调用代码一样或者类似。
react-native的优点：不用webview,摆脱了webview的交互和性能问题；有较强的扩展性，java端提供了基础控件，js可以自由组合使用也可以自定义组合控件；
react-native的缺点：组件不全，第三方组件也不全，遇到某些特殊功能，需要花大力气写；性能方面也无法媲美原生，还是有一些损耗，特别是交换大数据时；IOS版本略好，androi发展较慢；ios和android代码并非通用，有可能需要维护两套代码或者在代码中做一些判断；开发人员还是需要会原生开发，不然自定义组件无法编码；
个人感受，react-native不是万能药，只是一种高效的解决方案，不要期望它解决所有的问题，要不要使用需要场景衡量；客户端转开发react-native感觉比较简单，比较JS大部分人都有基础，前端人员开发react-native理解原生部分的代码应该十分困难；相比原生海量的第三方控件和第三方包，react-native大部分道路还得靠自己摸索；不同端的代码风格和结构大体类似，但具体标签可能会不一样；目前得到经验是IOS版本比较稳定，android版本还不太成熟，android
版本2015年下半年发布，一直在0.*版本上更新，android1.0版本还没有发布；把把facebook的第三方包网络连接包okhttp和图片下载解析包fresco等一起封装进结果，造成包增加7、8M，但据了解这是可以修改的；只支持IOS7以上和android4.1以上机型，这应该不成问题，比较其他属于少数；听说qzone使用了react-native，但是crash率前10，react-native占8个，前5全是react-native，但是我一朋友项目使用过react-native，虽然有坑，但是不会有如此多
总结：新技术，开发环境和代码编码方面都比较艰涩，有可能有很多坑，但是在界面简单，三端都要求，开发成本需要降低情况下可以使用react-native。
最近在学习react-native，以后可能会有新感受，公司内部最近可以找个项目实战一下。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：9015次
排名：千里之外