工程化 on Last Stand

编译优化-Bazel方案

Sat, 02 May 2026 22:32:27 +0800

当 iOS 工程的规模突破 CocoaPods / Xcode 原生构建体系的舒适区，Bazel 就成为下一代构建系统的首选。字节跳动的头条、抖音、Airbnb、Uber、Lyft、Pinterest、Square、Bilibili 等都已把 iOS 工程迁到 Bazel。本文介绍 Bazel 的核心原理、在 iOS 上的生态（rules_apple / rules_swift / rules_xcodeproj）以及大厂落地实践。

为什么是 Bazel

CocoaPods + Xcode 在超大工程上的固有瓶颈：

粗粒度依赖：以 Pod / Target 为单位，增量编译颗粒粗
隐式依赖：Build Phases 隐含顺序，难以沙箱化
难以远程缓存：编译环境非 hermetic，hash 易变
难以远程执行：Xcode Build System 绑定本地 macOS

Bazel 针对这些问题从设计之初就提供了：

能力	Bazel	Xcode/CocoaPods
依赖粒度	文件级	Target 级
依赖显式化	必须声明	部分隐式
Sandbox	默认开启	无
远程缓存	原生	需第三方（ccache/Rugby）
远程执行	原生	不支持
跨语言	一流（Swift/OC/C++/Go/Rust/JS）	主要 Apple 平台
多平台	天生	iOS/macOS 为主

Bazel 核心概念

Workspace 与 Package

WORKSPACE # 仓库根，声明外部依赖
foo/
├── BUILD.bazel # package，本目录的构建声明
├── main.swift
└── util/
 └── BUILD.bazel # 子 package

Workspace：整个 Bazel 仓库，一个 WORKSPACE 文件一个仓
Package：任何包含 BUILD.bazel 的目录
Target：BUILD 文件里的一个 rule 调用，比如 swift_library(name = "foo")
Label：Target 的全局 ID，形如 //foo/util:util

Rule

Rule 是构建函数，输入 sources + deps，输出 artifacts：

前端模块化

Sat, 05 Oct 2024 00:00:00 +0800

一、模块化的理解

1.什么是模块?

将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并进行组合在一起
块的内部数据与实现是私有的, 只是向外部暴露一些接口(方法)与外部其它模块通信

2.模块化的进化过程

全局function模式 : 将不同的功能封装成不同的全局函数
- 编码: 将不同的功能封装成不同的全局函数
- 问题: 污染全局命名空间, 容易引起命名冲突或数据不安全，而且模块成员之间看不出直接关系

function m1(){
 //...
}
function m2(){
 //...
}

namespace模式 : 简单对象封装
- 作用: 减少了全局变量，解决命名冲突
- 问题: 数据不安全(外部可以直接修改模块内部的数据)

let myModule = {
 data: 'www.baidu.com',
 foo() {
 console.log(`foo() ${this.data}`)
 },
 bar() {
 console.log(`bar() ${this.data}`)
 }
}
myModule.data = 'other data' //能直接修改模块内部的数据
myModule.foo() // foo() other data

这样的写法会暴露所有模块成员，内部状态可以被外部改写。

IIFE模式：匿名函数自调用(闭包)
- 作用: 数据是私有的, 外部只能通过暴露的方法操作
- 编码: 将数据和行为封装到一个函数内部, 通过给window添加属性来向外暴露接口
- 问题: 如果当前这个模块依赖另一个模块怎么办?

// index.html文件
<script type="text/javascript" src="module.js"></script>
<script type="text/javascript">
 myModule.foo()
 myModule.bar()
 console.log(myModule.data) //undefined 不能访问模块内部数据
 myModule.data = 'xxxx' //不是修改的模块内部的data
 myModule.foo() //没有改变
</script>

// module.js文件
(function(window) {
 let data = 'www.baidu.com'
 //操作数据的函数
 function foo() {
 //用于暴露有函数
 console.log(`foo() ${data}`)
 }
 function bar() {
 //用于暴露有函数
 console.log(`bar() ${data}`)
 otherFun() //内部调用
 }
 function otherFun() {
 //内部私有的函数
 console.log('otherFun()')
 }
 //暴露行为
 window.myModule = { foo, bar } //ES6写法
})(window)

最后得到的结果：

编译优化-CocoaPods优化

Sat, 02 May 2026 22:32:27 +0800

在 iOS 生态中，CocoaPods 依然是大多数中大型工程的依赖管理工具。当 Pod 数量达到几百个子组件上千个时，pod install 的耗时会变成研发流程里的硬性卡点。抖音在其 seer-optimize 项目中系统化地优化了 CocoaPods 的整个生命周期，全量 Pod Install 耗时减少 50%、增量减少 65%。本文系统介绍这些优化背后的原理。

关于 CocoaPods 整体架构的深度介绍可以参考 CocoaPods源码导读-架构总览。

Pod Install 耗时构成

Installer#install! 的六个阶段：

flowchart LR
A[prepare] --> B[resolve_dependencies]
B --> C[download_dependencies]
C --> D[validate_targets]
D --> E[generate_pods_project]
E --> F[integrate_user_project]

抖音公开的典型耗时分布：

阶段	典型耗时	说明
prepare	< 0.01s	初始化
resolve_dependencies	数秒到数分钟	依赖决议，瓶颈
download_dependencies	数秒到数分钟	依赖下载，IO 密集
validate_targets	0.1s	校验
generate_pods_project	数秒到数十秒	生成 xcodeproj
integrate_user_project	0.01s	集成主工程

resolve_dependencies 优化

Source 仓库更新

默认 CocoaPods 在 pod install --repo-update 时会更新所有 source 仓库。抖音改造为：

Webpack与Vite

Sat, 05 Oct 2024 00:00:00 +0800

前言

vite比webpack快？

vite比webpack简单？

今天我们就来分析一下，到底有什么不一样的地方！

定位

对比之前，我们先要搞懂，vite与webpack的定位以及关系才可以。

那前端社区中常谈到的这些工具webpack、rollup、parcel、esbuild、vite、vue-cli、create-react-app、umi他们之间的关系是怎样的。

webpack、rollup、parcel、esbuild都是打包工具，代码写好之后，我们需要对代码进行压缩、合并、转换、分割、打包等操作，这些工作需要打包工具去完成。
vue-cli、create-react-app、umi 是基于webpack的上层封装，通过简单的配置就可以快速创建出一个项目，把更多的时间放在业务开发上。
vite开发环境依赖esbuild进行预构建，生产环境则依赖rollup进行打包，并且充分利用了现代浏览器的特性，比如http2、ES module，vite是站在众多巨人肩膀上的一个产物，类似webpack + webpack-dev-server的结合体，是一个非常棒的前端项目的构建工具。

运行原理

首先，我们从运行原理上分析一下，vite为什么比webpack快。

webpack运行原理

当我们使用webpack启动项目时，webpack会根据我们配置文件（webpack.config.js）中的入口文件（entry），分析出项目项目所有依赖关系，然后打包成一个文件（bundle.js），交给浏览器去加载渲染。

这样就会带来一个问题，项目越大，需要打包的东西越多，启动时间越长。

关于ES module

在讲vite运行原理之前，我们先说一下ES module

目前，绝大多数现代浏览器都已经支持ES module了，我们只需要在<script>标签中添加type="module"，就可以使用ES module了。

下面这段代码是可以直接在浏览器中运行的。

// test.js
export default function hello() {
  console.log('hello world');
}

// index.html
<script type="module">
  import hello from './test.js';

  hello(); // hello world
</scirpt>

vite运行原理

在<script type="module">中，浏览器遇到内部的import引用时，会自动发起http请求，去加载对应的模块。

vite也正是利用了ES module这个特性，使用vite运行项目时，首先会用esbuild进行预构建，将所有模块转换为es module，不需要对我们整个项目进行编译打包，而是在浏览器需要加载某个模块时，拦截浏览器发出的请求，根据请求进行按需编译，然后返回给浏览器。

这样一来，首次启动项目（冷启动）时，自然也就比webpack快很多了，并且项目大小对vite启动速度的影响也很小。

构建方式

我们再来看一下，vite与webpack在项目构建上有哪些区别。

webpack

