性能优化

渲染流程 首先要了解的概念: 渲染引擎：它是浏览器最核心的部分是 “Rendering Engine”，不过我们一般习惯将之称为 “浏览器内核” 渲染引擎主要包括的线程： 各个线程主要职责： GUI渲染线程：GUI 渲染线程负责渲染浏览器界面，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等。当界面需要重绘（Repaint）或由于某种操作引发回流（Reflow）时，该线程就会执行。 JavaScript引擎线程: JavaScript 引擎线程主要负责解析 JavaScript 脚本并运行相关代码。 JavaScript 引擎在一个Tab页（Renderer 进程）中无论什么时候都只有一个 JavaScript 线程在运行 JavaScript 程序。需要提起一点就是，GUI线程与JavaScript引擎线程是互斥的，这也是就是为什么JavaScript操作时间过长，会造成页面渲染不连贯，导致页面出现阻塞的原理。 事件触发线程：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。 通常JavaScript引擎是单线程的，所以这些事件都会排队等待JS执行。 定时器触发器： 我们日常使用的setInterval 和 setTimeout 就在该线程中，原因可能就是：由于JS引擎是单线程的，如果处于阻塞线程状态就会影响记时的准确，所以需要通过单独的线程来记时并触发响应的事件这样子更为合理。 Http请求线程： 在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求，这个线程就Http请求线程，它 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。 有了上述的概念，对接下我们讲渲染流水线会有所帮助 简略版的渲染机制 很久之前就把浏览器工作原理读完了，看了很多博客，文章，当时简简单单的梳理一些内容,如下👇 简略版渲染机制一般分为以下几个步骤 处理 HTML 并构建 DOM 树。 处理 CSS 构建 CSSOM 树。 将 DOM 与 CSSOM 合并成一个渲染树。 根据渲染树来布局，计算每个节点的位置。 调用 GPU 绘制，合成图层，显示在屏幕上。 接下来大概就是这么说： 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。 ...

