这是一个在StuQ做分享时的讲稿。当然还有很大的改进空间,但我这会却没有什么劲头继续改进,既然这样就不如索性先发出来,先把它从脑袋清出来,把其它我更想做的事情做了,回头再看哪天想改了再回来改。
当然,大家有觉得不对的地方,随便批,我会当做问题之一,以后努力改进:)
大家好,我是深圳平安科技的利炳根。网名:清醒疯子。主要研究iOS和ReactNative。
今天和大家分享的是我在ReactNative上的一些开发实践经验。请大家多多指教。
在ReactNative上的研究,我还是做得比较粗浅,有不对的地方,大家随便批,我多向大家学习。
今天的内容分为四个部分。分别的ReactNative的开发环境搭建、JS/Bundle的管理、混编以及数据流的处理。
ReactNative的开发环境搭建比较简单。只需要把node、watchman、flow通过brew安装完,通过npm把ReactNative命令行安装到全局,就可以用init命令创建ReactNative项目。
其中,node是node.js。它有非常好用的包管理工具npm。也可以拿来写后台。我自己经常拿来在本地快速写一些简单的后台辅助调试代码。
watchman是Facebook的开源项目,主要用来监视文件,记录文件的改动。React通过watchman来实现代码发生变化时完成相关的重建功能。
flow也是Facebook的开源项目,用来做JavaScript的静态类型检查。用来发现JS程序里的类型错误,提高编码效率和代码质量。包括前期错误检测、代码智能提示等。
安装ReactNative命令行的时候要注意加上-g这个参数,把RN命令行安装到全局,才方便我们在任何目录通过命令行创建ReactNative项目。
ReactNative项目创建的时候,会自动把一些需要用的库加到项目工程里,自动做好基本的依赖管理,并且自动生成最简Demo代码。创建完之后就可以运行一个最简单的Demo,方便大家体验ReactNative的编程。
目前,ReactNative还没有特别好用的开发工具。开发效率会稍微打点折扣。但利用现有的开发工具还是足够完成基本的开发任务的。
Nuclide是Facebook的开源项目,是与Ract配套的IDE。目前还在不断地完善当中。已经能实现基本的代码提示和静态类型检查。Nuclide目前还不是独立的IDE,需要作为Atom的包进行安装。
Atom和WebStorm都可以做到React的部分代码提示。对ReactNative的支持就相对差一些。主要还是针对JavaScript的支持而已。
ReactNative的JSX只是JavaScript的封装。一些在JavaScript上的打包工具,ReactNative也能用。比如Browserify和Webpack。
Browserify使用比较简单。指明入口点和出口点就可以打包。而Webpack则一般要写一个配置文件webpack.config.js指明打包细节。当然,Webpack的功能相对就更强大一些。
Nuclide的开源项目代码提交还是比较活跃的,对这方面有兴趣的朋友不妨关注一下,参与其中和大神一起做一个IDE也不失为一种相当不错的娱乐项目。
虽然ReactNative最终会渲染成Native的View,但它只能通过浏览器调试。基本上就是用Chrome来做。
Chrome上有一个插件React Developer Tools,不过要翻墙才能装。
通过Chrome的consle可以打印变量。如果对这块不熟悉的话,可以先通过调用一个网络请求,打印返回的数据,并根据数据调整显示,来熟悉一下Chrome的调试过程。
在JavaScript代码中插入debugger;就可以作为调试过程中的断点。
在iOS平台上,ReactNative组件通过RCTRootView这个类接入到Native的视图层次里头。
RCTRootView初始化只需要提供两个参数,一个是JS包的路径,一个是模块的名称。
ReactNative的应用组件,最后渲染出来都是一个View的子类,都可以通过addSubView加到Native的视图层次上面。
ReactNative可以实现动态编码。只需要在远端修改JS文件并保存,Native端无需重新编译,只需要Reload刷新一下,就可以更新APP视图和功能。
在设置RCTRootView的JS包地址时,设置为远端的JS文件资源网址,在引用时把文件后缀改为.bundle,即可以调用远端的ReactNative bundle命令,把对应的JS文件打包为可用的JS包文件,在Native端实现视图的渲染。
bundle命令有两个常用的参数。platform参数指定打包到iOS平台还是Android平台。dev参数指定是否开启开发选项以提供更多的调试信息。
调用远端JS文件打包的方式有一个缺点,打包过程导致视图初次加载比较慢,影响用户体验。可以过加载离线包的方式解决这个问题。
在设置RCTRootView的JS包地址时,设置为Native端沙盒内的jsbundle文件地址,ReactNative就可以从Native端加载渲染视图,速度有明显提升。
通过bundle命令,可以把JS文件打包成jsbundle包。bundle命令有三个常用参数。platform参数指定平台,entry-file参数指定入口文件,bundle-output参数指定出口文件。
通过加载Native端离线包jsbundle文件,在提升加载速度的同时也让ReactNative失去了远端更新的能力。这样得不偿失。我们可以通过静默下载jsbundle文件替换Native端jsbundle文件的方式解决这个问题。
通过远端jsbundle文件资源网址,启动一个下载文件请求。在收到请求返回的时候设定文件路径。在收到返回数据时写文件。
写文件时,要注意先让写入点移动到文件末尾,再进行文件写入,避免覆盖之前接收到的数据。
ReactNative因为技术发展不久,还有部分Native端的功能并没有完全实现。在项目开发过程中有可能需要在ReactNative项目里加入Native端的功能代码辅助。
ReactNative有一套机制实现。在Native端的类里引用RCTBridgeModule,并遵循RCTBridgeModule协议。通过宏RCT_EXPORT_MODULE向JS暴露Native端的类,通过宏RCT_EXPORT_METHOD暴露Native端的方法,通过RCTResponseSenderBlock实现JS端的回调。
JS端的处理和Native端同样简单。在JS文件的开始引用NativeModules组件。通过NativeModules引用Native端指定类。由Native端指定的类就可以直接调用指定的方法并指定回调的实现。
Native项目添加ReactNative模块稍微复杂一点。首先需要进行一些工程配置。把ReactNative需要的静态库加到工程里。在Build Settings里设置Other Linker Flags 和Header Search Paths。最后还要在Info.plist里设置App Transport Security Settings -> Allow Arbitrary Loads。
在Native的类中引用RCTBridge和RCTEventDispatcher。通过bridge的eventDispatcher向JS端派发事件。派发事件的接口有5个,分别对应5个不同的事件类型。
这里要注意,不要在Native端的viewDidLoad方法里向JS发送事件消息,因为这个时候ReactNative组件还没有挂载出来,接收不到消息。
JS端在文件一开始引用NativeAppEventEmitter组件。通过NativeAppEventEmitter组件的addListener方法监听Native端派发的事件消息。组件卸载时,通过NativeAppEventEmitter组件的removeAllListeners方法移除监听。
ReactNative的数据流处理,目前业内有4种方案。原生的ReactJS通过Props - States - Components的机制处理数据流。
缺点很多。扩展性差,增加新功能时,需要在每一个用到的组件里复制一遍代码。
可读性、可维护性差,代码量大,难以调试、测试。
可移值性差,代码耦合度高,视图、数据不分层。
违背单一数据层原则,在视图层直接进行数据操作。
Facebook官方推荐的Flux,通过Actions - Dispatcher-Stores - Component的机制处理数据流。
代码冗长,Dispatcher和Store有很多重复烦琐的人工检查、定义。
多个Store中处理同一个Action,将产生大量的waitFor方法处理Store的先后逻辑。
多个Store间共享一个State,State有可能被分散到多个Store中,State的变化将变得不可控。
多个Store互相依赖,还有可能产生依赖循环。
Redux通过Actions -Store - Components的机制处理数据流。
Redux针对Flux做了不少优化。通过内部拓展actions的行为,移除了单例的dispatcher。stores可以监听actions的行为,无需进行冗杂的switch判断。
stores可以相互监听,可以进行进一步的数据聚合操作。waitFor方法被连续和平行的数据流所替代。
Redux也有自身的一些弊端。由于整个应用的数据都集中在1个Store里,数据和处理逻辑的复杂度将不可避免地变高。
因为语法相似,从ReactJS、Flux迁移到Redux成本较低,建议旧项目迁移采用Redux。
Baobab通过Actions -Baobab Tree - Components的机制处理数据流。
Baobab的优点十分明显。应用所有状态都存在一棵数据树里。可以非常简单地实现数据域的切换。应用状态树的存在使得数据流管理变得非常简单,代码量少。
通过Baobab库创建状态树,数据以键值对的方式存储。
Baobab通过select方法直接切换数据节点,还可以通过cursors创建数据游标组,访问数据。
Baobab通过set方法修改数据。
如果项目新建,没有旧代码维护的包袱,个人建议采用Baobab来处理数据流,一定会更省事省力。
结束语:
我的分享到此结束,非常感谢大家今天来参加,希望上面分享的内容能对大家有所帮助。如果大家对ReactNative或者其它问题想跟我交流,欢迎到我的支付宝经费群来。
1.能说说选择相较PhoneGap,ionic等些其他平台,为什么选择React么?
PhoneGap是比较早期的技术,一直以来,在性能上或者功能的覆盖上,大家都不够满意。尤其是性能。RN因为最终是渲染成Native的View ,体验上就好很多。同时呢,因为RN是Facebook在推,从Github上的Star,大家也可以看出业界还是对Facebook有很大的期待和信心的。
2.请问rn中的组件出现相互嵌套的问题可以怎么解决?即 a require b, b 也require a。当调用a时,就会b=null了。可以用es6的模块解决吗?
这就是涉及到数据流的处理。如果用原生的ReactJS去处理,是会非常麻烦的。Facebook希望Flux能解决这个问题,但实际下来,大家觉得满足不了需求。然后业界就有了Redux和Baobab两种方案。Baobab是最新的方案,解决方式也最优雅,大家有兴趣可以重点研究一下。
3.既然是在Mac下,为什么不用safari调试,当前safari调试窗口也是很棒的
在我自己这边主要是习惯问题。一直以来用的都是Chrome。因为很早之前调试API啊各种东西都是用Chrome搞。既然Chrome能搞定就懒得换了。
4.Native与js调用时,与hybrid方式的app有什么不同。
RN的双向通信还是做得比较好的,上面的分享也有讲到,实现起来非常简单。我在这上面多花了一点时间,也只是因为把发消息的代码放到了AppDelegate上,结果死活收不到。Hybrid,常见也是用Bridge。这块的麻烦是,需要HTML5的同事配合。
5.再请教一个问题。组建多层嵌套时,组建间该如何通信?特别是最底层跟顶层的通信,除了props之外,还有啥好办法吗
这个其实就是第四部分数据流的处理问题。Baobab可以把数据统一到一个地方,而且数据域切换非常方便,可以看看。
6.提问:React Native对安卓的支持情况,是否能兼容如此碎片化的安卓
目前,我们还没有去处理具体的适配。这块因为主要是Android的同事在研究,我也不大清楚。不过,既然很多大厂都有用RN,应该不会有太大问题。
8.没有ios经验,只有reactjs经验的,怎么上手xcode下react native开发配置呢,或者android下的
Native下的工作量是非常少的。基本上只要随便找几篇入门的文章看看,问题就不大了。遇到搞不定的问题多上stackoverflow搜搜。或者找我交流也可以:)
9.rn在开发团队中的分工如何,如界面,js,ios程序员如何合作
目前我们是1个iOS和1个Android,然后就是后端了。其实重点的开发量反而是JS上的。一旦把平台需要配合的东西摸清,剩下的主要工作量就是写JS了。两个平台的多数组件都是可以共用的,也就是很多代码只要写一份就可以了。
11.rn适合渲染view还是处理各种逻辑呢,有不如原生的地方吗
目前为止,我还是学习RN就算是View上也做得没有Native漂亮。如果逻辑比较复杂,是不是适合全部用RN来做,还有待考察。RN目前主要的针对点还是迭代比较快的相对轻一点的业务。反正熟悉之后,混编是非常简单的事情,大不了拿Native做一个复杂业务的API:)
问题回答完毕:)
招聘:深圳平安科技移动开发架构师团队,iOS/Android/Java/HTML5/测试/运营都招。15薪,过节费丰厚,内部福利众多,欢迎大家自投或推荐。简历直接微信发给我就可以了,尽量用PDF文件。
2024 - 快车库 - 我的知识库 重庆启连科技有限公司 渝ICP备16002641号-10
企客连连 表单助手 企服开发 榜单123