React Native 是什么
React Native(下称RN) 官网的标题是A framework for building native apps using React，也就是说RN是一个能让我们使用 react 模式去开发原生应用的一个框架，我们也可以解读为RN能够让我们只使用 javascript 去开发原生应用，这也是在讨论 RN 的特点时常常会提及到的一个点。
React Native 有什么优势？
相较于使用原生，或者 Hybrid，甚至 web 开发一个应用，RN的优势在哪里？ 抛开场景针对框架本身来谈，RN的优势如下:
- 原生应用的用户体验
由于RN所使用的基础UI组件与原生应用一致，所以声称可以和原生应用一致的体验，但是体验二字与实际开发的很多细节息息相关，是否能和原生一致，对开发者的能力具有一定的要求。 - 跨平台特性
开发者可以只使用 js 同时开发 IOS 和 Android 两个平台的应用，对前端开发者而言上手快，入门容易；同时由于技术栈单一了，开发和维护的时间、成本都更低，适合快速上线。
但是实际使用RN开发过程中，你会遇到很多不愉快
React Native 是什么原理？
既然是 react 系的框架，可以知道由 jsx 转换成 virtual dom 的过程是应该是和 react 一致的，而 vd 转换成 real dom 的过程并不在 react.js 中，react 将核心渲染的部分抽离了，并定义了一套渲染相关的配置；
简单浏览 RN的 config 文件，可以知道 RN 主要依靠 UIManager模块下的各个 api 来实现在 native 端渲染组件，那样式布局的渲染如何实现的呢？RN 使用了 Yoga 来实现 css 中的 flex 布局效果，但是一些其他的样式则是映射到对应的 native 属性吧(?)。
然而到这里所说的一切都还止步在 js 部分，计算出 dom diff 后，RN 到底如何和 native 端通信，将要执行的 js 指令，传达给 native 端的呢？
首先需要向 js 的执行环境中注入 native 配置表，包括 native 提供的一些方法，模块以及常量，js 运行环境配置好后，才开始启动应用，此时即可调用 native 模块的内容了，需要注意的是 js 和 native 间不存在任何指针传递，所有参数都是字符串传递。
因为笔者对原生开发暂且一窍不通，想了解具体的同学可以看看@guoxiaoxing 的Vinci，这里只能简单的概括为 c++ 在 js 和 native 之间担任沟通桥梁的角色。
React Native与其他技术栈的性能对比？
这里借用了H5、React Native、Native应用对比分析一文的数据： 依靠三种技术栈尽量保持一致的开发同一个简单的 app，测试三者的性能情况，这里只取部分。
| platform | 内存平均使用 | CPU使用最大值 | 流畅度(原文作者感知) | 更新成本 | 维护成本 |
|---|---|---|---|---|---|
| RN | 72MB | 41% | 95/100 | 可热更新，修复及时 | 单一技术栈易于维护 |
| Native | 117MB | 34% | 85/100 | 随版本更新，需要平台审核，周期较长 | 两个团队成本较大 |
| Hybrid | 137MB | 30% | 70/100 | 随时平稳更新 | web + native 支持，相对简单 |
综上所述： RN 相较于纯 Native 的优势 我认为只有开发的成本(对应的开发人员+较长的开发周期),而相较于 hybrid 只有较小的性能修饰和流畅度优势(且这两优势对开发者具有一定要求),但是牺牲了h5的跨平台，迭代迅速，社区繁荣和易推广的优势，我觉得选择 RN 最好慎之又慎。
React Native与同类技术横向相对比？
如果你确信要基于 native ，并且有自信(?)，你还可以在 rn、weex 和 flutter 中选择。
- weex 框架所解决的问题和解决的手段与 rn 类似，都是在原生组件的基础上进行封装，开发者可以简单的使用 js 来对应用进行“组装”，不过 weex 还不仅仅是 native 端的输出，还支持提供 web 端的输出(就是一行代码，生成 ios、android、浏览器三端都可运行的应用。)这相比RN是个较大的优势，唯一的不足就是 weex 不支持 react 仅仅支持 rax，不过 rax 声明自己基于 react 标准实现的。
- Flutter 就真的是只解决原生跨平台(ios 和 android)问题了，采用的也是全新的编程语言 Dart，尽管我认为 flutter 的出现主要是为了解决 Fuchsia(google 新开发的操作系统) 上的应用开发问题。所以直到 Fuchsia 在市场占有一定额度之前，可能 flutter 的发展都不会太好(flag)。这里再提一下 flutter 与 weex、rn 最大的不同，就是他另外实现了一套组件的渲染方式，而不是对原生组件的封装，这点可能在性能上会有一定的优势。
React Native 开发实践感悟
1.技术选型
其实并没有完整的技术选型过程，当时是因为项目组之前累积了使用RN开发 app 的经验，所以这次项目自然而然的承接了之前的开发经验，使用 RN 来开发。 现在想来实在有些没有缘由，首先没有了web生态活跃的优势，开发过程中很多组件都是自行开发的，比如 1.渲染表格的组件，渲染echart的组件(在 native-echart 上再次开发)。而且自行封装的组件在后期都遇到了性能问题且没有解决(能力+时间有限，团队也没有懂原生开发的人)；2.后期需求变更，需要同步发布浏览器端(PC+Mobile)查看的版本，两个需求没法复用代码，因为开发初期没有考虑到这个问题，也没有使用 iOS + Android + web 三端合并的开发框架。
2.实际开发时遇到的一些问题
- 关于RN：
- 使用 native-echart 绘制图表，当同一个页面有多个图表，就组件而言一个绘图组件需要打开一个 webview ，多个 webview 的使用导致应用内存占用很大，现在想来，应该搭配使用 hybrid 形式的页面，或者修改 native-echart 组件，接受 options 数组，逐个绘制多个图表。
- 渲染大数量的列表有明显的掉帧，大多数情况对长列表都是有翻页(或懒加载)处理的，但是会有个别业务没有翻页的，现在想来应该对数据做一下处理，逐步放入视图中。
- 组里没有对原生开发有一定的了解的人最好还是不要使用RN了，遇到问题只能求助搜索引起，优化甚至都无从下手，深度自定义更是不要想了。
- 关于架构
- app 使用 redux 做状态管理，由于业务功能多，整个 redux 相关的代码 非常庞大；后期认为，应该将处理数据和处理业务的代码分开处理，页面组件几乎不处理数据，只保留对UI的改动。
- 用RN这个框架似乎没有很高的优先度，在不知道用什么比较好的时候更建议选择 hybrid 的框架去开发，至少 hybrid 可以在 native + web 两端跑，其次在不熟悉原生开发的情况下用RN可能也达不到你理想中的性能。
参考阅读：
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
