您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
react-native布局、组件、热更新和常见错误资料.doc 35页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：350 &&
你可能关注的文档：
··········
··········
更多组件：https://react.parts/native，调用系统的，注意查看：支持IOS or 安卓 组件和相关使用样式用这种方式定义，可以单独提出来成一个文件。1.引入外部样式：var Style = require('./Styles');就可引入相对自己目录下的Styles.js，注：React Native 没有所谓的CSS。var styles = StyleSheet.create({ base: { width: 38, height: 38, },background: { backgroundColor: '#222222', }, active: { borderWidth: 2, borderColor: '#00ff00'}});使用样式：&Text style={styles.base} /& &View style={styles.background} /& 2.以下是组件说明：2.AppRegistry：应用注册，用于初始化启动应用AppRegistry.registerComponent(项目名, () =&&入口Class名&);例如：AppRegistry.registerComponent('AwesomeProject', () =& SampleComponent); 3.View：试图，里面可以套用子试图：&View style={styles.view }&
&View style={styles.subview }&
你的其它组件
&View&&/View&布局使用的，Android 和 IOS 都支持。 4.Text：用于显示你要显示的文字：&Text style={styles.Text }&你的文字&/Text&你可以配合字体样式去用 5.Image：用于显示图片信息：&Image source={{uri: team.logo}} style={styles.thumbnail}/&Source: 图片源（URL）（请求网络用uri，请求本地用：（require('image! &图片&')））注意：图片只能放在：android\app\src\main\res\drawable-[尺寸]，目录下，才能被找到，其它任意位置均不能使用本地图片（文件命名：全字母小写，才能使用，否则报错）。
6.ListView: 列表试图，用于渲染自定义列表：&ListView dataSource={this.state.dataSource} renderRow={this.renderScoreboard}style={styles.listView} /&dataSource：数据源（JSON 格式）renderRow：自定义渲染行（绑定一个方法，在this下返回JSX，自定义行代码）
7.Loading加载试图的做法
1.this-&renderLoadingView，建立一个显示 文字 或Image。 2.在列表渲染的时候之前，做一个这个判断，让它显示。这里说一下，请求数据，是如何工作的，这里要用到new ListView.DataSource 和fetch 3.如上图：初始化数据使用getInitialState，对dataSource初始化，rowHasChanged: (row1, row2) =& row1 !== row2，和下面这句rowHasChanged: function(row1, row2){ row1 !== row2} 这两句是相等的，用于行是否改编 请求数据使用的是fetch ，REQUEST_URL 是URL地址,第一个then用于 调试 或 改写返回结果，第二个then用于渲染界面，第三个catch是请求出错，所执行的。更多请求详情，可参考：/github/fetch，(文件上传 和 表单提交，添加头部 及 提交方式，可参考，最后两项) 8.TextInput: 文本输入框，用于输入文字的&TextInput placeholder='Search via name or postcode' secureTextEntry={true} /&Placeholder：提示要显示的文字secureTextEntry：是否是密码框 以下是三个触屏试图：9.TouchableHighlight: 触屏高亮试图，体验效果更好。&TouchableHighlight underlayColor='#99d9f4'&&
正在加载中，请稍后...主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
傻丫头和高科技产物小心翼翼的初恋
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
个人大数据技术博客：
人生得意须尽欢，莫使金樽空对月。
作者简介： 彭飞，58 同城 iOS 客户端架构师。专注于新技术的研发，主要负责 App 端组件化架构以及性能优化，并已推广 React Native 在 58 同城 App 中业务场景的应用。在 MDCC 2016 iOS 开发峰会上分享《》主题演讲。
导读React Native 在 iOS 界早就炒得火热了，随着 2015 年底 Android 端推出后，一套代码能运行于双平台上，真正拥有了 Hybrid 框架的所有优势。再加上 Native 的优秀性能，让越来越多的公司在实际项目中一探究竟。58 同城 App 发布模块年代久远，一直计划进行重构以适应日益苛刻的用户体验，这个需求与我们在 React Native 上一探究竟的意愿一碰撞，就产生了 React Native 在 58 App 的开发实践。本文重点介绍的是实践过程中的技术架构和 Native 组件层以及热更新平台的基本情况，以期能对 React Native 的从零到深入有一个整体的把握。工欲善其事，必先利其器React Native 是一项全新的技术，不同公司使用有不同的体验，好坏众说纷纭。基于此，必须根据自身的情况进行摸底调研。58 App 的调研过程从 2015 年 6 月就开始了，那时候 Android 还没推出，仅调研了 iOS 的相关情况。真正的全面调研展开是在 2016 年 3 月开始的，整个过程持续到 5 月初结束。下面分三个阶段介绍一下58 App 调研的具体历程。iOS RN 调研（2015.6）React Native 确切的说从 2015 年开始在国内火起来的。墙外开花，墙内结果，国外技术研发，国内炒得火热。阿里天猫在这一方面走的比较靠前，但这时候 Android 部分还未推出，仅有 iOS。当时我们是拿二手车的列表页进行的试验，主要测试用 RN 实现的列表页和用 Native 实现的列表页在性能上的差别，当时得出的调研结论如下：
集成 React Native 需要从 iOS 7.0 开始，在 7.0 以下会因私有 API 问题在审核过程中被拒；
性能方面，通过对 ListView 的针对性分析，在数据量不大的情况（50 条左右），内存和 CPU 的差别在 iPhone 4S 以上的设备上可以接受；当数据量比较多，比如试验过程中的 150 条，内存比较大，在低端设备（4S／5C）上随着业务的扩展，性能会有瓶颈。
开发学习成本上，上手会比较快。但在开发的过程中遇到一些复杂的业务逻辑，得基于现有的框架扩展组件；还有在崩溃的收集上会比较麻烦，只能定位到 OC 层的代码，对于 JS 的运行时崩溃，目前的崩溃收集系统还无法采集。
当然，React Native 的理念是比较好的，既能拥有 Native 的良好用户体验，又能具备 Web 的快速发布和迭代的功能。如果 Android 后续能很好推出，还能实现跨平台的“一处编写，多处运行”的效果。无论集成与否，后续要持续关注，保持前沿技术的敏感性。对应 ListView 性能问题，RN 官方一直没有一个很好的解决方案，我们最近也在做一些调研和组件的重新封装，期望能从根本上解决这个问题。双平台RN基础调研（2016.3）在 2015 年底，React Native 就推出了 Android 版本，然后就有很多公司在开始尝试了。春节流量高峰一过，上面就在筹划 RN 上开发尝试的事了。大体方向是以 App 中的发布模块做为试点，然后我们调研的技术偏向于发布模块的相关功能实现。调研由无线的总监专门组织，iOS/Android/JS 分别出一个人，成立了调研三人组，每周汇报进度。3 月份的调研主要面向的是RN基础调研，摘取了其中的一些调研细节：
Android／iOS 如何将RN集成到当前项目中？
如何用 RN 提供的原生组件实现发布界面？
写完的 JS 如何打包给 Native 使用？
由于是集成到已有项目，如何处理项目中的统一导航和 RN 提供的导航？
发布表单中图片区域如何处理？Native 封装的组件粒度如何？
发布页面的 UI 是用 ScrollView 控制还是 ListView 控制？
3 月份的调研，在 RN 的应用层面做到了一个心中有数，为后期的技术工作开展奠定了一个很好的基础。至于基础调研过程中的问题，限于篇幅问题，就不一一展开叙述了，有兴趣的同学可以私下交流。RN 热更新调研(2016.4)热更新调研是整个调研最最关键的一环，因为官方并没有热更新的成熟方案。整个 4 月份一直在进行热更新的调研，直到 5 月 8 日结束。热更新调研主要涉及的主题为：
热更新 Native 端的流程？如何控制热更新包的大小及内置的资源大小？
Server 端热更新 diff 文件存储方案及更新方案？
Native 端如何获取文件的更新？
异常回滚机制？
是基于二进制算法的 diff 还是基于文件算法的 diff？
热更新中涉及的细节真的很多，上面只是列出其中的一些。我们的调研过程，也是内部一遍遍技术评审／修改／再评审的过程。在下一章节会对这里提到的主要问题进行分析和解释。万事具备，水滴石穿5月份 PM 已经陆续把需求整理完成了，然后成立了项目组，加入了发布业务的 FE 及 Server。项目代号为“水滴”，无线 FE同学的创意。水滴，源自于三体，多维空间武器，通过量子纠缠进行超远距离通讯和控制。React Native 如同水滴，对 JS-Native 通讯和控制。另外，寓意水滴石穿，坚持不懈，终能成功！基于 RN 的移动 App 开发架构首先从整体上了解一下基于 RN 的 App 开发架构。架构共分为五个部分：Native 组件／API 层、JS 中间层、JS 业务层、视图载体页、热更新平台。JS 业务层、JS 中间层、Native 组件／API 层三者运行于视图载体页中，且 JS 业务层和 JS 中间层的代码更新是通过热更新平台更新到用户手机应用中的。Native 组件／API 层是整个装置的基石，JS 业务层通过 JS 中间层调用 Native 组件与 API。Native 组件／API 层与 JS 中间层是无状态，可以被复用的，它们被不同业务调用和组装，能形成不同的业务功能。在这里，一切业务都是基于组件的，任何业务的形成，都是调用 Native 组件及 API 来的。尤其是引入了 JS 中间层，不仅抹平了在不同平台（iOS／Android）上调用组件的差异性，还解耦了 JS 业务层与 Native 组件层。如果没有 JS 中间层，Native 一个组件或者 API 的变动，都需要通知所有的业务方去进行修改，在业务到达一定量的情况下，这种改动不仅费时费力还具有风险，会影响线上功能。引入了 JS 中间层之后，Native 组件及 API 的变动，都在 JS 中间层进行处理，JS 业务层毫无感知。下面对这五个部分进行分别介绍：Native 组件／API 层Native 组件／API 层是在整个架构的最底层，也是整个装置的基础。在这一层，除了 React Native 本身提供的原生组件外，我们还对没有覆盖到的组件进行了封装。React Native 提供的组件有 Image、ListView、Picker、Text、TextInput、ScrollView 等，具体可从 上查询。我们扩展的组件有：支付、语音、弹窗、单选选择器、多选无联动选择器、登录等。在 React Native 中，除了组件，还有 API。官方提供的 API 有 ClipBoard、AsyncStorage、AppRegistry、Alert 等，更多完备的 API 可从 React Native 官方网站上查询。我们扩展的 API 有：跳转、定位、埋点、初始化参数等。这些扩展的组件和 API 使得用 React Native，来实现本地化的业务成为了可能。当然随着业务的逐步扩大，还会不断丰富组件／API 库，以适应业务的特殊性和多样性。具体自定义组件情况如下图：以弹窗 dialog 组件为例，Native 与 JS 交互的协议为：JS调用的示例为：JS 中间层JS 中间层是非常关键的一层，是为上文中扩展的 Native 组件／API 来服务的。JS 中间层如上文所述，不仅能抹平在不同平台上调用 Native 组件／API 的差异，还解耦了 JS 业务层与 Native 组件／API 层。上图所示的是在自定义弹窗组件（Dialog）中的代码片段，从代码的 95 行到 102 行，所做的是处理 iOS／Android 两个平台上弹窗界面确定按钮放置的位置不同而做的差异化处理。类似这些平台差异化的内容在实际开发中会有很多，如果这些差异都有业务方去做，不仅代码可复用性差，而且耗时耗力，每一个新接入方都要重新开发调试。至于 JS 业务层与 Native 组件／API 层之间的耦合关系，可以试想，如果没有中间层的封装，以上文的 dialog 组件为例，在业务层中将会，其中 WBCustomDialogManager 是 Native 的组件标识别，还有 show 函数的相关参数存在多份这样相同的代码。这些与 Native 相关的内容如果发生变化，则所有与这个组件相关的业务都要更改。而引入了中间层之后，业务调用方，将不再关注这些细节，中间层在其中做了解藕。即使 Native 发生了变动，也会最大限度降低业务层的变动。JS业务层JS 业务层主要专注了业务的实现，包括视图的渲染、组件的串联、UI样式的设置、Server API接口的调用与数据的处理。JS 业务层在改装置中是最终代码的落地，视图载体页加载的视图以及热更新系统更新的代码都是直接针对 JS 业务层的，只是这时业务层引用了 JS 中间层的代码来实现对 Native 组件的调用。视图载体页视图载体页在这里扮演了很重要的角色，是所有业务的一个统一载体。以 58同城 App 为例，里面有大类页／列表页／详情页／发布等不同形态的各种业务。通用的做法每一个业务一个载体页。因为载体页是 Native 代码写的，这使得当需要扩展一个业务线的时候，必须依赖发版。而统一了载体页后，只需要通过热更新平台将 JS 代码更新到 App 本地即可实现。视图载体页单一载体功能的实现，很关键的部分在于跳转到载体页跳转协议的设计。由于跳转协议与具体的业务关联较大，我们的跳转协议中有一个重要的参数 pagetype，在这里我们将 pagetype 设置为RN，而不是 list(列表页)／detail（详情页）等与业务相关的类型。这样在跳转入口，服务器进行配置的时候，不需要维护到特定载体页的映射，从根本上解除了因业务变动带来的跳转配置耦合。跳转协议在不同的 App 中，实现思路不同，有很多 App 采用的 URL 形式来实现，但具体思路与上文描述的 JSON 形式相同。热更新平台热更新平台是整个框架的核心。热更新平台的主要功能是将JS业务层及其引用的代码编译 link 好的 JSBundle 下载到 Native App 中。在此过程中，需要控制更新文件的大小以及失败情况的处理。热更新平台涉及 JSBundle 资源管理系统（Server）、JSBundle 数据接口层（Server）、JSBundle Native 更新及管理层（Native）。JSBundle 资源管理系统负责将相关 JS 业务层代码编译 link 成 JSBundle 文件，并将相关更新写到一个数据缓存中心（例如 Redis 或 Memcached）。当 Native 通过 JSBundle 数据接口层提供的接口获取对应的 JSBundle 的信息时，数据接口层将从数据缓存中心查询数据并返回给 Native 端。Native 端为了提高用户体验，会对 JSBundle 进行缓存，用户访问相关页面的时候，先展示缓存，再访问接口，看是否有更新。热更新这块，在这里我从另外一个角度来阐述，即我们为什么不用现有市面上的方案，而要自己搞一套。下面的三个章节来逐步叙述。热更新的三个主要问题热更新现在公开的两个方案是微软的 Code Push 和 React Native 中文网中的 react-native-pushy。这两种方案实现思路其实差不多，但针对我们的 App，不能满足以下情况：1. 内置资源体积过大，导致整个应用包的大小过大，导致过多占用用户手机容量以及下载应用耗时超长。在 App 提交给应用商店审核时，会将 RN 集成编译后的 JSBundle 打进内置资源里面去，而一个完整的 JSBundle 在区分平台（iOS／Android）以及 JS 压缩的前提下，体积有 600K 左右。如果随着业务的快速扩展，假设有 100 个 JSBundle 的内置资源，那么大小就会达到 60M。而应用商店的 App 大小，以 58App 为例，大小才 100M。内置资源过大，导致整个应用包的体积过大，一是占用用户手机容量，另一个每次下载应用耗时超长。这在一定程度上是很难接受的。2. 计算增量的基准文件不唯一，平均合并的 diff 个数过多，增加了服务器处理增量的复杂度和降低了 App 端合并 diff 性能。Code Push 和 react-native-pushy 在利用 bsdiff 算法计算增量时，是相邻两个版本文件的 diff。现在假设用户本地 App 文件版本是 1.0，而服务器最新文件版本是 4.0，则服务器需要返回App 3 个 diff（1.0 至 2.0 一个 diff， 2.0 至 3.0 一个 diff，3.0 至 4.0 一个 diff）。所以，由于 bsdiff 算法计算增量的基准文件不唯一，导致平均需合并的 diff 个数过多。这不仅增加了服务器处理增量的复杂度，还降低了 App 端合并 diff 的性能，合并时间多长，阻塞用户操作。3. 将整个 App 的所有 JSBundle 文件打包进行更新，不区分业务。导致如果一个业务的 JSBundle 有问题，会影响其他业务 JSBundle 的正常运行。Code Push 和 react-native-pushy 做的是一个通用的热更新平台，一个 App 有一个 key，文件更新以此 key 为标识，所有文件在一个 zip 包里面，不区分业务。当前稍微大的互联网公司，都是以业务线划分职能的，在技术架构上，各业务线业务应该做到相互不干扰。react-native-pushy 这种不区分业务的更新模式，会导致如果一个业务的 JSBundle 有问题，会影响其他业务 JSBundle 的正常更新，造成业务的相互干扰。基于对上面的分析，我们得出了热更新需要解决的三个问题：
既要控制更新包的大小，又要控制内资资源的大小；
降低服务器处理增量复杂度和提高 App 端合并 Diff 性能；
Diff 更新以 JSBundle 文件为单位，业务 Diff 之间相互不干扰。
热更新的解决方案基于上面的三个问题，我们有如下的解决方案：JSBundle拆分及公共部分生成在介绍 diff 生成及合并算法之前，先介绍一下一个关键性要点。即我们重点关注 React Native 中 JSBundle 的内容的特殊性，发现打包编译后的一个 JSBundle 可以拆成一个稳定的公共部分加上差异部分。如上图所示，针对一个入口文件 pageIndex.jsbundle, 可以拆分成稳定的 commonPart.jsbundle 以及差异部分 diffPart.jsbundle。其中，commonPart.jsbundle 与具体业务无关，是 React Native 中一些公用的 JS 库。commonPart.jsbundle 生成的方法为(以 iOS 为例，Android 的原理相同)：1. 新建一个blank.ios.js文件，在文件中仅需引入react及react-native,注意不要包含任何业务代码，具体代码如下截图：2. 通过curl命令将blank.ios.js文件编译成common.ios.jsbundle。笔者在本地的执行命令为：curl 'http://localhost:8081/blank.ios.bundle?minify=true&dev=false' -o common.ios.jsbundle得到的common.ios.jsbundle结果如下图所示：需要补充的是，因为 commonPart.jsbundle 依赖 Native 代码，所以 commonPart.jsbundle 的更新是跟着 App 发版走的。Diff的生成与合并基于上文对 jsbundle 的拆分，我们选择了 google-diff-match-patch 算法生成diff 及合并 diff。在计算diff时，以commonPart.jsbundle为基准，计算当前版本的pageIndex.jsbundle与commonPart.jsbundle之间的文本差异，然后APP端拿到文本差异描述后，再利用google-diff-match-patch算法将文本差异合并到本地的commonPart.jsbundle中去。生成diff调用google-diff-match-patch的API为（iOS端为例，其他端可找到对应API）：合并diff调用google-diff-match-patch的API为（iOS端为例，其他端可找到对应API）：热更新流程热更新流程如上图所示。图中载体页是指native加载React Native代码的一个载体。RN是React Native的缩写。下面对上述流程进行叙述：1. 进入载体页，判断是否有缓存。进入载体页之后，会先判断是否有RN缓存，如果有缓存，则直接进行下一步。如果没有缓存，则去服务器下载对应的RN资源（RN资源指的RN代码文件）。2. 展示RN页面根据RN资源，载体页渲染出对应的页面。3. 后台请求当前页面最新信息在展示完RN页面后，新起子线程在后台向服务器请求当前页面的最新信息数据。4. 根据最新信息进行更新操作根据上一步服务器返回的数据，进行分支操作：如果是强制更新，则弹窗提示用户需要强制刷新当前页面才能继续操作；如果是一般的非强制更新，则程序在后台更新数据，用户下次进入此页面后更新生效；如果没有更新，则不做任何操作，流程结束。针对上述流程有一个补充：在APP启动的时候向服务器请求预加载数据，提前对一些重要的RN资源进行加载，这样在上述流程的第一步就可以直接利用RN缓存快速进入页面，用户体验会更好。结果分析基于上述方案，可解决上述提到的三个问题：
在内置资源的时候，只需内置一分commonPart.jsbundle和相应入口页面对应的diffPart.jsbundle。在通常情况下，commonPart.jsbundle占整个jsbundle近2/3的大小，这相比基于react-native-pushy而内置的资源节省了近2/3的大小。针对业务迭代过程的更新包，都只是业务代码的更新，包的大小也得到了很好的控制。另外，由于RN的接口只能加载一个合并后的完整的jsbundle，但这个完整的jsbundle我们是实时合并的，是不存储到文件系统的，只在内存中操作。通过实际运行，这种合并耗时时间很少，基本可忽略不计。这样，即使app运行相对长的一段时间，也不会增加包的大小的。
服务器计算diff包的时候，由于只需对commonPart.jsbundle进行比较，所以计算增量的复杂度相比react-native-pushy降到了最低。APP端在合成diff的时候，只需要将一个common.jsbundle与一个diff.jsbundle进行合并即可，合并性能相比react-native-pushy平均要合并多个，得到了很大的提高。
本方案计算的更新，以某一个入口页面对于的pageIndex.jsbundle为单位来操作，是以具体业务为单位的。每一个pageIndex.jsbundle对应的更新都是相互独立的，即使一个业务更新出错，也不会影响到其他业务的更新。
产品顺利上线，幸有PM烧高香经过两个多月的研发，Native端，FE中间层，FE业务层，业务Server，热更新平台所有功能全部上线了，多亏PM上线前烧了高香，整个过程是很曲折的，但结果是美好的。但老板说了，RN这个东西从来没上过，万一上线之后出了重大问题怎么办？通过发版解决周期太长，速度太慢。于是乎只能通过Server端来控制了。通过Server控制线上出现问题的风险，我们称为降级策略。即用RN之前，58APP使用的Hybrid框架来做的发布页面。如果线上的RN出了问题，通过Server端控制跳转协议，让跳转到web的发布页面上。等待RN问题解决了，再行切换。产品上线后，产品层面最关注的就是加载速度了。针对发布功能来说，从Hybrid切换到React Native，为的就是加载速度。由于RN有热更新，基本上用户是在90%的情况下进入有缓存的界面的。下图是由QA组同学提供的双平台在加载时间上的性能测试结果（有缓存的情况下）。上图中的Web页面加载时间是在网络状况良好的情况下的数据。从图中可以看出，RN页面基本上是秒进，这让从点击发布按钮到展示发布页面期间的用户流失基本降到了最低。经过项目组成员的辛苦努力，React Native在58 App上算是迈出了第一步，官方SDK现在是一个星期一个版本的更新节奏，后期开发中肯定还会有好多坑，跃坑的过程肯定很精彩！了解最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。本文标签：
一、React Native背景
有没有朋友想过一个问题，为什么取名React Native?，？
React 是由Facebook推出的一个JavaScript框架，主要用于前段开发。
React 采用组件化方式简化Web开发
DOM:每个HTML界面可以看做一个DOM
原生的web开发方式，HTML一个文件，javaScript一个文件，文件分开，就会导致修改起来比较麻烦。
可以把一组相关的HTML标签和单独封装到一个组件类中，便于复用，方便开发。
React 可以高效的绘制界面
原生的Web,刷新界面()，需要把整个界面刷新.
React只会刷新部分界面，不会整个界面刷新。
因为React独创了Virtual DOM机制。Virtual DOM是一个存在于内存中的对象，它与DOM是一一对应的关系，当界面发送变化时，React会利用DOM Diff算法，把有变化的进行刷新.
React是采用JSX语法，一种JS语法糖，方便快速开发。
想要了解Native是什么，需要了解下开发App有哪些开发模式，卖了一个馆子，请继续往下看。
二、常见的五种App开发模式
常见的开发模式有5种（）
Native App:指使用原生API开发App,比如iOS用OC语言开发
优点：性能高
缺点：开发维护成本高，养一个原生开发工程师需要很多钱，最重要iOS版本更新也成问题。
Web App:指使用Html开发的移动端网页App,类似微信小程序，整个App都是网页。
优点：用户不需要安装，不会占用手机内存
缺点：用户体验不好，不能离线，必须联网
Hybrid App
App:混合开发模式，原生Api+Html共同开发，比如iOS,用html写好界面，用展示。
优点:界面复用性强，一个界面，iOS和安卓都可以使用
缺点:相对于原生，性能相对有所损害
Weex:基于Vue(JS框架)的语法开发的App,底层会自动把JS代码解析成对应平台(iOS,安卓)的原生API，本质还是原生API开发，只不过表面是用Vue开发。
优点:可以做到一套代码，跨平台执行，底层会自动判断当前是哪个平台，转换为对应平台的原生API代码。
缺点：开源较晚，互联网上相关资料还比较少，社区规模较小
React Native
React Native:基于React开发的App
优点：跳过App Store审核，远程更新代码，提高迭代频率和效率，既有Native的体验，又保留React的开发效率。
缺点:对于不熟悉前端开发的人员上手比较慢，不能真正意义上做到跨平台，使用后，对app体积增加。
相信大多数人了解完，越来越困惑了，那不是跟Native冲突了吗，Native是用原生Api开发,但是React Native又是用React开发。
要想彻底搞明白，需要了解React Native底层实现原理，又来了，想知道原理，继续往下看
三、React Native原理
React Native原理其实跟Weex差不多，底层也会把React转换为原生API
和Weex区别在于跨平台上面，Weex只要写一套代码，React Native需要iOS,安卓都写，说明React Native底层解析原生API是分开实现的，iOS一套，安卓一套。
四、React Native如何把React转化为原生API
React Native会在一开始生成OC模块表，然后把这个模块表传入JS中，JS参照模块表，就能间接调用OC的代码。
相当于买了一个机器人（OC），对应一份说明书（模块表），用户（JS）参照说明书去执行机器人的操作。
五、React Native是如何做到JS和OC交互
iOS原生API有个JavaScriptCore框架，通过它就能实现JS和OC交互，想了解JavaScriptCore，请点击
1.首先写好JSX代码（React框架就是使用JSX语法）
2.把JSX代码解析成javaScript代码
3.OC读取JS文件
4.把javaScript代码读取出来，利用JavaScriptCore执行
5.javaScript代码返回一个数组，数组中会描述OC对象，OC对象的属性，OC对象所需要执行的方法，这样就能让这个对象设置属性，并且调用方法。
JS和OC交互.png
六、React Native启动流程(iOS)
1.创建RCTRootView -& 设置窗口根控制器的View,把RN的View添加到窗口上显示。
2.创建RCTBridge -& 桥接对象,管理JS和OC交互，做中转左右。
3.创建RCTBatchedBridge -& 批量桥架对象，JS和OC交互具体实现都在这个类中。
4.执行[RCTBatchedBridge loadSource] -& 加载JS源码
5.执行[RCTBatchedBridge initModulesWithDispatchGroup] -& 创建OC模块表
6.执行[RCTJSCExecutor injectJSONText] -& 往JS中插入OC模块表
7.执行完JS代码，回调OC，调用OC中的组件
8.完成UI渲染
React Native启动流程(iOS).png
七、React Native加载JS源码流程(iOS)
1.[RCTJavaScriptLoader loadBundleAtURL] -& 加载远程服务器中JS代码
2.attemptAsynchronousLoadOfBundleAtURL(C函数) -& 开启异步加载JS代码
3.[RCTBatchedBridge executeSourceCode:sourceCode] -& 让批量交接对象执行源代码
[RCTJSCExecutor executeApplicationScript] -& 交给JS执行者（RCTJSCExecutor）执行源码)
真正执行JS代码的是RCTJSCExecutor对象
5.[postNotificationName:RCTJavaScriptDidLoadNotification] -& 发送JS代码执行完成通知
6.RCTRootView监听到RCTJavaScriptDidLoadNotification通知
7.创建RCTRootContentView
8.获取RCTBridge中的RCTUIManager注册RCTRootView,并且记录RCTRootView，_viewRegistry
RCTUIManager:管理UI组件
_viewRegistry：保存所有注册的View
9.[RCTRootView runApplication:bridge] -& 通知JS运行App
10.[RCTBridge enqueueJSCall:@"AppRegistry"
method:@"runApplication"
args:@[moduleName, appParameters]
completion:NULL] -& 通过桥接对象让JS调用AppRegistry
11.[RCTBatchedBridge _actuallyInvokeAndProcessModule:module method:method arguments:args queue:RCTJSThread] -& 通过批量桥架让JS执行AppRegistry方法
12.[RCTJSCExecutor _executeJSCall:bridgeMethod arguments:@[module, method, args] unwrapResult:unwrapResult callback:onComplete] -& 让JS执行者调用JS代码
13.执行完JS代码，就能获取执行JS结果，是一个数组，OC需要做的事情都会保存到这个数组中
14.[RCTBatchedBridge _processResponse:json error:error] -& 处理执行完JS代码返回的结果对象
15.[RCTBatchedBridge handleBuffer] -& 处理JS返回的数据，JS会返回的方法调用数组：按顺序描述需要调用哪个对象的方法，一组调用包含（module，method，arguments）
16.[self callNativeModule:[moduleIDs[index] integerValue]
method:[methodIDs[index] integerValue]
params:paramsArrays[index]] -& 遍历数组，依次执行原生方法
注意：当前方法，在遍历数组中的代码块中执行，不只是执行一次.
React Native加载JS源码流程.png
八、React NativeUI控件渲染流程(iOS)
1.[RCTRootView runApplication:bridge] -& 通知JS运行App
2.[RCTBatchedBridge _processResponse:json error:error] -& 处理执行完JS代码(runApplication)返回的相应，包含需要添加多少子控件的信息。
3.[RCTBatchedBridge batchDidComplete] -& 批量桥架对象调用批量处理完成方法
4.[RCTUIManager batchDidComplete] -& RCTUIManager调用批量处理完成的方法，就会开始去加载rootView的子控件。
5.[RCTUIManager createView:viewName:rootTag:props] -& 通过JS执行OC代码，让UI管理者创建子控件View
通过RCT_EXPORT_METHOD宏定义createView这个方法
RCT_EXPORT_METHOD(createView:(nonnull NSNumber *)reactTag
viewName:(NSString *)viewName
rootTag:(__unused NSNumber *)rootTag
props:(NSDictionary *)props)
RCT_EXPORT_METHOD宏:会在JS中生成对应的OC方法，这样JS就能直接调用
注意每创建一个UIView,就会创建一个RCTShadowView，与UIView一一对应
RCTShadowView:保存对应UIView的布局和子控件,管理UIView的加载
6.[RCTUIManager _layoutAndMount] -& 布局RCTRootView和增加子控件
7.[RCTUIManager setChildren:reactTags:] -& 给RCTRootView对应的RCTRootShadowView设置子控件
注意：此方法也是JS调用OC方法
8.[RCTRootShadowView insertReactSubview:view atIndex:index++] -& 遍历子控件数组，给RCTRootShadowView插入所有子控件
9.[RCTShadowView processUpdatedProperties:parentProperties:] -& 处理保存在RCTShadowView中属性，就会去布局RCTShadowView对应UIView的所有子控件
10.[RCTView didUpdateReactSubviews] -& 给原生View添加子控件
11.完成UI渲染
React Native (UI控件渲染流程).png
九、React Native事件处理流程(iOS)
1.在创建RCTRootContentView的时候，内部会创建RCTTouchHandler
RCTTouchHandler:继承UIGestureRecognizer，也就是它就是一个手势
并且它会作为RCTRootContentView的手势，这样点击RCTRootContentView，就会触发RCTTouchHandler
RCTTouchHandler:内部实现了touchBegin等触摸方法，用来处理触摸事件
2.在创建RCTTouchHandler的时候，内部会创建RCTEventDispatcher
RCTEventDispatcher:用来把事件处理传递给JS的方法处理，也就是当UI界面产生事件，就会执行JS的代码处理。
3.通过RCTRootContentView截获点击事件
产生事件就会去触犯RCTRootContentView中的RCTTouchHandler对象。
4.当产生事件的时候,会执行[RCTTouchHandler touchBegin]
5.RCTTouchHandler的touch方法，会执行[RCTTouchHandler _updateAndDispatchTouches:eventName:]
内部会创建RCTTouchEvent事件对象
6.[RCTEventDispatcher sendEvent:event] -& 让事件分发对象调用发送事件对象
内部会把事件保存到_eventQueue（事件队列中）
7.[RCTEventDispatcher flushEventsQueue] -& 让事件分发对象冲刷事件队列，就是获取事件队列中所有事件执行
8.[RCTEventDispatcher dispatchEvent:event] -& 遍历事件队列，一个一个分发事件
分发事件的本质：就是去执行JS的代码，相应事件。
9.[RCTBatchedBridge enqueueJSCall:[[event class] moduleDotMethod] args:[event arguments]]; -& 让桥架对象调用JS处理事件
本质：就是产生事件调用JS代码
10.这样就能完成把UI事件交给JS代码相应
React Native (事件处理流程).png
写在最后：FOR Freedom 看看外边的世界，以及IT这一行，少不了去Google查资料，最后，安利一个加速器代理。，去Google查资料是绝对首选，连接速度快，使用也方便。我买的是99￥一年的，通过这个链接（）注册后输上 优惠码wh80，终身85折 ，平摊下来，每月才7块钱，特实惠。
本文标签：
原文地址：
相关阅读:《》
相关阅读:《》
相关阅读:《》
相关BLOG：
原文地址：
网站的维护离不开大家的支持鼓励，捐赠让我更有动力走的更远：
本博客所有文章如无特别注明均为原创。作者： ，复制或转载请以超链接形式注明转自
。原文地址《》
邮箱（必填）
网址（选填）