选择 React Native 的理由

转载：选择 React Native 的理由

从开始知道 React Native 到现在已经过了5个月，真实的试用也经历了三个月的时间。阅读文档开始，了解是什么，到简单的理解为什么，都是在聆听不同的人的不同的声音，无论是，知乎上的“科学家”们，还是 Youtube 上的各位“牛人”，都从某个角度告诉了我们选择 RN 的理由。

国内开始询问为什么用 RN 的问题由来已早，见于知乎，看到的解释，尚没有让我看到能真实反应今天的 RN 的状况的内容，带出来的各种负面的反应大于正面的反应，混乱了问题的真正所在，“为什么要选择 RN”。

当开始问，“评价 RN”，这样的问题，而真正想知道为什么要选择 RN 的理由的时候，其实际，已经和为什么选择 RN 这样的初衷渐行渐远，大多数的回答，让人感觉的更多的是，RN 还有很多 Bug，RN 性能还是不如 Native Code，等等诸如此类，或多或少的阻碍了某人去尝试试用 RN 的那点热情。

在 React Conf 2017 上 Airbnb，以及 Wix.com 的各位“牛人”的演讲中，充分的体现了他们为什么选择 RN 的主题，他们的演讲所表达的，是走的更远的过程，把 Web，Mobile 项目合并为 用 React X 来统一，减少了开发的成本，还使得项目更加高效，当然，虽然如此， RN 的采用，并不代表只需要，完全的 JS 程序员，只是负责写 Native Code 的程序员依然存在，不过处理的问题更集中了，人员相对减少了。

我同意上面的观点，试用的原因只有一个，就是高效，使得开发、维护项目更加高效，而且真的可以做到。

RN 发展到今天，已经是位于 0.47.1 的位置上，每个月的版本迭代，其发展的速度相当的快，虽然，还有诸多的问题所在，但是其促成的高效开发，学一次，随处可写，已经实实在在可以应付各类手机项目问题。

当代码从 Native Code 转到 RN 的时候，所面临的最大的问题，或许就是性能的问题，这已经不是 RN 的短板所在，因为有很多优秀的教程和演说，已经说明了提升 RN 以接近 Native Code 性能的实践和方法，并得到了很好的效果。这其中 Wix.com 上的“牛人”走在前面，去 Youtube 上看看他们在 React Conf 2017 上的演讲，你就会有很多启发，觉得其实用 RN 实现 Native Code 的性能并不难，或许相当的容易。

或许选择 RN 以使用，对很多人，有很多壁垒，是的，其中一个，RN 要求你绝不仅仅是一个良好的 JS 程序员，或者是只懂得 JS 的程序员。而相反的是，你需要是一个有相当经验的 Android 或者 iOS，或者同时使用过两种开发工具的有能力的程序员。

从个人体验上，至今，个人做的项目，仅仅是用了 3 个月左右的时间（学习了 2 个月）基本同步完成了 Android 和 iOS 部分的应用，这是一个相对复杂的数据计算应用，而 RN 大幅度的提升了项目的效率。

与之前类似 iOS 应用做了对比，减少了至少 2 ／ 3 的时间，这是一个令我惊讶的事实，我没有想到 RN 有如此高的效率。错误率也相对减少了，而调试变得简单。

感觉写应用又回到了有趣的时代。

当然，这其中得益于 Realm 手机数据库，Mbox 状态管理两种高效的第三方组件的帮助。

RN 中的第三方的组件并不是所有都很完善，越简单的库，越稳定，而复杂的库，问题会随之而来，在实际的开发中，通常会遇到两种问题：

第一，库有缺陷，提出的 Issue 得不到快速的解决，那么你只好亲自动手去修改了，往往自己修改要快过等待。

第二，库缺乏一些自己需要的特性，这样的问题，除了自己解决，没有更好的办法。而在自己解决的过程中，你会对 RN 了解的更全面。

对于新手而言，我想说，在选择 RN 之前，你需要是一个有着 Android 或 iOS 开发经验的程序员，在我看来，这必不可少。

然后，学习有成本的，但是，不要看重学习的成本而忽略了其真实的价值所在。

那就是，更轻松的完成自己的工作，给自己多点时间。