webpack是基于nodejs运行的，但js只能单线程运行，无法利用多核CPU的优势，当项目越来越大时，构建速度也就越来越慢了。

vite

vite预构建与按需编译的过程，都是使用esbuild完成的。

esbuild是用go语言编写的，可以充分利用多核CPU的优势，所以vite开发环境下的预构建与按需编译速度，都是非常快的。

http2

vite充分利用了http2可以并发请求的优势，这也是速度快的一个主要原因。接下来，我们了解一下http2的来龙去脉。

在之前http1的时候，浏览器对同一个域名的请求，是有并发限制的，一般为6个，如果并发请求6个以上，就会造成阻塞问题，所以在http1的时代，我们要减少打包产物的文件数量，减少并发请求，来提高项目的加载速度。

2015年以后，http2出现了，他可以并发发送多个请求，不会出现http1的并发限制。这时候，将打包产物分成多个小模块，并行去加载，反而会更快。

vite也充分利用了这一优势，对项目资源进行了合理的拆分，访问项目时，同时加载多个模块，来提升项目访问速度。

热更新

vite速度快的另一个原因是与webpack不同的热更新机制。

编译优化-Explicit Modules

Tue, 05 May 2026 00:41:41 +0800

Apple 从 Xcode 15 开始在 Swift 上引入 Explicit Modules，Xcode 16 在 C/C++/Objective-C 上全面铺开，Xcode 17 进一步默认启用并与细粒度依赖追踪结合。这是近五年 Apple 构建系统最重要的一次变革，直接影响到大部分项目的编译模型。

模块（Module）基础

为什么需要模块

C 家族语言的 #include 机制有两个致命问题：

文本替换：头文件是纯文本替换，每个源文件都要重新解析一遍所有包含的头文件
宏污染：先引入的头文件宏会影响后续头文件的行为，没有隔离

Clang 在 2012 年引入 Clang Modules，用一个预编译的二进制模块（.pcm）替代文本包含，同一 module 在一次构建里只解析一次。Swift 的 .swiftmodule 从设计之初就是模块化的。

flowchart LR
A["源文件"] -->|"include 头文件"| B["Foundation.h 文本"];
B --> C["每次都重新解析"];
D["源文件"] -->|"@import Foundation"| E["Foundation.pcm 预编译"];
E --> F["一次解析，多次复用"];

模块的组成

类型	载体	描述
Clang Module	`.pcm`	C/OC 模块的序列化 AST
Swift Module	`.swiftmodule`	Swift 模块的接口 + SIL
Swift Interface	`.swiftinterface`	可被不同 Swift 版本解析的文本接口
Module Map	`module.modulemap`	描述哪些头文件构成某个 module

Implicit Modules 的问题

原理

在 Xcode 16 之前，Clang Modules 以隐式方式工作：

任务自动化

Sat, 05 Oct 2024 00:00:00 +0800

在前端开发中，我们经常需要执行各种重复性任务，比如编译代码、启动本地服务器、监听文件变化、运行测试、部署代码等。虽然可以使用不同的工具来完成这些任务，但npm本身提供了一个强大的功能：npm scripts。通过npm scripts，我们可以将这些任务脚本化并集中管理，从而提高开发效率。本文将专注于如何使用npm scripts自动化前端开发任务，以及它在项目管理中的作用。

什么是`npm scripts`？

npm scripts是npm提供的一种机制，允许我们在项目的package.json文件中定义一组命令，方便执行各种任务。在package.json文件中，scripts字段可以包含多个脚本，每个脚本都是一个键值对，其中键是脚本的名称，值是实际要执行的命令。例如：

{
 "scripts": {
 "build": "webpack --config webpack.config.js",
 "test": "jest"
 }
}

在上面的示例中，定义了两个脚本：build 和 test。可以通过以下方式在命令行中运行这些脚本：

npm run build
npm run test

npm会执行对应的命令，自动帮我们完成编译和测试任务。

为什么使用`npm scripts`？

在现代前端开发流程中，自动化任务是不可或缺的，而npm scripts的使用有以下几大优势：

减少对全局依赖的需求：在传统项目中，开发者通常需要全局安装各种命令行工具，如webpack、eslint、babel等。而npm scripts可以直接调用项目的本地依赖，无需全局安装。这确保了不同开发环境中的工具版本一致，减少了版本冲突和兼容性问题。
集中管理任务：npm scripts将所有任务定义集中在package.json文件中，项目中的所有开发人员都可以直观地看到可用的任务列表，无需了解每个工具的详细使用方法。只需运行npm run <task>，便可一键完成常见任务。
支持跨平台执行：npm scripts中的命令可以跨平台使用，在Windows、macOS和Linux系统上表现一致，尤其适合团队协作。
便于组合和链式执行：npm允许通过逻辑操作符来组合脚本，实现复杂任务的自动化执行。例如可以通过&&和||来串联多个任务，使得多个步骤一次完成。

如何定义和使用`npm scripts`？

让我们通过具体的示例来看看npm scripts如何自动化前端开发任务。

1. 设置基本的开发任务

假设我们正在开发一个React项目，我们可以在package.json中定义以下基本任务：

{
 "scripts": {
 "start": "webpack serve --mode development",
 "build": "webpack --mode production",
 "test": "jest",
 "lint": "eslint src/**/*.js"
 }
}

这里的脚本分别执行以下任务：

编译优化-Swift编译优化

Sat, 02 May 2026 22:32:27 +0800

Swift 的类型推导、泛型约束求解、WMO / CMO 是编译性能的核心影响因素。理解它们能让源码层面的小改动带来显著的编译加速。本文聚焦"代码写法 + 编译开关"两方面的优化。

Swift 编译流程速览

相比 C/OC，Swift 编译多出大量工作：

flowchart LR
A[Parse] --> B[Sema
类型检查]
B --> C[SILGen
生成 SIL]
C --> D[SIL Optimization]
D --> E[IRGen
LLVM IR]
E --> F[LLVM Optimization]
F --> G[CodeGen]

其中 Sema（语义分析） 阶段负责类型推导，是 Swift 特有的性能热点。-debug-time-compilation 看到的 “Type checking” 时间基本都集中在这里。

类型推导与 “Too Complex” 错误

约束求解

Swift 的类型系统比大多数语言复杂：

函数重载 + 运算符重载
隐式字面量类型（Int、Double、Float80…）
泛型 + 协议 + 关联类型
闭包参数类型推导
SwiftUI 风格的 ViewBuilder / Result Builders

遇到表达式 let x = a + b * c - d，编译器需要给 + * - 每个运算符枚举所有可能的重载，在多个候选里做约束传播。当候选组合爆炸时，Sema 会放弃并抛出：

前端构建工具详解

Thu, 07 Aug 2025 00:00:00 +0800

谈到构建工具，大家首先想到的肯定就是 Webpack 以及现在最🔥的 Vite。 Webpack，功能强大，生态丰富，从面世到今天，一直是很受大家欢迎；Vite 采用 unbundle 构建模式，带来了极致的开发体验，给开发人员以新的选择。

在这两个构建工具之外，还有其他的构建工具，如和 Webpack、Vite 类似的 Rollup、Parcel、Esbuild，自动化构建工具 grunt、gulp，以及更加久远的 YUI Tool。

这些工具的存在，构成了前端构建工具的发展史。

YUI Tool + Ant

YUI tool 是 07 年左右出现的一个构建工具，功能比较简单，用于压缩混淆 css 和 js 代码，需要配合 java 的 Ant 使用。

当时 web 应用开发主要采用 JSP，还不像现在这样前后端分离，通常是由 java 开发人员来编写 js、css 代码，前端代码都是和后端 java 代码放在一起的。因此前端代码的压缩混淆也就基于 java 实现了。

Grunt / Gulp

Grunt / Gulp 都是运行在 node 环境上的自动化工具。

在开发过程中，我们可以将一些常见操作如解析 html、es6 代码转换为 es5、less / sass 代码转换为 css 代码、代码检查、代码压缩、代码混淆配置成一系列任务，然后通过 Grunt / Gulp 自动执行这些任务。

Grunt 和 Gulp 的不同点：

编译优化-Xcode构建系统

