1192人阅读
前端学习、ReactNative（6）
公司前端推动了React Native在app的使用，身为客户端开发人员怎能连环境都不装，一是好配合前端进行开发，二是RN可能会广泛使用起来，前端统治一切。今天搞了下RN的环境，各种坑。在此记录一下，作为RN的开端。
在MAC下操作，非Windows。
1. 配置环境
第一步，安装Homebrew
使用命令行安装。
安装完后使用brew -v 确认是否安装。
第二步，安装node、watchman、flow
brew install node
brew install watchman
brew install flow
//安装完后使用 `node -v`、`watchman -v` 确认是否安装。
watchman -v
第三步，使用淘宝npm镜像
npm --registry https://registry.npm.taobao.org info underscore
使用淘宝镜像能快点，否则你会因为墙的原因而变得很慢、非常慢。
第四步，安装React Native command line
npm install -g react-native-cli
第五步，创建第一个RN应用
react-native init AwesomeProject
cd AwesomeProject
react-native run-android
此处在run-android之前需要在 /AwesomeProject/android 目录下添加local.properties 文件，就像所有的Andriod Project一样，里面设置sdk的目录 sdk.dir=/Users/XXX/Library/Android/sdk 。否则run时会报错，sdk location not found
2. 遇到的坑解决方案
1.使用node -v 时提示already installed, but it is not linked
&&&&使用 brew update 如果立即弹出了 user local must be writable! 提示，说明你没有权限。使用如下命令修改：
sudo chgrp -R admin /usr/local
sudo chmod -R g+w /usr/local
然后使用 brew uninstall node 卸载后在重装。简单粗暴。
2.使用MX5调试时，安装不了apk，报错
&&&&RN 里的android gradle 版本不要修改。我之前修改为gradle到2.1.2，gradle wrapper修改为2.10后真机调试不了，run-android时报错。然而在小米5上可以+_+。
3.真机上红色界面报错
5.0以上机器 使用 adb reverse tcp:8081 tcp:8081 反向代理端口。
然后摇一摇手机点选Dev Settings，选择Debug server host & port for device 输入你的IP地址和端口号8081。例如 192.127.XXX.XXX:8081。
点击返回后发现一片空白，摇一摇点选Reload。
这块你可以阅读红色界面上的信息，可以帮助找到错误。
4.小米5调试时爆出 Failed to establish session
GitHub上 提到：
在开发者选项里 取消启用MIUI优化 ，然后按照第三个 红色界面报错 处理就OK了。
搞了一下午，在真机上才运行起来。所遇到的问题都有答案，多搜搜就有(小米这个是真心服了-_-|||)。希望我遇到的这些能帮助到你。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：134557次
积分：2617
积分：2617
排名：第14569名
原创：131篇
评论：53条
阅读：32745
阅读：4529
(1)(3)(1)(5)(2)(25)(1)(5)(4)(1)(1)(20)(5)(7)(17)(18)(2)(2)(7)(5)(2)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'ReactNative 开发实践 - 简书
ReactNative 开发实践
这是一个在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代码中插入就可以作为调试过程中的断点。
在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文件资源网址，启动一个下载文件请求。在收到请求返回的时候设定文件路径。在收到返回数据时写文件。
写文件时，要注意先让写入点移动到文件末尾，再进行文件写入，避免覆盖之前接收到的数据。
10.pic.jpg
ReactNative因为技术发展不久，还有部分Native端的功能并没有完全实现。在项目开发过程中有可能需要在ReactNative项目里加入Native端的功能代码辅助。
ReactNative有一套机制实现。在Native端的类里引用RCTBridgeModule，并遵循RCTBridgeModule协议。通过宏RCT_EXPORT_MODULE向JS暴露Native端的类，通过宏RCT_EXPORT_METHOD暴露Native端的方法，通过RCTResponseSenderBlock实现JS端的回调。
11.pic.jpg
JS端的处理和Native端同样简单。在JS文件的开始引用NativeModules组件。通过NativeModules引用Native端指定类。由Native端指定的类就可以直接调用指定的方法并指定回调的实现。
12.pic.jpg
Native项目添加ReactNative模块稍微复杂一点。首先需要进行一些工程配置。把ReactNative需要的静态库加到工程里。在Build Settings里设置Other Linker Flags 和Header Search Paths。最后还要在Info.plist里设置App Transport Security Settings -& Allow Arbitrary Loads。
13.pic.jpg
在Native的类中引用RCTBridge和RCTEventDispatcher。通过bridge的eventDispatcher向JS端派发事件。派发事件的接口有5个，分别对应5个不同的事件类型。
这里要注意，不要在Native端的viewDidLoad方法里向JS发送事件消息，因为这个时候ReactNative组件还没有挂载出来，接收不到消息。
14.pic.jpg
JS端在文件一开始引用NativeAppEventEmitter组件。通过NativeAppEventEmitter组件的addListener方法监听Native端派发的事件消息。组件卸载时，通过NativeAppEventEmitter组件的removeAllListeners方法移除监听。
15.pic.jpg
ReactNative的数据流处理，目前业内有4种方案。原生的ReactJS通过Props - States - Components的机制处理数据流。
缺点很多。扩展性差，增加新功能时，需要在每一个用到的组件里复制一遍代码。
可读性、可维护性差，代码量大，难以调试、测试。
可移值性差，代码耦合度高，视图、数据不分层。
违背单一数据层原则，在视图层直接进行数据操作。
16.pic.jpg
Facebook官方推荐的Flux，通过Actions - Dispatcher-Stores - Component的机制处理数据流。
代码冗长，Dispatcher和Store有很多重复烦琐的人工检查、定义。
多个Store中处理同一个Action，将产生大量的waitFor方法处理Store的先后逻辑。
多个Store间共享一个State，State有可能被分散到多个Store中，State的变化将变得不可控。
多个Store互相依赖，还有可能产生依赖循环。
17.pic.jpg
Redux通过Actions -Store - Components的机制处理数据流。
Redux针对Flux做了不少优化。通过内部拓展actions的行为，移除了单例的dispatcher。stores可以监听actions的行为，无需进行冗杂的switch判断。
stores可以相互监听，可以进行进一步的数据聚合操作。waitFor方法被连续和平行的数据流所替代。
Redux也有自身的一些弊端。由于整个应用的数据都集中在1个Store里，数据和处理逻辑的复杂度将不可避免地变高。
因为语法相似，从ReactJS、Flux迁移到Redux成本较低，建议旧项目迁移采用Redux。
18.pic.jpg
Baobab通过Actions -Baobab Tree - Components的机制处理数据流。
Baobab的优点十分明显。应用所有状态都存在一棵数据树里。可以非常简单地实现数据域的切换。应用状态树的存在使得数据流管理变得非常简单，代码量少。
通过Baobab库创建状态树，数据以键值对的方式存储。
Baobab通过select方法直接切换数据节点，还可以通过cursors创建数据游标组，访问数据。
Baobab通过set方法修改数据。
如果项目新建，没有旧代码维护的包袱，个人建议采用Baobab来处理数据流，一定会更省事省力。
我的分享到此结束，非常感谢大家今天来参加，希望上面分享的内容能对大家有所帮助。如果大家对ReactNative或者其它问题想跟我交流，欢迎到我的支付宝经费群来。
19.pic.jpg
问答环节：
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文件。
欢迎付费咨询(150元每小时)，
我的微信：qingxingfengzi
正确学习：每天十八小时，
一周干活，一月入门，
一年立足，两年收钱。苹果热更新事件后续：React Native可过审
[摘要]虽然绝大多数开发者没有收到警告邮件，但整体情绪比较恐慌。好消息是，有开发者表示他的Lua游戏昨天刚过审。随着昨天各个社区的推进，苹果对热更新警告邮件的问题所在，看起来已经比较清晰了。React Native有人昨天刚通过AppStore审核：Cocos社区里虽然绝大多数开发者没有收到警告邮件，但整体情绪比较恐慌。好消息是在Cocos论坛上，有开发者表示他的Lua游戏昨天刚过审：目前最全的进度搜集，应该是JSPatch仓库里的这个issue：同时还有第三方SDK的情况解决进度列表：目前重灾区是JSPatch和Rollout.io这两个框架，貌似是100%收到警告邮件无一幸免。Rollout.io的CEO在Hack News论坛里面洗地，结果被无数开发者喷成翔：其他具备JS热更新能力的React Native、Weex等虽然社区里有所讨论，但基本已经被排除是自身问题导致。看来苹果和微软互怼导致React Native中枪的猜测，看起来并不成立。我也联系了阿里Weex的勾三股四，他那边也只是社区里有所讨论，实际情况还好。Cocos社区里也有小部分开发者收到警告邮件，但一般都是因为集成的第三方SDK如友盟、个推或者直接集成了JSPatch导致。昨天国内外各家受波及的公司如BugTags、个推、高德等都纷纷更新SDK、或者推出临时解决方案。这事也很好地考验了各家中间件公司的公关、客服和技术研发实力。当然其中也有比较痛苦的，比如React Native的维护者昨天一定很吐血，在那个issue下面删除了上百个来自中国开发者的【mark】,【 +1】等无意义回复。话说大家出门还是要遵守社区的交流规则，不要在国际开源社区里留下不好的群体形象。我昨天也一直关注事态进展，很是担心Cocos社区的Lua和JavaScript用户受到牵连。昨晚我在微信上问了一圈用Cocos的各大厂商，绝大多数都是『没收到警告邮件，对事情保持关注』。毕竟Cocos有一个大大的引擎runtime在那边，Lua和JS脚本再怎么热更新，也很难脱离出C++ runtime提供的API范围，从而更新成完全不同的另一个游戏。在这个节骨眼上，我还是建议大家除非遇到不得已的严重bug，否则还是少用Cocos的热更新功能去更新脚本，老老实实做好版本迭代计划，把脚本和C++ runtime一并打包好，提交给苹果审核。而仅使用热更新功能来下载资源，这是没问题的。
正文已结束，您可以按alt+4进行评论
责任编辑：aniszhou
扫一扫，用手机看新闻！
用微信扫描还可以
分享至好友和朋友圈
Copyright & 1998 - 2017 Tencent. All Rights Reserved天猫Web架构/Pad客户端负责人：如何评价 React Native？
招聘信息：
作者：Facebook在3.26 F8大会上开源了React Native（），本文是对React Native的技术背景、规划和风险的概述。组里的同学于4.2完成了天猫iPad客户端“猜你喜欢”业务的React Native改造（4月中发版）。本周开始陆续放出性能/体验、稳定性、扩展性、开发效率等评估结果。图1 - 4.2已完成React Native改造的业务一、背景为什么需要 React Native？"What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web."摘自3.26 React Native的发布稿（），加粗的关键字传达了React Native的设计理念：既拥有Native的用户体验、又保留React的开发效率。这个理念似乎迎合了业界普遍存在的痛点，开源不到1周github star破万，目前是11000+。图2 - React Native项目成员Tom Occhino发表的React Native: Bringing modern web techniques to mobile（）详细描述了React Native的设计理念。Occhino认为尽管Native开发成本更高，但现阶段Native仍然是必须的，因为Web的用户体验仍无法超越Native：1. Native的原生控件有更好的体验；2. Native有更好的手势识别；3. Native有更合适的线程模型，尽管Web Worker可以解决一部分问题，但如图像解码、文本渲染仍无法多线程渲染，这影响了Web的流畅性。Occhino没提到的还有Native能实现更丰富细腻的动画效果，归根结底是现阶段Native具有更好的人机交互体验。笔者认为这些例子是有说服力的，也是React Native出现的直接原因。图3 - Occhino在F8分享了React Native（Keynote）"Learn once, write anywhere"“Learn once, write anywhere”同样出自Occhino的。因为不同Native平台上的用户体验是不同的，React Native不强求一份原生代码支持多个平台，所以不提“Write once, run anywhere”（Java），提出了“Learn once, write anywhere”。图4 - “Learn once, write anywhere”这张图是笔者根据理解画的一张示意图，自下而上依次是：1. React：不同平台上编写基于React的代码，“Learn once, write anywhere”。2. Virtual DOM：相对Browser环境下的DOM（文档对象模型）而言，Virtual DOM是DOM在内存中的一种轻量级表达方式（原话是lightweight representation of the document），可以通过不同的渲染引擎生成不同平台下的UI，JS和Native之间通过Bridge通信（）。3. Web/iOS/Android：已实现了Web和iOS平台，Android平台预计将于2015年10月实现（）。前文多处提到的React是Facebook 2013年开源的Web开发框架，笔者在翻阅其发布稿时，发现这么一段：图5 - 摘自React发布稿（2013）1. 加亮文字显示2013年已经在开发React Native的原型，现在也算是厚积薄发了。2. 最近另一个比较火的项目是（详见 @rank），渲染层使用了Web Canvas来提升交互流畅性，这和上图第一个尝试类似。React本身也是个庞大的话题不再展开，详见。笔者认为“Write once, run anywhere”对提升效率仍然是必要的，并且和“Learn once, write anywhere”也没有冲突，我们内部正在改造已有的组件库和HybridAPI，让其适配（补齐）React Native的组件，从而写一份代码可以运行在iOS和Web上，待成熟后开源出来。二、规划下图展示了业务和技术为React Native所做的改造：图6 - 业务和技术改造自下而上：1. React Node：React支持服务端渲染，通常用于首屏服务端渲染；典型场景是多页列表，首屏服务端渲染翻页客户端渲染，避免首次请求页面时发起2次http请求。2. React Native基础环境：2.1. Framework集成：尽管React Native放出了文档，集成到现有复杂App中仍然会遇到很多细节问题，比如集成到天猫iPad客户端就花了组里iOS同学2天的时间。2.2. Networking改造：主要是重新建立session，而session通常存放于http header cookie中，React Native提供的网络和XMLHttpRequest不支持改写cookie。所以要不在保证安全的条件下实现fetch的扩展，要么由native负责网络IO（已有session机制）再通过HybridAPI由JS调用，暂时选择了后者。2.3. 缓存/打包方案：只要有资源从服务器端加载就避免不了这个话题，React Native也是如此，缓存用于解决资源二次访问时的加载性能，打包解决的是资源首次访问时的加载性能。3. MUI是一套组件库，目前会采用向React Native组件补齐的思路进行改造。4. HybridAPI是阿里一组Hybrid API，此前也在多个公开场合（）分享过不再累述，React Native建立了自己的通信机制，看起来更高效（未验证），改造成本不大。5. 最快的一个业务将于4月中上线，通过最初几个业务改造推动整体系统的改造，如果效果如预期则会启动更大规模的业务改造。更多详细规划和进展，以及性能、稳定性、扩展性的数据随后放出。三、风险1. 尽管Facebook有3款App（Groups、Ads Manager、F8）使用了React Native，随着React Native大规模应用，Appstore的政策是否有变不得而知，我们只能往前走一步。2. React Native Android 预计2015年10月才发布，这对希望三端（Web/iOS/Android）架构一致的用户而言也算个风险。3. iOS6 JavascriptCore为私有API（），如在iOS6上使用有拒审风险。4. ListView 性能问题需要持续关注（）React Native相对于Webview和Native的优势和劣势 @berg 也给出了较详细的描述，可以相互参照。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量6646点击量5944点击量4816点击量4543点击量3285点击量3068点击量2796点击量2552点击量2519
&2016 Chukong Technologies,Inc.
京公网安备89}