Initializers是指在main函数之前执行的初始化代码，包括C++静态构造函数和__attribute__((constructor))标记的函数。这些代码会在Pre-main阶段同步执行，阻塞启动。 问题分析 以下代码会在main之前执行： 1. C++静态构造函数 __attribute__((constructor)) static void MyInitializer() { // 耗时初始化 initializeHeavyResource(); } 2. 全局静态变量的构造函数 // 全局静态变量 static std::vector<std::string> globalCache = loadFromDisk(); // 构造函数在main前调用 3. 非基本类型的全局变量 // 非POD类型的全局变量会触发构造函数 static std::string globalString = "Hello"; static MyClass globalObject; 优化方案 方案1：延迟初始化 将全局变量改为懒加载模式： // 优化前：全局变量在main前初始化 static std::vector<std::string> globalCache = loadFromDisk(); // 优化后（纯C++方案，适用于 .cpp 文件）： #include <mutex> static std::vector<std::string>* getGlobalCache() { static std::vector<std::string>* cache = nullptr; static std::once_flag onceFlag; std::call_once(onceFlag, [&] { cache = new std::vector<std::string>(); *cache = loadFromDisk(); }); return cache; } // 优化后（ObjC++方案，适用于 .mm 文件）： static std::vector<std::string>* getGlobalCache() { static std::vector<std::string>* cache = nullptr; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ cache = new std::vector<std::string>(); *cache = loadFromDisk(); }); return cache; } 方案2：使用Swift懒加载 Swift的懒加载特性可以避免在启动时初始化： ...

一、前言 缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离，减少延迟，并且由于缓存文件可以重复利用，还可以减少带宽，降低网络负荷。 对于一个数据请求来说，可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求，或者发起了请求但后端存储的数据和前端一致，那么就没有必要再将数据回传回来，这样就减少了响应数据。 接下来的内容中我们将通过缓存位置、缓存策略以及实际场景应用缓存策略来探讨浏览器缓存机制。 如需获取思维导图或想阅读更多优质文章请猛戳GitHub博客 二、缓存位置 从缓存位置上来说分为四种，并且各自有优先级，当依次查找缓存且都没有命中的时候，才会去请求网络。 Service Worker Memory Cache Disk Cache Push Cache 1.Service Worker Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。 Service Worker 实现缓存功能一般分为三个步骤：首先需要先注册 Service Worker，然后监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。 当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。 2.Memory Cache Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。 那么既然内存缓存这么高效，我们是不是能让数据都存放在内存中呢？ 这是不可能的。计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。 当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存 内存缓存中有一块重要的缓存资源是preloader相关指令（例如<link rel="prefetch">）下载的资源。总所周知preloader的相关指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络请求下一个资源。 需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。 3.Disk Cache Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。 ...

Rebase和Bind是Pre-main阶段的重要步骤，用于修正程序中的指针地址。ObjC类、方法、协议等元数据越多，需要修复的指针越多，启动时间越长。 基本概念 由于ASLR（Address Space Layout Randomization）技术，App每次启动时加载到内存的地址都是随机的，因此需要进行地址修正。关于Rebase和Bind的底层原理，可以参考Mach-O的链接、装载与库。 Rebase（重定位） 修正指向Mach-O内部的指针，将编译时的地址加上ASLR偏移量。 Bind（绑定） 修正指向Mach-O外部的指针，查找符号表，绑定到正确的外部符号地址。 flowchart LR subgraph compile["编译时 (Mach-O文件)"] A1["内部指针: 0x1000(指向内部数据)"] A2["外部符号: _objc_msgSend(待绑定)"] end subgraph runtime["运行时 (内存中)"] B1["内部指针: 0x1000 + slide(Rebase修正)"] B2["外部符号: 实际地址(Bind绑定)"] end A1 -->|"Rebase"| B1 A2 -->|"Bind"| B2 问题分析 以下因素会增加Rebase/Bind的工作量： 因素 影响 ObjC类数量 每个类都有元数据需要修正 Swift类数量 Swift类在Apple平台也会生成ObjC兼容的元数据，同样需要修正 ObjC方法数量 方法列表中的指针需要修正 Category数量 Category的方法列表需要绑定 C++虚函数 虚函数表中的指针需要绑定 全局变量 指向其他符号的全局变量需要绑定 关于缓存机制： 系统动态库：Rebase/Bind 操作已在 dyld shared cache 中预先完成，不会在 App 启动时执行 App 动态库：dyld 3 的 Launch Closure 会缓存 Rebase/Bind 的元数据信息（哪些指针需要修正、修正方式等），但 Rebase/Bind 操作本身仍需每次启动时执行，因为 ASLR slide 每次启动都不同 因此，减少 ObjC 类、Category、C++ 虚函数等仍然是有效的优化手段。 ...

浏览器的垃圾回收（Garbage Collection, GC）机制是前端性能优化和内存管理的重要基础。 一、垃圾回收的基本概念 目的：自动回收不再使用的内存，避免内存泄漏，保证浏览器性能稳定。 GC 触发：当浏览器检测到内存不足或特定条件时，启动垃圾回收过程。 二、主要垃圾回收算法 1. 标记清除（Mark-and-Sweep） 浏览器从**根对象（Global、执行上下文中的变量）**开始，标记所有可达对象。 没被标记的对象被认为不可达，即不再被使用，进行回收。 是现代 JS 引擎普遍采用的算法。 2. 引用计数（Reference Counting） 每个对象维护引用计数，引用增加时计数+1，引用消失时计数-1。 计数为 0 的对象立即回收。 缺陷：无法处理循环引用，现代引擎一般不单独使用。 三、垃圾回收的触发时机 内存分配达到一定阈值时自动触发。 主动调用相关接口（如 Chrome DevTools 手动触发）。 页面卸载时进行清理。 四、内存泄漏常见原因 全局变量未释放 全局变量一直被引用，无法回收。 闭包导致的变量无法释放 闭包作用域内变量被外部引用。 定时器未清除 setInterval、setTimeout 未正确清除，导致引用保留。 DOM 节点引用未释放 JS 中持有对已删除 DOM 的引用。 事件监听未移除 绑定事件后，未及时解绑，导致内存无法回收。 五、性能优化建议 避免不必要的全局变量。 使用完定时器及时清除。 解绑不再使用的事件监听。 谨慎使用闭包，避免无用变量持久存在。 小心操作 DOM，及时释放引用。 常见考点 面试中考察点主要包括 GC 的原理、算法、触发时机、内存泄漏原因及避免方法： 浏览器垃圾回收的原理和常见算法？ 标记清除与引用计数的区别与优缺点？ 什么是内存泄漏？常见的内存泄漏类型？ 如何避免内存泄漏？ JS 引擎如何判断对象是否可回收？ 浏览器中 GC 触发的时机？ 如何用 Chrome DevTools 监测内存泄漏？ 事件监听和闭包如何导致内存泄漏？

didFinishLaunchingWithOptions是main阶段的核心入口，在这里初始化大量SDK和服务会阻塞启动。本文介绍如何优化这个阶段的耗时。 问题分析 典型的问题代码： func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { // 所有初始化都在主线程同步执行 CrashReporter.setup() Analytics.setup() PushNotification.setup() NetworkManager.setup() DatabaseManager.setup() ImageCache.setup() AdSDK.setup() SocialSDK.setup() // ... 更多SDK return true } 这种写法的问题： 所有初始化都在主线程同步执行 无论是否需要，所有SDK都在启动时初始化 阻塞首帧渲染 优化方案 方案1：分级启动任务管理 将启动任务按优先级分类，只在启动时执行必要的任务： // 启动任务优先级 enum LaunchTaskPriority { case required // 必须在首帧前完成 case high // 首帧后立即执行 case normal // 首屏稳定后执行 case low // 空闲时执行 } // 启动任务管理器 class LaunchTaskManager { static let shared = LaunchTaskManager() private var tasks: [LaunchTaskPriority: [() -> Void]] = [:] func register(priority: LaunchTaskPriority, task: @escaping () -> Void) { if tasks[priority] == nil { tasks[priority] = [] } tasks[priority]?.append(task) } func executeRequiredTasks() { tasks[.required]?.forEach { $0() } } func executeHighPriorityTasks() { DispatchQueue.main.async { self.tasks[.high]?.forEach { $0() } } } func executeNormalTasks() { DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tasks[.normal]?.forEach { $0() } } } func executeLowPriorityTasks() { // 监听RunLoop空闲时执行 CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopDefaultMode) { self.tasks[.low]?.forEach { $0() } } } } 使用示例 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { let manager = LaunchTaskManager.shared // 必须在首帧前完成 manager.register(priority: .required) { CrashReporter.setup() // 崩溃收集必须最先初始化 } // 首帧后立即执行 manager.register(priority: .high) { Analytics.setup() PushNotification.setup() } // 首屏稳定后执行 manager.register(priority: .normal) { AdSDK.setup() SocialSDK.setup() } // 空闲时执行 manager.register(priority: .low) { PreloadManager.preloadResources() } // 只执行必须的任务 manager.executeRequiredTasks() return true } 任务分级建议 优先级 适用场景 示例 required 崩溃收集、核心功能依赖 Crash SDK、必要的配置加载 high 用户可能很快用到 推送、统计、网络配置 normal 非首屏功能 广告SDK、社交分享 low 预加载、缓存 图片预加载、数据预热 方案2：并行初始化 将无依赖关系的初始化任务并行执行： ...

浏览器的存储机制涵盖多种技术，目的是满足 Web 应用在不同场景下的数据持久化、缓存和离线访问需求。它们各自具有不同的存储容量、生命周期、安全策略和访问方式，理解这些机制对于构建高效、安全的前端应用至关重要。 一、浏览器存储机制分类 1. Cookie 最早期的存储机制，主要用于会话管理和身份认证。 容量限制：单个约 4KB，总数有限制； 生命周期：可设置过期时间或为会话级； 访问方式：由浏览器自动在 HTTP 请求头中携带，也能通过 JS 访问（除非设置 HttpOnly）； 安全性：可设置 HttpOnly、Secure、SameSite 防范安全风险。 2. Web Storage（LocalStorage 和 SessionStorage） HTML5 新增的简单键值对存储方案。 LocalStorage：永久存储，关闭浏览器数据仍保留，同源可访问； SessionStorage：页面会话存储，关闭标签页即清空； 容量：一般为 5~10MB； 访问方式：同步 API，容易使用但可能阻塞主线程。 3. IndexedDB 浏览器内置的底层结构化数据库，支持事务和索引，适合复杂和大容量数据存储。 容量：远大于 LocalStorage，通常以设备剩余空间为限； 访问方式：异步 API，支持复杂操作； 用途：离线应用、大数据缓存、文件存储等。 4. Cache Storage 由 Service Worker 管理的请求和响应缓存，用于离线和加速访问。 容量：较大，依赖设备和浏览器策略； 访问方式：异步 Promise API； 用途：缓存静态资源、接口响应，实现离线支持。 5. Service Worker 虽然不是存储机制本身，但作为浏览器后台代理进程，管理 Cache Storage，实现网络请求拦截和缓存策略，是现代离线应用的核心。 生命周期独立于页面，可在后台运行； 控制页面的网络请求，提供离线能力和资源预缓存； 可结合 Cache Storage 和 IndexedDB 进行数据管理。 二、存储机制的生命周期与访问作用域 Cookie：基于域和路径，可设置 HttpOnly、Secure 限制访问； LocalStorage/SessionStorage：基于同源策略，SessionStorage 进一步限定于标签页会话； IndexedDB 和 Cache Storage：基于同源，支持版本控制和升级； Service Worker：独立于页面，能控制同源下的所有相关页面。 三、容量限制与性能影响 Cookie 容量最小，且会随每次请求自动发送，影响网络性能； LocalStorage/SessionStorage 适合轻量存储，容量适中； IndexedDB 和 Cache Storage 容量大，适合海量数据和文件缓存； Service Worker 通过异步调度，避免阻塞主线程。 四、安全与隐私考虑 Cookie 可被服务器访问，设置 HttpOnly 避免脚本窃取； Web Storage、IndexedDB 只能由同源脚本访问，防止跨站数据泄漏； Service Worker 需 HTTPS 环境，避免被恶意注入； 用户隐私模式下，存储行为可能受限，数据不保证持久。 五、应用场景及选择建议 需要与服务器频繁交互、会话维持时用 Cookie； 存储简单配置、少量数据用 LocalStorage； 页面会话临时数据用 SessionStorage； 大规模结构化数据和离线存储用 IndexedDB； 静态资源及请求缓存用 Cache Storage，配合 Service Worker 提升离线体验和性能； Service Worker 负责管理缓存和拦截网络请求，实现 PWA 功能。 常见考点 面试考察点通常围绕存储类型、特点、使用场景、容量限制、安全性和生命周期展开： ...

+load方法是ObjC运行时在类被加载时自动调用的方法，所有+load方法在main函数之前同步执行，会阻塞启动。 问题分析 +load方法的特点： 特性 说明 调用时机 main函数之前，ObjC Runtime初始化时 调用顺序 父类 → 子类 → Category 线程 主线程，同步执行 影响 直接阻塞启动 // 问题代码：+load中执行耗时操作 @implementation HeavyModule + (void)load { // 耗时操作会阻塞启动 [self setupDatabase]; [self preloadResources]; [self registerServices]; } @end +load与+initialize的区别 特性 +load +initialize 调用时机 main之前 类首次使用时 调用次数 只调用一次 可能多次（子类触发） 是否阻塞启动 是 否 线程安全 是 是 调用顺序 父类→子类→Category 父类→子类 更详细的对比请参考：+load与+initialize的区别 优化方案 方案1：使用+initialize替代 将+load中的逻辑迁移到+initialize，延迟到类首次使用时执行： @implementation HeavyModule // 优化前 + (void)load { [self setupDatabase]; } // 优化后 + (void)initialize { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ // 延迟到类首次使用时执行 [self setupDatabase]; }); } @end 注意：+initialize可能被子类触发多次调用，需要使用dispatch_once保证只执行一次。 ...

3D球场项目 (五) 把客户端的核心业务流 讲完了：Native 推送 → DataManager 队列 → ScenePlayer 章节调度 → GameController 状态机 → Handler → 渲染层。功能闭环跑通之后，真正的硬仗是 “工程化"和"性能”——前者保证 项目能稳定上线（编译跑通、退出不崩、Swift 调用顺手），后者保证在中低端机上画面流畅。 第一版上线时遇到了两类问题： 稳定性 / 工程化：modulemap 编译报错、lipo 架构冲突、A11 设备启动 crash、 Cocos 退出期 OpenAL 资源竞争 crash……这些都不是"画面卡"，但每一个都能让用户体验 归零； 性能：中端 iPhone 在比赛回合渲染期间，GPU 和 CPU 都偶尔抖到 80%+，帧率掉到 30 fps 出头。 本篇按这两类拆成两部分，所有改动都遵循一条原则：不动玩法，只把工程问题和帧时间 解决掉。 架构改动一览 3D球场项目 (二) 介绍过弹幕引擎的四层 架构（腾讯视频 APP / MagicDanmakuiOS / MagicDanmaku / cocos-engine）。这一阶段 每一层都动了——3D 球场不是单点改造，而是一次自上而下的纵贯。下面这张图是把 PartTwo 那张原始架构图重画一遍，改动的节点用蓝色、新增的节点用绿色， 没动的节点保持白色： ...

二进制重排是一种通过重新排列二进制文件中函数顺序来减少启动时Page Fault的优化技术。 基本原理 Page Fault问题 iOS使用虚拟内存管理，讨论Page Fault时需要先区分两层“内存”： 虚拟地址空间：进程看到的是一段连续的虚拟地址。App启动时，dyld会把Mach-O的__TEXT、__DATA等段映射到进程的虚拟地址空间里。这里的“映射”只是建立虚拟地址和文件偏移的关系，不代表整段二进制代码已经全部进入物理内存。 物理内存：CPU真正执行代码时，需要对应虚拟页背后有可用的物理页。代码页通常是文件映射页，第一次访问某个尚未驻留在物理内存中的代码页时，会触发Page Fault。内核再从App二进制文件中读取这个页的内容，填充到物理页，并更新页表。 所以，更准确地说：程序代码按页映射到虚拟地址空间；启动过程中实际执行到某个函数时，才会按需把该函数所在的代码页调入物理内存。Page Fault本身不是异常崩溃，而是虚拟内存按需调页的正常机制，只是冷启动时如果触发太多文件读取，会增加启动耗时。 默认情况下，编译器按照链接顺序排列函数，导致启动时调用的函数可能分散在不同的代码页中： 优化前（启动函数分散在不同代码页）： ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ Page 1 │ │ Page 2 │ │ Page 3 │ │ Page 4 │ │ func_A │ │ func_X │ │ func_B │ │ func_C │ │ ... │ │ ... │ │ ... │ │ ... │ └────────┘ └────────┘ └────────┘ └────────┘ 启动调用 A→B→C 会触达 Page 1, 3, 4。 如果这些代码页还没有驻留在物理内存中，就可能产生3次Page Fault。 二进制重排的效果 通过重排，将启动时调用的函数集中排列在相邻的代码页中： ...