Sat, 02 May 2026 22:32:27 +0800

Xcode 的构建系统由多个组件协同完成，从 Cmd+B 到生成 .app 经历了完整的任务图构建、依赖分析、并行调度流程。理解这套体系是后续一切优化的基础。

构建系统组成

Xcode 10 之后默认采用 Swift Build System（基于 llbuild），整体架构如下：

flowchart TD
A[Xcode IDE] --> B[XCBBuildService
Daemon]
B --> C[Build Description
任务图 JSON]
C --> D[llbuild
调度内核]
D --> E1[Swift Driver / swiftc]
D --> E2[clang]
D --> E3[ld / ld-prime]
D --> E4[actool / ibtool / 脚本]
E1 & E2 & E3 & E4 --> F[产物缓存]

组件	职责
`XCBBuildService`	独立进程，为 Xcode / xcodebuild 提供构建 RPC 服务
Build Description	根据 Scheme、Target、Build Settings 生成的任务图
`llbuild`	通用构建引擎，执行任务图、做增量与并行调度
`swift-driver`	Swift 编译驱动，生成 frontend job 并驱动 swiftc
`clang` / `swift-frontend`	真正的编译器前端
`ld` / `ld-prime`	链接器

XCBBuildService

Xcode 和 xcodebuild 都是客户端，真正的构建逻辑在 XCBBuildService 这个独立进程。它通过 XPC 接收请求，生成并执行任务。社区工具 XCBBuildServiceProxy 利用这一架构在中间插一层代理，实现自定义构建（Bazel、远程执行等）。字节 BitSky、Tuist Cloud 都基于此类模式。

前端任务自动化（npm scripts实现）

Thu, 07 Aug 2025 00:00:00 +0800

在前端开发中，我们经常需要执行各种重复性任务，比如编译代码、启动本地服务器、监听文件变化、运行测试、部署代码等。虽然可以使用不同的工具来完成这些任务，但npm本身提供了一个强大的功能：npm scripts。通过npm scripts，我们可以将这些任务脚本化并集中管理，从而提高开发效率。

本文将专注于如何使用npm scripts自动化前端开发任务，以及它在项目管理中的作用。

什么是`npm scripts`？

{
 "scripts": {
 "build": "webpack --config webpack.config.js",
 "test": "jest"
 }
}

在上面的示例中，定义了两个脚本：build 和 test。可以通过以下方式在命令行中运行这些脚本：

npm run build
npm run test

npm会执行对应的命令，自动帮我们完成编译和测试任务。

为什么使用`npm scripts`？

在现代前端开发流程中，自动化任务是不可或缺的，而npm scripts的使用有以下几大优势：

减少对全局依赖的需求：在传统项目中，开发者通常需要全局安装各种命令行工具，如webpack、eslint、babel等。而npm scripts可以直接调用项目的本地依赖，无需全局安装。这确保了不同开发环境中的工具版本一致，减少了版本冲突和兼容性问题。
集中管理任务：npm scripts将所有任务定义集中在package.json文件中，项目中的所有开发人员都可以直观地看到可用的任务列表，无需了解每个工具的详细使用方法。只需运行npm run <task>，便可一键完成常见任务。
支持跨平台执行：npm scripts中的命令可以跨平台使用，在Windows、macOS和Linux系统上表现一致，尤其适合团队协作。
便于组合和链式执行：npm允许通过逻辑操作符来组合脚本，实现复杂任务的自动化执行。例如可以通过&&和||来串联多个任务，使得多个步骤一次完成。

如何定义和使用`npm scripts`？

让我们通过具体的示例来看看npm scripts如何自动化前端开发任务。

1. 设置基本的开发任务

假设我们正在开发一个React项目，我们可以在package.json中定义以下基本任务：

{
 "scripts": {
 "start": "webpack serve --mode development",
 "build": "webpack --mode production",
 "test": "jest",
 "lint": "eslint src/**/*.js"
 }
}

这里的脚本分别执行以下任务：

3D球场项目 (六)：客户端工程化与优化

Sun, 31 May 2026 09:00:00 +0800

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 那张原始架构图重画一遍，改动的节点用蓝色、新增的节点用绿色，没动的节点保持白色：

编译优化-二进制化

Sat, 02 May 2026 22:32:27 +0800

二进制化是大型 iOS 工程编译加速的"银弹"：把组件从源码编译改成预编译产物链接，在本地无需再跑 Swift/Clang 前端，直接链接已有的 .a / .framework / .xcframework。美团在 cocoapods-hmap-prebuilt 之外，还通过二进制化把整体编译速度提升 50%+。本文系统介绍二进制化的原理、实现方式与工具链。

为什么能加速

典型项目的编译时间分布（抖音量级）：

pie title 冷编译耗时占比
"业务代码编译" : 25
"第三方依赖编译" : 50
"链接" : 15
"其他" : 10

超过一半的时间都花在编译 “不会改” 的依赖上。把依赖预编译成二进制，本地只需要链接，这部分耗时直接归零。再配合远程缓存，第一次拉代码的同学也能命中他人产物。

二进制产物形态

静态库（.a）

最传统的形态：

libSDWebImage.a
SDWebImage/Headers/
├── SDWebImage.h
└── ...

特点：

最小体积，Mach-O 里没有 LC_SEGMENT_64 / LC_LOAD_DYLIB 负担
启动最快，无 dyld 成本
静态链接时整合到主可执行
不支持资源文件（需要单独管理 bundle）

Framework（.framework）

Apple 推荐的打包形态：

SDWebImage.framework/
├── SDWebImage # 二进制（静态或动态）
├── Headers/ # 公开头文件
├── Modules/ # modulemap、swiftmodule
│ ├── module.modulemap
│ └── SDWebImage.swiftmodule/
│ ├── arm64-apple-ios.swiftmodule
│ └── arm64-apple-ios.swiftinterface
└── Info.plist

通过 Mach-O Type 设置决定内部是静态还是动态库：

代码规范工程化

Thu, 07 Aug 2025 00:00:00 +0800

规范化是前端工程化的一个重要部分。现在，有许多工具能够辅助我们实行代码的规范化,比如你一定知道的 ESLint 和 Prettier。

今天，来聊聊这些工具的工作原理和基本使用，了解它们是如何发挥作用的，以及如何更好地利用这些工具去规范项目的代码。

1. ESlint - 检查你的 JavaScript 代码

让我们先从知名度最高的 ESLint 开始。

1.1. ESLint 及其作用

Lint 是一类专门用于检查代码的工具软件，也称 linter。ESLint ，即 JavaScript （ECMAScript）代码的检查工具。

正如官网的介绍 —— “Find and fix problems in your JavaScript code”，ESLint 能够辅助查找出你的 JavaScript 代码中的问题，包括：

代码风格问题（styles）。比如，运算符两边的空格、语句末尾的分号。
不好的写法。比如，使用 == 进行比较而不是 ===。
可能存在逻辑问题的代码模式。比如，定义了一个变量，但没有使用到它。

此外，ESLint 还能够帮你自动修复一些简单的问题。

我们将在下一小结学习如何使用 ESLint 检查我们的 JavaScript 代码，并修复其中的一些问题。

1.2. ESLint 快速上手

为了在项目中使用 ESLint，需要先安装它。

# 初始化一个 npm 项目
mkdir eslint-test
cd eslint-test
npm init -y
# 安装 eslint
npm init @eslint/config

回答一系列问题后，你可以看目录中的配置文件 .eslintrc.js，这个配置文件告诉 ESLint 如何去解析项目，这个项目采用了哪些规范和规则。

编译优化-二进制化实现原理

Fri, 08 May 2026 22:56:38 +0800

本文结合 cocoapods-bin（社区最成熟的二进制化插件）拆解"Pod 二进制化"背后的工程机制：集成时如何透明替换 spec、打包时如何还原 Xcode 产物、调试时如何跳回源码。文末给出"自研一套二进制系统"的落地 checklist。

想先了解二进制化的整体背景、坑点和适用场景，可以先看编译优化-二进制化；想了解 pod install 阶段本身的优化（HMap、并发下载等）见编译优化-CocoaPods优化。

总体架构

一套完整的 Pod 二进制化系统由三层组成：

