先说结论
React Native实际上是一种Hybrid开发方式。
理论上，RN可以在跨平台的基础上。解决开发中的任何问题、达到和native一样的效果。
但前提是。开发人员至少要完全熟悉React框架。以及iOS、Android端的Native代码。
在有人很hold主RN的整体系统的前提下。业务开发人员是可以舒服的开发RN代码的。
RN大略
移动端开发。大家很少使用H5实现主路径功能的原因是。H5的交互体验略差。但H5有一个优势，就是它是跨平台的。所以就有人想让native和js结合。达到既能有很好的使用体验。又能跨平台。这就是RN产生的原因。
但真的能做到性能与跨平台兼有吗？JavaScript的运行环境是串行的。一旦串行中有阻塞，就会造成卡顿。就应该放到native中实现。所以结论就是耗性能的操作应该放到native中实现，其他的操作可以用javascript实现。
令一个解决js性能问题的方案是。在native另开一个js环境。在另外的线程运行js代码。结果回传到原来的js context里面。类似的开源库是react-native-threads这种方式可能造成内存问题。
业务开发人员的舒适度
javascript语言是弱类型。用来开发单页面的web端。代码量不会很高。问题不是很大。但如果用到RN开发，会很吃力。因为开发人员会经常调用未知的接口。接口的参数数量、接口的参数类型、参数如果是对象的话、对象的结构。都不知道。这会是非常痛苦的。
解决js弱类型的方法是在js的语法基础上，增加类型检查语法。目前的方案有两种。
flow+babel：这个方式也是RN自带的方式。flow负责静态语法检查、babel负责编译js，将检查语法去掉。但Facebook并没有将flow做的足够贴心。导致各种小bug。包括断点调试，断点不生效。断点的位置不准确等问题。同时开发人员需要一个用着顺手的IDE。atom和flow集成后的使用体验并不好。VSCode集成flow体验还不错。
TypeScript：这是微软开发的开源语言。虽然很多人都不喜欢微软。但TypeScript集成VSCode是真心好用。安装React Native Tools插件后。开发体验和传统IDE没有区别。debug、断点、查看声明、语法检查与提示样样贴心！
这里有一个需要注意的点。因为RN本身是一flow语法为主的。其他的第三方库是以js为主的。这里如果需要依赖js库。就需要d.ts文件。这个文件往往都是现成的。如果是自己的js库，就需要使用命令生成d.ts文件。可参考这里。
关于TypeScript+RN的配置。在这里。
总体来说，TypeScript+VSCode+React NativeTools+RN，是真心好用。但有大牛能hold住RN整个系统的前提下。生产环境下使用是绝对没有问题的。
