React Native 开发时，如果只是写些简单的页面，基本上按着官方文档 reactnative.dev就能写出来，但是 React Native 的 API 有几百个，没有一定的开发踩坑经验，面对一些新的需求时确实会抓不到重点。
本文总结了我个人开发 React Native 中遇到的问题和一些冷门的 API，如果有有缘人看到这篇文章并解决了实际问题，那就最好不过了。
上一篇文章主要从 Native 的角度分析了 React Native 的初始化流程，并从源码出发，总结了几个 React Native 容器初始化的优化点。本文主要从 JavaScript 入手，总结了一些 JS 侧的优化要点。
Web 开发有一个经典问题：「浏览器中从输入 URL 到页面渲染的这个过程中都发生了什么？」
据我考据这个问题起码有十年历史了。在日新月异学不动的前端圈子里，这个问题能一直被问，就是因为因为它是个非常好的问题，涉及非常多的知识点，平时做一些性能优化，都可以从这个问题出发，分析性能瓶颈，然后对症下药进行优化。
不过今天我们不谈 Web 的性能优化，只是借助刚刚的那个那个经典问题的分析思路，从 React Native 的启动到页面的第一次渲染完成，结合 React Native 的源码和 1.0 的新架构，探索 React Native 的启动性能优化之路。
在一般的移动端开发场景中，每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。但是市场瞬息万变，Native 语言在开发效率上存在一定不足，并且从 APP 版本更新 到 应用市场审核发布 再到 用户下载更新，总会存在一定的时间差，这样就导致新的功能无法及时覆盖全量用户。
为了解决这个问题，开发者们一般会在项目里引入一门脚本语言，提速 APP 的研发流程。在移动端应用比较广泛的脚本语言有 Lua 和 JavaScript，前者在游戏领域用的比较多，后者在应用领域用的比较多。本篇文章主要是想探讨一下移动双端（iOS & Android）的 JavaScript 引擎选型。由于个人水平有限，文章总会有遗漏和不足的地方，还请各位大佬多多指教。
前段时间我们公司的一个大佬从一些渠道得知了一些小道消息，某国民级 APP 因为 Apple App Store 审核人员检测出 React Native 热更新的内容，被拒审了三个月。我们的热更新平台和出事的 APP 原理相似，所以也存在着拒审危险。那么我们就要想一些办法，隐藏热更新 bundle，不被审核人员发现。
其实这个问题蛮复杂的，因为它不单纯是一个技术问题，还涉及到各种复杂的商业利益，在诸多的限制条件下，你很难去找到一个最优解。而且这个问题也比较敏感，我也只能大致讲一下我的思路，具体的代码实现本文也不会提供。
郑重声明：若有人按本文思路隐藏热更新数据导致应用拒审或下架，本人概不负责
本文是我在学习多个平台 UI 框架后的一些感触，受精力和技术水平所限，文中定有不足之处，请各位大佬多多指教
React Native 作为一款跨端框架，有一个最让人头疼的问题，那就是版本更新。尤其是遇到大版本更新，JavaScript、iOS 和 Android 三端的配置构建文件都有非常大的变动，有时候三者的配置文件又互相耦合在一起，往往牵一发而动全身。
文章已于 2022-08-29 更新「图片」优化内容
文章已于 2022-01-22 更新「Fabric」架构章节
文章已于 2021-07-01 更新 Redux 优化内容
2020 年谈 React Native，在日新月异的前端圈，可能算比较另类了。文章动笔之前我也犹豫过，但是想到写技术文章又不是赶时髦，啥新潮写啥，所以还是动笔写了这篇 React Native 性能优化的文章。
本文谈到的 React Native 性能优化，还没到修改 React Native 源码那种地步，所以通用性很强，对大部分 RN 开发者来说都用得着。
产品为了提高推送送达率，提了一个需求：在 APP 推送关闭的情况下显示一个小 TIP，点击 TIP 跳转到 APP 消息设置界面。
我们的 APP 是基于 React Native 开发的，这些功能 Facebook 官方没有提供，需要我们开发对应的原生模块。