flowchart TB
subgraph CI[打包 CI]
A1[源码 podspec] --> A2[壳工程 pod install]
A2 --> A3[xcodebuild 双 SDK 编译]
A3 --> A4[lipo / create-xcframework]
A4 --> A5[上传 OSS]
A5 --> A6[生成 binary podspec]
A6 --> A7[push 到二进制仓]
end
subgraph Dev[开发机 pod install]
B1[Podfile 声明 plugin] --> B2[Resolver/LazySpecification Hook]
B2 --> B3{二进制仓
是否有该版本?}
B3 -- 是 --> B4[替换为 binary spec]
B3 -- 否 --> B5[回退源码 spec]
B4 --> B6[pod download zip]
B5 --> B6
B6 --> B7[Xcode 链接]
end
subgraph Debug[调试]
C1[dwarfdump 读取
DW_AT_comp_dir] --> C2[下载源码]
C2 --> C3[软链到 DWARF 路径]
C3 --> C4[LLDB 自动跳转源码]
end
A7 --> B3
A3 -.DWARF 路径信息.-> C1

关键设计点：

版本控制

Thu, 07 Aug 2025 00:00:00 +0800

什么是版本控制

版本控制是一种系统性的方法，用于管理和跟踪软件开发项目中的代码、文件和资源。它的核心目标是在不同时间点的开发中保持代码的一致性、可追溯性和可维护性。

为什么要做版本控制

这个问题可以从定义中的关键词可以看出端倪：不同时间点下的代码一致性、可追溯性、可维护性。这里额外补充一点：当今的互联网开发早已步入敏捷迭代，各种动态化方案层出不穷都有着顺应时代潮流的意思，因此软件开发一定会越来越多地涉及到团队开发，团队之间的协作也一定需要这样一个机制去保障稳定性。

代码一致性

版本控制系统允许开发人员有效地管理和组织项目中的代码。它跟踪每个文件的历史记录，记录了每个版本的变更，包括谁做了什么修改、何时以及为什么。

可追溯性

版本控制系统允许为重要的里程碑或发布创建标签（tag），以便轻松识别和回滚到特定版本。

并且当某个版本的代码出现问题，版本控制系统允许开发人员轻松地回滚到之前的稳定版本，并在不破坏其余代码的情况下进行修复。

可维护性

开发人员可以创建分支（branch），这是一个独立的代码副本，用于开发新功能、修复错误或进行实验性工作。然后，这些分支可以与主代码库合并，以实现功能集成。

团队协作

在多人协作的环境中，不同开发者可能同时修改代码。版本控制系统确保不同的修改不会互相冲突，以及如何解决冲突。

版本控制系统促进了团队之间的协作，可以通过代码审查工具进行代码审查，以确保代码质量和一致性。

版本控制工具`Git`

`Git`的安装

`WIndows`

访问 Git官网，选择对应的操作系统下载即可。

这里下载独立安装包即可

点install就行，会自动安装一个git GUI工具，但通常不会直接用它

下载完成安装即可，输入以下命令验证安装是否成功

git version

图形化工具

安装

这里推荐TortoiseGit这个工具，非常方便。但我觉得Git本身学习成本并不高，GUI工具更多是为了提升效率，基本的Git知识点还是需要掌握的。

下载本体

然后是语言包

安装时一路next即可，安装完本体后再安装语言包。

配置好Github的账户、邮箱、秘钥等，注意配置好了密钥也不会在下述部分显示，可以打开编辑全局进行查看

使用

在使用之前先提前补充一个点（后续会详细介绍），Git有本地仓库和远端仓库的概念，通常支持HTTPS和SSH两种协议进行关联，两种方式优缺点也十分明显：

HTTPS：无需额外配置，但是在每次连接远端仓库时需要输入账号密码进行校验。
SSH：生成一组密钥对，需要本地进行配置，好处是配置好后每次连接远端仓库时会自动比较密钥对，无需额外校验。关于SSH详细可以参考这篇文章ssh-远程登录协议

为了一劳永逸，我们这里配置下SSH，首先打开Git bash

# 输入下列命令，最后一个参数是您的邮箱
$ ssh-keygen -t rsa -C yourEmail.com

可以看到密钥对已经生成了

进入上述目录，注意.ssh文件夹默认是隐藏的，直接访问路径就行

以Github为例，配置公钥

创建一个Demo项目，平时学习的话就创建公有项目就行

复制一下我们的项目链接

选取一个你喜欢的目录作为本地工作区，然后按鼠标右键

编译优化-头文件与HMap

Sat, 02 May 2026 22:32:27 +0800

对以 Objective-C 为主或混编的 iOS 大型工程，头文件查找是一个被严重低估的编译开销点。美团的统计显示，400+ Pod 组件的工程会产生近 5 万个头文件，导致海量的 IO 操作和编译参数膨胀。Header Map（HMap）技术能把头文件查找从 O(n) 的目录扫描退化为 O(1) 的哈希查表。

头文件查找的代价

Clang 的查找流程

当 Clang 遇到 #import <AFNetworking/AFNetworking.h> 时：

