文章已于 2022-08-22 更新
作为一名 Web 开发工程师，天天都会和网络打交道。Charles 作为一款网络抓包工具，几乎成了 Web 开发的标配。
本文是我深度使用 Charles 后总结而成，不同于其它介绍 Charles 的文章，这篇文章不会详细介绍 Charles 的各个功能（例如 remote 和 rewrite），而是专注于分析一个问题：什么情况下 Charles 会抓包失败？
对于大部分开发者来说，版本兼容是一件存在感很低的事情，因为它在绝大部分情况下都是一行配置，在一些前端工具链（例如 Babel、CoreJS，Autoprefixer 等工具）的帮助下适配到目标浏览器，只会在一些大的 break change 事件（例如 Vue3 必须在支持 Proxy 的现代浏览器下才能运行）下才会关注这件不起眼的事情。
但当你稍微研究一下的时候，才会发现这块儿内容知识非常杂，因为版本兼容的相关知识没有那么多内在逻辑性，很多细碎的知识点散落在在各个商业公司的博弈和版本变更中。前段时间因工作需要对部分语言/浏览器特性重点关注了一下，以此文做一下记录。
本文主要记录了移动端的版本适配问题，未对桌面端做更多的研究，后面有可能补充相关内容。
文章已于 2022-08-06 更新
最近在做 web 性能优化的工作，所以想集中学习了解一下相关的专题内容。这部分内容肯定要学习一手信息，所以找先找了 https://web.dev/，一个 Google 官方推出的一个面向 Web 开发者的网站，里面有非常多的教程和最佳实践，非常适合有性能优化诉求的开发者去浏览和学习。
网站的核心部分分为 4 类：
从上面的结构可以看出，Lean/Measure/CaseStudy 这三个章节内容都是比较体系化的，但是 Blog 内容却没有一个很好的分类。以我的阅读经验，Blog 里有一些非常好的文章，所以我很好奇 Blog 章节里有多少好东西可供挖掘，于是上个月的时候花了一些时间，把所有的 Blog 读了一遍，并以自己的认知对内容做了分析和总结，以便自己后续回顾与搜索。
2021 年一直没有怎么更文，2022 准备开个好头，所以先挑些简单的内容写一写，记录一下我是如何把个人站点的文件存储资费降低 90% 的。
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 的启动性能优化之路。
上周写了篇长文《移动端 JS 引擎哪家强？美国硅谷找......》，太耗精力了，这周写篇轻松的文章过渡一下。
在一般的移动端开发场景中，每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。但是市场瞬息万变，Native 语言在开发效率上存在一定不足，并且从 APP 版本更新 到 应用市场审核发布 再到 用户下载更新，总会存在一定的时间差，这样就导致新的功能无法及时覆盖全量用户。
为了解决这个问题，开发者们一般会在项目里引入一门脚本语言，提速 APP 的研发流程。在移动端应用比较广泛的脚本语言有 Lua 和 JavaScript，前者在游戏领域用的比较多，后者在应用领域用的比较多。本篇文章主要是想探讨一下移动双端（iOS & Android）的 JavaScript 引擎选型。由于个人水平有限，文章总会有遗漏和不足的地方，还请各位大佬多多指教。
前段时间我们公司的一个大佬从一些渠道得知了一些小道消息，某国民级 APP 因为 Apple App Store 审核人员检测出 React Native 热更新的内容，被拒审了三个月。我们的热更新平台和出事的 APP 原理相似，所以也存在着拒审危险。那么我们就要想一些办法，隐藏热更新 bundle，不被审核人员发现。
其实这个问题蛮复杂的，因为它不单纯是一个技术问题，还涉及到各种复杂的商业利益，在诸多的限制条件下，你很难去找到一个最优解。而且这个问题也比较敏感，我也只能大致讲一下我的思路，具体的代码实现本文也不会提供。
郑重声明：若有人按本文思路隐藏热更新数据导致应用拒审或下架，本人概不负责