作为一名 Web 开发工程师，天天都会和网络打交道。Charles 作为一款网络抓包工具，几乎成了 Web 开发的标配。

本文是我深度使用 Charles 后总结而成，不同于其它介绍 Charles 的文章，这篇文章不会详细介绍 Charles 的各个功能（例如 remote 和 rewrite），而是专注于分析一个问题：什么情况下 Charles 会抓包失败？

对于大部分开发者来说，版本兼容是一件存在感很低的事情，因为它在绝大部分情况下都是一行配置，在一些前端工具链（例如 Babel、CoreJS，Autoprefixer 等工具）的帮助下适配到目标浏览器，只会在一些大的 break change 事件（例如 Vue3 必须在支持 Proxy 的现代浏览器下才能运行）下才会关注这件不起眼的事情。

但当你稍微研究一下的时候，才会发现这块儿内容知识非常杂，因为版本兼容的相关知识没有那么多内在逻辑性，很多细碎的知识点散落在在各个商业公司的博弈和版本变更中。前段时间因工作需要对部分语言/浏览器特性重点关注了一下，以此文做一下记录。

本文主要记录了移动端的版本适配问题，未对桌面端做更多的研究，后面有可能补充相关内容。

最近在做 web 性能优化的工作，所以想集中学习了解一下相关的专题内容。这部分内容肯定要学习一手信息，所以找先找了 https://web.dev/，一个 Google 官方推出的一个面向 Web 开发者的网站，里面有非常多的教程和最佳实践，非常适合有性能优化诉求的开发者去浏览和学习。

网站的核心部分分为 4 类：

• Learn：体系化的教程，例如性能优化和 PWA
• Measure：就是一个在线版本的 Lighthouse，和 Chrome DevTools 的 Lighthouse 功能一致
• Case Study：优化案例（商业互吹），内容一般为采用 X 优化带来数据 Y 的提升最终带来 Z 的商业增长
• Blog：内容较杂，优化教程/API 解读/优化案例等等都有涉及

从上面的结构可以看出，Lean/Measure/CaseStudy 这三个章节内容都是比较体系化的，但是 Blog 内容却没有一个很好的分类。以我的阅读经验，Blog 里有一些非常好的文章，所以我很好奇 Blog 章节里有多少好东西可供挖掘，于是花了几个月的时间，把所有的 Blog 读了一遍，并以自己的认知对内容做了分析和总结，以便自己后续回顾与搜索。

I didn't write much in 2021, so I wanted to start 2022 on a good note by writing some simple content first, recording how I reduced my personal site's file storage costs by 90%.

When developing with React Native, if you're just writing some simple pages, you can basically write them following the official documentation reactnative.dev. However, React Native has hundreds of APIs. Without certain development experience and pitfall-hitting experience, you really can't grasp the key points when facing new requirements.

This article summarizes the problems I encountered in personal React Native development and some less common APIs. If someone happens to see this article and solves actual problems with it, that would be great.

Previous article mainly analyzed React Native's initialization process from a Native perspective and summarized several optimization points for React Native container initialization based on source code. This article focuses on JavaScript and summarizes some JS-side optimization points.

Web development has a classic question: "What happens from entering a URL to page rendering in the browser?"

According to my research, this question has at least ten years of history. In the ever-changing, hard-to-learn frontend circle, this question continues to be asked because it's a very good question involving many knowledge points. When doing some performance optimization, you can start from this question, analyze performance bottlenecks, and then optimize accordingly.

But today we're not talking about Web performance optimization. Just borrowing the analysis approach of that classic question, from React Native startup to the first page render completion, combining React Native source code and the new 1.0 architecture, explore React Native's startup performance optimization path.

Last week I wrote a long article "Which Mobile JS Engine is the Strongest? Looking in Silicon Valley...", which was too energy-consuming. This week I'm writing a relaxed article to transition.

在一般的移动端开发场景中，每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。但是市场瞬息万变，Native 语言在开发效率上存在一定不足，并且从 APP 版本更新 到 应用市场审核发布 再到 用户下载更新，总会存在一定的时间差，这样就导致新的功能无法及时覆盖全量用户。

为了解决这个问题，开发者们一般会在项目里引入一门脚本语言，提速 APP 的研发流程。在移动端应用比较广泛的脚本语言有 Lua 和 JavaScript，前者在游戏领域用的比较多，后者在应用领域用的比较多。本篇文章主要是想探讨一下移动双端（iOS & Android）的 JavaScript 引擎选型。由于个人水平有限，文章总会有遗漏和不足的地方，还请各位大佬多多指教。

A while ago, a senior person at our company learned through some channels that a certain national-level APP was rejected for three months because Apple App Store reviewers detected React Native hot update content. Our hot update platform has similar principles to the problematic APP, so we also face the risk of rejection. Therefore, we need to think of some ways to hide the hot update bundle and avoid being discovered by reviewers.

Actually, this problem is quite complex because it's not purely a technical issue but also involves various complex commercial interests. Under many constraints, it's difficult to find an optimal solution. Moreover, this issue is quite sensitive, so I can only briefly outline my thinking process. This article will not provide specific code implementations.

Serious declaration: If anyone hides hot update data according to the ideas in this article and the application gets rejected or removed, I will not be responsible.