flowchart TD
A[遇到 #import] --> B{是否系统头?}
B -- 是 --> C[SYSTEM_HEADER_SEARCH_PATHS]
B -- 否 --> D[USER_HEADER_SEARCH_PATHS]
C --> E[按顺序遍历 HEADER_SEARCH_PATHS]
D --> E
E --> F{路径下有吗?}
F -- 否 --> G[下一个路径]
G --> E
F -- 是 --> H[stat + open]
H --> I[解析头文件]

每一次查找都要对所有 HEADER_SEARCH_PATHS 执行 stat(2) 系统调用，当路径数量达到数千时，光 stat 就是显著开销。

包管理

Thu, 07 Aug 2025 00:00:00 +0800

现如今，前端开发的同学已经离不开 npm 这个包管理工具，其优秀的包版本管理机制承载了整个繁荣发展的NodeJS社区，理解其内部机制非常有利于加深我们对模块开发的理解、各项前端工程化的配置以加快我们排查问题（相信不少同学收到过各种依赖问题的困扰）的速度。

本文从三个角度：package.json、版本管理、依赖安装结合具体实例对 npm 的包管理机制进行了详细分析。

一、剖析 package.json

在 Node.js 中，模块是一个库或框架，也是一个 Node.js 项目。Node.js 项目遵循模块化的架构，当我们创建了一个 Node.js 项目，意味着创建了一个模块，这个模块必须有一个描述文件，即 package.json。它是我们最常见的配置文件，但是它里面的配置你真的有详细了解过吗？配置一个合理的 package.json 文件直接决定着我们项目的质量，所以首先带大家分析下 package.json 的各项详细配置。

1.1 必备属性

package.json 中有非常多的属性，其中必须填写的只有两个：name 和 version ，这两个属性组成一个 npm 模块的唯一标识。

npm包命名规则

name 即模块名称，其命名时需要遵循官方的一些规范和建议：

包名会成为模块url、命令行中的一个参数或者一个文件夹名称，任何非url安全的字符在包名中都不能使用，可以使用 validate-npm-package-name 包来检测包名是否合法。
语义化包名，可以帮助开发者更快的找到需要的包，并且避免意外获取错误的包。
若包名称中存在一些符号，将符号去除后不得与现有包名重复

例如：由于react-native已经存在，react.native、reactnative都不可以再创建。

如果你的包名与现有的包名太相近导致你不能发布这个包，那么推荐将这个包发布到你的作用域下。

例如：用户名 conard，那么作用域为 @conard，发布的包可以是@conard/react。

查看包是否被占用

name 是一个包的唯一标识，不得和其他包名重复，我们可以执行 npm view packageName 查看包是否被占用，并可以查看它的一些基本信息：

若包名称从未被使用过，则会抛出 404 错误：

另外，你还可以去 https://www.npmjs.com/ 查询更多更详细的包信息。

1.2描述信息

基本描述

{
 "description": "An enterprise-class UI design language and React components implementation",
 "keywords": [
 "ant",
 "component",
 "components",
 "design",
 "framework",
 "frontend",
 "react",
 "react-component",
 "ui"
 ]
}

description用于添加模块的的描述信息，方便别人了解你的模块。

编译优化-编译缓存

Fri, 08 May 2026 13:07:14 +0800

“已经编译过的东西不再编译一遍”——这是编译优化的基础原理。Xcode 的增量编译、CocoaPods 的二进制缓存、Bazel 的 Action Cache 都是不同层次的编译缓存。本文聚焦 ccache、Clang/Swift module cache、远程缓存等通用方案的原理与 iOS 落地。

缓存分层

缓存按命中粒度可以分为三个层次：

flowchart TD
A[编译缓存] --> B[编译器内部缓存
PCH/PCM/module cache]
A --> C[Action 级缓存
ccache/sccache]
A --> D[产物级缓存
framework/xcframework]
B --> B1[进程内复用模块]
C --> C1[按 .o 粒度缓存]
D --> D1[按 Pod/module 缓存]

层次	粒度	代表	命中率
编译器内部	frontend 解析结果	Clang ModuleCache、Swift Module Cache	高（本地）
Action	源文件 → 目标文件	ccache、sccache、Bazel	中（取决于参数稳定性）
产物	整个 Pod 或 module	cocoapods-bin、Rugby	高（版本号稳定）

Clang Module Cache

原理

Clang 的 @import / @_exported import 会把外部模块预编译成 .pcm，缓存到 ModuleCachePath：

持续集成/持续部署（CI/CD）

Thu, 07 Aug 2025 00:00:00 +0800

传统应用发布模式

开发人员：在开发环境完成代码编写，单元测试，测试通过后提交到代码仓库

运维人员：把项目部署到测试环境，供QA团队测试，测试通过后，部署生成环境

测试人员：进行测试，测试完成后通知运维部署生产环境

缺点

项目在早期就存在错误，但到最后集成的时候才发现
需要手动操作，易错率高
开发与运维需要及时沟通有了以上缺点，那么就有了CI/CD

CI/CD

持续集成(CI):

合并开发人员正在编写的所有代码
一天内进行多次合并和提交代码
从存储库或生产环境中进行构建和自动化测试，确保没有集成问题并及早发现任何问题

持续交付(CD):

可以通过将更改自动推送到发布系统来随时将软件发布到生产环境中
持续部署，并自动将更改推送到生产中

GitLab内置CI/CD

运行流水线任务

Job

在文件中可以定义一个或多个作业，每个作业具有唯一的名称，每个作业是独立执行的，每个作业至少包含一个script

stages：

用于定义作业可以使用的阶段，并且是全局定义，同一个阶段的作业并行运行，不同阶段按顺序运行

only：

用分支策略来限制jobs构建

script:

项目中package中的脚本

environment：

定义此作业完成部署的环境名称

下面是每个jobs的详细变量名

Keyword	Required	Description
script	yes	Runner执行的命令或脚本
image	no	所使用的docker镜像，查阅使用docker镜像
services	no	所使用的docker服务，查阅使用docker镜像
stage	no	定义job stage（默认：`test`）
type	no	`stage`的别名（已弃用）
variables	no	定义job级别的变量
only	no	定义一列git分支，并为其创建job
except	no	定义一列git分支，不创建job
tags	no	定义一列tags，用来指定选择哪个Runner（同时Runner也要设置tags）
allow_failure	no	允许job失败。失败的job不影响commit状态
when	no	定义何时开始job。可以是`on_success`，`on_failure`，`always`或者`manual`
dependencies	no	定义job依赖关系，这样他们就可以互相传递artifacts
cache	no	定义应在后续运行之间缓存的文件列表
before_script	no	重写一组在作业前执行的命令
after_script	no	重写一组在作业后执行的命令
environment	no	定义此作业完成部署的环境名称
coverage	no	定义给定作业的代码覆盖率设置

配置.gitlab-ci.yml

stages:
 - deploy_dev
 - deploy_test
 - deploy_production

deploy_dev:
 stage: deploy_dev
 environment:
 name: dev
 only:
 - dev
 script:
 - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH}
 - npm run build:dev
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=/opt/devroot/"

deploy_test:
 stage: deploy_test
 environment:
 name: test
 only:
 - master
 script:
 - rsync -av . ${WORKSPACE_PATH} && cd ${WORKSPACE_PATH}
 - npm run build:stage
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=cloud_ui_test projectDir=${WORKSPACE_DIST_PATH} projectName=${PROJECT_NAME} webRootPath=${WEB_ROOT_PATH}"

deploy_production:
 stage: deploy_production
 only:
 - production
 when: manual
 script:
 - npm install
 - npm run build:prod
 - ansible-playbook ansible-deploy.yml --extra-vars "hosts=dvs-front-prod projectDir=${PROJECT_PATH} projectName=xianglin-cloud-ui/${PROJECT_NAME} webRootPath=/opt/"

上面这个.yml文件,我们首先定义了三个阶段，deploy_dev部署到dev环境，并且拉去的是dev分支代码; deploy_test部署到test环境，拉去的是master分支代码，deploy_production拉取production分支代码，执行完后需要手动操作

编译优化-观测

Tue, 05 May 2026 00:41:41 +0800

“无法度量就无法优化”。在开始任何编译优化动作之前，必须先建立一套可重复、可对比的观测手段，否则改动的真实收益无从谈起。本文介绍 iOS 编译耗时观测的主要工具链和原理。

观测目标分层

不同层次的观测工具回答不同的问题：

flowchart TD
A[编译耗时观测] --> B[整体耗时]
A --> C[阶段耗时]
A --> D[任务级耗时]
A --> E[函数/表达式级]
B --> B1[xcodebuild 总耗时]
C --> C1[Build Timing Summary]
C --> C2[Pod Install 阶段计时]
D --> D1[Build Timeline]
D --> D2[XCLogParser]
E --> E1[-debug-time-compilation]
E --> E2[-warn-long-expression]

观测层次	典型问题	工具
整体	一次构建花了多久？	`time xcodebuild`、MetricKit
阶段	哪个阶段最慢？	`-showBuildTimingSummary`、Build Timing Summary
任务	哪个文件/目标最慢？	Xcode Build Timeline、XCLogParser
函数级	哪个函数/表达式让前端卡住？	`-debug-time-function-bodies`、`-warn-long-expression-type-checking`

整体耗时

xcodebuild 命令行计时

最简单也最稳定的方式是直接给 xcodebuild 加 time：

代码分割工程化

Thu, 07 Aug 2025 00:00:00 +0800

什么是 Bundle Splitting？

Bundle Splitting（代码分割）是一种将前端资源拆分成更小、独立的模块的技术。传统上，前端资源（如 JavaScript、CSS 和图片等）被打包成单个文件，通常称为“bundle”。这种方式存在一个问题，即无论用户需要哪些功能，都必须下载整个 bundle。而 Bundle Splitting 技术通过将代码拆分为更小的模块，按需加载，可以有效解决这个问题。

Bundle Splitting 的优点

减少初始加载时间通过将代码拆分为多个小块，可以减少初始加载时间。当用户首次访问网页时，只需下载当前页面所需的资源，而无需等待整个应用程序的加载完成。这可以极大地提高页面的响应速度，并减少用户的等待时间。
提升用户体验通过将代码分割成模块，可以使应用程序更具响应性。当用户与应用进行交互时，只需加载所需的代码块，而不是整个应用。这将减少不必要的资源消耗，并使用户感觉应用更加流畅和快速。
优化缓存策略拆分代码还能优化缓存策略。当应用程序发生更改时，只需重新加载发生变化的模块，而不必重新下载整个应用。这减少了不必要的网络请求，提高了应用的更新效率，并减轻了服务器的负载。
并行加载资源通过将代码拆分为多个模块，可以实现并行加载资源。浏览器能够同时下载多个文件，从而减少整体加载时间。这对于大型应用程序和复杂的前端框架特别有益，能够更好地利用浏览器的并行下载能力，提高资源的加载效率。
代码复用和维护通过将代码分割成模块，可以更好地实现代码的复用和维护。不同的模块可以根据需求进行加载和升级，使得代码结构更加清晰、模块化。这也有助于团队合作，不同开发者可以并行工作在不同的模块上，提高开发效率和代码质量。

Bundle Splitting 的缺点

