一个“三端”开发者眼中的React Native
招聘信息：
这里是我临时写的一个React Native的试水项目，打开后等会会看到gif动画演示（，欢迎star和watch）三端的三观大家别拍我，起这么个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，还真是有点期待呢！不扯蛋，埋头去学不要总是试着去评论一个技术，而是在大家都在学习的时候赶紧迎头赶上去，学习总不会白白浪费的，你看那些大牛，虽然他们以前学习的技术一直在不断被淘汰，但是他们啥时候掉过队。参考资料：Github搜索react native了解第三方开源组件，看个差不多就先试着写个App出来，边做边学，乐趣无限。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量8759点击量6430点击量5248点击量4707点击量3878点击量3175点击量2888点击量2771点击量2450
&2016 Chukong Technologies,Inc.
京公网安备89使用 React Native 一年后的感受
当我在面试的时候，技术主管Stanislav跟我说：代表着未来。等它一发布，我们就会用它从零构建iOS应用。作为一名原生iOS开发者，基于先前使用PhoneGap的经验，我非常怀疑使用Web技术构建移动应用的这种方式。但是当我学习并使用React Native一段时间之后，我非常庆幸我们做了这个决定。开发效率虽然iOS“团队”只有我自己一个人，但是iOS应用开发依然可以赶上Web和桌面应用开发闪电般的速度。Apple公司已经允许开发者使用JavaScriptCore进行应用的升级，而无需等待App Store的审核流程。这对于那些缺乏专业的iOS QA（质量保障）团队的小公司来说是非常便利的，因为iOS团队可以在发布新功能之后进行热更新。使用React Native一年之后，我们的iOS开发周期明显变快了，这得益于很高的开发效率。比如：基于现有的前端架构，我们在两周之内就发布了V1.0的版本。相比于Auto Layout，基于的样式可以节省一半的代码，并且更容易理解。使用Flux设计模式，iOS和Web应用共享了store和action的98%的代码。性能React Native在后台线程运行JavaScript并发送极小的代码到主线程中。事实证明，React Native相比于Objective-C或Swift编写的原生iOS应用来说有一些性能差异！Reactiflux小组的性能演示，该组有超过1.1万个会员 —— UI和JS线程大多数都是60FPS然而，我们当初开始构建iOS应用时发现聊天滚动视图的性能并不令人满意，尤其是一些活跃的聊天分组。于是，我们决定使用构建聊天视图并编写必要的桥接代码代替原有的方案。当JS线程在完成一些繁重任务的时候，类库也无法提供原生那样流畅的动画（译注：之前动画是在JS线程执行，，有望使用原生iOS动画接口），因此我们在抽屉侧滑动画上继续使用。注： 作者称该应用仅聊天视图和抽屉动画是原生代码实现的，其他均由React Native实现。当React Native Android版本发布时，我们也尝试在Android设备上运行应用，但遗憾的是，我们遇到了一些性能问题，只好暂时放弃。Android开发主管Miguel是这样说的：很遗憾，不同Android设备的性能差异很大，这点明显落后于iOS。我们可以让应用运行地很快，但是性能——尤其是触摸事件，即使在更高端设备上也不能令人满意。并且在早期，由于React Native Android缺乏完善的功能，我们从产品原型过渡到成品应用比iOS花费了更多时间。可用性React Native让开发工作更简洁，使得开发者可以专注于每个新版本核心功能的开发。应用内自带的开发者菜单为我节省了大量的时间。其中我最喜欢的一个功能是Show Inspector（审查工具），它可以即时展现交互视图的层级结构以及被选组件中所有必要的样式信息，这无疑是我用过的最棒的iOS审查工具。社区React Native项目每两周会发布一个新版本，其中包含一些新的特性以及修复的bug。这有利有弊，好比iOS几个月的稳定版本的发布，新的代码需要额外的时间进行升级，尤其是生产环境中的应用。因此，这也是到目前为止我们fork的React Native仓库只有四次主要升级的原因。由于React Native还不太成熟，资源有限，也不完整。但随着它越来越流行，在不久之后一定能赶上其他成熟的技术。下面列出了一些实用的资源，我也经常在它的仓库上提问和获取最新的信息：Reactiflux上的。—React Native开源组件列表。—大量的React Native文章、教程和示例。译注：中文资源：总的来说，React Native很有潜力，它把我们团队的移动应用开发带上了一个新的台阶。像我这样原生的iOS开发者可以平滑地过渡到React Native，这有些出乎我的意料。同时，它也帮助我扩展职业技能，因为我也可以很轻松地向React编写的Web应用贡献代码了。原文：&译文：&
React Native 的详细介绍：
React Native 的下载地址：
转载请注明：文章转载自 开源中国社区
本文标题：使用 React Native 一年后的感受
本文地址：为你推送和解读最前沿、最有料的科技创投资讯
36Kr股权投资
汇集行业内最优质创业项目的股权投资平台
聚集15家顶级投资机构的专业互联网融资平台
聚集全球最优秀的创业者，项目融资率接近97%，领跑行业}