增加了网络请求拆分代码会增加应用程序的网络请求次数。每个模块都需要进行一次独立的网络请求，这可能会导致一些额外的延迟和性能损失。在网络条件较差的情况下，这可能会对用户体验产生一定影响。
增加了开发复杂性使用 Bundle Splitting 技术需要对应用程序的依赖关系进行深入分析和管理。开发人员需要仔细考虑代码的拆分点，以及如何在运行时动态加载模块。这增加了开发复杂性，并要求开发人员具备较高的技术水平和经验。
潜在的代码冗余当模块之间存在共享的代码片段时，可能会出现潜在的代码冗余问题。如果不合理地进行代码拆分，可能会导致多个模块中存在相同的代码，增加了资源的下载和维护成本。因此，在进行代码拆分时，需要仔细考虑代码复用和代码冗余的问题。
需要额外的工具和配置 Bundle Splitting 需要使用额外的工具和配置来实现代码的拆分和动态加载。这可能需要对构建工具进行配置，如 Webpack、Rollup 等，以及对模块加载器进行调整。这增加了一些学习成本和开发成本，尤其是对于新手来说。

Bundle Splitting 的适用场景

Bundle Splitting 技术适用于大型的 Web 应用程序，特别是那些具有复杂功能和大量依赖的应用。以下是一些适合使用 Bundle Splitting 的场景：

大型单页应用：对于由多个模块组成的单页应用，使用 Bundle Splitting 可以提高初始加载速度，提升用户体验。
按需加载：对于需要动态加载不同功能模块的应用，Bundle Splitting 可以根据用户的需求按需加载模块，减少不必要的资源消耗。
公共库和框架：对于使用公共库或框架的应用，可以将这些库和框架拆分成单独的模块，以便在多个页面中共享和复用。
国际化支持：对于需要支持多种语言的应用，可以将不同语言的资源文件拆分成独立的模块，根据用户的语言偏好进行加载。
代码分支管理：对于大型团队开发的项目，使用 Bundle Splitting 可以更好地实现代码的分支管理和并行开发，提高开发效率。

Bundle Splitting 在知名项目中的应用

示例 1：React.lazy 和 Suspense

React.js 是一个广泛使用的 JavaScript 库，用于构建用户界面。React 提供了 React.lazy 和 Suspense API 来实现 Bundle Splitting。

编译优化-链接优化

Sat, 02 May 2026 22:32:27 +0800

链接是 iOS 编译的最后一个阶段，也是大型工程里经常被忽略的瓶颈。Apple 在 WWDC22 的 “Link fast: Improve build and launch times” 演讲中公开：Xcode 14 新的 ld-prime 链接器比 ld64 快 2 倍。随着 Xcode 17、ThinLTO、Mergeable Libraries 等改进，链接优化已经成为编译加速的重要一环。

链接器的职责

链接器把多个 .o 合并成最终可执行文件或库：

flowchart TD
A[若干 .o] --> L[链接器]
B[静态库 .a] --> L
C[动态库 .dylib / framework] --> L
L --> D[符号解析]
D --> E[dead_strip]
E --> F[ObjC runtime fix-up]
F --> G[生成 LC_* 加载命令]
G --> H[写入 Mach-O]

关键任务：

符号解析：所有 undefined symbol 必须在某个 .o / .a / .dylib 里找到
重定位：把符号引用的偏移写入正确位置
Dead Strip：去掉未被使用的代码/数据
ObjC 元数据修复：把分散的类、分类信息合并成 ObjC runtime 能识别的结构
生成 Mach-O：写 Load Commands、__LINKEDIT 等段

链接器对比

ld64（经典）

ld64 是 Apple 长期使用的经典链接器，源代码在 apple-oss-distributions/ld64。单线程为主，在大工程上明显偏慢。

前端性能监控

Thu, 07 Aug 2025 00:00:00 +0800

大纲

我们会从以下三个方向来讲解埋点与监控的知识：

什么是埋点？什么是监控？
JS 中实现监控的核心方案
写一个“相对”完整的监控实例

一、什么是埋点？什么是监控？

在日常沟通中，我们经常会把【埋点】和【监控】放到一起说，但是它们在本质上是有一定的区别的：

1. 埋点

埋点主要用于收集用户行为数据。在日常开发中，我们会通过 在前端代码中插入代码或脚本的方式 来实现埋点功能。

埋点的主要作用就是：捕获特定用户行为（如点击、浏览、提交表单、页面跳转等）以及关键业务数据（如下单金额、商品类别等）

在日常开发中，埋点的实现方案大致可以分为以下三大类：

手动埋点：在代码中手动加入记录代码来捕获特定事件。
自动埋点：利用 DOM 事件代理等技术来捕获页面上所有事件，从而减少手动配置。
可视化埋点：通过工具界面标记需要采集的元素和事件，可以不用手写代码。

2. 监控

而监控则主要关注 系统的性能和稳定性。在日常开发中，我们会通过 采集页面加载时间、资源请求、错误日志等数据 的方式来实现前端监控。

监控的主要作用就是：及时发现并定位页面性能瓶颈或代码异常，目的是为了保障系统不出 bug

在日常开发中，监控一般需要完成以下三大部分：

性能监控：如：首屏加载时间、页面交互耗时、资源加载耗时等。
错误监控：捕获 JavaScript 错误、网络请求失败、资源加载异常等。
用户体验监控：收集白屏、卡顿等影响用户体验的问题等。

区别总结

维度	前端埋点	前端监控
目标	捕获用户行为数据	监控系统性能、错误、稳定性
数据类型	用户点击、表单提交、页面跳转等	页面加载时间、错误日志、卡顿情况等
实现方式	手动埋点、自动埋点、可视化埋点	错误捕获、性能指标采集
核心关注点	用户行为、业务数据	系统Bug、性能优化

二、JS 中实现监控的核心方案

根据上面所说，我们知道埋点和监控的目的存在不同，但是它们的思路确是有很多一致性的，其核心都是：获取关键的数据，发送（上报）给服务端，依据数据来解决其不同的目的。

所以，无论是埋点也好，还是监控也罢，我们都需要 获取关键位置数据。

1. 跟踪用户事件（点击、滚动等）

定义通用跟踪函数（后续事件会通过该函数完成上报）：trackEvent 函数接收事件类型和事件详情，并上报到服务端。

// 用于记录或发送跟踪数据到服务器的函数
function trackEvent(eventType, details) {
 console.log(`Event: ${eventType}`, details); // 在控制台打印事件类型和详情
 // 上报到服务端。
 fetch('/测试接口地址', { method: 'POST', body: JSON.stringify({ eventType, details }) });
}

捕获按钮点击事件：获取 id 为 myButton 的按钮，并在其 click 事件上添加监听器。在按钮被点击时调用 trackEvent 函数，记录点击事件的类型（button_click）、按钮 ID 和时间戳。

编译优化

Wed, 27 May 2026 22:24:03 +0800

大型 iOS 工程的编译耗时往往是研发效能最突出的瓶颈之一。以抖音、今日头条、美团为代表的一线团队，工程代码量通常在数百万到千万行级，本地全量编译耗时 10 分钟以上、CI 上半小时起步已是常态。编译等待不仅直接压缩研发时间，还会打断心流、降低人均产出。

本系列文章从 iOS 编译系统的原理出发，结合社区最新实践（Xcode 16/17 Explicit Modules、rules_xcodeproj、seer-optimize、cocoapods-hmap-prebuilt、Rugby 等），系统性介绍编译优化的各类手段与背后的原理。

编译流程概述

理解iOS编译原理是编译优化的前提。一次典型的 iOS 编译流程可以划分为以下阶段：

flowchart TD
A[Parse Podfile / 生成工程] --> B[Pod Install / 依赖解析]
B --> C[Xcode Build System 调度]
C --> D[Dependency Scan / 模块依赖扫描]
D --> E[Swift/Clang 前端编译]
E --> F[生成 .o / .swiftmodule / .pcm]
F --> G[链接 ld64 / ld-prime / lld]
G --> H[签名 / 打包 / 资源处理]
H --> I[产出 .app / .ipa]

阶段	主要工作	常见瓶颈
依赖管理	Pod Install、SPM 解析	Source 更新慢、Specification 解析重复、沙盒拷贝
工程生成	生成 Pods.xcodeproj、xcconfig、hmap	Target 数量多、pbxproj 膨胀
构建调度	Build System 解析任务图、并行调度	依赖粒度过粗、并行度不足
模块扫描	Clang/Swift 依赖扫描	隐式模块重复编译
源码编译	Swift/Clang 前端、类型检查、SIL/IR 生成	类型推导爆炸、WMO 关闭、PCH 失效
链接	符号解析、LTO、dead-strip	链接参数过长、ThinLTO 串行
收尾	签名、资源拷贝、dSYM	串行脚本阻塞

优化思路全景

编译优化的核心思路只有三条：减少需要做的工作、让必须做的工作更快、让做过的工作可复用。所有社区实践都可以归入这三类。

前端组件化开发

Thu, 07 Aug 2025 00:00:00 +0800

背景

不知道你有没有遇到过以下场景:

页面逻辑越来越多,代码越来越庞大,写到后面难以 hold 住所有逻辑,很容易牵一发而动全身.
你负责的页面好好的突然出现问题,查到最后是别人代码影响.
同样的逻辑在多个地方重复书写,每次一改要改一批文件

随着前端项目复杂度的急剧增加, 上面列出的几种场景就是传统开发中会出现的问题. 也是前端组件化出现的原因.

项目复杂度增加, 一个页面一个文件需要处理的内容过多.
重复性劳动多, 效率低
质量差, 不可控

组件化初探

正是由于出现了这样的问题, 为了在越来越复杂的前端项目中提高开发效率和保证开发质量, 各路大神们开始通过各种方式来尝试解决问题.

曾经非常火的 jQuery 就基于自己建立了 jQuery 插件机制. 你可以将一些常用逻辑进行封装变成 jQuery 插件, 还可以将插件开源进行共享. 比如纯手写会吐血的日期时间选择器,轮播, 多级菜单等等. 你可以在这里浏览更多jQuery插件.

jQuery 插件的用法通常是:

$(".select").pluginName(config)

除了 jQuery 插件模式, 还有一种常见模式是对象模式. 这种模式现在仍然有很多优秀的库在被我们直接或者间接使用. 比如: swiper

对象模式的写法:

<!-- Slider main container -->
<div class="swiper-container">
 <!-- Additional required wrapper -->
 <div class="swiper-wrapper">
 <!-- Slides -->
 <div class="swiper-slide">Slide 1</div>
 <div class="swiper-slide">Slide 2</div>
 <div class="swiper-slide">Slide 3</div>
 ...
 </div>
</div>

<script src="path/to/swiper.min.js"></script>
<script>
 var mySwiper = new Swiper ('.swiper-container', {
 direction: 'vertical',
 loop: true,
 })
 </script>

对象模式通过配置创建对象, 通常创建对象的参数中有一项是元素/元素选择器, 通过js代码将逻辑与这个元素紧密绑定.

单页面架构

Thu, 07 Aug 2025 00:00:00 +0800

传统的多页面应用构建方式：

纯服务端渲染，前后端不分离，使用jsp,jade,’ejs’,’tempalte’等技术在后台先拼接成对应的HTML结构，然后转换成字符串，在每个对应的路由返回对应的数据（文件）即可

Jade模版服务端渲染，代码实现：

const express= require('express')
const app =express()
const jade = require('jade')
const result = ***
const url path = ***
const html = jade.renderFile(url, { data: result, urlPath })//传入数据给模板引擎
app.get('/',(req,res)=>{
 res.send(html)//直接吐渲染好的`html`文件拼接成字符串返回给客户端
}) //RestFul接口

app.listen(3000,err=>{
 //do something
})

使用jQuery等传统库绘制的前端页面

传统前后端不分离，服务端渲染的优缺点：

优点：

SEO友好，因为返回给前端的是渲染好的HTML结构，里面的内容都可以被爬虫抓取到。
对于一些应用性能等要求不高的项目，比如某个公司的静态网页，内容很少的情况下，直接一把梭就好，不用再搭建工程化的环境等
对于后端程序员（全干工程师）来说，不用去特意学习前端框架，公司也不用特意去招聘前端
兼容性好，传统服务端渲染多页面应用吐出来的都是字符串，HTML结构

缺点：

如果项目很大，不利于维护，据我所知，目前很多云计算公司，还有不少都是使用非单页面应用，例如一个几十万行的项目是用jQuery写的，如果注释和文档不是非常齐全，那么真的会无从下手
性能和用户体验，不能跟单页面应用相比
后期迭代，升级空间不大，目前大部分写得比较好的库，都建立vue,react等框架基础上，他们都有一套自己的运行机制，有自己的生命周期，并且不像传统的应用，还加上了一层虚拟DOM以及diff算法
现在类似Ant-Design-pro这样的开箱即用的库已经很多，单页面应用的学习和开发成本已经很低很低，如果还在使用传统的技术去开发新的应用，对于开发人员多内心来说也是一种折磨。

这里并不是说多页面应用不好，只能说各有各自的好，单页面应用如果通过大量的极致优化手段，是可以从不少方面跟原生一拼。

目前的单页面应用：

只有一张Web页面的应用，是一种从Web服务器加载的富客户端，单页面跳转仅刷新局部资源，公共资源(js、css等)仅需加载一次，常用于PC端官网、购物等网站
其实只有一个空的DIV标签，其他都是js动态生态的内容

单页面应用实现步骤：

代码实现：

首先是一个静态模板文件 index.html

<!DOCTYPE html>
<html lang="en">

<head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta http-equiv="X-UA-Compatible" content="ie=edge">
 <title>Document</title>
</head>

<body>
 <div id="root"></div>
</body>
<script>

</script>

</html>

在vue react框架的入口文件中指定对应的渲染元素：

import React from 'react;
import ReactDOM from 'react-dom';

ReactDOM.render(
<App/>,
document.querySelector("#root")
)

引入react-router或者 react-router-dom，dva等路由跳转的库
配置路由跳转

<HashRouter>//这里使用HashRouter
 <ErrorBoundary>//React错误边界
 <Switch>
 <Route path="/login" component={Login} />
 <Route path="/home" component={Home} />
 <Route path="/" component={NotFound} />//404路由或者重定向都可以
 </Switch>
 </ErrorBoundary>
</HashRouter>

单页面应用所谓路由跳转，其实最终结果就是：

浏览器的url地址发生变化，但是其实并没有发送请求，也没有刷新整个页面
根据我们配置的路由信息，每次点击切换路由，会切换到不同的组件显示，类似于选项卡功能的实现,但是同时url地址栏会变化
分为HashRouter和BrowserRouter两种模式

自己实现一个粗略的路由跳转：

自己实现传统的`Hash`模式跳转：

hash 就是指 url 后的 # 号以及后面的字符。例如www.baidu.com/#segmentfault,那么#segmentfault就是hash值

状态管理工程化

Thu, 07 Aug 2025 00:00:00 +0800

状态管理是一个前端界老生常谈的话题了，所有前端框架的发展历程中都离不开状态管理的迭代与更替，对于react来说呢，整个状态管理的发展也随着react架构的变更和新特性的加入而不停的做调整，作为一个一起伴随react成长了快5年的开发者，经历过reflux、redux、mobx，以及其他redux衍生方案dva、mirror、rematch等等后，我觉得它们都不是我想要的状态管理的终极形态，所以为了打造一个和react结合得最优雅、使用起来最简单、运行起来最高效的状态管理方案，踏上了追梦旅途。

为何需要状态管理

为何需要在前端引用里引入状态管理，基本上大家都达成了共识，在此我总结为3点：

随着应用的规模越来越大，功能越来越复杂，组件的抽象粒度会越来越细，在视图中组合起来后层级也会越来越深，能够方便的跨组件共享状态成为迫切的需求。
状态也需要按模块切分，状态的变更逻辑背后其实就是我们的业务逻辑，将其抽离出来能够彻底解耦ui和业务，有利于逻辑复用，以及持续的维护和迭代。
状态如果能够被集中的管理起来，并合理的派发有利于组件按需更新，缩小渲染范围，从而提高渲染性能

已有状态管理方案现状

redux

遵循react不可变思路的状态管理方案，无论从git的star排名还是社区的繁荣度，首推的一定是redux这个react界状态管理一哥，约束使用唯一路径reducer纯函数去修改store的数据，从而达到整个应用的状态流转清晰、可追溯。

image.png

mbox

遵循响应式的后期之秀mbox，提出了computed、reaction的概念，其官方的口号就是任何可以从应用程序状态派生的内容都应该派生出来，通过将原始的普通json对象转变为可观察对象，我们可以直接修改状态，mbox会自动驱动ui渲染更新，因其响应式的理念和vue很相近，在react里搭配mobx-react使用后，很多人戏称mobx是一个将react变成了类vue开发体验的状态管理方案。

image.png

当然因为mbox操作数据很方便，不满足大型应用里对状态流转路径清晰可追溯的诉求，为了约束用户的更新行为，配套出了一个mobx-state-tree，总而言之，mobx成为了响应式的代表。

其他

剩下的状态管理方案，主要有3类。

一类是不满足redux代码冗余啰嗦，接口不够友好等缺点，进而在redux之上做2次封装，典型的代表国外的有如rematch，国内有如dva、mirror等，我将它们称为redux衍生的家族作品，或者是解读了redux源码，整合自己的思路重新设计一个库，如final-state、retalk、hydux等，我将它们称为类redux作品。

一类是走响应式道路的方案，和mobx一样，劫持普通状态对象转变为可观察对象，如dob，我将它们称为类mobx作品。

剩下的就是利用react context api或者最新的hook特性，主打轻量，上手简单，概念少的方案，如unstated-next，reactn、smox、react-model等。

我心中的理想方案

上述相关的各种方案，都各自在一定程度上能满足我们的需求，但是对于追求完美的水瓶座程序猿，我觉得它们终究都不是我理想的方案，它们或小而美、或大而全，但还是不够强，不够友好，所以决定开始自研状态管理方案。

我知道小和美、全、强本身是相冲突的，我能接受一定量的大，gzip后10kb到20kb都是我接受的范围，在此基础上，去逐步地实现美、全、强，以便达到以下目的，从而体现出和现有状态管理框架的差异性、优越性。

让新手使用的时候，无需了解新的特性api，无感知状态管理的存在，使其遁于无形之中，仅按照react的思路组织代码，就能享受到状态管理带来的福利。
让老手可以结合对状态管理的已有认知来使用新提供的特性api，还原各种社区公认的最佳实践，同时还能向上继续探索和提炼，挖掘状态管理带来的更多收益。
在react有了hook特性之后，让class组件和function组件都能够享有一致的思路、一致的api接入状态管理，不产生割裂感。
在保持以上3点的基础上，让用户能够使用更精简且更符合思维直觉的组织方式书写代码，同时还能够获得巨大的性能提升收益。

为了达成以上目标，立项concent，将其定义为一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，期待能把他打磨成为一个真真实实让用户用起来感觉到美丽、全面、强大的框架。

说人话就是：理解起来够简单、代码写起来够优雅、工程架构起来够健壮、性能用起来够卓越…… ^_^

concent.png

可预测

react是一个基于pull based来做变化侦测的ui框架，对于用户来说，需要显式的调用setState来让react感知到状态变化，所以concent遵循react经典的不可变原则来体现可预测，不使用劫持对象将转变为可观察对象的方式来感知状态变化（要不然又成为了一个类mobx……）, 也不使用时全局pub&sub的模式来驱动相关视图更新，同时还要配置各种reselect、redux-saga等中间件来解决计算缓存、异步action等等问题（如果这样，岂不是又迈向了一个redux全家桶轮子的不归路….. ）

吐槽一下：redux粗放的订阅粒度在组件越来越多，状态越来越复杂的时候，经常因为组件订阅了不需要的数据而造成冗余更新，而且各种手写mapXXXToYYY很烦啊有木有啊有木有，伤不起啊伤不起……

零入侵

上面提到了期望新手仅按照react的思路组织代码，就能够享受到状态管理带来的福利，所以必然只能在setState之上做文章，其实我们可以把setState当做一个下达渲染指令重要入口（除此之外，还有forceUpdate）。

setState，下达更新指令

仔细看看上图，有没有发现有什么描述不太准确的地方，我们看看官方的setState函数签名描述:

代码语言：txt

AI代码解释

setState<K extends keyof S>(
 state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
 callback?: () => void
): void;

通过签名描述，我们可以看出传递给setState的是一个部分状态(片段状态)，实际上我们在调用setState也是经常这么做的，修改了谁就传递对应的stateKey和值。

工程化面试题

Mon, 01 Jan 0001 00:00:00 +0000

共 87 道工程化面试题。答案默认折叠，便于先自行作答。

1. webpack 中的 Loader ，链式调用顺序会影响编译结果吗？

难度：2 · 类型：QA

题目要点

Webpack Loader 是一个按流水线执行的源码转换系统，Loader 的链式顺序直接决定源码被处理的阶段；配置顺序为从左到右，但执行顺序为从右到左，每个 Loader 都处理前一个 Loader 的输出，因此顺序错误会导致语义阶段错乱甚至编译失败；通常应遵循“靠近源码的 Loader 放右侧，靠近运行时的 Loader 放左侧”的原则，同时 Loader 还存在 pitch 与 normal 两阶段执行机制，使顺序对最终编译结果具有决定性影响。

参考答案

会，而且这是 Webpack Loader 机制中非常关键且经常被误解的一点：

Loader 的链式调用顺序不仅会影响编译结果，而且很多语法是否能正确工作，完全取决于 Loader 的执行顺序。

理解这个问题的关键在于：Loader 本质是一个“源码转换流水线（transform pipeline）”。

一、Loader 本质：源码的逐步转换

在 Webpack 中 hookup 的 Loader，并不是同时运行的，它们会对模块源码进行一层一层的转换：

原始源码 → loaderA → loaderB → loaderC → 最终 JS 模块

每个 Loader：

接收上一个 Loader 的输出
返回新的源码字符串（或 AST 转换结果）
交给下一个 Loader

因此：

工程化 on Last Stand

编译优化-Bazel方案

为什么是 Bazel

Bazel 核心概念

Workspace 与 Package

Rule

前端模块化

一、模块化的理解

1.什么是模块?

2.模块化的进化过程

编译优化-CocoaPods优化

Pod Install 耗时构成

resolve_dependencies 优化

Source 仓库更新

Webpack与Vite

前言

定位

运行原理

构建方式

http2

热更新

编译优化-Explicit Modules

模块（Module）基础

为什么需要模块

模块的组成

Implicit Modules 的问题

原理

任务自动化

什么是npm scripts？

为什么使用npm scripts？

如何定义和使用npm scripts？

1. 设置基本的开发任务

编译优化-Swift编译优化

Swift 编译流程速览

类型推导与 “Too Complex” 错误

约束求解

前端构建工具详解

YUI Tool + Ant

Grunt / Gulp

编译优化-Xcode构建系统

构建系统组成

XCBBuildService

前端任务自动化（npm scripts实现）

什么是npm scripts？

为什么使用npm scripts？

如何定义和使用npm scripts？

1. 设置基本的开发任务

3D球场项目 (六)：客户端工程化与优化

架构改动一览

编译优化-二进制化

为什么能加速

二进制产物形态

静态库（.a）

Framework（.framework）

代码规范工程化

1. ESlint - 检查你的 JavaScript 代码

1.1. ESLint 及其作用

1.2. ESLint 快速上手

编译优化-二进制化实现原理

总体架构

版本控制

什么是版本控制

为什么要做版本控制

代码一致性

可追溯性

可维护性

团队协作

版本控制工具Git

Git的安装

WIndows

图形化工具

安装

使用

编译优化-头文件与HMap

头文件查找的代价

Clang 的查找流程

包管理

一、剖析 package.json

1.1 必备属性

npm包命名规则

什么是`npm scripts`？

为什么使用`npm scripts`？

如何定义和使用`npm scripts`？

什么是`npm scripts`？

为什么使用`npm scripts`？

如何定义和使用`npm scripts`？

版本控制工具`Git`

`Git`的安装

`WIndows`

自己实现传统的`Hash`模式跳转：

工程化面试题