阅读视图

【Flutter×鸿蒙】FVM 不认鸿蒙 SDK？4步手动塞进去

2026年3月5日 18:26

系列导航：

(1) 环境开荒

(2) 驯服 SDK ← 你在这里

(3) 项目搬家

(4) 保命急救箱

我第一次让 FVM 管理鸿蒙版 Flutter SDK 时，前后踩了 4 个坑，花了大半天才跑通。事后复盘发现，每个坑都不难，只是没人提前告诉我"为什么要这样做"。这篇把整个过程拆成 5 关，每关讲清「为什么」和「怎么做」，争取让你 20 分钟一次通关。

前置条件：请先完成第一篇的全部内容——DevEco Studio 已安装，ohpm、node、hvigorw 在终端里都能正常调用。

🗺️ 通关路线图

关卡	任务	预计耗时
第1关	安装 FVM	2 min
第2关	克隆鸿蒙版 SDK	5 min（取决于网速）
第3关	修复版本"身份证"	3 min
第4关	指定鸿蒙 SDK 路径	1 min
第5关	全绿验证	2 min

🎯 第 1 关：安装 FVM

目标

让终端认识 fvm 命令。

为什么需要 FVM

一句话——让不同项目用不同版本的 Flutter，互不干扰。比如项目 A 用官方 3.24 跑 Android/iOS，项目 B 用鸿蒙版 3.35.8。FVM 就是 Flutter 的"版本档案柜"，每个抽屉放一个版本。

📋 操作

# macOS（在终端里执行，这是用 Homebrew 包管理器安装 FVM）
brew install fvm

# Windows（在 cmd 或 PowerShell 中执行，这是用 Chocolatey 包管理器安装 FVM）
choco install fvm

安装完后，配置 FVM 缓存路径。把以下两行写入 ~/.zshrc（上一篇介绍过，这是 Mac 终端的配置文件）：

# FVM 存放所有 Flutter 版本的目录
export FVM_CACHE_PATH=$HOME/fvm
# 让 FVM 的默认版本可以直接用 flutter 命令调用
export PATH="$HOME/fvm/default/bin:$PATH"

保存后执行下面这条命令，让刚才的配置立即生效（否则要关掉终端重新打开）：

source ~/.zshrc

✅ 验证

# 查看 FVM 版本号，确认安装成功
fvm --version

看到版本号（如 3.1.4）就过关了。

⚠️ 如果报 command not found：Mac 用户确认已安装 Homebrew（执行 brew --version 看有没有输出）；Windows 用户确认已安装 Chocolatey（执行 choco --version）。如果包管理器本身都没装，请先去官网安装。

🎯 第 2 关：克隆鸿蒙版 SDK

目标

把华为的鸿蒙版 Flutter 放进 FVM 管辖。

为什么不能直接 `fvm install`

正常装 Flutter 只需要 fvm install 3.24.0，FVM 会自动去 GitHub 下载。但鸿蒙版是华为团队在 AtomGit（国内代码托管平台）上单独维护的，FVM 的世界里它根本不存在。所以我们要"手动入库"——自己下载代码，放到 FVM 的档案柜里，假装它一直在那。

⚠️ 本关最大的坑：分支名和版本号是两回事！

仓库的分支叫 oh-3.35.7-dev，看到 3.35.7 你会以为版本就是 3.35.7。但实际上代码里的版本已经迭代到了 3.35.8-ohos-0.0.2。

类比：Git 分支叫 feature/login-v1，但代码早就改到 v3 了。分支名是创建时起的，不会跟着版本号自动更新。

千万别拿分支名当版本号用，团队必须统一用 3.35.8-ohos-0.0.2 这个真实版本号。

📋 操作

# --depth 1 只取最新代码，省空间（省去几个 GB 的历史记录）
git clone -b oh-3.35.7-dev --depth 1 
https://atomgit.com/openharmony-tpc/flutter_flutter.git 
~/fvm/versions/3.35.8-ohos-0.0.2

注意看：clone 命令里分支名是 oh-3.35.7-dev，但目标文件夹名是 3.35.8-ohos-0.0.2——这不是写错了，上面已经解释了为什么不一样。

💡 怎么确认真实版本号？ clone 完后执行 ~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter --version 看输出。如果加入已有团队，直接看项目的 .fvmrc 文件（命令：cat .fvmrc）。

✅ 验证

# 确认文件下载成功（ls = 列出目录内容）
ls ~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter

文件存在就过关。

⚠️ 如果报 No such file or directory：回去检查 clone 命令是否执行成功。常见原因是网络超时（AtomGit 在国内，通常不需要梯子，但公司内网可能有限制）。重新执行 clone 前，先删掉残留目录：rm -rf ~/fvm/versions/3.35.8-ohos-0.0.2，再重试。

🎯 第 3 关：修复版本"身份证"

目标

让 FVM 正确识别这个 SDK 的版本号。

为什么要做这步

clone 下来的 SDK 有两张"证件"：

version 文件——相当于身份证，一行文本写着版本号
bin/cache/flutter.version.json——相当于内部档案，JSON 格式的详细版本信息

问题是，这两张证件上都写着 0.0.0-unknown（因为鸿蒙团队是从开发分支构建的，没有打标准标签）。但我们的文件夹名叫 3.35.8-ohos-0.0.2。FVM 一查——名字对不上，直接翻脸。

⚠️ 不做这步的后果：FVM 会弹出 "Version mismatch" 并试图删掉你的 SDK 重装。如果看到了这个弹窗，千万不要选任何选项，按 Ctrl+C（Mac 也是 Ctrl 不是 Cmd）退出，回来做这步。

📋 操作

macOS / Linux：

cd ~/fvm/versions/3.35.8-ohos-0.0.2
# 第一步：改"身份证"
echo -n "3.35.8-ohos-0.0.2" > version
# 第二步：初始化 Flutter 引擎（首次运行会下载 Dart SDK，需要等 1-3 分钟）
bin/flutter --version
# 第三步：改"内部档案"（把所有 0.0.0-unknown 替换成正确的版本号）
sed -i '' 's/0.0.0-unknown/3.35.8-ohos-0.0.2/g' bin/cache/flutter.version.json

Windows PowerShell：

# 进入 SDK 所在目录
cd $env:USERPROFILE\fvm\versions\3.35.8-ohos-0.0.2
# 第一步：改"身份证"
"3.35.8-ohos-0.0.2" | Set-Content version -NoNewline
# 第二步：初始化引擎
bin\flutter --version
# 第三步：改"内部档案"（PowerShell 的查找替换写法）
(Get-Content bin\cache\flutter.version.json) -replace '0.0.0-unknown', '3.35.8-ohos-0.0.2' | Set-Content bin\cache\flutter.version.json

⚠️ 三步的顺序不能乱——第二步会生成 flutter.version.json 文件，第三步才有东西可改。如果你先执行了第三步，会报文件不存在。

✅ 验证

# 回到任意目录都可以执行（fvm list = 列出 FVM 管理的所有 Flutter 版本）
fvm list

看到 Version 列显示 3.35.8-ohos-0.0.2（不是空白、不是 Need setup、不是 0.0.0-unknown），这关就过了。

⚠️ 如果还是显示异常，逐一排查两张"证件"：
# 检查"身份证"内容
cat ~/fvm/versions/3.35.8-ohos-0.0.2/version
# 应该输出：3.35.8-ohos-0.0.2（没有多余空行）

# 检查"内部档案"有没有残留的 0.0.0-unknown
cat ~/fvm/versions/3.35.8-ohos-0.0.2/bin/cache/flutter.version.json
# 里面所有 version 字段应该都是 3.35.8-ohos-0.0.2
如果 version 文件内容不对，重新执行第一步；如果 JSON 里还有 0.0.0-unknown，重新执行第三步。

🎯 第 4 关：指定鸿蒙 SDK 路径

目标

让 Flutter 知道鸿蒙的 SDK（OpenHarmony SDK）装在哪。

为什么不用环境变量

我试过 HOS_SDK_HOME、OHOS_SDK_HOME 等环境变量，时灵时不灵。原因是不同方式打开的终端（VS Code 内置终端 vs 系统终端 vs CI 环境）加载配置文件的顺序不一样，变量可能没被读到。flutter config 会把路径写入 Flutter 自己的配置文件，不管从哪里启动都能读到，最稳。

📋 操作

# 把鸿蒙 SDK 的位置"写死"到 Flutter 的配置里（一次性操作）
~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter config \
--ohos-sdk="/Applications/DevEco-Studio.app/Contents/sdk"

⚠️ Windows 用户路径改为：--ohos-sdk="C:\Program Files\Huawei\DevEco Studio\sdk"

请根据 DevEco Studio 实际安装路径调整。不确定装在哪？打开 DevEco Studio → Settings → SDK 页面可以看到路径。

终端输出 Setting "ohos-sdk" value to "..." 就成功了。

✅ 验证

不急，下一关一起验收。

🎯 第 5 关：全绿验证

目标

flutter doctor 中 HarmonyOS toolchain 一栏显示绿色对勾。

📋 操作

# 运行 Flutter 的环境诊断工具（-v 表示显示详细信息）
~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter doctor -v

✅ 验证

关注输出中的 HarmonyOS 那一栏：


[✓] HarmonyOS toolchain - develop for HarmonyOS devices
• OpenHarmony Sdk at /Applications/DevEco-Studio.app/Contents/sdk,
available api versions has [22:default]
• Ohpm version 6.0.1
• Node version v18.20.1
• Hvigorw binary at .../hvigor/bin/hvigorw

看到 [✓] 加上 4 个子项都有值 = 通关！

💡 你可能会看到 Flutter 那栏有几个 ! 警告（channel 不标准、upstream 不是官方地址）。这是鸿蒙版的正常现象，完全不影响开发和打包，放心忽略。

⚠️ 如果 HarmonyOS 那栏还是红叉，按优先级排查：

SDK not found → 回第 4 关检查 config 路径是否正确

ohpm/hvigorw missing → 回第一篇检查环境变量

Version mismatch → 回第 3 关检查两张"证件"

🔧 附加关：FVM 的"碎碎念"

通关后你会发现，每次用 fvm flutter xxx 时 FVM 都会弹 "not a valid version" 的警告让你确认。这不是报错，只是 FVM 在说："这个版本号我在官方列表里查不到，你确定要用吗？"

三种应对方式：

手动按 y——每次弹出输入 y 回车
自动确认——命令前加 yes |：

yes | fvm flutter doctor

绕过 FVM——直接用绝对路径调用，完全不弹警告：

~/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter doctor

我推荐第三种，路径虽长但最省心。可以设个快捷方式（alias）缩短它：

# 把这行加到 ~/.zshrc 里（alias = 给一条长命令起个短名字）
alias hflutter="$HOME/fvm/versions/3.35.8-ohos-0.0.2/bin/flutter"

保存后 source ~/.zshrc，之后直接 hflutter run、hflutter doctor 就行。

🏆 通关总结

项目	状态
FVM	✅ 已安装
鸿蒙版 Flutter SDK	✅ ~/fvm/versions/3.35.8-ohos-0.0.2
version 文件	✅ 已修复
flutter.version.json	✅ 已修复
flutter config --ohos-sdk	✅ 已配置
flutter doctor HarmonyOS	✅ 全绿

回顾核心逻辑：FVM 只管官方 Flutter，鸿蒙版要我们手动塞进去（第 2 关）；塞进去后"证件"信息对不上，需要手动修正（第 3 关）；最后告诉 Flutter 鸿蒙 SDK 在哪（第 4 关）。理解了这条线，以后鸿蒙版 SDK 升级换版本号，你也能照样搞定。

如果中途卡住，大概率是版本号写错了——检查文件夹名、version 文件内容、flutter.version.json 里的版本号，三者必须完全一致。

下一篇预告：SDK 准备好了，接下来要把你的老 Flutter 项目跑到鸿蒙上——听起来就是敲几行命令的事？没那么简单。→ Flutter 鸿蒙通关手册（三）：项目搬家

iOS PDF阅读器段评实现：如何从 PDFSelection 精准还原一个自然段

掘金 iOS

iceiceiceice

2026年3月5日 18:13

iOS PDF 阅读器段评实现：如何从 PDFSelection 精准还原一个自然段

目标读者：有 PDFKit 使用经验的 iOS 开发者。
本文重点：几何分块算法、段落识别逻辑、跨栏语义合并三个核心难点。

背景：段评是什么，难在哪里

杂志类 App 有一个常见需求——用户长按某段正文，划出一段话，然后对这段话写评论。这个交互在微信读书、Kindle 里都很成熟，但它们针对的是结构化的电子书格式（ePub、MOBI），正文结构天然清晰。

PDF 没有这种结构。一份杂志 PDF 在底层只有一堆带坐标的"文字片段"（glyph run），没有段落、没有栏、没有语义层次。PDFKit 提供的 PDFSelection 和 selectionsByLine 能给你"行"，但它不知道哪些行属于同一个段落，也不知道这一页有几栏。

因此，段评的核心问题是：给定用户选中的一行文字，如何还原它所在的完整自然段？

这个问题比想象中复杂，主要难点有三个：

几何噪声：PDF 的行坐标存在浮点误差，标题、页码、图注混杂其中，必须过滤。
多栏布局：杂志常见双栏、三栏排版，阅读顺序不是简单地从上到下。
跨栏断段：一个自然段可能从左栏末尾延续到右栏开头，PDFKit 对此一无所知。

XLPDFParagraphEngine 的设计思路，就是用纯几何方法逐层解决这三个问题。

整体架构：四层流水线

整个引擎的入口是：

/// 自定义PDFView里面获取menu
+ (NSString *)paragraphTextFromSelection:(PDFSelection *)selection
                                document:(PDFDocument *)document;

它的内部执行路径是一条清晰的四层流水线：

PDFSelection
    │
    ▼
① buildLinesFromSelection     — 行提取 + 噪声过滤
    │
    ▼
② buildBlocksFromLinesIteratively  — 几何连通分块
    │
    ▼
③ readingOrderForBlock         — 列识别 + 段落切分
    │
    ▼
④ mergeSemanticContinuousBlocks — 跨栏语义合并
    │
    ▼
paragraphTextFromLines         — 拼接文本输出

每一层解决一个独立问题，下面逐层展开。

第一层：行提取与噪声过滤

PDFKit 的 selectionsByLine 会把选区内的每一行作为独立的 PDFSelection 返回，这是我们的原始数据源。但原始数据有大量噪声需要清理。

/// 获取所有lines
+ (NSArray<XLPDFLine *> *)buildLinesFromPage:(PDFPage *)page document:(PDFDocument *)document {
    CGRect pageRect = [page boundsForBox:kPDFDisplayBoxMediaBox];
    PDFSelection *pageSelection = [page selectionForRect:pageRect];
    return [self buildLinesFromBaseSelection:pageSelection document:document];
}

/// 获取选中的lines
+ (NSArray<XLPDFLine *> *)buildLinesFromSelection:(PDFSelection *)selection document:(PDFDocument *)document {
    return [self buildLinesFromBaseSelection:selection document:document];
}

+ (NSArray<XLPDFLine *> *)buildLinesFromBaseSelection:(PDFSelection *)baseSelection document:(PDFDocument *)document {

    NSMutableArray<XLPDFLine *> *lines = [NSMutableArray array];

    NSArray<PDFPage *> *pages = baseSelection.pages;

    for (PDFSelection sel in baseSelection.selectionsByLine) {

        NSString *text = sel.string;
        if (text.length == 0) continue;

        // 找到当前行所属 page
        PDFPage *linePage = nil;
        CGRect rect = CGRectZero;

        for (PDFPage *page in pages) {
            rect = [sel boundsForPage:page];
            if (!CGRectIsEmpty(rect)) {
                linePage = page;
                break;
            }
        }

        if (!linePage) continue;

        if (CGRectIsEmpty(rect)) continue;

        // ========= 公共过滤逻辑 =========

        CGFloat width = CGRectGetWidth(rect);

        CGFloat height = CGRectGetHeight(rect);

        // 过滤竖排
        if (text.length > 1 && height > width * 2.0) continue;
        // 过滤异常高度
        CGRect pageRect = [linePage boundsForBox:kPDFDisplayBoxMediaBox];
        CGFloat pageHeight = CGRectGetHeight(pageRect);
        if (height > pageHeight * 0.05) continue;

  
        NSString *trimText = [text stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];

        if (trimText.length == 0) continue;

        // 过滤纯数字编号（01、02、1、2、一、二 等页码/序号）
        NSString *numberPattern = @"^\\s*[零一二三四五六七八九十百\\d]+[、.]?\\s*$";
        NSPredicate *numberPredicate = [NSPredicate predicateWithFormat:@"SELF MATCHES %@", numberPattern];
        if ([numberPredicate evaluateWithObject:trimText]) continue;

        // ========= 构建模型 =========
        XLPDFLine *line = [XLPDFLine new];
        line.selection = sel;
        line.page = linePage;
        line.rect = rect;
        line.text = trimText;

        NSInteger pageIndex = [document indexForPage:linePage];
        line.pageIndex = pageIndex == NSNotFound ? -1 : pageIndex;

        [lines addObject:line];
    }

    return lines;
}

这里的过滤策略针对杂志 PDF 的典型噪声：

竖排文字：部分杂志有竖向装饰文字，height > width * 2.0 可以有效识别并排除。
异常高度：正文行高通常不超过页面高度的 5%，超出这个比例的往往是大图、横幅或装饰元素。
页码与序号：正则 ^[零一二三四五六七八九十百\d]+[、.]?$ 可以匹配中英文页码和列表编号，避免它们干扰后续分段判断。

过滤完成后，每一行被封装成 XLPDFLine 模型，携带 text、rect、page、pageIndex 等属性，供后续层使用。

第二层：几何连通分块

拿到干净的行列表后，下一个问题是：这一页上有几个独立的文字区域？

杂志版式复杂，一页上可能同时存在主正文区、侧边栏、图注、引言框等多个互不相连的文字区域。如果不先区分这些区域，段落识别就会跨区混淆。

引擎使用了一个经典的**几何连通图（Connected Components）**算法：

将每一行的 rect 向外膨胀（inflate）半个行高
如果两行膨胀后的 rect 有交叉 → 认为它们"连通"
对所有行做图的连通分量遍历 → 每个连通分量就是一个 Block

膨胀量选择行高的 50%，是一个关键的经验值设定：

+ (BOOL)linesConnected:(XLPDFLine *)a other:(XLPDFLine *)b {
    CGFloat insetA = a.rect.size.height * 0.5;
    CGFloat insetB = b.rect.size.height * 0.5;
    CGRect ra = CGRectInset(a.rect, -insetA, -insetA);
    CGRect rb = CGRectInset(b.rect, -insetB, -insetB);
    return CGRectIntersectsRect(ra, rb);
}

为什么不用固定像素值？因为杂志里的字号差异很大——正文可能是 10pt，大标题可能是 36pt。固定像素膨胀会导致小字号的脚注与正文粘连，或者大标题与相邻栏文字误连。用行高比例膨胀，让每行的"感知范围"与自身字号成正比，鲁棒性更好。

连通分量的遍历使用迭代 DFS：

+ (NSArray *)buildBlocksFromLinesIteratively:(NSArray *)lines {
    NSMutableArray *remaining = [lines mutableCopy];
    NSMutableArray *resultBlocks = [NSMutableArray array];

    while (remaining.count > 0) {
        NSArray *block = [self buildSingleBlockFromLines:remaining];
        [resultBlocks addObject:block];
        [remaining removeObjectsInArray:block];
    }
    return resultBlocks;
}

每次从剩余行中任取一行作为起点，BFS/DFS 扩展出整个连通分量，然后从剩余集合中移除，直到所有行都被分配完毕。

第三层：阅读顺序还原与段落切分

每个 Block 内部可能还有多列（例如一个双栏正文区，在几何上是一个连通分量）。这一层先识别列，再在每列内部切分段落。

3.1 列识别：X 轴区间合并

+ (NSArray<XLPDFLine *> *)readingOrderForBlock:(NSArray<XLPDFLine *> *)block {
 
    NSArray *ranges = [self xRangesFromBlock:block]; // 投影到X轴：x+w
    NSArray *columnRanges = [self mergeXRanges:ranges]; // 算出有多少列
    NSArray *columns = [self splitBlock:block intoColumns:columnRanges]; // 划入列里
    NSMutableArray *result = [NSMutableArray array];
    NSInteger paragraphIndex = 0;

    // 列里面直接按照Y排序即可
    for (NSArray<XLPDFLine *> *column in columns) {
        // 分段
        NSArray *ordered = [self readingOrderForColumnByIndentOnly:column paragraphStartIndex:&paragraphIndex];
        [result addObjectsFromArray:ordered];
    }

    return result;
}

具体做法：把 Block 内每一行的 [minX, maxX] 区间收集起来，按 minX 排序后做区间合并（sweep line），相互重叠或相接的区间合并为一个列边界。最终得到若干互不重叠的列区间，每一行按其中心 X 坐标归入对应的列。

这个方法的优势是完全不依赖任何先验知识，无论一页有几栏、栏宽是否均等，都能正确识别。

3.2 段落切分：三条几何规则

列识别完成后，列内的行按 Y 坐标从上到下排好序。接下来要判断相邻两行是否属于同一段落，引擎使用了三条互补的规则：

+ (NSArray<XLPDFLine *> *)readingOrderForColumnByIndentOnly:(NSArray<XLPDFLine *> *)column paragraphStartIndex:(NSInteger *)paragraphIndex {

    NSArray<XLPDFLine *> *sorted = [self sortLinesByYDescending:column];
    CGFloat baseMinX = [self baseMinXForColumn:sorted];
    CGFloat baseMaxX = [self baseMaxXForColumn:sorted];
    CGFloat columnWidth = baseMaxX - baseMinX;

    [sorted enumerateObjectsUsingBlock:^(XLPDFLine * _Nonnull line, NSUInteger idx, BOOL * _Nonnull stop) {

        if (idx > 0) {

            XLPDFLine *prevLine = sorted[idx - 1];

            // 条件1：当前行首行缩进
            CGFloat indent = CGRectGetMinX(line.rect) - baseMinX;
            BOOL currentLineIsHead = indent > 10.0;

            // 条件2：上一行是尾行（右侧留白超过列宽 10%）
            CGFloat prevLineTrailingGap = baseMaxX - CGRectGetMaxX(prevLine.rect);
            BOOL prevLineIsTail = prevLineTrailingGap > columnWidth * 0.1;

            // 条件3：行间距超过行高阈值
            CGFloat gap = CGRectGetMinY(prevLine.rect) - CGRectGetMaxY(line.rect);
            CGFloat lineHeight = CGRectGetHeight(line.rect);
            BOOL hasLargeGap = gap > lineHeight * 0.8;

            if (currentLineIsHead || prevLineIsTail || hasLargeGap) {
                (*paragraphIndex)++;
            }
        }

        line.paragraphIndex = *paragraphIndex;
    }];

    return sorted;

}

规则1（首行缩进） 是中文排版最常见的段落标记，10pt 的阈值约等于一个汉字的宽度。

规则2（末行留白） 是规则1的补充：段落末行通常不会写满整行。15% 的阈值过滤掉因行尾标点导致的微小留白，同时能识别出明显的短尾行。注意这里使用的 baseMaxX 是列内所有行 maxX 的中位数，而不是最大值，这样对行尾有标点突出的情况更鲁棒。

规则3（行间距） 用于处理无缩进、无留白但通过空行分隔的段落风格（英文排版常见）。

三条规则取 OR，任意一条满足就认为新段落开始，paragraphIndex 递增。

第四层：跨栏语义合并（最难的部分）

前三层解决了单个 Block 内部的问题，但杂志双栏排版有一个特殊情况：

一个自然段从左栏末尾开始，写满后在右栏顶部继续。

这两部分在几何上属于不同的 Block（左栏和右栏不连通），但语义上是同一个段落。这就是跨栏语义合并问题。

4.1 判断标准：段尾 + 段首

合并的充要条件是：左栏某 Block 的最后一行是段尾行（Tail） ，同时右栏某 Block 的第一行是段首行（Head） ，且两者字号一致。

段尾判断：末行写满（右侧留白 < 列宽10%）且没有句末标点（。！？；…等）：

+ (BOOL)isTailBlock:(NSArray *)block {
    XLPDFLine *lastLine = block.lastObject;
    CGFloat trailingGap = columnMaxX - CGRectGetMaxX(lastLine.rect);
    BOOL noTrailingGap  = trailingGap <= columnWidth * 0.1;
    BOOL noEndingSymbol = ![self lineEndsWithParagraphSymbol:lastLine];
    return noTrailingGap && noEndingSymbol;
}

段尾判断：判断一行是否以句末标点结尾（处理引号包裹和英文小数）

+ (BOOL)lineEndsWithParagraphSymbol:(XLPDFLine *)line {

    NSCharacterSet *endingSymbols = [NSCharacterSet characterSetWithCharactersInString:@"。！？；.!?;…"];
    NSCharacterSet *wrapperSet =
    [NSCharacterSet characterSetWithCharactersInString:@"”’\"')）】》〉 "];
    NSString *trimmed = [line.text stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];

    if (trimmed.length == 0) return NO;

    NSInteger index = (NSInteger)trimmed.length - 1;

    // 跳过包裹字符
    while (index >= 0 &&
           [wrapperSet characterIsMember:[trimmed characterAtIndex:index]]) {
        index--;
    }

    if (index < 0) return NO;

    unichar c = [trimmed characterAtIndex:index];

    // 英文小数点不算句末（3.14）
    if (c == '.' && index > 0 &&
        [[NSCharacterSet decimalDigitCharacterSet]
         characterIsMember:[trimmed characterAtIndex:index - 1]]) {
        return NO;
    }

  
    return [endingSymbols characterIsMember:c];
}

段首判断：首行无明显缩进（缩进量 ≤ 10pt），说明这一行是接续上一栏的内容，而不是新段落的起点：

+ (BOOL)isHeadBlock:(NSArray *)block {
    XLPDFLine *firstLine = block.firstObject;
    CGFloat indent = CGRectGetMinX(firstLine.rect) - columnMinX;
    return indent <= 10.0;
}

解决多栏PDF的跨列语义连续问题：

/// 先对所有allPageLines进行分列（大概2、3列）
/// 将所有block归列，每一列N个block
/// 每一列的从后往前找可能是段尾的block
/// 从第二列内部blocks遍历从前往后判断是否是段首
/// 合并段位和段首，处理blockIndex、paragraphIndex
+ (NSArray<NSArray<XLPDFLine *> *> *)mergeSemanticContinuousBlocks:(NSArray<NSArray<XLPDFLine *> *> *)blocks pageLines:(NSArray<XLPDFLine *> *)allPageLines {

    if (blocks.count < 2) return blocks;

    NSArray<NSValue *> *columnRanges = [self detectColumnRanges:allPageLines];

    if (columnRanges.count < 2) return blocks;

    // 按列分组（保持列内Y排序）
    NSMutableArray<NSMutableArray *> *columns = [NSMutableArray array];
    for (NSInteger i = 0; i < columnRanges.count; i++) {
        [columns addObject:[NSMutableArray array]];
    }

    for (NSArray<XLPDFLine *> *block in blocks) {

        NSInteger colIdx = [self columnIndexForBlock:block inRanges:columnRanges];
        if (colIdx >= 0) [columns[colIdx] addObject:[block mutableCopy]];
    }

    for (NSMutableArray *column in columns) {
        [column sortUsingComparator:^NSComparisonResult(NSArray *a, NSArray *b) {

            CGFloat maxYA = 0, maxYB = 0;
            for (XLPDFLine *l in a) maxYA = MAX(maxYA, CGRectGetMaxY(l.rect));
            for (XLPDFLine *l in b) maxYB = MAX(maxYB, CGRectGetMaxY(l.rect));
            return maxYA > maxYB ? NSOrderedAscending : NSOrderedDescending;
        }];
    }

    // 跨列合并
    for (NSInteger col = 0; col < (NSInteger)columns.count - 1; col++) {

        NSMutableArray *currentCol = columns[col];
        NSMutableArray *nextCol    = columns[col + 1];
        if (currentCol.count == 0 || nextCol.count == 0) continue;

        CGFloat dominantLineHeight = [self dominantLineHeightInColumn:currentCol];
        NSMutableArray<XLPDFLine *> *tailBlock = nil;

        for (NSInteger blockIdx = (NSInteger)currentCol.count - 1; blockIdx >= 0; blockIdx--) {
            // 特别注意要倒叙，然后过滤飞主体文本block
            NSMutableArray<XLPDFLine *> *block = currentCol[blockIdx];
            if ([self lineHeightMatches:block withHeight:dominantLineHeight] &&
                [self isTailBlock:block]) {
                tailBlock = block;
                break;
            }
        }

        if (!tailBlock) continue;

        NSInteger searchCol = col + 1;
        while (searchCol < (NSInteger)columns.count) {

            NSMutableArray *searchNextCol = columns[searchCol];
            if (searchNextCol.count == 0) {
                searchCol++;
                continue;
            }

            NSArray<XLPDFLine *> *headBlock = nil;
            NSInteger headIdx = -1;
            for (NSInteger i = 0; i < (NSInteger)searchNextCol.count; i++) {
                NSArray<XLPDFLine *> *block = searchNextCol[i];
                if ([self isHeadBlock:block] &&
                    [self blockContainsParagraphEndingSymbol:block] &&
                    [self lineHeightMatches:tailBlock with:block]) {
                    headBlock = block;
                    headIdx   = i;
                    break;
                }
            }

            if (!headBlock) break;

            [self mergeBlock:headBlock intoBlock:tailBlock];
            [searchNextCol removeObjectAtIndex:headIdx];

            if (![self isTailBlock:tailBlock]) break;

            searchCol++;
        }
    }

    // 重整blockIndex + 构建结果数组
    NSMutableArray<NSArray<XLPDFLine *> *> *result = [NSMutableArray array];
    NSInteger idx = 0;
    for (NSMutableArray *column in columns) {
        for (NSArray<XLPDFLine *> *block in column) {
            for (XLPDFLine *line in block) line.blockIndex = idx;
            idx++;
            if ([self blockContainsParagraphEndingSymbol:block] || block.count > 6) {
                [result addObject:block];
            }
        }
    }

    return [result copy];
}

4.2 列检测：中心 X 聚类

跨栏合并需要先知道页面有几列，以及每列的 X 边界。引擎用了一个轻量的聚类方法：

// 收集所有行的中心X，排序后按间隙聚类
// 相邻 centerX 差值超过页宽的 10% → 认为是列间距
CGFloat gapThreshold = CGRectGetWidth(pageRect) * 0.10;

通过这个间隙阈值，可以把所有行的中心 X 分成若干簇，每簇的 [minX, maxX] 加上半行高的 padding 就是列的 X 范围。这比依赖页面宽度平均分割更准确，因为杂志栏宽不一定均等。

4.3 合并过程：倒序扫描 + 链式追踪

for (NSInteger col = 0; col < columns.count - 1; col++) {

    // 在当前列，倒序找最后一个"主体文字"的段尾 Block
    // （倒序是为了跳过可能存在的图注、小标题等非主体 Block）
    NSMutableArray *tailBlock = nil;
    CGFloat dominantLineHeight = [self dominantLineHeightInColumn:currentCol];
    for (NSInteger i = currentCol.count - 1; i >= 0; i--) {
        NSArray *block = currentCol[i];
        if ([self lineHeightMatches:block withHeight:dominantLineHeight] &&
            [self isTailBlock:block]) {
            tailBlock = block;
            break;
        }
    }

    if (!tailBlock) continue;

    // 在下一列，找第一个满足条件的段首 Block
    // 字号一致 + 无缩进 + 含句末标点（保证是正文段落，不是纯标题）
    NSArray *headBlock = nil;
    for (NSArray *block in nextCol) {
        if ([self isHeadBlock:block] &&
            [self blockContainsParagraphEndingSymbol:block] &&
            [self lineHeightMatches:tailBlock with:block]) {
            headBlock = block;
            break;
        }
    }

    // 合并：将 headBlock 的所有行追加进 tailBlock，修正 blockIndex 和 paragraphIndex
    [self mergeBlock:headBlock intoBlock:tailBlock];
    [nextCol removeObject:headBlock];

    // 如果合并后 tailBlock 仍是段尾 → 继续追踪到下下列（三栏情况）
    if ([self isTailBlock:tailBlock]) { /* 继续向右搜索 */ }
}

合并时对 paragraphIndex 的修正是一个容易出错的地方。next Block 的 paragraphIndex 从 0 开始编号，合并时需要续接 prev Block 的最大 paragraphIndex，同时修正 blockIndex 保持一致：

for (XLPDFLine *line in next) {
    line.blockIndex     = prevBlockIndex;
    line.paragraphIndex = (line.paragraphIndex - nextBaseIndex) + maxParagraphIndex;
    [prev addObject:line];
}

段落 ID 的设计

完成以上步骤后，每一行都携带了 pageIndex、blockIndex、paragraphIndex 三个坐标。段落 ID 由此生成：

mgid_pageIndex_blockIndex_paragraphIndex

例如：mag001_3_2_1 表示杂志 mag001，第 3 页，第 2 个文字区域，第 1 个段落。

这个 ID 有两个关键用途：

写入评论时：通过 paragraphIDFromSelection:document:mgid: 生成 ID，与评论数据一起存储到服务端。

读取评论时：通过 paragraphTextFromParagraphID:document: 反向解析 ID，定位到页面 → Block → paragraphIndex，取出对应行集合，用于高亮展示或文字复原。

反向定位的路径：

// 1. 解析 ID，得到 pageIndex / blockIndex / paragraphIndex
// 2. 取出对应页面
PDFPage *page = [document pageAtIndex:pageIndex];
// 3. 对整页重新执行分块
NSArray *pageBlocks = [self pageLinesBlocksFromPage:page document:document];
// 4. 按 blockIndex 取出对应 Block
NSArray *block = pageBlocks[blockIndex];
// 5. 按 paragraphIndex 过滤出段落行
NSArray *paragraph = [self paragraphLinesForParagraphIndex:paragraphIndex inBlock:block];

评论气泡（PDFAnnotation）的锚点应该定位在段落最后一行的位置，这样气泡显示在段尾更自然，同时把段尾行的位置信息传给服务器，服务端也能精确还原气泡坐标。

几个值得关注的工程细节

同行判断的阈值：PDF 中同一行的不同字符因字体 baseline 差异，midY 可能相差 1～3pt。引擎用行高的 50% 作为阈值，而不是固定的 1pt，避免同行字符被误判为不同行：

+ (BOOL)isSameLineByY:(CGRect)r1 rect:(CGRect)r2 {
    CGFloat threshold = MIN(CGRectGetHeight(r1), CGRectGetHeight(r2)) * 0.5;
    return fabs(CGRectGetMidY(r1) - CGRectGetMidY(r2)) < threshold;
}

列 maxX 用中位数：baseMaxXForColumn: 返回的是所有行 maxX 的中位数，而不是最大值。这样可以过滤掉个别行尾有标点符号溢出导致的 maxX 偏大问题，让"末行留白"的判断更稳定。

主体行高过滤：在跨栏合并中，用 dominantLineHeightInColumn: 计算列内出现频率最高的行高（取整后做频次统计），作为主体正文的行高基准。倒序扫描段尾 Block 时，只考虑字号与主体行高接近的 Block，这样可以跳过可能夹在正文之间的小字号图注或大字号小标题。

局限性与未来方向

当前实现在以下场景有一定局限：

竖排中文：过滤规则直接丢弃竖排行，不支持竖排杂志。
不规则分栏：栏宽差异极大时（如 1:3 的图文混排），X 轴聚类可能误判列数。
跨页段落：目前只处理单页内的跨栏，跨页的段落连续暂不支持。
表格内文字：表格单元格中的文字可能因行高相近而被当作正文处理。

小结

XLPDFParagraphEngine 的核心设计思路可以归纳为：用几何信息替代语义信息，逐层收敛不确定性。

层次	输入	输出	解决的问题
行提取	PDFSelection	XLPDFLine 数组	去除噪声行
几何分块	XLPDFLine 数组	Block 数组	区分独立文字区域
列识别 + 分段	Block	带 paragraphIndex 的行	还原阅读顺序和段落边界
跨栏合并	Block 数组	合并后的 Block 数组	修复跨栏断段

整个流水线不依赖任何 PDF 元数据，仅凭坐标和文本表面特征运作，因此对不同来源、不同排版风格的杂志 PDF 均有较好的适应性。

iOS 知识点 - IAP 是怎样的？

掘金 iOS

齐生1

2026年3月4日 20:04

一、IAP 基本概念

定义： In-App Purchase 是苹果提供的支付机制，允许用户在 App 内购买虚拟商品或订阅服务，所有数字内容和服务的交易必须通过 IAP 完成（苹果会抽成 15%～30%），否则会拒审。
类型：

类型	描述	使用场景	特点
Consumable（消耗型）	用完即消失，可反复购买	金币、体力、道具	不可恢复，需自己记录消耗
Non-Consumable（非消耗型）	永久可用，购买一次即可	解锁关卡、去广告、付费功能	可恢复，支持跨设备恢复
Auto-Renewable Subscription（自动续订订阅）	周期性付费，自动续订	VIP 会员、内容订阅	苹果处理续订、退款、过期提醒
Non-Renewing Subscription（非续订订阅）	周期性付费，但需手动续订	课程、限时会员	不自动续订，需要自己管理过期

消耗型商品必须在验证成功后调 finishTransaction，否则 Apple 会认为你还没发货，下次启动继续提醒。

四个核心名词：
- 商品（Product）:
  - 在 App Store Connect 后台配置的可购买项目。
  - 每个商品都有唯一的 productIdentifier，App 需要用这个 ID 去 Apple 查询商品的实时价格和货币信息，返回类型是 SPProduct(StoreKit 91) 或 Product(StoreKit 2)。
- 订单（Order）:
  - 自己服务器创建的记录。
  - 在调用 Apple 支付之前创建，拿到 order_id，用于后期的对账（钱对应哪个商品、给哪个用户、是购买还是赠送等等）。
  - Apple 不知道这个东西的存在，业务层概念。
- 交易（Transaction）:
  - Apple 侧产生的记录。
  - 在 Apple 的支付弹窗上确认付款后，Apple 会生成一笔交易。
  - 交易有多种状态：
```
purchasing(支付中) → purchased(已支付) → finished(已完成)
                  → failed(失败)
                  → deferred(等待家长审批)
                  → restored(恢复购买)
```
- 收据（Receipt）:
  - Apple 侧产生的付款凭证，证明用户确实付了钱。
  - 需要拿该凭证去服务器校验，服务器确认为真后才能发货，有两种格式：
    - StoreKit 1: 一个 Base64 编码的二进制文件(ASN.1)，存在 App 沙盒里(Bundle.main.appStoreReceiptURL)。
    - StoreKit 2: 一个 JWS（JSON Web Signature）字符串，带有 Apple 的数字签名，更安全，不存本地，通过 Transaction API 获取。
流程概述：

用户点击购买
  │
  ├─ ① App 用 productIdentifier 向 Apple 查询商品信息
  │     └─ Apple 返回 Product（价格、货币、描述）
  │
  ├─ ② App 向自己服务器创建订单，拿到 order_id
  │
  ├─ ③ 调用购买 API，Apple 弹出支付确认框
  │     └─ 用户输入密码 / Face ID / Touch ID
  │
  ├─ ④ Apple 返回交易结果（Transaction）
  │     ├─ purchased → 继续验证
  │     ├─ failed → 提示用户
  │     └─ deferred → 等待家长审批
  │
  ├─ ⑤ 拿 receipt/transaction 发给自己服务器验证
  │     └─ 服务器向 Apple 验证真伪（或本地验签 JWS）
  │     └─ 服务器确认后发货（加金币/开会员/解锁功能）
  │
  └─ ⑥ 调用 finishTransaction，告诉 Apple "我已发货"

二、StoreKit 1 与 StoreKit 2

维度	StoreKit 1（已废弃，但仍可用）	StoreKit 2（推荐）
语言	Objective-C / Swift 均可	Swift only
异步模式	Delegate 回调	async/await
最低版本	iOS 3+	iOS 15+
交易监听	SKPaymentTransactionObserver	Transaction.updates（AsyncSequence）
恢复购买	手动调 restoreCompletedTransactions()	自动可用，Transaction.currentEntitlements
收据验证	/verifyReceipt（服务端，已废弃）	JWS 本地验签 / App Store Server API
订阅状态	自己解析 receipt 推算	Product.SubscriptionInfo.status 直接获取
退款处理	收不到通知	Transaction.revocationDate 有值 = 已退款
家庭共享	不支持	内置支持

2.1 StoreKit 1 核心类

SKProductsRequest          → 请求商品信息
  └─ SKProductsRequestDelegate  → 回调商品列表
       └─ SKProduct            → 单个商品（价格、标题、描述）

SKPayment                  → 支付请求对象
SKPaymentQueue             → 交易队列（单例）
  └─ SKPaymentTransactionObserver  → 交易状态回调
       └─ SKPaymentTransaction     → 单笔交易（状态、receipt）

SKReceiptRefreshRequest    → 强制刷新本地收据

StoreKit 1 典型代码流程：

// 1. 查询商品
let request = SKProductsRequest(productIdentifiers: ["com.app.coin100"])
request.delegate = self
request.start()

// 2. 收到商品信息
func productsRequest(_ request: SKProductsRequest, didReceive response: SKProductsResponse) {
    let product = response.products.first!
    // 展示价格：product.localizedTitle, product.price
}

// 3. 发起购买
let payment = SKPayment(product: product)
SKPaymentQueue.default().add(payment)

// 4. 监听交易状态
func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
    for tx in transactions {
        switch tx.transactionState {
        case .purchased:
            // 验证收据 → 发货 → finish
            verifyAndDeliver(tx)
            queue.finishTransaction(tx)
        case .failed:
            queue.finishTransaction(tx)
        case .restored:
            queue.finishTransaction(tx)
        case .deferred, .purchasing:
        break
        }
    }
}

2.2 StoreKit 2 核心类

Product                         → 商品（静态方法 .products(for:) 查询）
Product.purchase()              → 发起购买，返回 PurchaseResult
Transaction                     → 交易（自带签名验证）
Transaction.updates             → AsyncSequence，监听新交易
Transaction.currentEntitlements → 当前有效权益（自动含恢复）
Transaction.finish()            → 确认已发货
Product.SubscriptionInfo        → 订阅状态（续订、过期、宽限期）

StoreKit 2 典型代码流程：

// 1. 查询商品
let products = try await Product.products(for: ["com.app.coin100"])
let product = products.first!

// 2. 发起购买
let result = try await product.purchase()

switch result {
case .success(let verification):
    // 3. 验证交易
    switch verification {
    case .verified(let transaction):
        // 发货
        await deliverContent(transaction)
        // 4. 告诉 Apple 已发货
        await transaction.finish()
    case .unverified(_, let error):
        // 签名验证失败，可能被篡改
        handleError(error)
    }
case .userCancelled:
    break
case .pending:
    // 等待家长审批 / 支付确认
    break
}

// 5. App 启动时监听未完成的交易
Task {
    for await result in Transaction.updates {
        if case .verified(let transaction) = result {
            await deliverContent(transaction)
            await transaction.finish()
        }
    }
}

三、购买流程

3.1 正常购买流程

    App                     Apple                   自己服务器
     │                        │                        │
     │──Product.products()──> │                        │
     │<──返回商品信息─────────  │                        │
     │                        │                        │
     │──创建订单────────────────────────────────────────>│
     │<──返回 order_id──────────────────────────────────│
     │                        │                        │
     │──product.purchase()──> │                        │
     │    (用户确认支付)        │                        │
     │<──Transaction───────── │                        │
     │                        │                        │
     │──发送 transaction/receipt 验证─────────────────> │
     │                        │          │──验证签名/调 Apple API──>│
     │                        │          │<──确认有效──────────────│
     │<──验证通过，已发货─────────────────────────────────│
     │                        │                        │
     │──transaction.finish()─>│                        │
     │                        │                        │

3.2 异常场景处理

场景	现象	处理方式
支付成功但 App 崩溃/网络断开	没调 finish，下次启动 Apple 会重新推送交易	App 启动时监听 Transaction.updates，重新验证并发货
用户取消支付	result == .userCancelled	不做任何处理
家庭共享/家长审批	result == .pending	提示用户等待，后续通过 Transaction.updates 接收结果
重复购买（消耗型）	正常，消耗型可重复买	每次都走完整验证流程
重复购买（非消耗型）	Apple 提示"你已购买过"	不会重复扣费，返回原始交易
退款	Apple 后台处理	服务端收到 S2S 通知 REFUND，或客户端检查 transaction.revocationDate
掉单（钱扣了但没收到交易）	极少见，通常是网络问题	服务端定期用 App Store Server API 查询用户交易历史

3.3 收据验证

	客户端验证	服务端验证（推荐）
安全性	低，可被越狱设备绕过	高，服务器可信环境
实现复杂度	简单	需要后端配合
适用场景	个人开发者、低价值商品	商业应用、涉及虚拟货币

四、服务端通知（Server-to-Server Notifications）

Apple 会主动推送事件到你配置的服务器 URL（在 App Store Connect 中设置）。

4.1 主要通知类型

通知类型	含义
SUBSCRIBED	用户首次订阅
DID_RENEW	自动续订成功
EXPIRED	订阅过期
DID_FAIL_TO_RENEW	续订失败（信用卡过期等）
GRACE_PERIOD_EXPIRED	宽限期结束
REFUND	用户退款
REVOKE	家庭共享撤销
CONSUMPTION_REQUEST	Apple 要求你提供消耗信息（用于退款裁决）
ONE_TIME_CHARGE	一次性购买通知（2025 新增）

4.2 通知格式

{
  "signedPayload": "<JWS 字符串>"
}

解码 JWS 后得到：

{
  "notificationType": "DID_RENEW",
  "subtype": "AUTO_RENEW",
  "data": {
    "signedTransactionInfo": "<JWS>",
    "signedRenewalInfo": "<JWS>"
  }
}

五、App Store Connect 配置

商品要在 App Store Connect 对应 App 的 App 内购买项目中配置并审核。

沙盒测试：
- App Store Connect → 用户和访问 → 沙盒测试员 → 添加测试 Apple ID
- 手机 App Store 登入沙盒账号，测试环境会使用沙盒账号模拟支付。

六、常见的架构策略

6.1 项目分层

View 层
  └─ 购买按钮、价格展示、订阅状态 UI

ViewModel / Manager 层
  └─ IAPManager（单例）
     ├─ 查询商品
     ├─ 发起购买
     ├─ 监听交易
     └─ 管理订阅状态

Service 层
  └─ IAPService（与服务器交互）
     ├─ 创建订单
     ├─ 验证收据
     └─ 查询购买记录

Apple 层
  └─ StoreKit 2 API

6.2 防掉单策略

                    正常流程                         异常恢复
                  ┌──────────┐                   ┌──────────────┐
用户购买  ───────> │ 服务器验证 │──> 发货            │ App 启动      │
                  │ + finish │                   │ Transaction   │
                  └──────────┘                   │ .updates 推送 │
                                                 │ 未 finish 的  │
                                                 │ 交易          │──> 重新验证发货
                                                 └──────────────┘

服务端兜底：
  - 定期调 App Store Server API 查用户交易历史
  - 对比自己数据库，找出 Apple 有但自己没发货的交易
  - 补发

七、一些 2025 年新动向

StoreKit 1 已被标记为 Deprecated（WWDC 2024），虽然仍能用，但新项目应该用 StoreKit 2
/verifyReceipt 接口已废弃，改用 App Store Server API
S2S Notifications V1 已废弃，改用 V2
iOS 18.4+ 新增：
- appTransactionID：每个 Apple 账户唯一标识
- Offer Codes 扩展到消耗型/非消耗型商品（之前只支持订阅）
- Advanced Commerce API：支持复杂的订阅附加组件
Xcode 16.2+ 必须升级，否则 iOS 18.2 上可能出现购买失败

UniApp开发应用多平台上架全流程：H5小程序iOS和Android

掘金 iOS

开心就好2025

2026年3月3日 17:45

UniApp 开发的应用上架流程因目标平台（如H5、小程序、iOS、Android）而异。以下是 UniApp 应用上架的详细流程和注意事项。

1.H5 上架

H5 应用的上架主要是将应用部署到服务器，并通过域名访问。

1.1打包 H5 应用

1.2部署到服务器

将打包后的文件上传到服务器（如Nginx、Apache）。
配置服务器，确保正确路由和资源加载。

1.3配置域名与 HTTPS

绑定域名，确保用户可以通过域名访问应用。
配置 HTTPS，确保数据传输安全。

1.4测试与发布

在浏览器中访问应用，确保功能正常。
将应用链接分享给用户。

2.小程序上架

以微信小程序为例，其他小程序（如支付宝、百度）流程类似。

2.1打包小程序

2.2上传到微信开发者工具

打开微信开发者工具，选择“导入项目”。
选择打包后的小程序目录，填写 AppID 和项目名称。
点击“确定”导入项目。

2.3调试与测试

在微信开发者工具中调试应用，确保功能正常。
使用真机预览功能，在手机上测试应用。

2.4提交审核

在微信开发者工具中点击“上传”。
填写版本号和项目备注，点击“上传”。
登录微信公众平台，提交审核。

2.5发布

审核通过后，在微信公众平台点击“发布”。
用户可通过微信搜索或扫码使用小程序。

3.iOS 上架

iOS 应用的上架需要通过 App Store 审核。

3.1打包 iOS 应用

使用 HBuilderX 的云打包功能：
- 打开 HBuilderX，选择“发行” -> “原生App-云打包”。
- 选择 iOS 平台，配置证书和描述文件。
- 点击“打包”，生成 .ipa 文件。

对于证书和描述文件的管理，开发者可以使用AppUploader工具直接创建和管理iOS开发者或发布证书，无需钥匙串助手，支持多电脑协同使用，简化证书申请流程。

3.2配置 App Store Connect

登录 App Store Connect。
创建新应用，填写应用名称、描述、截图等信息。
上传应用图标和预览视频。

AppUploader还支持批量上传应用截图和描述信息到App Store Connect，提高效率。

3.3上传应用

使用 Xcode 或 Transporter 工具上传 .ipa 文件到 App Store Connect。

此外，AppUploader工具允许开发者在Windows、Linux或Mac系统中直接上传IPA文件到App Store，无需Mac电脑，比传统工具更高效。

3.4提交审核

在 App Store Connect 中提交应用审核。
填写审核信息，确保符合 Apple 的审核指南。

3.5发布

审核通过后，设置发布日期。
应用会自动发布到 App Store。

4.Android 上架

Android 应用的上架主要通过 Google Play 或其他应用商店。

4.1打包 Android 应用

使用 HBuilderX 的云打包功能：
- 打开 HBuilderX，选择“发行” -> “原生App-云打包”。
- 选择 Android 平台，配置签名证书。
- 点击“打包”，生成 .apk 或 .aab 文件。

4.2配置 Google Play Console

登录 Google Play Console。
创建新应用，填写应用名称、描述、截图等信息。
上传应用图标和预览视频。

4.3上传应用

在 Google Play Console 中上传 .aab 或 .apk 文件。

4.4提交审核

填写应用内容分级和隐私政策。
提交应用审核，确保符合 Google Play 的政策。

4.5发布

审核通过后，设置发布日期。
应用会自动发布到 Google Play。

5.上架注意事项

5.1应用合规

确保应用内容符合各平台的政策和法律法规。
提供隐私政策链接，明确用户数据使用方式。

5.2应用图标与截图

提供高质量的图标和截图，符合平台要求。
确保截图展示应用的核心功能。

5.3版本管理

使用语义化版本号（如 v1.0.0）。
记录版本更新日志，方便用户了解新功能。

5.4测试与优化

在上架前进行全面测试，确保应用稳定运行。
优化应用性能，提升用户体验。

总结

UniApp 应用的上架流程因目标平台而异，但总体包括打包、配置、上传、审核和发布等步骤。通过合理的上架流程和注意事项，可以确保应用顺利发布并触达用户。

flutter接入三方库运行报错：Error running pod install

掘金 iOS

王晓枫

2026年3月3日 17:33

最近在研究flutter，在flutter中引入第三方webview_flutter后，运行iOS设备时报错，具体报错如下：

Error running pod install

Error launching application on iPhone 15.

看问题时iOS的cocoapod在执行pod install命令下载第三方库时出现问题，如是我们找到项目中ios目录，使用xcode打开项目看看情况，

打开后发现项目包错Module 'webview_flutter_wkwebview' not found，很明显这里第三方没有下载下来

如是我们打开控制台cd 到项目的iOS目录，执行pod install这时候我们能看到控制台提示：- /Library/Ruby/Gems/2.6.0/gems/ffi-1.17.0-arm64-darwin/lib/2.6/ffi_c.bundle (LoadError)

/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- ffi_c (LoadError)

这个错误表明 Ruby 在尝试加载 ffi_c 时失败了，通常是因为 ffi gem 没有正确安装或与系统 Ruby 不兼容

重新安装 ffi gem

ffi gem 可能没有正确安装或损坏，可以尝试重新安装。

卸载ffi gem：

gem uninstall ffi

#如果报权限问题就使用

sudogem uninstall ffi

重新安装 ffi gem：

gem install ffi

#如果报权限问题就使用

sudo gem install ffi

升级ruby环境

本地环境很多依赖于默认的ruby环境，所以我们可以使用rvm管理和安装多个版本ruby

安装 rvm：

\curl -sSL get.rvm.io | bash -s stable

安装一个 Ruby 版本（如 3.0.0）：

rvm install 3.0.0

rvm use 3.0.0 --default

验证 Ruby 版本：

ruby-v

查看所有ruby：

rvm list

在安装ruby的时候我出现了下面的包错

Error running '__rvm_make -j6',

please read /Users/apple/.rvm/log/1739849439_ruby-3.0.0/make.log

我怀疑指定的OpenSSL版本可能没生效，于是干脆通过brew uninstall openssl命令把最新版本的OpenSSL卸载了，再次执行上面的命令一切正常🎉！

解决方案

如果不局限于安装Ruby 3.0版本，那么可以通过安装更高的Ruby版本解决该问题，可以参考这篇文章RVM - 安装最新Ruby版本。

如果一定要安装Ruby 3.0版本，请安装1.1版本的OpenSSL，并卸载最新版本，同时指定使用HomeBrew安装的OpenSSL完成安装：

安装1.1版本的OpenSSL

brew install openssl@1.1

卸载最新版本的OpenSSL

brew uninstall openssl

指定使用HomeBrew安装的OpenSSL完成安装

rvm install ruby-3.0.0 --with-openssl-dir=brew --prefix openssl

如果不想卸载最新版本，可以通过brew link命令切换（链接）openssl的版本完成安装：

安装1.1版本的OpenSSL

brew install openssl@1.1

切换OpenSSL的版本为1.1

brew link --overwrite openssl@1.1

--overwrite参数的作用是强制切换。如果不使用该参数，可以先执行brew unlink openssl命令后再执行brew link openssl@1.1命令完成切换。

指定使用HomeBrew安装的OpenSSL完成安装

rvm install ruby-3.0.0 --with-openssl-dir=brew --prefix openssl@1.1

执行完成后再次执行pod install 报错: `find_spec_for_exe':can't find gem cocoapods (>= 0.a) with executable pod (Gem::GemNotFoundException)

因使用 brew 安装工具导致 ruby 环境错乱，执行pod install时报错提示找不到 gem 可执行文件

Traceback (most recent call last): 2: from /usr/local/bin/pod:23:in ' 1: from /Library/Ruby/Site/2.6.0/rubygems.rb:294:in activate_bin_path'/Library/Ruby/Site/2.6.0/rubygems.rb:275:in `find_spec_for_exe': can't find gem cocoapods (>= 0.a) with executable pod (Gem::GemNotFoundException)

解决办法:

重新安装 ruby 环境（默认安装最新版本）

rvm reinstall ruby --disable-binary

运行结果

mruby-1.3.0 - #removing src/mruby-1.3.0 - please waitmruby-1.3.0 - #removing rubies/mruby-1.3.0 - please waitRVM does not have prediction for required space for mruby-1.3.0, assuming 150MB should be enough, let us know if it was not.Checking requirements for osx.Certificates bundle '/usr/local/etc/openssl@1.1/cert.pem' is already up to date.Requirements installation successful.Installing Ruby from source to: /Users/jack/.rvm/rubies/mruby-1.3.0, this may take a while depending on your cpu(s)...mruby-1.3.0 - #downloading 1.3.0, this may take a while depending on your connection...mruby-1.3.0 - #extracting 1.3.0 to /Users/jack/.rvm/src/mruby-1.3.0 - please waitmruby-1.3.0 - #compiling - please waitmruby-1.3.0 - #installing - please waitInstall of mruby-1.3.0 - #completeRequired ruby-2.7.0 is not installed.To install do: 'rvm install "ruby-2.7.0"'

重新安装 cocoapods

gem install cocoapods

运行结果：

Successfully installed cocoapods-1.9.3Parsing documentation for cocoapods-1.9.3Done installing documentation for cocoapods after 1 seconds1 gem installed

再重新执行pod install就OK了

Homebrew，是Mac OS X上的软件包管理工具，使用起来非常方便，安装任意软件包时 brew 会自动下载其依赖；

RubyGems 提供了ruby社区gem的托管服务，主要用于下载、安装使用 ruby 软件包

平常 iOS 开发使用 cocoapods 等工具都是使用 gems 进行安装管理，当使用 brew 安装软件包时有可能因依赖导致 ruby 环境错乱，不建议混合使用（使用 brew 也可以安装 cocoapods 而且很方便）

再次运行项目，又发现新的包错： 'Flutter/Flutter.h not found'

这里这样做

1、为了保守起见先备份ios文件

2、删除iOS文件

3、cd到项目跟目录执行命令重新创建ios项目

flutter create .

4、将备份的ios重要文件替换进来

详细见：www.kindacode.com/article/flu…

免 Xcode 的 iOS 开发新选择？聊聊一款更轻量的 iOS 开发 IDE kxapp 快蝎

掘金 iOS

开心就好2025

2026年3月3日 14:54

在 iOS 开发领域，Xcode 几乎是默认标配。但这些年做项目的过程中，我越来越频繁地遇到一些现实问题：版本更新频繁、安装包体积巨大、不同系统环境兼容性复杂、团队成员机器配置差异明显……尤其是在需要快速验证想法、做 Demo 或维护多个项目时，环境本身反而成了效率瓶颈。

最近在技术社区里看到不少人讨论一款名为快蝎的 iOS 开发 IDE（ kxapp.com/ ），主打“免 Xcode 开发 iOS”。

一、为什么会有人想“绕开”Xcode？

不是说 Xcode 不好，而是它确实越来越“重”。

安装包体积大，更新频率高
多版本切换成本高
真机调试证书配置复杂
某些跨平台项目需要额外适配

对于资深开发者来说，这些问题可以解决，但它们会消耗时间。对于新手来说，这些反而是第一道门槛。

如果有一个工具能把“环境搭建”这件事去掉，让开发者更专注于代码本身，其实是件挺有吸引力的事。

二、从项目创建开始，流程确实更简化

快蝎给我的第一印象是轻量。安装完成后，可以直接创建 Swift、Objective-C 或 Flutter 项目，不需要手动搭建模板结构。

项目结构是规范化生成的，新建即用，没有那种“先配半天环境再写第一行代码”的感觉。尤其是 Flutter 项目直接支持 iOS 构建，这点在跨端开发中比较实用。

对于经常写原生和混合项目的人来说，这种“一站式支持多项目类型”的方式确实省事，不用在不同工具之间频繁切换。

三、真机调试体验，少了一些步骤

iOS 开发最真实的体验一定是在真机上。模拟器再强，也无法完全替代真实设备环境。

快蝎内置了真机实时调试引擎，连接 iPhone 后可以一键构建并安装运行，不需要额外打开 Xcode，也不用手动导出 IPA。

我实际测试时，从修改代码到同步到手机，大概几秒完成，调试过程比较顺畅。对比传统流程：

切回 Xcode
选择设备
构建运行
可能还要处理签名问题

这种流程减少带来的体验差异还是挺明显的。

特别是在频繁改 UI、调交互细节时，所见即所得的反馈节奏，会让开发状态更连贯。

四、免 Xcode 开发 iOS 的可行性

不少人第一反应会问：真的可以不装 Xcode 吗？

从使用体验来看，快蝎内置了自主研发的编译工具套装，可以完成 iOS App 的开发、构建与生成安装包流程。对于日常开发、测试构建来说是完全够用的。

当然，如果涉及某些极端底层调试或特殊配置场景，传统工具链依然有价值。但对于大多数业务开发者来说，能减少对 Xcode 的依赖，本身就是一种效率提升。

尤其是在不想频繁升级 Xcode 版本、担心系统兼容问题时，这种独立工具链的价值就会体现出来。

五、基于 VSCode 架构的编码体验

这一点是我比较喜欢的。

快蝎的编辑体验基于 VSCode 生态，可以使用熟悉的快捷键、插件体系以及各种 AI 代码助手。对于已经习惯 VSCode 工作流的开发者来说，上手成本几乎为零。

智能提示、代码补全、规范化项目结构都做得比较流畅。写代码时没有明显卡顿感，整体体验偏“轻快型”，而不是传统 IDE 的沉重感。

对于长期写业务代码的人来说，工具的流畅度其实会直接影响专注度。少一点卡顿和等待，多一点即时反馈，长时间开发时差异会非常明显。

六、从开发到发布：流程闭环

很多工具只解决某个环节，但真正提高效率的是“闭环”。

在快蝎里，从创建项目、编码、调试到构建生成安装包，流程都在同一个界面内完成。开发完成后可以一键构建安装包，用于测试分发或提交 App Store。

整个过程不需要频繁切换工具，也没有复杂命令行操作。这种全流程整合，对于中小团队或者个人开发者来说尤其友好。

七、适合什么类型的开发者？

根据我的体验，这类工具比较适合：

想快速验证产品想法的独立开发者
需要维护多个 iOS 项目的工程师
使用 Flutter 同时涉及 iOS 构建的开发者
希望减少环境折腾时间的新手

它并不是要取代传统工具，而是提供另一种更轻量的选择。

工具趋势的一个信号

这几年开发工具的发展方向很明显：更轻量、更自动化、更智能。

从容器化部署到云开发环境，再到 AI 辅助编码，本质上都是在减少非核心成本。iOS 开发工具链也在发生变化，出现像快蝎这样的方案，其实是顺应趋势。

开发者真正关心的不是工具本身，而是效率、稳定性和可控性。如果一个 IDE 能让开发流程更简单，同时不牺牲性能和安全性，它就有存在的空间。

做开发这些年，最大的感受是：时间比工具重要。

如果一个工具能让你少花时间在配置上，多花时间在产品和代码质量上，那它就值得尝试。快蝎这种免 Xcode 的 iOS 开发 IDE，本质上是在优化流程，而不是改变语言或技术栈。

对于习惯传统工具链的人来说，也许可以把它当作一个备用方案或效率补充。对于刚入门 iOS 的开发者来说，它可能会让第一步走得更轻松。

技术从来不是非黑即白，多一个选择，往往意味着多一种可能。

iOS 深度解析

掘金 iOS

忆江南

2026年3月2日 18:07

1. iOS 启动流程

1.1 启动的宏观阶段划分

iOS App 的启动可分为两个大阶段：pre-main 阶段（main 函数执行之前）和 post-main 阶段（main 函数执行之后到首帧渲染完成）。

冷启动（Cold Launch）：App 完全不在内存中，需要从磁盘加载所有资源，经历完整的 pre-main 和 post-main 流程。
热启动（Warm Launch）：App 进程虽然被终止，但部分数据仍然在系统内核的页缓存中（page cache），此时 dyld 加载速度会更快。
恢复启动（Resume）：App 只是从后台切回前台，不涉及进程创建，严格意义上不算"启动"。

1.2 Pre-main 阶段详解

1.2.1 内核阶段（Kernel）

当用户点击 App 图标时，系统通过 launchd 进程（PID=1）fork 出一个新的进程。内核为新进程完成以下工作：

创建进程：分配 PID，创建虚拟内存空间（每个进程都有独立的 4GB/16EB 虚拟地址空间）。
ASLR（Address Space Layout Randomization）：生成一个随机偏移值（slide），将 Mach-O 的加载基地址随机化，防止固定地址攻击。ASLR 是在内核层面实现的，每次启动 slide 不同。
加载可执行文件：将 Mach-O 的头部和 Load Commands 映射到虚拟内存中（注意是映射，不是全部读入物理内存，利用的是 mmap 和按需缺页机制）。

1.2.2 dyld 阶段（Dynamic Linker）

dyld（dynamic link editor）是 Apple 的动态链接器，它是第一个在用户态运行的代码。Apple 在 iOS 13/macOS 11 之后将 dyld 升级到了 dyld3 和后来的 dyld4，引入了启动闭包（Launch Closure）机制。

dyld 的核心工作流程：

a) 加载动态库（Load Dylibs）

dyld 根据 Mach-O 的 LC_LOAD_DYLIB 等 Load Commands，递归地加载所有依赖的动态库。每个动态库自身也可能依赖其他动态库，形成一棵依赖树。系统共享库（如 UIKit、Foundation）通过 dyld shared cache（共享缓存）提前合并优化，存放在 /System/Library/Caches/com.apple.dyld/ 下，加载速度极快。

动态库的加载过程：

解析 Mach-O Header，验证魔数（Magic Number）、CPU 架构、文件类型。
读取 Load Commands，确定各 Segment（__TEXT、__DATA、__LINKEDIT）的内存映射方式。
调用 mmap() 将文件内容映射到虚拟内存。
由于使用了 Copy-on-Write（COW）技术，只读段可以被多个进程共享物理内存。

b) Rebase（基址重定位）

由于 ASLR 的存在，Mach-O 中所有写死的内部指针地址都需要加上 slide 偏移量。这个过程就是 Rebase。

Rebase 主要操作 __DATA 段中的指针。现代的 chained fixups（链式修正）格式将 rebase 信息直接编码在指针值中，减少了 __LINKEDIT 的大小，也加速了处理。

Rebase 的性能瓶颈不在于计算（加法操作极快），而在于 Page Fault：当访问尚未加载到物理内存的虚拟页时，会触发缺页中断，内核需要从磁盘读取对应的页并进行解密验证（如果开启了代码签名验证）。

c) Bind（符号绑定）

Bind 处理的是对外部动态库符号的引用。App 中调用的 NSLog、objc_msgSend 等函数，在编译时并不知道它们的真实地址，需要在运行时通过符号名查找。

Lazy Binding（懒绑定）：大部分外部函数调用使用懒绑定，第一次调用时才通过 dyld_stub_binder 查找真实地址并回填到 __DATA.__la_symbol_ptr（Lazy Symbol Pointer）中，后续调用直接跳转，不再走 dyld。
Non-Lazy Binding（非懒绑定）：部分符号（如 Objective-C 类引用、全局变量指针）需要在启动时立即绑定，存放在 __DATA.__nl_symbol_ptr（Non-Lazy Symbol Pointer）中。
Weak Binding（弱绑定）：__attribute__((weak)) 修饰的符号需要搜索所有已加载的镜像来确定是否有强定义覆盖，开销较大。

d) dyld3/dyld4 的 Launch Closure

dyld3 引入了 Launch Closure（启动闭包）机制——将首次启动时的解析结果（依赖关系、rebase/bind 信息、初始化顺序等）序列化保存到磁盘。后续启动时直接读取闭包文件，跳过大量解析工作。

dyld4 进一步引入了 PrebuiltLoaderSet，对 App 的启动路径做了更激进的预计算。

1.2.3 Objective-C Runtime 初始化

dyld 在完成所有动态库的加载和绑定后，会调用注册的初始化函数。ObjC Runtime 的初始化是其中最重要的一步：

map_images：当新的 Mach-O 镜像被映射到内存时调用。Runtime 解析 __DATA.__objc_classlist、__DATA.__objc_catlist（Category 列表）、__DATA.__objc_protolist（Protocol 列表）等 section，将类、分类、协议注册到全局表中。
类的实现（Realize）：将类从磁盘格式转换为运行时格式，设置 superclass 指针、method list、ivar layout 等。这个过程是懒加载的——只有第一次使用类时才会 realize。
Category 的附加：将 Category 中的方法、属性、协议"织入"到对应的类中。方法会被插入到方法列表的前面，这就是 Category 能"覆盖"原类方法的原因。
load_images：调用所有类和 Category 的 +load 方法。调用顺序：先按编译顺序调用父类的 +load，再调用子类的，最后调用 Category 的。+load 在所有类完成注册后、任何 +initialize 之前执行。

1.2.4 C++ 静态初始化器

所有标记了 __attribute__((constructor)) 的函数以及 C++ 全局对象的构造函数会在此阶段被调用。它们通过 __DATA.__mod_init_func section 记录。

1.2.5 执行 main 函数

完成以上所有步骤后，dyld 调用 App 可执行文件的入口点，即 main() 函数。

1.3 Post-main 阶段详解

1.3.1 UIApplicationMain

main() 函数通常只做一件事：调用 UIApplicationMain()。这个函数完成：

创建 UIApplication 单例对象。
创建 App Delegate 对象。
启动主线程的 RunLoop（CFRunLoopGetMain()）。
加载 Info.plist，如果指定了 Main Storyboard，则加载并实例化初始 ViewController。

1.3.2 Application Lifecycle Callbacks

按照 iOS 13+ 的 Scene-based Life Cycle（多窗口架构）：

application:didFinishLaunchingWithOptions: — App 级别的初始化入口。
scene:willConnectToSession:options: — Scene 连接。
sceneWillEnterForeground: — 即将进入前台。
sceneDidBecomeActive: — 已激活，用户可交互。

1.3.3 首帧渲染（First Frame Render）

首帧渲染标志着用户可以看到 App 的实际界面。系统在第一次 CATransaction commit 时将渲染树提交给 Render Server（一个独立进程 backboardd），完成 GPU 合成并上屏。

Apple 的 App Launch Instrument 以 CA::Transaction::commit() 中第一帧绘制完成作为启动结束的标志。

1.4 Mach-O 文件格式补充

Mach-O 是 macOS/iOS 的可执行文件格式，理解它对理解启动流程至关重要：

区域	内容
Header	魔数、CPU 类型、文件类型（MH_EXECUTE/MH_DYLIB）、Load Commands 数量
Load Commands	描述文件布局的元数据：段的位置和大小、动态库依赖、入口点、代码签名位置等
__TEXT	只读、可执行：机器码（`__text`）、ObjC 方法名（`__objc_methname`）、字符串常量（`__cstring`）等
__DATA	可读写：全局变量、ObjC 类数据、符号指针表等
__DATA_CONST	启动后只读：ObjC 类列表、协议列表等（rebase/bind 后被 `mprotect` 设为只读）
__LINKEDIT	动态链接器使用的元数据：符号表、字符串表、rebase/bind 操作码、代码签名等

2. 启动优化

2.1 度量体系

2.1.1 Apple 官方指标

TTID（Time to Initial Display）：App 进程创建到第一帧渲染完成的时间。Apple 建议冷启动控制在 400ms 以内。
MetricKit：MXAppLaunchMetric 提供生产环境的启动耗时数据（p50/p90/p99）。
DYLD_PRINT_STATISTICS：设置此环境变量可在控制台输出 pre-main 阶段各步骤的耗时。

2.1.2 自建度量

在 +load 或进程创建时记录起始时间戳，在首帧 viewDidAppear: 或 CADisplayLink 回调中记录结束时间戳，差值即为端到端启动时间。注意要使用 mach_absolute_time() 或 clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW) 获取高精度时间，避免使用 NSDate（会受 NTP 校时影响）。

2.2 Pre-main 阶段优化

2.2.1 减少动态库数量

每个自定义动态库都会增加 dyld 的加载、rebase、bind 开销。Apple 建议自定义动态库不超过 6 个。

优化手段：

将多个小型动态 framework 合并为一个。
能用静态库的场景优先使用静态库（静态库在编译链接阶段就合并到了主二进制中，不增加 dyld 的运行时负担）。
使用 xcframework 统一管理多架构，避免重复链接。

2.2.2 减少 ObjC 元数据

减少类和 Category 的数量：每个 ObjC 类都需要在 map_images 阶段注册到 Runtime 的全局类表中，每个 Category 都需要被合并到宿主类。大量无用的类会拖慢这个过程。
清理无用代码：使用 LinkMap 文件分析各模块大小，结合 AppCode 的 Inspect Code 或开源工具（如 fui、periphery）找出未使用的类和方法。
Swift 优势：Swift 的结构体和枚举不经过 ObjC Runtime，不产生 map_images 的注册开销。能用 Swift 值类型代替 ObjC 类的场景应优先考虑。

2.2.3 消灭 +load 方法

+load 方法在启动的极早期串行执行（持有 Runtime 的全局锁），任何耗时操作都会直接阻塞启动。

替代方案：

+initialize：懒加载，在类第一次收到消息时调用，且只调用一次（线程安全由 Runtime 保证）。将初始化逻辑从 +load 迁移到 +initialize 可以将开销延后到实际使用时。
__attribute__((constructor)) 也应减少：与 +load 类似，在 main() 之前执行。

2.2.4 二进制重排（Binary Reordering）

原理：App 启动时并非所有代码都会被立即执行。由于虚拟内存的分页机制（iOS 上每页 16KB），启动时执行的函数如果分散在不同的页中，会导致大量 Page Fault。每次 Page Fault 需要从磁盘读取一页并进行代码签名验证（对于加密的 App），耗时约 0.1~~0.3ms。如果启动路径上有 2000 次 Page Fault，累计开销可达 200~~600ms。

做法：

使用 Clang 的 SanitizerCoverage（-fsanitize-coverage=func,trace-pc-guard）编译代码，在每个函数入口插入回调，记录启动路径上所有被调用的函数及其顺序。
生成 Order File（.order 文件），按启动调用顺序列出函数符号。
在 Xcode 的 Build Settings 中设置 Order File 路径，链接器会按指定顺序排布函数，使启动路径上的函数尽量集中在连续的页中，减少 Page Fault。

效果：对于大型 App，Page Fault 次数可减少 30%~~70%，带来 100~~300ms 的启动提升。

2.2.5 dyld3/dyld4 闭包缓存

现代 iOS 系统已默认使用 dyld3 闭包。开发者能做的是确保不破坏闭包缓存的有效性——每次 App 更新后首次启动闭包需要重新生成，这属于不可避免的开销。

2.3 Post-main 阶段优化

2.3.1 任务分级与延迟加载

将 didFinishLaunchingWithOptions: 中的初始化任务按优先级分为三类：

优先级	任务类型	执行时机
P0	崩溃监控、AB 实验框架	`didFinishLaunching` 最前面，同步执行
P1	网络库初始化、用户登录态恢复	`didFinishLaunching` 中异步执行
P2	分享 SDK、推送注册、非首屏功能	首帧渲染后延迟执行（通过 RunLoop idle 或延时 dispatch）

关键原则：首帧渲染前只做必须做的事。

2.3.2 首页渲染优化

缓存上次的首页截图：在启动时展示缓存截图（skeleton screen 或快照），让用户感知到"已打开"，待真实数据加载完成后替换。
减少首页视图层级：使用 Instruments 的 View Debugger 分析视图层级深度，减少不必要的嵌套。
避免首帧同步网络请求：使用本地缓存数据渲染首帧，网络数据到达后差量更新。

2.3.3 子线程预加载

将不需要在主线程执行的初始化任务放到并发队列中并行执行：

数据库初始化和预热。
预加载常用的图片资源到内存缓存。
预建立 HTTP/2 连接（TCP + TLS 握手）。

注意：UIKit 操作必须在主线程，CoreData 的 NSManagedObjectContext 要注意线程隔离。

2.3.4 启动任务调度框架

大型 App 通常会搭建启动任务调度框架，支持：

声明式地定义任务、依赖关系和线程要求。
自动拓扑排序确定执行顺序。
并行执行无依赖关系的任务。
监控每个任务的耗时，自动上报异常。

2.4 持续劣化防护

CI 卡口：在 CI 流水线中集成启动耗时测试（使用 XCTest + MetricKit 或自定义打点），设置阈值，超标则阻断合入。
LinkMap 体积监控：监控二进制体积增长（尤其是 __DATA 段的增长），它与 rebase/bind 耗时正相关。
+load 扫描：通过静态分析工具在编译期扫描新增的 +load 方法。

3. 网络优化

3.1 网络请求的全链路分析

一次 HTTPS 请求的完整链路：

DNS 解析 → TCP 三次握手 → TLS 握手 → 请求发送 → 服务器处理 → 响应接收 → 数据解析

每个环节都有优化空间。

3.2 DNS 优化

3.2.1 传统 DNS 的问题

解析延迟：首次解析需要递归查询根域名服务器 → 顶级域名服务器 → 权威域名服务器，耗时 50~200ms，极端情况下可达数秒。
DNS 劫持：运营商 LocalDNS 可能返回篡改的 IP 地址，将用户引导到广告页或错误服务器。
调度不精准：运营商 DNS 的出口 IP 与用户的实际 IP 可能不在同一地区，导致 CDN 调度到非最优节点。
DNS 缓存不可控：系统 DNS 缓存（res_9_getaddrinfo）的 TTL 由服务端控制，App 无法主动管理。

3.2.2 HTTPDNS

HTTPDNS 通过 HTTP/HTTPS 协议直接向 DNS 服务商（如阿里云 HTTPDNS、腾讯云 HTTPDNS）发送域名解析请求，绕过运营商 LocalDNS。

核心优势：

防劫持：使用 HTTPS 通道加密传输，运营商无法篡改。
精准调度：可以携带客户端真实 IP（EDNS Client Subnet），CDN 能调度到最优节点。
可控缓存：App 自主管理 DNS 缓存和预解析策略。

实现要点：

预解析：App 启动时对常用域名发起预解析，将结果缓存在本地。
缓存策略：本地维护 IP 缓存池，设置合理的 TTL。TTL 过期后异步刷新，期间仍使用旧 IP（"乐观缓存"策略），避免解析等待。
降级机制：HTTPDNS 服务异常时自动降级到系统 DNS。
SNI 问题：使用 HTTPDNS 后，HTTPS 请求的 Host 头是 IP 地址，需要手动设置 SNI（Server Name Indication）字段为原始域名，否则 TLS 握手会因证书不匹配而失败。在 NSURLSession 中需要实现 URLSession:didReceiveChallenge:completionHandler: 代理方法处理证书验证。

3.2.3 DNS-over-HTTPS (DoH) / DNS-over-TLS (DoT)

iOS 14+ 原生支持 DoH/DoT（通过 NEDNSSettingsManager），但这是系统级别的配置，App 级别的定制灵活性不如 HTTPDNS。

3.3 连接优化

3.3.1 连接复用

HTTP/1.1 Keep-Alive：在同一个 TCP 连接上串行发送多个请求，避免每次请求都建立新连接。但存在 队头阻塞（Head-of-Line Blocking） 问题——前一个请求未完成时后续请求必须等待。
HTTP/2 多路复用（Multiplexing）：在单个 TCP 连接上并行发送多个请求/响应，通过帧（Frame）和流（Stream）的概念实现真正的并发。一个连接可以同时承载上百个请求。但 TCP 层的队头阻塞依然存在——一个丢包会阻塞整个连接上的所有流。
HTTP/3 (QUIC)：基于 UDP，在传输层消除了队头阻塞。每个流独立进行丢包重传，互不影响。同时集成了 TLS 1.3，握手延迟更低（0-RTT/1-RTT）。iOS 15+ 的 NSURLSession 默认支持 HTTP/3。

3.3.2 预连接（Pre-connect）

在用户可能发起请求之前，提前完成 TCP + TLS 握手，使后续请求可以直接发送数据。

实现方式：使用 NSURLSession 的连接预热 API，或自行管理连接池。

3.3.3 连接迁移（Connection Migration）

传统 TCP 连接以四元组（源 IP、源端口、目的 IP、目的端口）标识，当用户从 WiFi 切换到蜂窝时，源 IP 变化导致连接断开。QUIC 使用 Connection ID 标识连接，网络切换时连接不中断，实现无缝迁移。

3.4 数据传输优化

3.4.1 数据压缩

Gzip/Brotli：在 HTTP 响应头中设置 Content-Encoding: gzip/br。Brotli 压缩率比 gzip 高 15~25%，特别适合文本类数据。NSURLSession 自动处理 gzip 解压。
Protocol Buffers / FlatBuffers：使用二进制序列化替代 JSON。Protobuf 体积比 JSON 小 3~~10 倍，解析速度快 20~~100 倍。适用于高频接口和大数据量场景。
增量更新（Delta Sync）：只传输变化的部分，而非全量数据。可以使用 JSON Patch（RFC 6902）或自定义 diff 算法。

3.4.2 请求合并与批处理

将多个小请求合并为一个批量请求，减少网络往返次数（RTT）。例如将 10 个独立的埋点上报请求合并为 1 个批量请求。

3.4.3 精简数据

按需请求字段：使用 GraphQL 或接口的 fields 参数，只请求客户端真正需要的字段，减少无用数据传输。
分页加载：对列表类数据实施分页，避免一次加载全量数据。

3.5 缓存策略

3.5.1 HTTP 缓存

强缓存：Cache-Control: max-age=3600 和 Expires 头。在有效期内直接使用本地缓存，不发起网络请求。
协商缓存：ETag / If-None-Match 或 Last-Modified / If-Modified-Since。客户端携带标识请求服务器，若资源未变则返回 304，节省传输带宽。
NSURLSession 的缓存策略：通过 NSURLRequest.cachePolicy 控制，NSURLCache 自动管理磁盘和内存缓存。

3.5.2 业务层缓存

将接口返回数据持久化到本地（SQLite、文件），优先展示缓存数据，网络数据到达后更新 UI（"先展示后刷新"策略）。
对于不频繁变化的数据（如配置信息），使用较长的本地缓存有效期。

3.6 弱网优化

超时策略：针对不同网络质量动态调整超时时间。WiFi 下 15s，4G 下 20s，3G/2G 下 30s。
重试策略：指数退避（Exponential Backoff）+ 抖动（Jitter）。避免重试风暴压垮服务器。只对幂等请求（GET、PUT）重试，POST 请求需要业务层保证幂等性。
网络质量检测：通过 NWPathMonitor（Network Framework）实时监听网络状态变化，结合 RTT、丢包率估算网络质量，动态降级（如切换到低分辨率图片）。
多通道竞速：在 WiFi 和蜂窝同时可用时，并行发起请求，取先返回的结果。NSURLSessionConfiguration.multipathServiceType 支持 MPTCP（Multipath TCP）。

3.7 安全层优化

TLS 1.3：将握手往返从 2-RTT（TLS 1.2）减少到 1-RTT，支持 0-RTT 恢复（PSK，Pre-Shared Key）。iOS 12.2+ 默认支持。
证书固定（Certificate Pinning）：在 App 内预埋服务器证书的公钥哈希，防止中间人攻击。需要注意证书轮换的运维流程。
OCSP Stapling：服务器在 TLS 握手时主动提供证书状态（是否被吊销），避免客户端额外查询 OCSP 服务器。

3.8 监控体系

URLSessionTaskMetrics（iOS 10+）：提供每个请求的详细时间线——DNS 解析时间、连接建立时间、TLS 握手时间、请求发送时间、响应接收时间等。这是做网络性能分析的核心数据源。
端到端监控指标：成功率、平均耗时、P99 耗时、DNS 解析耗时、首字节时间（TTFB）、错误类型分布等。
网络链路追踪：在请求头中注入 Trace ID，贯穿客户端 → CDN → 网关 → 后端服务，实现全链路问题定位。

4. RunLoop

4.1 RunLoop 的本质

RunLoop 本质上是一个 事件循环（Event Loop） 机制。它让线程在没有任务时进入休眠（不消耗 CPU），在有任务时被唤醒处理事件。没有 RunLoop 的线程执行完任务就会退出；有了 RunLoop，线程可以常驻内存，随时响应事件。

RunLoop 与线程是一一对应的关系：

主线程的 RunLoop 在 UIApplicationMain 中自动创建和启动。
子线程的 RunLoop 默认不创建，需要手动调用 [NSRunLoop currentRunLoop] 或 CFRunLoopGetCurrent() 时才会懒加载创建。
RunLoop 保存在一个全局的 CFMutableDictionaryRef 中，以 pthread_t 作为 key。

4.2 RunLoop 的核心架构

4.2.1 三大核心对象

a) CFRunLoopSource（输入源）

Source0（非端口事件源）：不能主动唤醒 RunLoop，需要手动调用 CFRunLoopSourceSignal() 标记为待处理，再调用 CFRunLoopWakeUp() 唤醒 RunLoop。触摸事件、performSelector:onThread: 等使用 Source0 分发。
Source1（端口事件源）：基于 Mach Port，能主动唤醒 RunLoop。系统内核通过 Mach Port 发送消息来通知事件，如硬件事件（触摸/锁屏/摇晃）首先由 IOKit 通过 Mach Port 传递给 SpringBoard，再由 SpringBoard 通过 Mach Port 分发给对应的 App 进程。App 内部的 Source1 接收到事件后，通常会封装成 Source0 在主线程 RunLoop 中处理。

b) CFRunLoopTimer（定时器源）

基于时间的触发器，与 NSTimer 是 toll-free bridged 的。Timer 的触发时间并非绝对精确——它依赖于 RunLoop 的运行状态。如果 RunLoop 正在处理一个耗时任务，Timer 的回调会被延迟到当前任务完成后才执行。Timer 有一个 tolerance（容差）属性，系统可以在 fireDate ± tolerance 范围内选择最佳触发时机以节能。

c) CFRunLoopObserver（观察者）

可以监听 RunLoop 的状态变化：

状态	含义
`kCFRunLoopEntry`	即将进入 RunLoop
`kCFRunLoopBeforeTimers`	即将处理 Timer
`kCFRunLoopBeforeSources`	即将处理 Source
`kCFRunLoopBeforeWaiting`	即将进入休眠
`kCFRunLoopAfterWaiting`	刚从休眠中唤醒
`kCFRunLoopExit`	即将退出 RunLoop

4.2.2 RunLoop Mode

RunLoop 在某一时刻只能运行在一个 Mode 下。每个 Mode 包含独立的 Source/Timer/Observer 集合。切换 Mode 时，当前 Mode 下的 Source/Timer/Observer 不会被处理。

常用 Mode：

kCFRunLoopDefaultMode（NSDefaultRunLoopMode）：默认 Mode，App 空闲时运行在此 Mode。
UITrackingRunLoopMode：ScrollView 滑动时切换到此 Mode。这就是为什么 NSTimer 在 Default Mode 下注册时，滑动 ScrollView 期间 Timer 不触发——因为 RunLoop 此时运行在 Tracking Mode 下。
kCFRunLoopCommonModes（NSRunLoopCommonModes）：这不是一个真正的 Mode，而是一个"模式集合"的标记。被标记为 Common 的 Source/Timer/Observer 会被同步到所有被标记为 Common 的 Mode 中。默认情况下 Default Mode 和 Tracking Mode 都是 Common Mode。将 Timer 添加到 Common Modes 可以让它在滑动时也能触发。

4.3 RunLoop 的运行机制（核心循环）

RunLoop 的核心运行逻辑（简化版）：

通知 Observer：即将进入 RunLoop（kCFRunLoopEntry）。
通知 Observer：即将处理 Timer（kCFRunLoopBeforeTimers）。
通知 Observer：即将处理 Source0（kCFRunLoopBeforeSources）。
处理所有待处理的 Source0 事件。
如果有 Source1（Mach Port 消息）待处理，跳转到步骤 9 直接处理。
通知 Observer：即将进入休眠（kCFRunLoopBeforeWaiting）。
休眠，等待唤醒。线程通过 mach_msg() 系统调用陷入内核态，让出 CPU。可以被以下事件唤醒：
- Mach Port 消息到达（Source1 事件、Timer 触发、CFRunLoopWakeUp() 调用）。
- 超时（RunLoop 有一个超时参数）。
- 被外部手动唤醒。
通知 Observer：刚从休眠中被唤醒（kCFRunLoopAfterWaiting）。
处理唤醒事件：
- 如果是 Timer 到期：处理 Timer 回调。
- 如果是 dispatch_main_queue 的 block：执行 block（GCD 派发到主队列的任务通过 RunLoop 的 Source1 唤醒主线程执行）。
- 如果是 Source1 事件：处理 Source1 回调。
判断是否需要退出（Mode 中没有任何 Source/Timer、被外部停止、超时等）。
如果不退出，跳转到步骤 2 继续循环。
通知 Observer：即将退出 RunLoop（kCFRunLoopExit）。

4.4 RunLoop 与系统功能的关系

4.4.1 AutoreleasePool

主线程 RunLoop 注册了两个 Observer 与 AutoreleasePool 配合：

第一个 Observer 监听 kCFRunLoopEntry（优先级最高，保证在所有回调之前）：调用 _objc_autoreleasePoolPush() 创建自动释放池。
第二个 Observer 监听 kCFRunLoopBeforeWaiting（优先级最低，保证在所有回调之后）：调用 _objc_autoreleasePoolPop() 释放旧池中的对象，再调用 _objc_autoreleasePoolPush() 创建新池。同时监听 kCFRunLoopExit：调用 _objc_autoreleasePoolPop() 做最终释放。

这意味着主线程上被 autorelease 的对象会在每次 RunLoop 循环即将休眠时被释放。

4.4.2 事件响应

硬件事件（触摸）传递链：

硬件产生中断 → IOKit.framework 封装为 IOHIDEvent。
通过 Mach Port 传递给 SpringBoard 进程。
SpringBoard 判断前台 App，通过 Mach Port 传递给 App 进程。
App 主线程 RunLoop 的 Source1 被唤醒，回调 __IOHIDEventSystemClientQueueCallback()。
Source1 内部触发 Source0（__UIApplicationHandleEventQueue()）。
Source0 中进行 Hit Test、手势识别、UIResponder 事件分发。

4.4.3 UI 刷新

setNeedsLayout、setNeedsDisplay 等调用不会立即触发布局/绘制，而是标记为"需要更新"。主线程 RunLoop 注册了一个 Observer 监听 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit，在回调中遍历所有标记了需要更新的视图，执行实际的 layout、display、render 操作，最终打包提交给 Render Server。

这就是 Core Animation 的 Transaction 机制。

4.4.4 GCD 与 RunLoop

当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会唤醒主线程的 RunLoop（通过向 RunLoop 的 dispatch port 发送 Mach 消息），RunLoop 在循环中检测到 dispatch port 有消息后，会调用 _dispatch_main_queue_callback_4CF() 来执行 block。

4.4.5 performSelector:afterDelay:

performSelector:withObject:afterDelay: 实际上是创建了一个 Timer 添加到当前线程的 RunLoop 中。如果当前线程没有 RunLoop（子线程默认没有），这个方法不会执行。

4.5 RunLoop 的实际应用

常驻子线程：为子线程创建 RunLoop 并添加一个永不触发的 Port（防止 RunLoop 因没有 Source/Timer 而退出），使线程常驻内存，随时可以接收任务。AFNetworking 2.x 和 SDWebImage 早期版本都使用过这个技巧。
NSTimer 滑动不停：将 Timer 添加到 NSRunLoopCommonModes。
卡顿监控：通过 Observer 监听 RunLoop 状态，检测主线程 Source 处理或休眠前等待是否超时（详见卡顿监控章节）。
线程保活（Thread Keep-Alive）：网络库中用于在子线程持续接收回调。
任务拆分：将大量计算任务拆分成小块，每次 RunLoop 循环处理一块，避免长时间阻塞主线程（类似协程的思想）。

5. Runtime

5.1 Runtime 的本质

Objective-C Runtime 是一个用 C/C++/汇编编写的运行时库，它实现了 ObjC 的面向对象特性和动态性。ObjC 是一门动态语言——许多决定（调用哪个方法、对象是什么类型）被推迟到运行时。

核心思想：消息发送（Messaging）。ObjC 中的方法调用 [obj method] 会被编译器转换为 objc_msgSend(obj, @selector(method))，由 Runtime 在运行时查找并执行对应的实现。

5.2 对象模型

5.2.1 对象（id / objc_object）

每个 ObjC 对象本质上是一个结构体，其第一个成员是 isa 指针，指向该对象所属的类。

从 ARM64 开始，Apple 使用了 Tagged Pointer 和 Non-pointer ISA 优化：

Tagged Pointer：对于 NSNumber、NSDate、短字符串等小对象，指针本身就直接存储了对象的值，不需要在堆上分配内存。判断方法：指针的最高位（ARM64）或最低位（x86_64）为 1 则是 Tagged Pointer。Tagged Pointer 不是真正的对象，没有 isa、没有 retain/release 开销，内存效率和访问速度极高。

Non-pointer ISA（优化的 isa）：在 64 位系统上，isa 不再是单纯的类指针。64 位中只有 33~44 位用于存储类地址，其余位存储了：

引用计数（extra_rc，19 位，存储引用计数减 1 的值）。当 extra_rc 溢出时，将一半的引用计数转存到 SideTable 的 RefcountMap 中，has_sidetable_rc 标志位置 1。
是否有关联对象（has_assoc）。
是否有 C++ 析构函数（has_cxx_dtor）。
是否使用了弱引用（weakly_referenced）。
是否正在释放（deallocating）。

5.2.2 类（objc_class）

类也是一个对象（元类的实例），继承自 objc_object。关键成员：

isa：指向元类（metaclass）。
superclass：指向父类。
cache：方法缓存（cache_t），使用哈希表存储最近调用的方法，加速消息发送。
bits / class_rw_t：
- class_ro_t（Read-Only）：编译期确定的只读数据——方法列表、属性列表、ivar 列表、协议列表、实例大小等。存储在 Mach-O 的 __DATA_CONST 段中。
- class_rw_t（Read-Write）：运行时创建的可读写数据，包含对 class_ro_t 的引用，以及运行时动态添加的方法、属性、协议列表。
- class_rw_ext_t：iOS 14+ 优化，只有在类被运行时修改过（如添加了 Category、使用了 class_addMethod）时才会创建 class_rw_ext_t，约 90% 的类不需要，节省大量内存（Apple 称全系统节省约 14MB）。

5.2.3 元类（Metaclass）

实例对象的 isa → 类对象。
类对象的 isa → 元类对象。
元类对象的 isa → 根元类（NSObject 的元类）。
根元类的 isa → 自身。
根元类的 superclass → NSObject 类。

这个链条解释了为什么实例方法存储在类中，类方法存储在元类中——消息发送总是沿着 isa 链查找方法。

5.3 消息发送机制（objc_msgSend）

5.3.1 快速查找（缓存查找）

objc_msgSend 是用汇编语言编写的（ARM64），追求极致性能。

执行流程：

判断 receiver 是否为 nil（Tagged Pointer 的特殊处理）。
通过 receiver 的 isa 找到类对象。
在类的 cache_t（方法缓存）中查找 SEL 对应的 IMP。cache_t 是一个开放寻址的哈希表，使用 SEL 的地址值做 mask 运算得到索引，查找效率接近 O(1)。
如果命中缓存（Cache Hit），直接跳转到 IMP 执行——整个过程几十纳秒，纯汇编实现。

5.3.2 慢速查找（方法列表查找）

缓存未命中时，进入 C/C++ 实现的 lookUpImpOrForward 函数：

在当前类的 class_rw_t 中搜索方法列表。方法列表已按 SEL 地址排序（在类 realize 时排序），使用二分查找，时间复杂度 O(log n)。
如果未找到，沿 superclass 链向上逐级查找父类的方法列表（每级都先查缓存再查方法列表）。
如果一直到 NSObject（根类）都未找到，进入消息转发流程。
如果找到了，将 SEL→IMP 的映射写入当前类的 cache_t（注意是写入最初接收消息的类的缓存，不是找到方法的那个父类的缓存）。

5.3.3 方法缓存（cache_t）的实现细节

哈希表使用 掩码（mask） 而非取模，因为 mask 可以用位与运算（& mask）替代除法，更快。
缓存容量始终是 2 的幂次，初始容量为 4（ARM64）。
当缓存使用率超过 3/4（75%） 时，容量翻倍并清空所有旧缓存（而非 rehash），因为 Apple 认为缓存的时间局部性很强，旧缓存大概率不再需要。
类在第一次收到消息时分配缓存。

5.4 消息转发机制（Message Forwarding）

当消息发送的快速查找和慢速查找都未找到方法实现时，进入消息转发的三个阶段：

5.4.1 第一阶段：动态方法解析（Dynamic Method Resolution）

Runtime 调用：

实例方法：+resolveInstanceMethod:
类方法：+resolveClassMethod:

在这个方法中，类有机会动态地为 SEL 添加一个 IMP（通过 class_addMethod）。如果返回 YES 且添加了方法，Runtime 会重新执行消息发送流程。

应用场景：@dynamic 属性的实现、Core Data 的 NSManagedObject 动态生成属性的 getter/setter。

5.4.2 第二阶段：快速转发（Fast Forwarding / Forwarding Target）

Runtime 调用 -forwardingTargetForSelector:。

在这个方法中，可以返回另一个对象来处理这条消息（消息转发给备用接收者）。这一步效率很高，因为直接对新对象执行 objc_msgSend，不需要创建 NSInvocation。

应用场景：多重代理（将消息转发给多个对象）、组合模式的简化实现。

5.4.3 第三阶段：完整转发（Normal Forwarding）

Runtime 依次调用：

-methodSignatureForSelector:：返回方法的类型签名（NSMethodSignature），描述参数类型和返回值类型。
-forwardInvocation:：接收一个封装了完整调用信息的 NSInvocation 对象，可以修改目标、参数、甚至调用多次。

这是最灵活但最慢的阶段，NSInvocation 的创建涉及堆分配和参数拷贝。

如果以上三个阶段都未处理，最终调用 -doesNotRecognizeSelector:，抛出经典的 "unrecognized selector sent to instance" 异常。

5.5 Method Swizzling

通过 Runtime 函数交换两个方法的 IMP，实现 AOP（面向切面编程）。

核心 API：

method_exchangeImplementations：交换两个 Method 的 IMP。
class_replaceMethod：替换某个 SEL 的 IMP。
method_setImplementation：设置某个 Method 的 IMP。

陷阱与最佳实践：

必须在 +load 中执行（或用 dispatch_once 保证只执行一次），避免竞态条件。
必须调用原始实现：Swizzle 后的方法中要调用"看似递归实际不是"的原始方法（因为 IMP 已经交换了）。
父类方法问题：如果当前类没有实现目标方法（继承自父类），直接交换会影响父类。正确做法是先 class_addMethod 尝试添加，成功则只需 class_replaceMethod 替换父类的实现到当前类的新 SEL，失败（说明当前类已有实现）才 method_exchangeImplementations。
_cmd 问题：Swizzle 后方法内部的 _cmd 值是交换后的 SEL，可能导致日志、KVO 等依赖 _cmd 的逻辑出错。

5.6 关联对象（Associated Objects）

通过 objc_setAssociatedObject / objc_getAssociatedObject 为已存在的类动态添加"属性"（实际是绑定的键值对）。

内部存储结构：

全局维护一个 AssociationsManager（自带锁），内部是一个 AssociationsHashMap：

AssociationsHashMap: { 对象地址(disguised_ptr_t) → ObjectAssociationMap }
ObjectAssociationMap: { key(const void*) → ObjcAssociation(policy + value) }

关联对象不存储在对象本身的内存中，而是存储在全局的哈希表中，以对象地址为 key。
对象销毁时（dealloc），Runtime 检查 isa 的 has_assoc 标志位，如果为 1，则调用 _object_remove_associations() 清除该对象的所有关联对象。
关联策略：OBJC_ASSOCIATION_ASSIGN（弱引用）、OBJC_ASSOCIATION_RETAIN_NONATOMIC（强引用，非原子）、OBJC_ASSOCIATION_COPY_NONATOMIC（拷贝）等，语义与 property 属性一致。

5.7 Category 的实现原理

Category 在编译后生成 category_t 结构体，包含：方法列表、属性列表、协议列表（但没有 ivar 列表，这就是 Category 不能添加实例变量的原因——实例变量列表在编译期确定，存储在 class_ro_t 中，不可修改）。

加载过程：

在 map_images 阶段，Runtime 遍历所有镜像的 __objc_catlist section，收集所有 Category。
调用 attachCategories() 将 Category 的方法列表倒序插入到类的方法列表数组的前面（使用 attachLists 的 ATTACH_EXISTING 方式）。
因此，后编译的 Category 的方法会排在最前面，最先被找到——这就是 Category "覆盖"原类方法的真相（原方法仍然存在，只是排在后面不会被优先找到）。

多个 Category 有同名方法时：取决于编译顺序（Build Phases → Compile Sources 中的文件顺序），最后编译的 Category 的方法排在最前面。

5.8 Weak 引用的实现

全局 Weak 表：Runtime 维护一个全局的 SideTable（实际上是一个 StripedMap，包含 64 个 SideTable 以减少锁竞争），每个 SideTable 包含：

spinlock_t：自旋锁，保护并发访问。
RefcountMap：存储对象的额外引用计数（extra_rc 溢出时使用）。
weak_table_t：弱引用表，核心结构。

weak_table_t 是一个哈希表，以对象地址为 key，value 是 weak_entry_t，包含所有指向该对象的 weak 指针的地址。

weak 指针的赋值过程：

调用 objc_initWeak()（或 objc_storeWeak()）。
如果旧值非 nil，从旧对象的 weak_entry_t 中移除该 weak 指针。
如果新值非 nil，将该 weak 指针注册到新对象的 weak_entry_t 中。

对象销毁时清除 weak 引用：

dealloc → _objc_rootDealloc → rootDealloc → object_dispose → objc_destructInstance。
objc_destructInstance 中：清除关联对象 → 清除弱引用（weak_clear_no_lock）→ 清除 SideTable 引用计数。
weak_clear_no_lock：遍历对象的 weak_entry_t 中所有 weak 指针地址，将它们全部置为 nil。

这就是 weak 指针在对象销毁后自动变为 nil 的底层机制。

5.9 KVO 的底层实现

KVO（Key-Value Observing）完全依赖 Runtime 实现：

当对某个对象的属性添加 KVO 观察时，Runtime 动态创建一个该对象所属类的子类（命名为 NSKVONotifying_OriginalClass）。
将对象的 isa 指向这个动态子类（isa swizzling）。
动态子类重写了被观察属性的 setter 方法，在 setter 中插入：
- willChangeValueForKey: → 调用原始 setter → didChangeValueForKey:。
- didChangeValueForKey: 内部触发 observeValueForKeyPath:ofObject:change:context: 回调。
动态子类还重写了 class 方法（返回原类而非 NSKVONotifying_ 前缀的子类，对外隐藏 KVO 的实现细节），以及 dealloc（清理观察）和 _isKVOA（标识 KVO 类）。

6. 卡顿监控

6.1 卡顿的定义与原理

iOS 设备的屏幕刷新率通常为 60Hz（ProMotion 设备最高 120Hz），意味着每帧的渲染时间预算为 16.67ms（60fps）或 8.33ms（120fps）。如果主线程在一帧的时间内未完成 UI 更新的所有工作（布局计算、绘制、图层合成提交），就会导致掉帧（Frame Drop），用户感知为卡顿。

渲染流水线（Render Pipeline）：

App 进程（CPU）                      Render Server（GPU）
┌─────────────────┐                  ┌──────────────────┐
│ Layout          │                  │ 图层树解码       │
│ Display (Draw)  │ ──Commit──────→  │ 纹理上传         │
│ Prepare         │   Transaction    │ 合成渲染         │
│ Commit          │                  │ 显示             │
└─────────────────┘                  └──────────────────┘
        ← 一帧 16.67ms →                 ← 一帧 16.67ms →

CPU 和 GPU 是流水线式工作的。CPU 在当前帧完成布局和绘制后提交给 GPU，GPU 在下一帧完成合成渲染。任一环节超时都会导致掉帧。

6.2 卡顿的常见原因

CPU 侧

复杂布局计算：Auto Layout 的约束求解是多项式时间复杂度，视图层级深、约束多时开销显著。
文本计算与渲染：NSAttributedString 的排版（Text Kit / Core Text）、行高计算、折行计算。
图片解码：UIImage 在首次渲染时才进行解码（从 PNG/JPEG 压缩格式解码为位图），大图的解码可能耗时数十毫秒。
对象创建与销毁：大量对象的 alloc/dealloc（尤其涉及 ARC 的 retain/release 操作和 SideTable 锁竞争）。
数据库/文件 I/O：主线程同步读写磁盘。
锁等待：主线程等待子线程持有的锁。

GPU 侧

离屏渲染（Offscreen Rendering）：cornerRadius + masksToBounds、shadow、mask、group opacity 等会触发离屏渲染，GPU 需要额外创建帧缓冲区。
过度绘制（Overdraw）：大量重叠的不透明图层导致 GPU 重复渲染。
大图纹理：超大图片上传到 GPU 的纹理缓存，占用大量显存和带宽。
图层爆炸：大量 CALayer 导致合成开销增大。

6.3 卡顿监控方案

6.3.1 方案一：RunLoop Observer 监控

原理：主线程的所有任务都在 RunLoop 中执行。通过监听 RunLoop 的状态变化，检测两个关键时间间隔：

kCFRunLoopBeforeSources 到 kCFRunLoopBeforeWaiting（Source 处理阶段）：如果这个间隔过长，说明 Source0 事件处理耗时过久（如触摸事件处理中有耗时操作）。
kCFRunLoopAfterWaiting 到下一次 kCFRunLoopBeforeWaiting（被唤醒后的处理阶段）：如果这个间隔过长，说明被唤醒后的任务处理耗时过久。

实现思路：

在主线程注册一个 CFRunLoopObserver，监听所有状态变化。
在 Observer 回调中记录状态变化的时间戳和当前状态。
创建一个子线程，用信号量（dispatch_semaphore）定期检测（如每 50ms 一次）主线程 RunLoop 是否长时间停留在某个状态。
如果连续多次（如 3 次）检测到主线程处于同一个状态超过阈值（如 250ms），判定为卡顿。
在子线程中抓取主线程的调用堆栈。

卡顿判定策略：

超过 1 帧（16ms）：微卡顿，通常不记录。
超过 3 帧（50ms）：轻微卡顿。
超过 250ms：明显卡顿，需要记录堆栈。
超过 3s：严重卡顿（ANR），需要立即上报。

6.3.2 方案二：子线程 Ping（心跳检测）

原理：子线程定期向主线程发送一个"心跳"任务（通过 dispatch_async 派发到主队列），如果主线程在规定时间内未能执行该任务，则认为主线程被阻塞。

实现思路：

子线程设置一个 flag 为 false，通过 dispatch_async(dispatch_get_main_queue(), ^{ flag = true; }) 发送心跳。
子线程等待一段时间（如 500ms 或 1s）。
检查 flag：如果仍为 false，说明主线程在此期间一直忙碌，判定为卡顿。
抓取主线程堆栈。

优缺点比较：

RunLoop Observer 方案更精确，能定位到具体的 RunLoop 阶段，但实现复杂。
心跳检测方案简单可靠，但只能检测到"主线程忙"，无法区分是哪种任务导致的。

6.3.3 方案三：CADisplayLink 帧率监控

利用 CADisplayLink 的回调计算实际帧率。CADisplayLink 会在每次屏幕刷新前调用回调，如果两次回调的间隔超过 16.67ms，说明发生了掉帧。

局限性：只能检测掉帧的发生和严重程度，无法直接获取卡顿原因的堆栈信息。通常作为辅助监控手段，与上述方案配合使用。

6.3.4 方案四：基于 MetricKit（iOS 14+）

MXHangDiagnostic 提供系统级别的卡顿诊断信息，包括卡顿时长和调用堆栈。MXCPUExceptionDiagnostic 报告 CPU 异常使用情况。

优点是零性能开销（系统在后台采集），缺点是数据延迟（次日推送），适合线上监控而非实时调试。

6.4 堆栈采集

卡顿检测到后，最关键的是采集主线程的调用堆栈，用于定位卡顿的根因。

6.4.1 基于 mach_thread API

使用 task_threads() 获取所有线程列表，通过 thread_get_state() 获取目标线程（主线程）的寄存器状态（包含 PC、FP、LR 等），然后沿着 Frame Pointer（FP）链回溯调用栈，结合 DWARF 调试信息或 dSYM 文件符号化。

6.4.2 基于 backtrace() / backtrace_symbols()

标准 POSIX 接口，但只能获取当前线程的堆栈，无法跨线程采集。

6.4.3 基于 PLCrashReporter

开源的崩溃报告库，提供了安全的跨线程堆栈采集能力（信号安全、锁安全），是业界常用方案。

6.5 堆栈聚合与分析

调用树合并：将多次采集的堆栈按调用路径合并成火焰图/调用树，识别热点函数。
符号化：将内存地址转换为函数名+偏移量，需要对应版本的 dSYM 文件。使用 atos 命令或 dwarfdump 工具。
去噪：过滤系统框架的堆栈帧（如 CFRunLoopRunSpecific、mach_msg_trap），聚焦业务代码。

6.6 治理策略

文本异步计算：使用 NSAttributedString 的 boundingRectWithSize: 在子线程预计算文本高度。
图片异步解码：在子线程用 CGBitmapContextCreate + CGContextDrawImage 强制解码图片，主线程直接使用解码后的位图。
预排版/预计算：Cell 的高度、布局信息在数据到达时在子线程预计算完成，主线程直接使用。
按需加载：屏幕外的 Cell 不进行复杂渲染。
减少离屏渲染：用 UIBezierPath + CAShapeLayer 替代 cornerRadius + masksToBounds；用 shadowPath 替代自动计算的阴影。
异步绘制：使用 drawRect: 在后台线程绘制位图，再赋值给 CALayer.contents（参考 Texture/AsyncDisplayKit 框架的思想）。

7. AFNetworking

7.1 整体架构

AFNetworking 是 iOS/macOS 上最流行的网络库。目前主流版本为 AFNetworking 4.x，完全基于 NSURLSession（3.x 开始移除了 NSURLConnection 支持）。

核心架构分层：

┌────────────────────────────────────────────┐
│           AFHTTPSessionManager            │  ← 最高层：便捷 HTTP 接口
│     (GET/POST/PUT/DELETE 等快捷方法)       │
├────────────────────────────────────────────┤
│           AFURLSessionManager             │  ← 核心层：Session 管理
│   (NSURLSession delegate 的完整实现)       │
├────────────────────────────────────────────┤
│  AFURLRequestSerialization                │  ← 请求序列化
│  (HTTP/JSON/PropertyList Request)         │
├────────────────────────────────────────────┤
│  AFURLResponseSerialization               │  ← 响应反序列化
│  (HTTP/JSON/XML/Image/PropertyList)       │
├────────────────────────────────────────────┤
│  AFSecurityPolicy                         │  ← 安全策略（HTTPS/证书验证）
├────────────────────────────────────────────┤
│  AFNetworkReachabilityManager             │  ← 网络状态监听
└────────────────────────────────────────────┘

7.2 AFURLSessionManager 深入解析

7.2.1 核心职责

AFURLSessionManager 是整个库的心脏，它：

持有并管理一个 NSURLSession 实例。
实现了 NSURLSessionDelegate、NSURLSessionTaskDelegate、NSURLSessionDataDelegate、NSURLSessionDownloadDelegate 四个协议的所有关键方法。
维护一个 mutableTaskDelegatesKeyedByTaskIdentifier 字典，将每个 NSURLSessionTask 映射到一个 AFURLSessionManagerTaskDelegate 对象，实现任务级别的回调隔离。

7.2.2 线程安全设计

使用 NSLock（名为 lock）保护 mutableTaskDelegatesKeyedByTaskIdentifier 字典的并发访问。
NSURLSession 的 delegate 回调在一个专用的串行 OperationQueue（operationQueue.maxConcurrentOperationCount = 1）上执行，保证回调的串行化，避免多线程问题。
完成回调（success/failure block）默认 dispatch 到主队列（completionQueue 默认为 dispatch_get_main_queue()），保证 UI 更新的线程安全。开发者也可以自定义 completionQueue 和 completionGroup。

7.2.3 任务代理（AFURLSessionManagerTaskDelegate）

每个 NSURLSessionTask 对应一个 AFURLSessionManagerTaskDelegate 实例，它负责：

收集响应数据：在 URLSession:dataTask:didReceiveData: 中将接收到的数据追加到 mutableData 中。
跟踪上传/下载进度：通过 NSProgress 对象提供 KVO 兼容的进度更新。
任务完成时：根据 responseSerializer 反序列化响应数据，在 completionQueue 上回调 success/failure block。

7.2.4 KVO 与通知机制

AFNetworking 大量使用了 KVO 和 NSNotification：

对 NSURLSessionTask 的 state 属性进行 KVO 观察，当任务状态变为 completed 时自动清理。
任务 resume/suspend/complete 时发送全局通知（如 AFNetworkingTaskDidResumeNotification），方便外部监听（如网络活动指示器 AFNetworkActivityIndicatorManager）。
使用 Method Swizzling 交换了 NSURLSessionTask 的 resume 和 suspend 方法，在调用时发送通知。这是因为 NSURLSession 不对 task 的 state 变化发送 KVO 通知，AF 需要自己实现。

7.3 请求序列化（AFURLRequestSerialization）

7.3.1 AFHTTPRequestSerializer

基础的 HTTP 请求序列化器：

设置通用 HTTP Header（User-Agent、Accept-Language、Authorization 等）。
将参数字典编码为 URL query string（GET/HEAD/DELETE）或 HTTP body（POST/PUT/PATCH）。
参数编码规则：对键值对进行百分号编码（Percent Encoding），嵌套字典和数组使用方括号语法（key[subkey]=value、key[]=value）。
multipartFormData：支持 multipart/form-data 编码，用于文件上传。内部使用 AFMultipartBodyStream（自定义的 NSInputStream 子类）实现流式上传，避免将整个文件载入内存。

7.3.2 AFJSONRequestSerializer

继承自 AFHTTPRequestSerializer，将参数字典使用 NSJSONSerialization 编码为 JSON 格式放入 HTTP Body，设置 Content-Type 为 application/json。

7.4 响应序列化（AFURLResponseSerialization）

响应序列化器负责验证响应的合法性并将数据转换为目标格式。

7.4.1 验证机制

所有序列化器都继承自 AFHTTPResponseSerializer，它的 validateResponse:data:error: 方法检查：

HTTP 状态码是否在 acceptableStatusCodes（默认 200~299）范围内。
响应的 Content-Type 是否在 acceptableContentTypes 集合中。

如果验证失败，生成对应的 NSError（AFURLResponseSerializationErrorDomain），并将响应数据放入 error.userInfo[AFNetworkingOperationFailingURLResponseDataErrorKey] 中，方便调试。

7.4.2 AFJSONResponseSerializer

使用 NSJSONSerialization 将 Data 解析为字典/数组。支持自动移除 JSON 中的 NSNull 值（removesKeysWithNullValues 属性）。

7.4.3 AFImageResponseSerializer

将 Data 解码为 UIImage。支持自动解压（inflate）——在子线程强制解码图片位图，避免在主线程首次渲染时的解码开销（与 SDWebImage 的思路一致）。

7.5 安全策略（AFSecurityPolicy）

7.5.1 三种验证模式

模式	说明	安全级别
`AFSSLPinningModeNone`	使用系统默认的证书链验证	低
`AFSSLPinningModeCertificate`	将服务器证书与 App 内预埋的证书进行完整比对	最高
`AFSSLPinningModePublicKey`	只比对证书中的公钥（Public Key）	高（推荐）

7.5.2 证书验证流程

获取服务器返回的证书链（SecTrustRef）。
设置锚点证书（Anchor Certificates）为 App 预埋的证书。
调用 SecTrustEvaluateWithError() 进行系统级证书链验证。
根据 Pinning Mode：
- Certificate Mode：逐一比对证书的 DER 编码数据。
- PublicKey Mode：提取证书的公钥数据进行比对。
validatesDomainName：是否验证证书中的域名与请求域名匹配。

7.5.3 公钥固定的优势

比证书固定更灵活——即使服务器更换了证书（只要使用相同的密钥对），App 无需更新。

7.6 网络可达性（AFNetworkReachabilityManager）

基于 SCNetworkReachability（SystemConfiguration 框架），监听网络状态变化。

核心流程：

使用 SCNetworkReachabilityCreateWithAddress 或 SCNetworkReachabilityCreateWithName 创建 reachability 引用。
设置回调函数，当网络状态变化时触发。
将 reachability 引用加入 RunLoop（CFRunLoopGetMain()）以持续监听。
回调中解析 SCNetworkReachabilityFlags，判断：
- 是否可达（kSCNetworkReachabilityFlagsReachable）。
- 是否通过 WWAN（kSCNetworkReachabilityFlagsIsWWAN）。

注意：SCNetworkReachability 检测的是"是否有网络路径"，不是"是否能真正连通互联网"。飞行模式能检测到，但连上 WiFi 但无法上网的情况检测不到。

7.7 与 Alamofire 的对比

Alamofire 是 AFNetworking 作者在 Swift 生态下的重写，核心思想一致但做了现代化改进：

对比维度	AFNetworking	Alamofire
语言	Objective-C	Swift
并发模型	GCD + NSOperationQueue	Swift Concurrency (async/await)
请求构建	Mutable URL Request	链式调用 + Request 协议
响应处理	Block 回调	Result + async/await
拦截器	需自行封装	内置 `RequestInterceptor` 协议
重试	需自行实现	内置 `RetryPolicy`

8. SDWebImage

8.1 整体架构

SDWebImage 是 iOS 上最广泛使用的图片加载和缓存库。其核心设计哲学是将复杂的图片加载流程封装为简洁的 API（如 sd_setImageWithURL:），同时提供高度可定制的扩展点。

架构分层：

┌──────────────────────────────────────────────────┐
│              UIView+WebCache                     │  ← 最上层：UIKit 扩展
│  (UIImageView / UIButton 的分类方法)              │
├──────────────────────────────────────────────────┤
│              SDWebImageManager                   │  ← 核心调度器
│  (协调缓存查找和网络下载)                          │
├──────────────┬───────────────────────────────────┤
│ SDImageCache │  SDWebImageDownloader             │  ← 缓存 / 下载
│ (内存+磁盘)   │  (网络下载管理)                    │
├──────────────┴───────────────────────────────────┤
│ SDWebImageDownloaderOperation                    │  ← 下载操作
│ (基于 NSURLSessionDataTask 的下载单元)             │
├──────────────────────────────────────────────────┤
│ SDImageCoder / SDImageTransformer                │  ← 编解码 / 变换
│ (PNG/JPEG/GIF/WebP/HEIF 编解码, 圆角/缩放等)      │
└──────────────────────────────────────────────────┘

8.2 加载流程全景

当调用 [imageView sd_setImageWithURL:url] 时，完整的执行流程：

Step 1：取消旧任务 取消该 UIImageView 上一次尚未完成的图片加载任务（通过关联对象存储的 operation key）。这避免了 Cell 复用场景下的图片错乱问题。

Step 2：设置占位图 如果提供了 placeholder，立即在主线程设置占位图。

Step 3：查询缓存 SDWebImageManager 调用 SDImageCache 查询缓存：

内存缓存查询：SDMemoryCache（基于 NSCache）中以 URL 的 MD5/SHA256 哈希为 key 查找。命中则直接返回。
磁盘缓存查询：如果内存未命中，在串行 I/O 队列（ioQueue）中异步查询磁盘缓存。磁盘缓存使用文件存储，文件名为 URL 的 MD5 哈希值。查询过程包括：
1. 检查文件是否存在（fileExistsAtPath:）。
2. 读取文件数据。
3. 对图片进行解码（从 PNG/JPEG 数据解码为位图）。
4. 将解码后的图片写入内存缓存（回填）。

Step 4：网络下载 如果缓存完全未命中（或设置了 SDWebImageRefreshCached 选项），启动网络下载：

SDWebImageDownloader 创建或复用一个 SDWebImageDownloaderOperation。
同一个 URL 的多次请求会被合并（Coalescing）——只发一次网络请求，结果回调给所有等待者。这通过 URLOperations 字典（以 URL 为 key）实现。
下载操作基于 NSURLSessionDataTask。

Step 5：图片处理 下载完成后：

在子线程进行图片解码（Decode）。
如果设置了 SDImageTransformer（如圆角、缩放、高斯模糊），在子线程执行变换。
将处理后的图片同时写入内存缓存和磁盘缓存。

Step 6：回调主线程 在主线程设置 imageView.image，触发 UI 更新。支持渐变动画（SDWebImageTransition）。

8.3 缓存机制深入解析

8.3.1 内存缓存（SDMemoryCache）

继承自 NSCache，具备以下特性：

自动淘汰：当系统内存紧张时，NSCache 会自动释放对象。开发者可以设置 countLimit（最大数量）和 totalCostLimit（最大总开销，以图片像素数为 cost）。
线程安全：NSCache 内部使用锁保护，可以在任意线程安全访问。
弱引用表（mapTable）：SDWebImage 额外维护了一个 NSMapTable（weakToStrongObjects），当 NSCache 因内存压力淘汰了某张图片时，如果该图片仍被某个 UIImageView 持有（强引用），通过 mapTable 仍然可以找到它，避免不必要的重新解码/下载。

8.3.2 磁盘缓存（SDDiskCache）

存储格式：原始的图片数据（未解码的 PNG/JPEG/WebP 数据），不是解码后的位图。这大幅减少了磁盘空间占用。
文件命名：URL 的 MD5 哈希值作为文件名，避免特殊字符问题。
过期策略：默认缓存保留 1 周（maxDiskAge = 60 * 60 * 24 * 7）。
容量限制：可设置 maxDiskSize（最大磁盘缓存大小），超限时按最近最久未使用（LRU） 策略淘汰——根据文件的 NSFileModificationDate（修改日期）排序，优先删除最旧的文件，直到缓存大小降至限制的一半。
清理时机：
- App 进入后台时（UIApplicationDidEnterBackgroundNotification）触发异步清理。
- App 终止时（UIApplicationWillTerminateNotification）触发清理。
- 开发者手动调用 clearDiskOnCompletion:。

8.3.3 缓存 Key 的计算

默认使用完整的 URL 字符串作为缓存 key。开发者可以通过 SDWebImageManager 的 cacheKeyFilter block 自定义 key 生成逻辑（例如去除 URL 中的 token 参数，使相同内容的不同签名 URL 共享缓存）。

如果使用了 SDImageTransformer，变换后的图片使用 originalKey + transformerKey 作为缓存 key，与原图分开缓存。

8.4 图片解码机制

8.4.1 为什么需要预解码

UIImage 的 imageWithData: 创建的图片是未解码的——它只是持有压缩的图片数据。只有在图片首次被渲染到屏幕上时（CALayer 的 display 方法中），Core Animation 才会调用解码器将其解码为位图。这个解码发生在主线程，可能导致掉帧。

SDWebImage 的策略是在子线程提前解码（Force Decode / Decompressing），将位图缓存到内存中，主线程直接使用解码后的位图，消除主线程解码开销。

8.4.2 解码实现

解码的核心步骤：

创建 CGBitmapContext（位图上下文），指定颜色空间、每像素字节数、Alpha 通道信息。
使用 CGContextDrawImage 将 CGImageRef 绘制到上下文中——这一步触发实际的解码。
从上下文中获取解码后的 CGImageRef，创建新的 UIImage。

内存占用计算：一张 1000×1000 的图片解码后占用 1000 × 1000 × 4 bytes = 4MB（RGBA 格式，每像素 4 字节）。因此，SDWebImage 提供了 SDImageCoderDecodeScaleDownLimitBytes 选项，对超大图片进行降采样后再解码，避免内存暴涨。

8.4.3 渐进式解码（Progressive Decoding）

对于 JPEG 等支持渐进式加载的格式，SDWebImage 可以在下载过程中边下载边解码。每接收一段数据就解码一次，UI 上展示从模糊到清晰的渐进效果。

通过 SDImageCoderProgressiveCoder 协议实现，每次调用 updateIncrementalData:finished: 更新数据并产生部分解码的图片。

8.4.4 编解码器架构（SDImageCoder）

SDWebImage 5.x 使用了协议化的编解码器架构：

SDImageCoder 协议定义了 canDecodeFromData:、decodedImageWithData:、encodedDataWithImage: 等方法。
内置编解码器：SDImageIOCoder（PNG/JPEG/TIFF/GIF 静图）、SDImageGIFCoder（GIF 动图）、SDImageAPNGCoder（APNG）。
可扩展：通过 SDImageCodersManager 注册自定义编解码器，如 SDImageWebPCoder（WebP 支持）、SDImageHEICCoder（HEIC 支持）。
解码器按注册的逆序遍历（后注册的优先），调用 canDecodeFromData: 判断哪个解码器能处理当前数据格式。

8.5 下载机制深入

8.5.1 SDWebImageDownloader

维护一个 NSOperationQueue（downloadQueue），控制最大并发下载数（默认 6）。
支持 LIFO（后进先出）和 FIFO（先进先出）两种执行顺序。LIFO 适合瀑布流场景——用户快速滑动时，最新可见的 Cell 的图片优先下载。通过设置 Operation 之间的依赖关系实现 LIFO。
支持 HTTP Header 自定义、认证（URLCredential）、超时配置等。

8.5.2 SDWebImageDownloaderOperation

继承自 NSOperation，内部封装了一个 NSURLSessionDataTask。

关键设计：

回调合并：使用 callbackBlocks 数组存储所有对同一 URL 的下载回调。当下载完成时，遍历数组逐一回调。
后台下载：支持 App 进入后台后继续下载（通过 UIApplication.beginBackgroundTaskWithExpirationHandler:）。
响应数据拼接：在 URLSession:dataTask:didReceiveData: 中将数据追加到 NSMutableData（imageData），下载完成后一次性交给解码器。
取消机制：调用 cancel 时取消 NSURLSessionDataTask，从 callbackBlocks 中移除对应的回调。如果所有回调都被移除，则取消整个下载任务。

8.5.3 URL 请求去重（Coalescing）

SDWebImageDownloader 维护一个 URLOperations 字典（以 URL 为 key，以 SDWebImageDownloaderOperation 为 value）。当新请求到来时：

如果该 URL 已有进行中的下载操作，直接将新的回调添加到现有 Operation 的 callbackBlocks 中，不创建新的网络请求。
如果没有，创建新的 Operation 并加入队列。

这种设计在列表场景下极为高效——同一张头像被多个 Cell 引用时，只会发起一次网络请求。

8.6 UIView+WebCache 的设计

通过 ObjC Runtime 的关联对象机制，为 UIImageView 等视图绑定当前的加载操作。

核心流程：

调用 sd_setImageWithURL: 时，先通过 sd_cancelCurrentImageLoad 取消当前关联的旧操作。
使用 objc_setAssociatedObject 将新的 SDWebImageCombinedOperation 关联到视图上。
加载完成或 Cell 复用时，通过 objc_getAssociatedObject 获取并取消/检查操作状态。

这解决了经典的 Cell 复用导致图片错乱问题：当 Cell 被复用时，旧 Cell 的下载完成回调中设置的图片会被忽略（因为旧操作已被取消）。

8.7 动图支持

8.7.1 GIF / APNG

SDWebImage 使用 SDAnimatedImageView（继承自 UIImageView）播放动图。其内部实现：

使用 CADisplayLink 驱动动画帧切换。
按需解码：不一次性解码所有帧（一个 GIF 可能有数百帧，全部解码会占用大量内存），而是维护一个帧缓存（NSMutableDictionary），预解码当前帧附近的若干帧（预取缓冲区），按需释放远离当前播放位置的帧。
帧缓冲区大小根据可用内存动态调整。

8.7.2 WebP / HEIF

通过可插拔的编解码器支持：

SDImageWebPCoder：使用 libwebp 库进行 WebP 编解码。
SDImageHEICCoder：使用系统 ImageIO 框架进行 HEIF 编解码（iOS 11+）。

8.8 性能优化细节

异步 I/O：磁盘缓存的所有读写操作都在专用的串行 ioQueue 上异步执行，不阻塞主线程。
解码降采样：对于超大图片（如 4000×3000 的相机照片），先使用 CGImageSourceCreateThumbnailAtIndex 进行降采样到目标显示尺寸，再解码。这比先解码再缩放效率高得多——直接操作压缩数据，内存峰值大幅降低。
内存警告响应：监听 UIApplicationDidReceiveMemoryWarningNotification，立即清空内存缓存（NSCache 的 removeAllObjects）。
URL 黑名单：对于下载失败的 URL（非超时错误），加入 failedURLs 集合，短期内不再重试，避免无效请求浪费资源（可通过 SDWebImageRetryFailed 选项关闭此行为）。
Prefetch（预加载）：SDWebImagePrefetcher 支持批量预加载图片到缓存中，适用于已知用户即将浏览的内容（如下一页的列表数据）。

8.9 SDWebImage 5.x 的架构升级

SDWebImage 5.x 相比 4.x 做了大量架构优化：

特性	4.x	5.x
编解码	硬编码在内部	协议化（SDImageCoder）
缓存	固定实现	协议化（SDImageCache Protocol）
下载	固定实现	协议化（SDImageLoader Protocol）
变换	需第三方库	内置 SDImageTransformer
动图	FLAnimatedImage 依赖	内置 SDAnimatedImage
指标	无	SDImageLoadIndicator

协议化设计使得每个组件都可以被替换为自定义实现，极大提升了灵活性。

总结

上述八个知识点构成了 iOS 开发中性能优化与底层原理的核心体系：

启动流程和启动优化帮助我们理解 App 从点击图标到用户可见的完整链路，并从 pre-main 和 post-main 两个阶段系统性地优化启动速度。
网络优化覆盖了从 DNS 到数据传输、从连接管理到弱网对抗的全链路优化策略。
RunLoop 是 iOS 事件驱动模型的基石，理解它才能理解触摸事件、Timer、UI 刷新等核心机制的运作方式。
Runtime 是 Objective-C 动态性的根基，消息发送、方法缓存、消息转发、KVO、Category 等特性都建立在它之上。
卡顿监控将 RunLoop 和性能分析结合，提供了从检测到治理的完整方案。
AFNetworking 和 SDWebImage 作为两个最经典的第三方库，它们的架构设计、线程安全策略、性能优化思路值得深入学习和借鉴。

移动端开发稳了？AI 目前还无法取代客户端开发，小红书的论文告诉你数据

掘金 iOS

恋猫de小郭

2026年3月2日 16:09

近期，由小红书联合多伦多大学等高校的研究人员发布了《SWE-Bench Mobile》（2602.09540）论文，内容主要是评估 LLM 智能体在处理真实生产级移动端应用开发任务时的能力，并提出了首个针对该领域的基准测试——SWE-Bench Mobile。

这个论文对比之前那些简单的需求场景，明显更具备说服力，最重要的是，用真实的数据给目前的 AI 狂热浇一浇冷水。

目前的编程基准测试大多集中在孤立的算法问题，而 SWE-Bench 则是关注 GitHub 上的 Bug 修复，然而真实的工业级移动端开发汪汪更为复杂：

多模态输入：开发者需要根据产品需求文档（PRD）和 Figma 设计稿等来写代码
复杂的工程环境：中大厂的移动端代码库通常规模巨大（ 5GB 以上），且涉及 Swift 与 Objective-C 混编、特定系统 API 及复杂的 UI 交互，还有编译环境影响
任务类型多样化：不限于 Bug 修复，更多是功能开发和 UI 增强

所以研究团队从目前小红书自己的真实产品流水线中提取了 50 个具有代表性的开发任务，构建了该基准测试：

数据集组成 ：
- 50 个真实任务：源自实际的产品需求
- 449 个人工验证的测试用例：平均每个任务 9.1 个测试点，用于评估功能正确性
- 多模态支持：70% 的任务附带 Figma 设计链接，92% 附带参考图
代码库规模：基于约 5GB 大小的真实 iOS 生产代码库（Swift/Objective-C）
任务复杂度：平均每个任务涉及修改 4.2 个文件，远超之前的基准测试

整个基准的规则是：

70% 任务包含 Figma
92% 包含参考图片
平均 PRD 长度 450 字

每个任务包含：

一个统一 diff 补丁（patch）输出
综合测试套件（平均 9.1 个测试案例）
任务难度分级：从简单 UI 调整到复杂跨模块改造

对于任务两个关键指标：

任务成功率：所有测试通过的任务比例

测试通过率：所有测试案例通过的比率

而对于 LLM，论文评估了 22 种 不同的“智能体-模型”配置，涵盖了四个主流框架：

商业智能体：Cursor、Codex (由 DeepSeek/OpenAI 等模型驱动)、Claude Code
开源智能体：OpenCode

评估维度包括：任务完成率、任务复杂度影响、成本效果对比、多次运行稳定性、Prompt 设计影响等。

而根据论文可以得出结论：当前 AI 在生产级的软件工程力存在巨大局限性：

成功率极低 ：表现最好配置的成功率仅为 12% ，大多数任务以“实现不完整”告终，但测试通过率最高可到 28%，说明部分任务可以部分正确生成，但没能完全部署成功
智能体架构十分重要 ：同一个底层模型，在 Cursor 框架下的成功率为 12%，但在 OpenCode 下仅为 2%，智能体的工具调用、上下文管理等设计与模型本身同等重要
商业模型占优：商业闭源智能体在处理大型代码库时的稳定性和正确性显著优于开源方案
复杂度陷阱：任务涉及 1-2 个文件时成功率为 18%，但当涉及 7 个以上文件时，成功率骤降至 2% ，显示出模型在跨文件长程推理方面的短板
“防御性编程”提示词更有效：研究发现，使用基于“防御性编程”（原则的简洁提示词，比复杂的提示词能让成功率提升 7.4%

对于失败，论文还针对失败类型归类：

缺失关键功能标志位或 Feature Flag 是主要的失败原因
其次是 数据模型缺失；
再者是 incomplete patch（文件覆盖不足）等问题

这些失败的类似，在一定程度上反映了智能体对真实工程流程、跨文件依赖、与视觉设计的理解严重不足，也就是这些问题是“工程级问题”，而不是“语言问题”：

所以哪怕换成 Android / Flutter，这类跨文件工程理解问题仍然存在。

基于这些数据，论文认为当前 LLM Agent 尽管在单一代码生成上有突破，但在端到端工程上下文（包含设计、代码库理解、工程流程）仍远未达到企业生产标准。

另外，论文也有一个有趣的结论数据，主要统计了各 Agent + Model 的每任务成本（美元）和平均耗时（分钟），例如：

Cursor + Opus 4.5 ： $3.50 / 15 min
Codex + GLM 4.6 ： $1.30 / 13.3 min
OpenCode + GLM 4.6 ： $0.13 / 32.5 min
OpenCode + Opus 4.5 ： $9.33 / 8.2 min

对此可以看出来：

Codex + GLM 4.6 是性价比最高
OpenCode 极便宜但成功率低
OpenCode + Opus 4.5 是最贵但效果很差（2%）

最后，下图是论文的最终结果对比，例如在 Success 和 Pass 上：

Cursor + Opus 4.5 → 12% / 28.1%
Codex + GLM 4.6 → 12% / 19.6%
OpenCode + GLM 4.6 → 8%

这么看，OpenCode 的实际数据表现是真的一般。

这个在同一个模型，在不同 agent 上的成功率也有所体现，OpenCode 再一次被鞭尸：

所以，可以看出来，目前的 AI 智能体离独立完成中大型移动开发还有很大距离，主要瓶颈在于多模态理解、大规模代码导航和跨文件逻辑一致性等。

另外，SWE-Bench Mobile 采用了托管基准挑战（Hosted Benchmark）模式 ，不公开测试集答案，以防止数据泄露到未来的模型训练中。

最后，论文只针对原生 iOS 开发进行测试，没有测试 Android 原生、Flutter、RN 等其他情况，按照一般直觉，这些框架的 AI 表现应该会好于 iOS 原生，当然这也只是我的个人直觉，真实数据还是得有企业做过 Benchmark 才知道。

不过至少从目前看，在移动端开发领域写代码上，至少比前端安全性高一些？你怎么看？

05-主题|事件响应者链@iOS-应用场景与进阶实践

掘金 iOS

没有故事的Zhang同学

2026年3月2日 14:16

本文在 01 总纲、02 hitTest、03 响应者链、04 UIResponder 基础上，总结工程中的应用场景与进阶用法：UIControl 的 target=nil 与响应者链、手势识别器与响应者的优先级、扩大点击区域与事件穿透、以及 SwiftUI 与 UIKit 的对比。文末附参考文献。

一、UIControl 与 target=nil 的响应者链

1.1 机制

对 UIControl（如 UIButton、UISlider）使用 addTarget(_:action:for:) 时，若将 target 设为 nil，系统不会在添加时绑定具体对象，而是在事件触发时从第一响应者开始，沿 next 查找第一个能响应该 action 的响应者并调用，即 action 沿响应者链寻找 target [1]。编辑菜单（复制/粘贴/剪切）也使用同一机制在链上查找实现 copy(_:)、paste(_:)、cut(_:) 等的对象。

1.2 Action 方法签名

Action 方法通常为以下形式之一 [2]：

@IBAction func doSomething()
@IBAction func doSomething(sender: UIButton)
@IBAction func doSomething(sender: UIButton, forEvent event: UIEvent)

1.3 使用注意

Cell 内按钮：按钮在 UITableViewCell/UICollectionViewCell 内时，链的路径是 Cell → 其他 view，不一定会经过 TableView 的 ViewController。若希望由 VC 处理，用 nil target 可能找不到 VC，此时更稳妥的做法是显式指定 target（如 VC）或通过 delegate/callback 把事件交给 VC [3]。Delegate、Block、闭包、函数封装、遍历传递等「传递方式」的对比与选型见 06-响应者链传递方式与编程模式详解。
非相邻 VC：通过 present 的 VC 与当前 VC 不一定在一条「相邻」的 next 链上，nil target 不一定能跨 present 边界找到目标，建议用显式 target 或业务层路由。

二、UIGestureRecognizer 与响应者链

2.1 优先级关系

手势识别器在触摸到达视图的 touchesBegan 等之前参与识别。若手势识别成功，可消费触摸，视图的 touches 方法可能不再被调用；若手势识别失败，触摸会交给视图并沿响应者链继续传递 [4]。

控件（如 UIButton）可通过 gestureRecognizerShouldBegin(_:) 等让父视图的手势不干扰自己的点击，从而保证按钮的 target-action 优先。

2.2 泳道图：手势、响应者与控件的优先级

flowchart TB
    subgraph 触摸发生
        T1[手指按下]
    end
    subgraph 系统
        S1[hit-test 得到 view]
        S2[手势识别器优先]
    end
    subgraph 手势层
        G1[识别成功?]
        G2[消费事件]
        G3[识别失败]
    end
    subgraph 响应者层
        R1[视图 touches / UIControl]
        R2[沿 next 传递]
    end
    T1 --> S1
    S1 --> S2
    S2 --> G1
    G1 -->|是| G2
    G1 -->|否| G3
    G3 --> R1
    R1 --> R2

2.3 小结

层级	说明
手势识别	先于视图的 touches 参与识别，成功则可消费事件
视图 touches	手势未消费时，由 hit-test view 及其 next 链处理
UIControl	通过内部逻辑与 gesture 的配合，保证点击等行为优先

三、扩大点击区域与事件穿透

3.1 扩大点击区域

对视觉较小的按钮或图标，可通过重写 point(inside:with:) 扩大可点击范围（如四周各扩展 20pt），提升可点性 [5]。

override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
    let margin: CGFloat = 20
    return bounds.insetBy(dx: -margin, dy: -margin).contains(point)
}

3.2 事件「穿透」到下层

若希望某视图不响应触摸、让触摸落到下层视图，可重写 hitTest(_:with:)，在满足条件时返回 nil，则当前视图及其子视图不参与命中，系统会继续用其兄弟或父视图参与 hit-test [6]。

override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    let hit = super.hitTest(point, with: event)
    // 若希望本视图不拦截，可返回 nil；否则返回 hit
    return shouldPassThrough ? nil : hit
}

商用场景示例：视频播放页上的礼物动画、点赞动效浮层使用 PassThroughView 或重写 hitTest 返回 nil，使点击落到下层进度条、暂停按钮；或活动弹窗关闭后遮罩不拦截，点击空白处关闭。

3.3 手势与按钮共存的完整代码（商用：列表 Cell 内按钮由 VC 处理）

// Cell 内「加购」按钮希望由 ListViewController 处理，用 delegate 传递，避免 nil target 链不到 VC
protocol ProductCellDelegate: AnyObject {
    func productCell(_ cell: ProductCell, didTapAddCart productId: String)
}

class ProductCell: UITableViewCell {
    weak var delegate: ProductCellDelegate?
    private var productId: String = ""
    @objc private func addCartTapped() {
        delegate?.productCell(self, didTapAddCart: productId)
    }
}

class ListViewController: UIViewController, ProductCellDelegate {
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "ProductCell", for: indexPath) as! ProductCell
        cell.delegate = self
        cell.configure(productId: items[indexPath.row].id)
        return cell
    }
    func productCell(_ cell: ProductCell, didTapAddCart productId: String) {
        // 加购、埋点、弹 toast 等
        cartService.add(productId: productId)
    }
}

3.4 应用场景分类（思维导图）

mindmap
  root((应用场景))
    列表与 Cell
      Cell 内按钮 delegate
      扩大热区 小图标
    浮层与遮罩
      穿透 hitTest 返回 nil
      手势与按钮共存
    编辑与输入
      编辑菜单 copy paste
      自定义 inputView
    手势与链
      手势优先 再响应者链
      gestureRecognizerShouldBegin

四、SwiftUI 与 UIKit 的对比（简要）

SwiftUI 没有 UIKit 式的「响应者链」[7][8]：

使用 Gesture 修饰符在视图上声明手势，由系统做 hit-test 与手势竞争，不会把事件沿「next」链向上冒泡。
可点击区域由 frame 与 contentShape 决定；.allowsHitTesting(false) 相当于从 hit-test 中排除。
多手势的优先级通过 highPriorityGesture、simultaneousGesture 等显式组合，而非依赖「链」传递。

在 UIKit 与 SwiftUI 混用时，需注意：SwiftUI 宿主视图内的交互由 SwiftUI 管理；嵌入的 UIKit 视图仍走 UIKit 的 hit-test 与响应者链。

五、应用场景小结

场景	涉及机制	建议
按钮/控件由上层 VC 统一处理	target-action + nil target → 响应者链	Cell 内或复杂层级下优先显式 target 或 delegate
编辑菜单（复制/粘贴）	链上查找 canPerformAction / target	在合适响应者上实现 copy/paste/cut 等方法
扩大按钮可点区域	point(inside:with:)	重写并扩大 bounds 的「有效」区域
浮层不拦截触摸	hitTest(_:with:) 返回 nil	指定条件下返回 nil 实现穿透
手势与按钮共存	手势识别 vs 响应者	用 gestureRecognizerShouldBegin 等保护控件
自定义键盘/输入条	First Responder + inputView	成为第一响应者并设置 inputView / inputAccessoryView
事件/回调传递方式选型	Delegate / Block / 闭包 / 函数封装 / 遍历	见 06-响应者链传递方式与编程模式详解

5.1 商用场景速查

场景	做法
电商列表加购/收藏	Cell 内小按钮用 delegate 交给 VC，或扩大热区 + target-action
视频/直播浮层不挡点击	浮层 view 重写 hitTest 在命中自己时返回 nil
活动弹窗遮罩点击关闭	遮罩用 PassThroughView 或 hitTest 返回 nil，按钮在遮罩上方单独处理
设置页开关/列表点击	系统 UITableView 的 didSelect + 响应者链；Cell 内控件用 delegate 更稳
安全输入/自定义键盘	自定义 UITextField 的 inputView，canBecomeFirstResponder = true

参考文献

[1] Using responders and the responder chain to handle events - Controls and the responder chain
[2] UIControl | Apple Developer Documentation
[3] UIControl Target Action event not flowing up the responder chain (Stack Overflow)
[4] Using responders and the responder chain - Gesture recognizers
[5] How to implement point(inside:with:) (Stack Overflow)
[6] Hacking Hit Tests (Khanlou)
[7] SwiftUI Gesture System Internals (DEV)
[8] SwiftUI Hit-Testing & Event Propagation Internals (DEV)

02-主题|事件响应者链@iOS-hitTest与事件传递详解

掘金 iOS

没有故事的Zhang同学

2026年3月2日 14:13

本文专门讲解 iOS 中事件传递的「确定目标」阶段：hitTest(_:with:) 与 point(inside:with:) 的原理、算法、子视图遍历顺序，以及可响应条件、自定义命中区域和常见图示。与「响应者链」的传递阶段配合理解，可参见 03-响应者链与 nextResponder 详解。

一、为什么需要 Hit-Testing

触摸发生时，系统需要确定「触摸点落在哪个视图上」，以便将事件交给该视图并进入响应者链。Hit-testing 即在这一阶段，从窗口根视图开始，沿视图层级向下查找最底层且包含该点的视图，该视图将作为该触摸事件的第一响应者（hit-test view）[1]。

二、核心 API

方法	所属	作用
`hitTest(_:with:)`	UIView	在视图树中查找包含指定点的最底层子视图；返回 nil 表示当前视图及其子视图均不接收该点
`point(inside:with:)`	UIView	判断给定点是否在当前视图的 bounds 内（可被重写以扩展或缩小命中区域）

系统从 UIWindow 开始，对根视图调用 hitTest(_:with:)，传入触摸点（已转换为该视图坐标系）。视图内部会先调用 point(inside:with:) 判断点是否在自己范围内，再递归对子视图调用 hitTest(_:with:)。

三、hitTest 算法与伪代码

3.1 可响应前提

视图要参与 hit-test，通常需同时满足（否则当前分支会被剪掉，返回 nil）[[2]][[3]]：

isUserInteractionEnabled == true
isHidden == false
alpha > 0.01

不满足时，hitTest(_:with:) 直接返回 nil，该视图及其子视图都不会成为命中目标。

3.2 系统 hitTest 逻辑（伪代码）

以下为对系统行为的等价描述，便于理解顺序与剪枝逻辑；实际实现以 Apple 源码为准。

函数 hitTest(point, event) -> UIView?:
    若 当前视图 不满足可响应条件（userInteractionEnabled / hidden / alpha）:
        返回 nil

    若 pointInside(point, event) 为 false:
        返回 nil   // 点不在当前视图内，整棵子树不再查找

    // 按子视图「从后往前」顺序遍历（逆序：最后加入的、Z 轴更靠前的先测）
    对 每个 subview 从 subviews.last 到 subviews.first:
        candidate = subview.hitTest( 将 point 转换到 subview 坐标系, event )
        若 candidate != nil:
            返回 candidate   // 找到第一个有返回值的子视图即停止

    若没有子视图命中:
        返回 self   // 点在自己范围内且没有更底层子视图命中，则自己就是 hit-test view

要点：

先判 pointInside：点不在当前视图内则直接返回 nil，整棵子树被剪枝。
子视图逆序：按 subviews 从后往前遍历，即** Z 轴靠前的子视图优先**，与视觉上的「最上层」一致。
第一个非 nil 即返回：找到第一个返回非 nil 的子视图就停止，该子视图即为 hit-test view。

3.3 point(inside:with:) 默认行为

默认实现等价于：判断点是否落在视图的 bounds 内（通常不考虑 subview 的超出部分；且若父视图 clipsToBounds == true，超出父视图 bounds 的子视图区域不会参与父视图的 hit-test，因为点不在父视图 bounds 内会先被剪枝）[[1]]。

函数 pointInside(point, event) -> Bool:
    返回 CGRectContainsPoint(self.bounds, 将 point 转换到当前视图的 bounds 坐标系)

可重写以扩大或缩小可点击区域（如圆形按钮、不规则形状、透明区域穿透等）。

四、事件传递流程（自上而下）

4.1 流程图

flowchart TB
    A[触摸发生] --> B[UIWindow 收到事件]
    B --> C[对根 view 调用 hitTest:withEvent:]
    C --> D{pointInside 为 true?}
    D -->|否| E[返回 nil，该分支结束]
    D -->|是| F[按逆序遍历子视图]
    F --> G[对子视图递归 hitTest]
    G --> H{有子视图返回非 nil?}
    H -->|是| I[返回该子视图 作为 hit-test view]
    H -->|否| J[返回 self]
    I --> K[该 view 成为触摸的 first responder]
    J --> K

4.2 泳道图：Hit-Test 各角色协作

flowchart TB
    subgraph 用户
        U1[手指触摸屏幕]
    end
    subgraph 系统_UIApplication
        S1[事件入队]
        S2[派发至 keyWindow]
    end
    subgraph 系统_UIWindow
        W1[hitTest 根 view]
        W2[得到 hit-test view]
    end
    subgraph 视图层级
        V1[pointInside 判断]
        V2[逆序遍历子视图]
        V3[递归 hitTest]
        V4[返回最终 view]
    end
    U1 --> S1
    S1 --> S2
    S2 --> W1
    W1 --> V1
    V1 --> V2
    V2 --> V3
    V3 --> V4
    V4 --> W2

4.3 Hit-Test 知识结构（思维导图）

mindmap
  root((Hit-Test))
    入口
      UIWindow 根视图
      hitTest:withEvent:
    条件
      userInteractionEnabled
      hidden / alpha
      pointInside
    遍历
      子视图逆序
      Z 轴优先
    结果
      hit-test view
      first responder
    自定义
      扩大热区
      穿透
      不规则区域

五、子视图顺序与 Z 轴

子视图在 subviews 数组中的索引越大，在 hit-test 时越先被遍历，因此后加入的、索引更大的子视图会优先被命中，与它们在屏幕上的「盖在上面」一致。若两个子视图重叠，则上面那一层会先被 hitTest 到并成为 hit-test view。

flowchart LR
    subgraph 视图层级
        V[父视图]
        V --> A[子视图 A index 0]
        V --> B[子视图 B index 1]
        V --> C[子视图 C index 2]
    end
    subgraph hitTest 顺序
        C --> B
        B --> A
    end

六、clipsToBounds 与命中

pointInside 只判断点是否在当前视图的 bounds 内。
若父视图设置了 clipsToBounds = true，子视图超出父视图 bounds 的部分会被裁剪掉显示，但 hit-test 仍按 bounds 判断：若触摸点落在父视图 bounds 外（即使落在子视图的 frame 内），父视图的 pointInside 会返回 false，整棵子树不会参与命中 [[1]]。
因此：子视图若超出父视图 bounds 且父视图 clipsToBounds，超出部分在默认实现下无法被 hit-test 命中，除非在父视图层重写 point(inside:with:) 或 hitTest(_:with:) 做特殊处理。

七、自定义 hitTest / pointInside 的常见用法

需求	做法
扩大点击区域	重写 `point(inside:with:)`，对中心区域做扩展（如上下左右各扩展 44pt）
透明区域不响应	重写 `point(inside:with:)`，根据像素透明度返回 false
让触摸「穿透」到下层	重写 `hitTest(_:with:)`，在特定条件下返回 nil，使当前视图不参与命中
指定子视图优先	重写 `hitTest(_:with:)`，自定义遍历顺序或强制返回某子视图

示例（扩大点击区域）：

override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
    let inset: CGFloat = -20
    return bounds.insetBy(dx: inset, dy: inset).contains(point)
}

商用场景示例：商品列表 Cell 内「加购」「收藏」等小图标，视觉约 24pt，为提升点击率将热区扩大到 44pt，重写该图标的容器 view 或子类的 point(inside:with:) 即可。

穿透示例（浮层不拦截、点击落到下层）：

/// 用于半透明遮罩：触摸不消费，交给下层视图（如背后的列表、按钮）
class PassThroughView: UIView {
    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
        let hit = super.hitTest(point, with: event)
        return hit == self ? nil : hit  // 若命中自己则返回 nil，让下层接收
    }
}

商用场景示例：活动弹窗关闭后残留半透明遮罩，希望点击遮罩空白处能穿透到下层（如关闭按钮、跳过）；或直播/视频上的礼物动画层不拦截点击，让下层进度条、点赞可点。

Swift 完整示例：可复用的「扩大热区」UIView 子类（适用于任意按钮/图标）：

/// 将子视图的可点击区域向外扩展，不改变视觉 frame
final class ExpandHitAreaView: UIView {
    var hitAreaInset: UIEdgeInsets = .zero  // 负值表示扩大，如 (-10,-10,-10,-10)
    override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
        bounds.inset(by: hitAreaInset).contains(point)
    }
}
// 使用：将按钮包在 ExpandHitAreaView 内，设置 hitAreaInset = UIEdgeInsets(top: -10, left: -10, bottom: -10, right: -10)

八、与响应者链的衔接

hit-test 得到的是触摸事件的第一响应者（某个 UIView）。触摸事件会先发给该视图（及其上的手势识别器）；若视图未处理或未实现 touchesBegan 等，事件会沿 nextResponder 向上传递。因此：

阶段一（本文）：hit-test，自顶向下，确定「谁被点中」。
阶段二：响应者链，自底向上，确定「谁处理」。详见 03-响应者链与 nextResponder 详解。

参考文献

[1] Using responders and the responder chain to handle events - Determine which responder contained a touch event
[2] Event handling for iOS - hitTest:withEvent: and pointInside:withEvent:
[3] HitTest and UIResponder in iOS (Medium)

尝试给Lookin 支持 MCP

掘金 iOS

FeliksLv

2026年3月1日 22:33

不知道大家在 Vibe Coding 的时候，是否经常遇到这样的情况，让 AI 修改一个复杂页面，改完之后发现布局乱了，只能通过文字描述让 AI 去改，还经常改不对。

在日常开发中，我们经常会使用 Lookin 来查看布局，我想能否给 Lookin 支持 MCP 查看布局+刷新。这样是不是就不用我们自己给 AI 描述问题了。

于是我开始了这个集成工作，用本文记录下整个过程。先放下最终效果：

Lookin MCP 支持的所有方法

#	方法名	描述	参数
1	get_status	获取 Lookin 服务器状态和连接状态，返回是否有 iOS 应用连接以及是否有层级数据	无
2	list_apps	列出所有连接的 iOS 应用及其基本信息	无
3	get_hierarchy	获取已连接 iOS 应用的完整视图层级，返回所有视图及其属性、frame 和关系	flat: bool (可选) - 是否返回扁平数组 maxDepth: int (可选) - 最大遍历深度
4	get_view	通过 oid 获取指定视图的详细信息，包括 frame、bounds、类继承链等	oid: int (必需) - 视图对象 ID
5	get_screenshot	获取指定视图的截图，返回 base64 编码的 PNG 图片	oid: int (必需) - 视图对象 ID
6	search_views	按类名、文字内容或 oid 搜索视图	query: string (必需) - 搜索关键词 type: enum (可选) - 搜索类型: "class"/"text"/"oid"
7	list_viewcontrollers	列出应用中所有的 ViewController，包括类名、内存地址和关联的视图 oid	无
8	get_app_info	获取已连接 iOS 应用的详细信息，包括应用名、Bundle ID、设备名、OS 版本、屏幕尺寸	无
9	reload_hierarchy	重新加载视图层级数据，用于 UI 变化后刷新数据	无
10	get_view_attributes	获取视图的完整属性详情，包括所有属性组（Layout、AutoLayout、UILabel、UIScrollView 等）、事件处理器（手势、target-action）和 AutoLayout 约束	oid: int (必需) - 视图对象 ID

第一版-双进程

MCP 协议要求 Server 通过 stdio（标准输入/输出）与 Client 通信，这对于 GUI 应用来说是个问题：

macOS GUI 应用没有 stdin/stdout
GUI 应用不适合作为子进程被其他应用启动
Lookin 需要保持独立运行以维护与 iOS 设备的连接

所以第一版采用双进程架构：一个独立的命令行工具 lookin-mcp 处理 MCP 协议，通过 HTTP 与 Lookin 主应用通信。

sequenceDiagram
    participant AI as AI 工具
    participant MCP as lookin-mcp
    participant HTTP as LKMCPServer
    participant iOS as iOS App
    
    Note over AI,MCP: stdio (JSON-RPC)
    Note over MCP,HTTP: HTTP (REST)
    Note over HTTP,iOS: Peertalk/Bonjour
    
    AI->>MCP: tools/call (get_hierarchy)
    MCP->>HTTP: GET /hierarchy
    HTTP->>iOS: 获取视图数据
    iOS-->>HTTP: LookinHierarchyInfo
    HTTP-->>MCP: JSON Response
    MCP-->>AI: Tool Result

组件	角色	通信方式
`lookin-mcp`	MCP Server	stdio (JSON-RPC)
`LKMCPServer`	HTTP Server	HTTP REST API
Lookin.app	主应用	内嵌 HTTP Server

实现细节

1. 手写 MCP 协议

MCP 协议基于 JSON-RPC 2.0，需要实现请求/响应的解析和序列化：

struct JSONRPCRequest: Codable {
    let jsonrpc: String
    let id: RequestId?
    let method: String
    let params: AnyCodable?
}

struct JSONRPCResponse: Codable {
    let jsonrpc: String
    let id: RequestId?
    let result: AnyCodable?
    let error: JSONRPCError?
}

2. HTTP Server (LKMCPServer)

在 Lookin 主应用中内嵌一个轻量级 HTTP Server，监听 127.0.0.1:47199：

@implementation LKMCPServer

- (void)start {
    self.server = [[GCDWebServer alloc] init];
    
    // GET /status - 检查连接状态
    [self.server addHandlerForMethod:@"GET" path:@"/status" 
        requestClass:[GCDWebServerRequest class]
        processBlock:^GCDWebServerResponse *(GCDWebServerRequest *request) {
            return [self handleStatusRequest];
        }];
    
    // GET /hierarchy - 获取视图层级
    [self.server addHandlerForMethod:@"GET" path:@"/hierarchy" ...];
    
    // POST /reload - 刷新数据
    [self.server addHandlerForMethod:@"POST" path:@"/reload" ...];
    
    [self.server startWithPort:47199 bonjourName:nil];
}

@end

3. MCP Tools 定义

第一版实现了 8 个 Tools：

Tool	描述	HTTP 映射
`status`	检查连接状态	GET /status
`get_hierarchy`	获取视图层级	GET /hierarchy
`get_view`	获取视图详情	GET /view/:oid
`search`	搜索视图	GET /search?q=&type=
`get_screenshot`	获取视图截图	GET /screenshot/:oid
`get_app_info`	获取应用信息	GET /app-info
`list_view_controllers`	列出 VC	GET /viewcontrollers
`reload`	刷新层级数据	POST /reload

4. 构建和部署

需要在 Xcode Build Phase 中添加脚本，将 lookin-mcp 复制到 app bundle：

# Scripts/build_mcp.sh
cd "${SRCROOT}/LookinMCP"
swift build -c release

mkdir -p "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/Helpers"
cp ".build/release/lookin-mcp" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/Helpers/"

通信流程

启动流程：

sequenceDiagram
    participant User as 用户
    participant Lookin as Lookin.app
    participant Pref as LKPreferenceManager
    participant HTTP as LKMCPServer
    
    User->>Lookin: 启动应用
    Lookin->>Pref: 读取 enableMCPServer
    alt MCP Server 已启用
        Pref-->>Lookin: YES
        Lookin->>HTTP: start()
        HTTP-->>Lookin: 监听 127.0.0.1:47199
    else MCP Server 已禁用
        Pref-->>Lookin: NO
        Note over HTTP: 不启动
    end

查询流程：

sequenceDiagram
    participant AI as AI 工具
    participant MCP as lookin-mcp
    participant HTTP as LKMCPServer
    participant DS as DataSource
    
    AI->>MCP: {"method": "tools/call", "params": {"name": "get_hierarchy"}}
    MCP->>HTTP: GET http://127.0.0.1:47199/hierarchy
    HTTP->>DS: flatItems
    DS-->>HTTP: [LookinDisplayItem]
    HTTP-->>MCP: {"views": [...], "total": 150}
    MCP-->>AI: {"content": [{"type": "text", "text": "..."}]}

使用方式

以OpenCode为例，修改 ～/.config/opencode/opencode.json：

{
  "mcp": {
    "lookin": {
        "type": "local",
        "command": "/Applications/Lookin.app/Contents/Helpers/lookin-mcp"
    }
  }
}

运行试了一下，可以拿到对应节点的视图信息。

第一版的问题

虽然能用，但有几个不太满意的地方：

双进程架构复杂 - 需要维护两套代码，调试也麻烦
手写协议不可靠 - MCP 协议还在演进，手写实现容易出 bug
部署麻烦 - 需要在 Build Phase 中复制二进制文件
配置繁琐 - 用户需要手动修改 JSON 配置文件

第二版

MCP 是有 Swift 版本官方 SDK 的：

github.com/modelcontex…

既然有官方 SDK，为什么还要自己手写协议呢？而且第一版的双进程架构也有点复杂。于是我决定重构，目标是：

使用官方 Swift SDK 替换手写的 MCP 协议实现
将 MCP Server 内嵌到 Lookin 主应用，去掉独立进程
使用 HTTP Transport，简化用户配置

新架构

graph TB
    subgraph "AI 工具"
        AI[OpenCode / Claude / Cursor ...]
    end
    
    subgraph "Lookin.app"
        HTTP[NIO HTTP Server<br/>:47199/mcp]
        MCP[MCP Server<br/>官方 Swift SDK]
        DS[LKStaticHierarchyDataSource]
        Apps[LKAppsManager]
    end
    
    subgraph "iOS App"
        LookinServer[LookinServer SDK]
    end
    
    AI <-->|HTTP<br/>MCP Protocol| HTTP
    HTTP --> MCP
    MCP --> DS
    MCP --> Apps
    Apps <-->|USB/WiFi| LookinServer

对比一下两个版本：

对比项	第一版	第二版
协议实现	手写 JSON-RPC	官方 Swift SDK
进程模型	双进程 (stdio + HTTP)	单进程 (内嵌 HTTP)
通信方式	stdio → HTTP → 数据源	HTTP → 数据源
配置方式	修改配置文件	一行命令
依赖管理	复制二进制到 app bundle	SPM 本地 Package

SDK 选型

官方 SDK 版本 0.11.0 支持多种 Transport：

StdioServerTransport: 传统的 stdio 方式
StreamableHTTPServerTransport: 有状态的 HTTP 流式传输
StatelessHTTPServerTransport: 无状态 HTTP，适合简单场景

我选择了 StatelessHTTPServerTransport，因为 Lookin 的场景不需要维护会话状态，每次请求都是独立的查询。

实现细节

1. LookinMCP Package 结构

重构后的 Package 变得更简洁：

LookinMCP/
├── Package.swift                    # SPM 配置，依赖官方 SDK
└── Sources/LookinMCP/
    ├── LookinMCPDataSource.swift    # 数据源协议 + 模型定义
    ├── LookinMCPServer.swift        # HTTP Server + MCP Server
    └── LookinMCPToolHandler.swift   # 9 个 Tools 的注册和处理

Package.swift 配置：

// swift-tools-version: 6.1
import PackageDescription

let package = Package(
    name: "LookinMCP",
    platforms: [.macOS(.v13)],
    products: [
        .library(name: "LookinMCP", targets: ["LookinMCP"]),
    ],
    dependencies: [
        .package(url: "https://github.com/modelcontextprotocol/swift-sdk.git", from: "0.11.0"),
    ],
    targets: [
        .target(
            name: "LookinMCP",
            dependencies: [
                .product(name: "MCP", package: "swift-sdk"),
            ]
        ),
    ]
)

2. HTTP Server 实现

SDK 提供了 StatelessHTTPServerTransport，但需要自己搭建 HTTP Server。参考 SDK 示例，使用 swift-nio：

public func start() async throws {
    let bootstrap = ServerBootstrap(group: eventLoopGroup)
        .serverChannelOption(.backlog, value: 256)
        .childChannelInitializer { channel in
            channel.pipeline.configureHTTPServerPipeline().flatMap {
                channel.pipeline.addHandler(HTTPHandler(transport: self.transport))
            }
        }
    
    let channel = try await bootstrap.bind(host: host, port: port).get()
    // Server started on http://127.0.0.1:47199/mcp
}

3. Tool 注册

使用 SDK 的 withMethodHandler API 注册 Tools：

await server.withMethodHandler(ListTools.self) { _ in
    ListToolsResult(tools: [
        Tool(name: "status", description: "Check Lookin connection status"),
        Tool(name: "get_hierarchy", description: "Get view hierarchy", inputSchema: ...),
        // ... 更多 tools
    ])
}

await server.withMethodHandler(CallTool.self) { params in
    switch params.name {
    case "status":
        let status = await dataSource.getStatus()
        return CallToolResult(content: [.text(status.toJSON())])
    case "get_hierarchy":
        // ...
    }
}

4. 主应用集成

在 AppDelegate.m 中启动 MCP Server：

if ([LKPreferenceManager mainManager].enableMCPServer) {
    [[MCPServerManager shared] start];
}

MCPServerManager 是一个 Swift 类，提供 @objc 接口供 Obj-C 调用：

@objc(MCPServerManager)
@MainActor
final class MCPServerManager: NSObject {
    @objc static let shared = MCPServerManager()
    
    @objc func start() {
        Task {
            let server = try await LookinMCPServer(dataSource: dataProvider, port: 47199)
            try await server.start()
        }
    }
}

使用方式

对于 OpenCode：

// .config/opencode/opencode.json
{
    // ...
  "mcp": {
    "lookin": {
      "type": "remote",
      "url": "http://127.0.0.1:47199/mcp",
      "enabled": true
    }
  }
}

对于 Claude Code：

claude mcp add --transport http lookin http://127.0.0.1:47199/mcp

然后就可以直接使用了：

现在可以愉快地让 AI 帮我看布局、找问题了！

代码放在 fork 的仓库里：github.com/FeliksLv01/…

01-研究系统框架@Web@iOS | JavaScriptCore 框架：从使用到原理解析

掘金 iOS

没有故事的Zhang同学

2026年3月1日 20:10

JavaScript 越来越多地出现在我们客户端开发的视野中，从 React Native 到 JSPatch，JavaScript 与客户端相结合的技术开始变得魅力无穷。本文主要讲解 iOS 中的 JavaScriptCore 框架，正是它为 iOS 提供了执行 JavaScript 代码的能力。未来的技术日新月异，JavaScript 与 iOS 正在碰撞出新的激情。

JavaScriptCore 是 JavaScript 的虚拟机，为 JavaScript 的执行提供底层资源。

📋 目录

一、JavaScript

在讨论JavaScriptCore之前，我们首先必须对JavaScript有所了解。

1. JavaScript干啥的？

说的高大上一点：一门基于原型、函数先行的高级编程语言，通过解释执行，是动态类型的直译语言。是一门多范式的语言，它支持面向对象编程，命令式编程，以及函数式编程。
说的通俗一点：主要用于网页，为其提供动态交互的能力。可嵌入动态文本于HTML页面，对浏览器事件作出响应，读写HTML元素，控制cookies等。
再通俗一点：抢月饼，button.click()。（PS：请谨慎使用while循环）

2. JavaScript起源与历史

1990年底，欧洲核能研究组织（CERN）科学家Tim Berners-Lee，在互联网的基础上，发明了万维网（World Wide Web），从此可以在网上浏览网页文件。
1994年12月，Netscape 发布了一款面向普通用户的新一代的浏览器Navigator 1.0版，市场份额一举超过90%。
1995年，Netscape公司雇佣了程序员Brendan Eich开发这种嵌入网页的脚本语言。最初名字叫做Mocha，1995年9月改为LiveScript。
1995年12月，Netscape公司与Sun公司达成协议，后者允许将这种语言叫做JavaScript。

3. JavaScript与ECMAScript

“JavaScript”是Sun公司的注册商标，用来特制网景（现在的Mozilla）对于这门语言的实现。网景将这门语言作为标准提交给了ECMA——欧洲计算机制造协会。由于商标上的冲突，这门语言的标准版本改了一个丑陋的名字“ECMAScript”。同样由于商标的冲突，微软对这门语言的实现版本取了一个广为人知的名字“Jscript”。
ECMAScript作为JavaScript的标准，一般认为后者是前者的实现。

4. Java和JavaScript

《雷锋和雷峰塔》

Java 和 JavaScript 是两门不同的编程语言一般认为，当时 Netscape 之所以将 LiveScript 命名为 JavaScript，是因为 Java 是当时最流行的编程语言，带有 “Java” 的名字有助于这门新生语言的传播。

二、 JavaScriptCore

1. 浏览器演进

演进完整图

upload.wikimedia.org/wikipedia/c…

WebKit分支

现在使用WebKit的主要两个浏览器Sfari和Chromium（Chorme的开源项目）。WebKit起源于KDE的开源项目Konqueror的分支，由苹果公司用于Sfari浏览器。其一条分支发展成为Chorme的内核，2013年Google在此基础上开发了新的Blink内核。

2. WebKit排版引擎

webkit是sfari、chrome等浏览器的排版引擎，各部分架构图如下

webkit Embedding API是browser UI与webpage进行交互的api接口；
platformAPI提供与底层驱动的交互，如网络，字体渲染，影音文件解码，渲染引擎等；
WebCore它实现了对文档的模型化，包括了CSS, DOM, Render等的实现；
JSCore是专门处理JavaScript脚本的引擎；

3. JavaScript引擎

JavaScript引擎是专门处理JavaScript脚本的虚拟机，一般会附带在网页浏览器之中。第一个JavaScript引擎由布兰登·艾克在网景公司开发，用于Netscape Navigator网页浏览器中。JavaScriptCore就是一个JavaScript引擎。
下图是当前主要的还在开发中的JavaScript引擎

4. JavaScriptCore组成

JavaScriptCore主要由以下模块组成：

Lexer 词法分析器，将脚本源码分解成一系列的Token
Parser 语法分析器，处理Token并生成相应的语法树
LLInt 低级解释器，执行Parser生成的二进制代码
Baseline JIT 基线JIT（just in time 实施编译）
DFG 低延迟优化的JIT
FTL 高通量优化的JIT

关于更多JavaScriptCore的实现细节，参考 trac.webkit.org/wiki/JavaSc…

5. JavaScriptCore 框架与历史

JavaScriptCore 是一个 C++ 实现的开源项目（WebKit 的一部分）。历史上，JSC 长期作为 Safari / WebKit 的内置 JS 引擎；自 iOS 7.0 / OS X 10.9 起，Apple 将 JavaScriptCore 以系统框架 JavaScriptCore.framework 的形式开放给开发者，使其可在 Objective-C 或基于 C 的程序中执行 JavaScript 代码，并向 JS 环境中插入自定义对象，而无需依赖 UIWebView。这为 Hybrid 应用、热更新、脚本引擎等场景提供了统一的底层能力。

在 JavaScriptCore.h 中，我们可以看到：

#ifndef JavaScriptCore_h
#define JavaScriptCore_h

#include <JavaScriptCore/JavaScript.h>
#include <JavaScriptCore/JSStringRefCF.h>

#if defined(__OBJC__) && JSC_OBJC_API_ENABLED

#import "JSContext.h"
#import "JSValue.h"
#import "JSManagedValue.h"
#import "JSVirtualMachine.h"
#import "JSExport.h"

#endif

#endif /* JavaScriptCore_h */

这里已经很清晰地列出了JavaScriptCore的主要几个类：

JSContext
JSValue
JSManagedValue
JSVirtualMachine
JSExport

接下来我们会依次讲解这几个类的用法。

6. Hello World！

这段代码展示了如何在 Objective-C 中执行一段 JavaScript 代码，并且获取返回值并转换成 OC 数据打印：

// 创建虚拟机
JSVirtualMachine *vm = [[JSVirtualMachine alloc] init];

//创建上下文
JSContext *context = [[JSContext alloc] initWithVirtualMachine:vm];

//执行JavaScript代码并获取返回值
JSValue *value = [context evaluateScript:@"1+2*3"];

// 转换成 OC 数据并打印
NSLog(@"value = %d", [value toInt32]);
// Output: value = 7

Swift 等价写法：

import JavaScriptCore

let vm = JSVirtualMachine()!
let context = JSContext(virtualMachine: vm)!
let value = context.evaluateScript("1 + 2 * 3")!
print("value =", value.toInt32())  // value = 7

三、 JSVirtualMachine

一个JSVirtualMachine的实例就是一个完整独立的JavaScript的执行环境，为JavaScript的执行提供底层资源。

这个类主要用来做两件事情：

实现并发的 JavaScript 执行
JavaScript 和 Objective-C 桥接对象的内存管理

看下头文件 JSVirtualMachine.h 里有什么：

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSVirtualMachine : NSObject

/* 创建一个新的完全独立的虚拟机 */
(instancetype)init;

/* 对桥接对象进行内存管理 */
- (void)addManagedReference:(id)object withOwner:(id)owner;

/* 取消对桥接对象的内存管理 */
- (void)removeManagedReference:(id)object withOwner:(id)owner;

@end

每一个JavaScript上下文（JSContext对象）都归属于一个虚拟机（JSVirtualMachine）。每个虚拟机可以包含多个不同的上下文，并允许在这些不同的上下文之间传值（JSValue对象）。

然而，每个虚拟机都是完整且独立的，有其独立的堆空间和垃圾回收器（garbage collector ），GC无法处理别的虚拟机堆中的对象，因此你不能把一个虚拟机中创建的值传给另一个虚拟机。

线程和JavaScript的并发执行

JavaScriptCore API都是线程安全的。你可以在任意线程创建JSValue或者执行JS代码，然而，所有其他想要使用该虚拟机的线程都要等待。

如果想并发执行JS，需要使用多个不同的虚拟机来实现。
可以在子线程中执行JS代码。

通过下面这个 demo 来理解这个并发机制：

JSContext *context = [[CustomJSContext alloc] init];
JSContext *context1 = [[CustomJSContext alloc] init];
JSContext *context2 = [[CustomJSContext alloc] initWithVirtualMachine:[context virtualMachine]];
NSLog(@"start");
dispatch_async(queue, ^{
    while (true) {
        sleep(1);
        [context evaluateScript:@"log('tick')"];
    }
});
dispatch_async(queue1, ^{
    while (true) {
        sleep(1);
        [context1 evaluateScript:@"log('tick_1')"];
    }
});
dispatch_async(queue2, ^{
    while (true) {
        sleep(1);
        [context2 evaluateScript:@"log('tick_2')"];
    }
});
[context evaluateScript:@"sleep(5)"];
NSLog(@"end");

context和context2属于同一个虚拟机。

context1属于另一个虚拟机。

三个线程分别异步执行每秒1次的js log，首先会休眠1秒。

在context上执行一个休眠5秒的JS函数。

首先执行的应该是休眠5秒的JS函数，在此期间，context所处的虚拟机上的其他调用都会处于等待状态，因此tick和tick_2在前5秒都不会有执行。

而context1所处的虚拟机仍然可以正常执行tick_1。

休眠5秒结束后，tick和tick_2才会开始执行（不保证先后顺序）。

实际运行输出的 log 是：

start
tick_1
tick_1
tick_1
tick_1
end
tick
tick_2

四、 JSContext

一个JSContext对象代表一个JavaScript执行环境。在native代码中，使用JSContext去执行JS代码，访问JS中定义或者计算的值，并使JavaScript可以访问native的对象、方法、函数。

1. JSContext执行JS代码

调用evaluateScript函数可以执行一段top-level 的JS代码，并可向global对象添加函数和对象定义
其返回值是JavaScript代码中最后一个生成的值

API Reference

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSContext : NSObject

/* 创建一个JSContext，同时会创建一个新的JSVirtualMachine */
(instancetype)init;

/* 在指定虚拟机上创建一个JSContext */
(instancetype)initWithVirtualMachine:
        (JSVirtualMachine*)virtualMachine;

/* 执行一段JS代码，返回最后生成的一个值 */
(JSValue *)evaluateScript:(NSString *)script;

/* 执行一段JS代码，并将sourceURL认作其源码URL（仅作标记用） */
- (JSValue *)evaluateScript:(NSString *)script withSourceURL:(NSURL*)sourceURL     NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的context */
+ (JSContext *)currentContext;

/* 获取当前执行的JavaScript function*/
+ (JSValue *)currentCallee NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的this */
+ (JSValue *)currentThis;

/* Returns the arguments to the current native callback from JavaScript code.*/
+ (NSArray *)currentArguments;

/* 获取当前context的全局对象。WebKit中的context返回的便是WindowProxy对象*/
@property (readonly, strong) JSValue *globalObject;

@property (strong) JSValue *exception;
@property (copy) void(^exceptionHandler)(JSContext *context, JSValue
    *exception);

@property (readonly, strong) JSVirtualMachine *virtualMachine;

@property (copy) NSString *name NS_AVAILABLE(10_10, 8_0);


@end

2. JSContext访问JS对象

一个JSContext对象对应了一个全局对象（global object）。例如web浏览器中中的JSContext，其全局对象就是window对象。在其他环境中，全局对象也承担了类似的角色，用来区分不同的JavaScript context的作用域。全局变量是全局对象的属性，可以通过JSValue对象或者context下标的方式来访问。

示例代码：

JSValue *value = [context evaluateScript:@"var a = 1+2*3;"];

NSLog(@"a = %@", [context objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", [context.globalObject objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", context[@"a"]);
// Output: a = 7, a = 7, a = 7

这里列出了三种访问JavaScript对象的方法

通过context的实例方法objectForKeyedSubscript
通过context.globalObject的objectForKeyedSubscript实例方法
通过下标方式

设置属性也是对应的。

API Reference

/* 为 JSContext 提供下标访问元素的方式 */
@interface JSContext (SubscriptSupport)

/* 首先将key转为JSValue对象，然后使用这个值在JavaScript context的全局对象中查找这个名字的属性并返回 */
(JSValue *)objectForKeyedSubscript:(id)key;

/* 首先将key转为JSValue对象，然后用这个值在JavaScript context的全局对象中设置这个属性。
可使用这个方法将native中的对象或者方法桥接给JavaScript调用 */
(void)setObject:(id)object forKeyedSubscript:(NSObject <NSCopying>*)key;

@end



/* 例如：以下代码在JavaScript中创建了一个实现是Objective-C block的function */
context[@"makeNSColor"] = ^(NSDictionary *rgb){
    float r = [rgb[@"red"] floatValue];
    float g = [rgb[@"green"] floatValue];
    float b = [rgb[@"blue"] floatValue];
    return [NSColor colorWithRed:(r / 255.f) green:(g / 255.f) blue:(b / 255.f)         alpha:1.0];
};
JSValue *value = [context evaluateScript:@"makeNSColor({red:12, green:23, blue:67})"];

五、 JSValue

一个JSValue实例就是一个JavaScript值的引用。使用JSValue类在JavaScript和native代码之间转换一些基本类型的数据（比如数值和字符串）。你也可以使用这个类去创建包装了自定义类的native对象的JavaScript对象，或者创建由native方法或者block实现的JavaScript函数。

每个JSValue实例都来源于一个代表JavaScript执行环境的JSContext对象，这个执行环境就包含了这个JSValue对应的值。每个JSValue对象都持有其JSContext对象的强引用，只要有任何一个与特定JSContext关联的JSValue被持有（retain），这个JSContext就会一直存活。通过调用JSValue的实例方法返回的其他的JSValue对象都属于与最始的JSValue相同的JSContext。

每个JSValue都通过其JSContext间接关联了一个特定的代表执行资源基础的JSVirtualMachine对象。你只能将一个JSValue对象传给由相同虚拟机管理（host）的JSValue或者JSContext的实例方法。如果尝试把一个虚拟机的JSValue传给另一个虚拟机，将会触发一个Objective-C异常。

1. JSValue类型转换

JSValue提供了一系列的方法将native与JavaScript的数据类型进行相互转换：

2. NSDictionary与JS对象

NSDictionary 对象以及其包含的 keys 与 JavaScript 中的对应名称的属性相互转换。key 所对应的值也会递归地进行拷贝和转换。

[context evaluateScript:@"var color = {red:230, green:90, blue:100}"];

//js->native 给你看我的颜色
JSValue *colorValue = context[@"color"];
NSLog(@"r=%@, g=%@, b=%@", colorValue[@"red"], colorValue[@"green"], colorValue[@"blue"]);
NSDictionary *colorDic = [colorValue toDictionary];
NSLog(@"r=%@, g=%@, b=%@", colorDic[@"red"], colorDic[@"green"], colorDic[@"blue"]);

//native->js 给你点颜色看看
context[@"color"] = @{@"red":@(0), @"green":@(0), @"blue":@(0)};
[context evaluateScript:@"log('r:'+color.red+'g:'+color.green+' b:'+color.blue)"];
// Output:
// r=230, g=90, b=100
// r=230, g=90, b=100
// r:0 g:0 b:0

可见，JS中的对象可以直接转换成Objective-C中的NSDictionary，NSDictionary传入JavaScript也可以直接当作对象被使用。

3. NSArray与JS数组

NSArray 对象与 JavaScript 中的 array 相互转换。其子元素也会递归地进行拷贝和转换。

[context evaluateScript:@"var friends = ['Alice','Jenny','XiaoMing']"];

//js->native 你说哪个是真爱？
JSValue *friendsValue = context[@"friends"];
NSLog(@"%@, %@, %@", friendsValue[0], friendsValue[1], friendsValue[2]);
NSArray *friendsArray = [friendsValue toArray];
NSLog(@"%@, %@, %@", friendsArray[0], friendsArray[1], friendsArray[2]);

//native->js 我觉得 XiaoMing 不错，给你再推荐个 Jimmy
context[@"girlFriends"] = @[friendsArray[2], @"Jimmy"];
[context evaluateScript:@"log('girlFriends :'+girlFriends[0]+' '+girlFriends[1])"];
// Output: Alice, Jenny, XiaoMing / girlFriends : XiaoMing Jimmy

4. Block/函数和JS function

Objective-C中的block转换成JavaScript中的function对象。参数以及返回类型使用相同的规则转换。

将一个代表native的block或者方法的JavaScript function进行转换将会得到那个block或方法。

其他的JavaScript函数将会被转换为一个空的dictionary。因为JavaScript函数也是一个对象。

5. OC对象和JS对象

对于所有其他 native 的对象类型，JavaScriptCore 都会创建一个拥有 constructor 原型链的 wrapper 对象，用来反映 native 类型的继承关系。默认情况下，native 对象的属性和方法并不会导出给其对应的 JavaScript wrapper 对象。通过 JSExport 协议可选择性地导出属性和方法。下面第六节对 JSExport 与原生对象导出做详细讲解。

六、JSExport 与原生对象导出

JSExport 是 JavaScriptCore 框架中的协议，用于将 Objective-C/Swift 的类（属性与方法）选择性导出给 JavaScript，使 JS 代码可以像调用普通对象一样调用原生对象 [1][2]。

6.1 作用与机制

遵循 JSExport 的协议中声明的属性和方法，会在将 native 对象注入到 JSContext（如 context[@"bridge"] = nativeObject）时，自动暴露为 JS 侧的属性和函数。
若类未实现 JSExport 或未在协议中声明，则对应属性/方法不会出现在 JS 中；这样可控制「桥接面」，避免暴露内部实现 [1][2]。

6.2 使用示例（概念）

@protocol MyPointExport <JSExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
- (NSString *)description;
@end

@interface MyPoint : NSObject <MyPointExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
@end

将 MyPoint 实例赋给 context[@"point"] 后，在 JS 中可访问 point.x、point.y 并调用 point.description()。
注意：若在 Block 或导出方法中再次使用 JSValue 或 JSContext，需注意线程与内存管理（见第七节 JSManagedValue）[1][2]。

Swift 中的等价写法（通过 JSContext 注入遵循 JSExport 的类）：

import JavaScriptCore

@objc protocol PointExport: JSExport {
    var x: Double { get set }
    var y: Double { get set }
    func description() -> String
}

class Point: NSObject, PointExport {
    @objc var x: Double
    @objc var y: Double
    init(x: Double, y: Double) { self.x = x; self.y = y }
    func description() -> String { "Point(\(x), \(y))" }
}

// 注入到 context
let context = JSContext()!
context.setObject(Point(x: 1, y: 2), forKeyedSubscript: "point" as NSString)
context.evaluateScript("point.x; point.description()")

6.3 与 Block 注入的对比

方式	适用场景
context[@"fn"] = ^(id arg){ ... }	单次或简单逻辑，直接暴露为 JS 函数
JSExport 协议 + 原生对象	需要暴露多个方法/属性、保持对象身份与状态的「桥接对象」

七、JSManagedValue 与内存管理

7.1 为何需要 JSManagedValue

JSValue 对 JSContext 有强引用；JSContext 又挂在 JSVirtualMachine 上。
若在 堆上的 OC 对象（如某 ViewController 的 property）中直接强引用 JSValue，而该 JSValue 通过某种方式（例如被注入到 context 的全局对象）又引用回该 OC 对象，会形成 OC ↔ JS 的循环引用，导致 Context 与 OC 对象均无法释放 [1][2]。

7.2 JSManagedValue 的职责

JSManagedValue 是 JSValue 的包装类，用于在「被 OC 堆对象持有」的场景下，以条件保留的方式引用 JS 值，并可与 JSVirtualMachine 的 addManagedReference:withOwner: / removeManagedReference:withOwner: 配合，让虚拟机在合适的时机断开或保留对 native 对象的引用，从而打破循环、避免 JSContext 无法释放 [1][2]。

7.3 使用要点（概念）

当需要把 JSValue（或从 JS 传回的函数/对象）存为 OC 对象的成员变量时，应使用 JSManagedValue 包装，并以 owner 注册到 JSVirtualMachine；在 owner 析构或不再需要时调用 removeManagedReference:withOwner: [1][2]。
仅临时在栈上使用 JSValue（如 evaluateScript 的返回值在方法内使用后不再持有）时，一般无需 JSManagedValue。

八、关键概念图示与流程

8.1 VM、Context、Value 关系

flowchart TB
  subgraph VM1[JSVirtualMachine 1]
    C1[JSContext 1]
    C2[JSContext 2]
  end
  subgraph VM2[JSVirtualMachine 2]
    C3[JSContext 3]
  end
  C1 --> V1[JSValue]
  C2 --> V2[JSValue]
  C1 -.->|可传值| C2
  C1 -.->|不可跨 VM| C3

同一 JSVirtualMachine 下多个 JSContext 可共享、传递 JSValue；不同 VM 之间不能传递 JSValue [3]。

8.2 JavaScriptCore 引擎执行层级（概念）

源码经 Lexer → Parser 得到语法树并生成字节码后，由下至上的执行/编译层级可概括为：

flowchart LR
  A[源码] --> B[Lexer]
  B --> C[Parser / AST]
  C --> D[字节码]
  D --> E[LLInt 解释器]
  E --> F[Baseline JIT]
  F --> G[DFG JIT]
  G --> H[FTL JIT]

LLInt：低级解释器，低延迟启动。
Baseline JIT：首次 JIT，兼顾分析与回退。
DFG：基于数据流的优化 JIT。
FTL：更高优化层（历史上曾用 LLVM/B3 后端）[4][5]。

更多实现细节见 WebKit JavaScriptCore Wiki。

九、应用场景与最佳实践

9.1 典型应用场景

场景	说明
Hybrid 应用	在 App 内执行 JS 脚本、调用原生能力（如弹窗、定位、支付），JavaScriptCore 提供 OC/Swift 与 JS 的双向桥接 [1][2]
React Native / 类 RN 方案	早期 RN 等方案在 iOS 上依赖 JSC 执行 JS bundle；JSC 提供 VM、Context、Value 等能力 [3]
JSPatch 等热修复	通过下发 JS 脚本并在 JSC 中执行，动态调用原生类与方法，实现热更新（需注意安全与审核政策）[3]
WKWebView 与 Web 页面	WKWebView 内部使用系统 WebKit，其 JS 引擎与 Safari 一致；独立使用 JSC 时无需 WebView 即可执行 JS [1][2]
规则引擎 / 脚本配置	将业务规则或配置写成 JS，由原生在 JSC 中执行并取结果，便于迭代与 A/B 测试

9.2 最佳实践要点

线程：同一 VM 下多线程会串行等待；需并发执行 JS 时使用多个 JSVirtualMachine [3]。
异常：设置 context.exceptionHandler，在 JS 抛错时记录或上报，避免静默失败 [3]。
内存：在 OC 堆对象中持有 JS 值时使用 JSManagedValue + add/removeManagedReference，避免循环引用 [1][2]。
安全：执行来自网络或不可信来源的 JS 时，需做沙箱与权限控制；避免将敏感 API 无限制暴露给 JS [3]。

十、伪代码与算法说明

10.1 执行脚本并取返回值（概念）

function evaluateScript(script: String) -> JSValue:
  parse script -> AST
  generate bytecode from AST
  execute bytecode (via LLInt or JIT tier)
  return last expression value as JSValue

10.2 将 Native 对象注入 Context（概念）

function setObject(object: Any, forKey key: String):
  if object is Block or conforms to JSExport:
    create JS wrapper (function or object with exported properties/methods)
  else:
    create generic wrapper preserving native type hierarchy
  set wrapper on context.globalObject[key]

10.3 JS 调用 Native Block 时（概念）

在 JavaScript 侧，调用通过 context[@"key"] 注入的 Block，与调用普通函数一致：

// 假设 Native 已注入：context["makeColor"] = ^(NSDictionary *rgb) { ... }
var color = makeColor({ red: 12, green: 23, blue: 67 });

底层流程（伪代码）：

当 JS 调用 context 中注册的 Block 时：
  1. JSC 将 JS 参数按类型转换为 OC 对象（NSNumber/NSString/NSDictionary/NSArray 等）
  2. 调用 Block，传入转换后的参数
  3. 将 Block 返回值按类型转换为 JSValue 并返回给 JS

参考文献

[1] Apple. JavaScriptCore Framework. iOS / macOS Developer Documentation.
[2] 掘金 / 博客. iOS 与 JS 交互开发知识总结、JavaScriptCore 初探 等.
[3] 本文原稿与常见 JSC 教程（JSVirtualMachine、JSContext、JSValue、并发与内存）.
[4] WebKit. Introducing the WebKit FTL JIT. webkit.org/blog/3362/i…
[5] WebKit. JavaScriptCore - Deep Dive. docs.webkit.org/Deep%20Dive…
[6] trac.webkit.org. JavaScriptCore. trac.webkit.org/wiki/JavaSc…
[7] 美团技术团队. 深入理解 JSCore. blog.csdn.net/MeituanTech…

SwiftUI路由管理架构揭秘：从混乱到优雅的蜕变

掘金 iOS

StarkCoder

2026年2月28日 19:26

引言

想象一下：当你打开一个 App，点击不同标签页，切换页面时，所有导航状态都能完美保持；当你从详情页返回时，TabBar 能智能地重新出现；当你需要传递数据时，类型安全的导航能让你告别字符串硬编码的烦恼。这一切，都离不开一个优秀的路由管理架构。

在现代 iOS 应用开发中，路由管理常常被视为"基础设施"而被忽视，但其重要性却不亚于任何核心功能。一个设计良好的路由系统，不仅能让代码结构更清晰，还能显著提升用户体验。今天，我将带大家深入剖析我项目中的路由管理架构，分享从设计到实现的全过程，希望能为你的项目带来启发。

路由架构概览

我项目的路由管理基于 SwiftUI 的 NavigationStack 和 NavigationPath，采用了集中式的路由管理方案。核心组件包括：

Router 类：全局导航路由器，管理所有 Tab 的导航路径
MainTab 枚举：定义应用的标签页结构
MainContainerView：主容器视图，负责整合标签页和导航逻辑
App 启动注入：在应用启动时将 Router 注入到环境中

路由的启动注入

在 EviApp.swift 中，我们通过 @StateObject 创建 Router 实例，并通过 environmentObject 将其注入到应用环境中：

import SwiftUI

@main
struct EviApp: App {
    // 把 AppDelegate 接进来，系统会照常调用 didFinishLaunchingWithOptions 等
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()
    
    var body: some Scene {
        WindowGroup {
            MainContainerView()
                .environmentObject(overlay)
                .environmentObject(router)
        }
    }
}

这样，在应用的任何视图中，都可以通过 @EnvironmentObject 来访问 Router 实例，实现全局路由管理。

核心组件分析

1. Router 类：路由管理的核心

import SwiftUI

/// 全局导航路由器，管理所有Tab的导航路径
class Router: ObservableObject {
    
    // 当前选中的Tab
    @Published var selectedTab: MainTab = .home
    
    // 为每个tab单独存储NavigationPath
    @Published var homePath = NavigationPath()
    @Published var hotPath = NavigationPath()
    @Published var creationPath = NavigationPath()
    @Published var stylePath = NavigationPath()
    @Published var profilePath = NavigationPath()
    
    // MARK: - 获取导航路径
    
    /// 获取指定tab的导航路径
    func getNavigationPath(for tab: MainTab) -> NavigationPath {
        switch tab {
        case .home: return homePath
        case .hot: return hotPath
        case .creation: return creationPath
        case .style: return stylePath
        case .profile: return profilePath
        }
    }
    
    /// 获取指定tab的导航路径绑定
    func getNavigationPathBinding(for tab: MainTab) -> Binding<NavigationPath> {
        switch tab {
        case .home: return binding(for: \.homePath)
        case .hot: return binding(for: \.hotPath)
        case .creation: return binding(for: \.creationPath)
        case .style: return binding(for: \.stylePath)
        case .profile: return binding(for: \.profilePath)
        }
    }
    
    // MARK: - 清空导航路径
    
    /// 清空指定tab的导航路径
    func clearPath(for tab: MainTab) {
        switch tab {
        case .home: clear(\.homePath)
        case .hot: clear(\.hotPath)
        case .creation: clear(\.creationPath)
        case .style: clear(\.stylePath)
        case .profile: clear(\.profilePath)
        }
    }
    
    /// 清空所有导航路径
    func clearAllPaths() {
        clear(\.homePath)
        clear(\.hotPath)
        clear(\.creationPath)
        clear(\.stylePath)
        clear(\.profilePath)
    }
    
    // MARK: - 当前Tab操作
    
    /// 获取当前选中Tab的导航路径
    func getCurrentNavigationPath() -> NavigationPath {
        return getNavigationPath(for: selectedTab)
    }
    
    /// 获取当前选中Tab的导航路径绑定
    func getCurrentNavigationPathBinding() -> Binding<NavigationPath> {
        return getNavigationPathBinding(for: selectedTab)
    }
    
    /// 清空当前选中Tab的导航路径
    func clearCurrentPath() {
        clearPath(for: selectedTab)
    }
    
    // MARK: - 私有辅助方法
    
    /// 创建导航路径的绑定
    private func binding(for keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) -> Binding<NavigationPath> {
        Binding {
            self[keyPath: keyPath]
        } set: {
            self[keyPath: keyPath] = $0
        }
    }
    
    /// 清空指定的导航路径
    private func clear(_ keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) {
        self[keyPath: keyPath].removeLast(self[keyPath: keyPath].count)
    }
}

设计亮点：

集中管理：所有路由逻辑集中在一个类中，便于统一管理
Tab 隔离：为每个标签页维护独立的导航路径，确保切换标签时不会影响其他标签的导航状态
响应式设计：使用 @Published 修饰符，实现路由状态的自动更新
便捷方法：提供了丰富的方法来操作导航路径，如获取路径、清空路径等

2. MainTab 枚举：标签页定义

import SwiftUI

/// 主标签栏枚举
enum MainTab {
    case home
    case hot
    case creation
    case style
    case profile
}

extension MainTab {
    
    /// 根据选中状态返回对应的图标名称
    func iconName(isSelected: Bool) -> String {
        switch self {
        case .home:
            return isSelected ? "tabbar_home_sel" : "tabbar_home_nor"
        case .hot:
            return isSelected ? "tabbar_hot_sel" : "tabbar_hot_nor"
        case .creation:
            return "tabbar_add"
        case .style:
            return isSelected ? "tabbar_style_sel" : "tabbar_style_nor"
        case .profile:
            return isSelected ? "tabbar_me_sel" : "tabbar_me_nor"
        }
    }
}

设计亮点：

类型安全：使用枚举定义标签页，避免了字符串硬编码
扩展功能：通过扩展为枚举添加了获取图标名称的功能，使代码更整洁

3. MainContainerView：路由的实际应用

import SwiftUI

/// 主容器视图，包含悬浮TabBar
struct MainContainerView: View {
    
    // 获取指定tab的导航路径
    private func getNavigationPath(for tab: MainTab) -> NavigationPath {
        return router.getNavigationPath(for: tab)
    }
    
    /// 创建带有NavigationStack的标签页视图
    private func tabView(_ tab: MainTab) -> some View {
        NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
            switch tab {
            case .home:
                HomeView()
            case .hot:
                HotHomeView()
            case .creation:
                CreationHomeView()
            case .style:
                StyleHomeView()
            case .profile:
                ProfileHomeView()
            }
        }
        .tag(tab)
    }
    
    @StateObject private var appConfigManager = AppConfigManager.shared
    
    @EnvironmentObject private var overlay: GlobalOverlayManager
    @EnvironmentObject private var router: Router
    
    var body: some View {
        if appConfigManager.appConfig != nil {
            ZStack {
                
                // 真正负责页面生命周期的容器
                TabView(selection: $router.selectedTab) {
                    tabView(.home)
                    tabView(.hot)
                    tabView(.creation)
                    tabView(.style)
                    tabView(.profile)
                }
                
                // 你的悬浮TabBar，根据当前选中标签的导航路径长度控制显示
                if isTabBarVisible {
                    VStack {
                        Spacer()
                        FloatingTabBar(selectedTab: $router.selectedTab)
                            .padding(.horizontal, 16)
                            .padding(.bottom, 20)
                    }
                }
                
                // 全局弹框显示
                if let current = overlay.current {
                    
                    // 遮罩
                    Color.black.opacity(0.4)
                        .ignoresSafeArea()
                        .onTapGesture {
                            overlay.dismiss()
                        }
                    
                    switch current {
                    case .login:
                        LoginOverlayView(onClose: {
                            overlay.dismiss()
                        })
                        .transition(.flipFromBottom)
                    }
                }
                
            }
            .animation(.easeInOut(duration: 0.25), value: overlay.current)
        } else {
            // 显示空View
            EmptyView()
                .background(ThemeManager.Background.global)
        }
    }
    
    var isTabBarVisible: Bool {
        return getNavigationPath(for: router.selectedTab).count == 0
    }
}

设计亮点：

NavigationStack 集成：为每个标签页创建独立的 NavigationStack
TabBar 智能显示：根据当前导航路径长度控制 TabBar 的显示/隐藏
环境对象注入：使用 @EnvironmentObject 注入 Router，实现全局访问
动画效果：添加了平滑的过渡动画，提升用户体验

路由管理的实现细节

1. 路径管理机制

路由系统的核心是 NavigationPath 的管理。NavigationPath 是 SwiftUI 4.0+ 引入的类型，它是一个类型擦除的容器，可以存储任意类型的导航目的地。

在我们的实现中：

每个标签页都有自己的 NavigationPath 实例
通过 getNavigationPathBinding 方法获取路径的绑定，用于 NavigationStack
提供了 clearPath 和 clearAllPaths 方法来清空导航路径

2. 标签页切换逻辑

当用户切换标签页时：

router.selectedTab 的值会更新
TabView 会根据新的 selectedTab 显示对应的标签页
由于每个标签页有独立的 NavigationPath，切换标签不会影响其他标签的导航状态

3. 导航路径的实际使用

在具体的视图中，可以通过以下方式使用路由：

// 在视图中注入 Router
@EnvironmentObject private var router: Router

// 使用全局路由管理进行导航
let currentPath = router.getCurrentNavigationPathBinding()
// 向当前路径添加新页面
currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material))

// 清空当前标签页的导航路径
router.clearCurrentPath()

4. 导航目的地定义

项目使用 AppNavigationDestination 枚举来定义导航目的地：

import Foundation
import SwiftUI

/// 导航目标枚举
enum AppNavigationDestination: Hashable {
    case accountLogin
    case materialDetail(MaterialListDTOElement)
}

这种方式的优势：

类型安全：使用枚举定义导航目的地，避免了字符串硬编码
参数传递：可以在导航时传递相关数据，如 materialDetail 中的 MaterialListDTOElement
可扩展性：可以轻松添加新的导航目的地

5. NavigationStack 中处理导航目的地

在使用 NavigationStack 时，需要处理导航目的地的显示逻辑。通常在根视图中添加 navigationDestination 修饰符：

NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .accountLogin:
                AccountLoginView()
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            }
        }
}

这样，当我们通过 currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material)) 导航时，NavigationStack 会自动显示对应的目标视图。

6. 完整导航流程示例

下面是一个完整的导航流程示例，展示从触发导航到显示目标页面的全过程：

// 1. 在视图中注入 Router
@EnvironmentObject private var router: Router

// 2. 定义导航触发事件
Button("查看素材详情") {
    // 3. 获取当前路径绑定
    let currentPath = router.getCurrentNavigationPathBinding()
    // 4. 向路径添加导航目的地
    currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(selectedMaterial))
}

// 5. 在根视图中处理导航目的地
NavigationStack(path: router.getNavigationPathBinding(for: .home)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            default:
                EmptyView()
            }
        }
}

// 6. 从详情页返回
Button("返回") {
    // 清空当前路径，返回根视图
    router.clearCurrentPath()
}

7. 导航路径与 TabBar 显示的关联

在 MainContainerView 中，通过 isTabBarVisible 计算属性控制 TabBar 的显示：

var isTabBarVisible: Bool {
    return getNavigationPath(for: router.selectedTab).count == 0
}

当导航路径为空时（即处于标签页的根视图），显示 TabBar；当导航路径不为空时（即进入了子页面），隐藏 TabBar，为用户提供更大的内容显示区域。

优势与最佳实践

优势

清晰的职责分离：路由逻辑与 UI 逻辑分离，使代码更易于维护
类型安全：使用枚举和类型化的导航路径，减少运行时错误
状态管理：集中管理路由状态，避免状态分散
灵活性：可以轻松添加新的标签页和导航目的地
用户体验：标签页切换时保持各自的导航状态，提升用户体验

最佳实践

统一的路由入口：所有导航操作都通过 Router 进行，避免直接操作 NavigationPath
合理的路径清理：在适当的时机清理导航路径，避免内存占用过高
导航目的地的类型定义：为导航目的地创建明确的类型，提高代码可读性
错误处理：添加适当的错误处理，确保导航操作的稳定性
测试：为路由逻辑编写单元测试，确保其正确性

代码优化建议

导航目的地类型化：

// 建议为每个标签页创建导航目的地枚举
enum HomeDestination {
    case detail(id: String)
    case search
}

// 然后在导航时使用
router.homePath.append(HomeDestination.detail(id: "123"))

添加导航日志：

// 添加导航日志，便于调试和分析用户行为
func appendToPath(_ value: some Hashable, for tab: MainTab) {
    let path = getNavigationPathBinding(for: tab)
    path.wrappedValue.append(value)
    print("Navigate to \(value) in tab \(tab)")
}

导航路径持久化：

// 可以考虑在应用进入后台时保存导航状态，在应用启动时恢复
func saveNavigationState() {
    // 保存导航状态到 UserDefaults 或其他存储
}

func restoreNavigationState() {
    // 从存储中恢复导航状态
}

添加路由拦截器：

// 可以添加路由拦截器，用于处理登录验证等场景
func appendToPath(_ value: some Hashable, for tab: MainTab) {
    if needsAuthentication(for: value) {
        // 显示登录界面
        overlay.present(.login)
    } else {
        let path = getNavigationPathBinding(for: tab)
        path.wrappedValue.append(value)
    }
}

总结

通过以上分析，我们可以看到，一个良好的路由管理架构对于 iOS 应用的重要性。我项目中的路由架构采用了集中式管理、Tab 隔离、响应式设计等原则，通过 Router 类、MainTab 枚举和 MainContainerView 的配合，实现了清晰、灵活、用户友好的导航体验。

这种路由架构不仅适用于当前项目，也可以作为其他 SwiftUI 项目的参考。通过不断优化和扩展，可以构建更加完善的路由系统，为用户提供更加流畅的应用体验。

希望这篇文章能够帮助大家更好地理解和实现 iOS 项目中的路由管理架构。如果你有任何问题或建议，欢迎在评论区留言讨论！

Flutter调试组件：打印任意组件尺寸位置信息 NRenderBox

掘金 iOS

SoaringHeart

2026年2月28日 22:20

一、需求来源

当页面元素特别多，比较杂，又必须获取某个组件尺寸位置时，一个个加 GlobalKey 有太麻烦，这是使用一个封装好的组件就特别有用了。然后就有了 NRenderBox 组件，可以打印出子组件的位置及尺寸。

二、使用

NRenderBox(
  child: Container(
    padding: EdgeInsets.symmetric(horizontal: 8, vertical: 4),
    decoration: BoxDecoration(
      color: Colors.transparent,
      border: Border.all(color: Colors.blue),
      borderRadius: BorderRadius.all(Radius.circular(0)),
    ),
    child: Column(
      mainAxisSize: MainAxisSize.min,
      children: [
        NNetworkImage(
          width: 50,
          height: 60,
          url: AppRes.image.urls.random ?? '',
        ),
        Text("选项"),
      ],
    ),
  ),
)

flutter: NRenderBox rect: Rect.fromLTRB(88.5, 322.0, 157.5, 413.0)

三、NRenderBox源码

import 'package:flutter/material.dart';

/// 点击打印尺寸
class NRenderBox extends StatefulWidget {
  const NRenderBox({
    super.key,
    required this.child,
  });

  final Widget child;

  @override
  State<NRenderBox> createState() => _NRenderBoxState();
}

class _NRenderBoxState extends State<NRenderBox> {
  final renderKey = GlobalKey();

  RenderBox? get renderBox {
    final ctx = renderKey.currentContext;
    if (ctx == null) {
      return null;
    }
    final box = ctx.findRenderObject() as RenderBox?;
    return box;
  }

  Offset? get renderPosition {
    return renderBox?.localToGlobal(Offset.zero);
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      key: renderKey,
      onTap: () {
        if (renderBox == null) {
          return;
        }
        final position = renderPosition;
        final size = renderBox!.size;
        final rect = Rect.fromLTWH(position!.dx, position.dy, size.width, size.height);
        debugPrint("$widget rect: $rect");
      },
      child: widget.child,
    );
  }
}

github

苹果谷歌商店：如何监控并维护用户评分评论

掘金 iOS

CocoaKier

2026年2月28日 18:59

前阵子，我无意中发现我们的应用在 App Store 上悄然出现了几条差评，但团队里似乎没人注意到。这让我意识到一个严重的问题：如果我们不能及时听到用户的声音，怎么能及时发现应用的不足，留住用户呢？ 更令人担忧的是，潜在用户在下载前往往会浏览评论区，一条未被回应的负面评价，可能就足以让他们转身离开，影响新增转化。

如果能在用户留下评论（尤其是差评）的第一时间收到通知，我们就能快速响应、修复问题、安抚情绪，甚至将一次不满转化为一次忠诚度的提升。更重要的是，积极、真诚地回复用户评论，不仅能展现团队的专业与负责，还能向所有观望者传递一个信号：我们在乎每一位用户。

本篇文章将从实操角度出发，为不熟悉苹果和谷歌开发者后台的开发或运营同学，讲解如何监控苹果谷歌商店的评分评论，以及如何回复用户评论，为大家提供一些帮助。

一、苹果

苹果开发者后台 appstoreconnect.apple.com/，需要 客户支持 权限。

1、如何监控评分和评论

苹果后台目前不支持收到新的评分评论后邮件通知开发者。只支持“开发者回复”（当顾客编辑你已回复的评论时，你将收到电子邮件），如需开启“开发者回复”邮件通知，按下面步骤操作：

登录 App Store Connect。
点击右上角的用户头像，进入 “用户和访问”。
选择你的账户，在左侧菜单点击 “通知”。

Tips：“收到评分评论后邮件通知开发者”，这个功能在旧版 iTunes Connect 中曾经存在，但在新版 App Store Connect 中已被移除。猜测苹果可能不想开发者过度关注单条评分评论。

如果目前想要监控苹果商店的评分评论，有几个方案可参考：
1、使用官方的 App Store Connect App，每天刷一刷，自己主动去看。App内可以设置“接收用户评分”通知，但不确定现在还是否有效。
2、苹果官方提供了App Store Connect API，可以自己开发程序拉取用户评分，再进一步做监控。
3、滴答清单定个周期性提醒，每天上班打开商店详情瞅一眼，现在苹果上线了Web版AppStore了，瞅一眼也很方便。
4、借助第三方平台。

2、查看和回复用户评论

（1）通过网页端查看

登录苹果开发者后台，appstoreconnect.apple.com/

评分评论入口：分发 - 评分和评论图片.png

点击“回复”可以回复用户评论
图片.png

（2）通过官方App "App Store Connect" 查看

iOS端下载地址：apps.apple.com/cn/app/app-…
（如果你搜不到可能是你手机系统版本太低了。没有安卓端。）

图片.png App Store Connect App核心功能：
-- 销售与趋势监控（查看 App 的下载量、销售额）
-- 版本状态管理（跟踪审核状态，回复审核）
-- 用户评论处理（查看和回复评论）

App Store Connect内查看评分及评论入口：
图片.png

3、重置总评分

发布新版本到 App Store 时（必须更包），你可以重置 App 总评分。重置后，你的 App Store 产品页面将显示说明，提示顾客 App 的总评分最近已重置。此说明将一直显示，直到有足够多的顾客对新版本进行了评分且页面出现新的总评分。

请注意，重置总评分并不会重置顾客评论，App Store 仍将继续显示历史的顾客评论。

图片.png

二、Google

Google开发者后台 play.google.com/console/dev…，需要 用户反馈 权限。
“用户反馈”权限

1、如何监控评分和评论

Google官方支持收到新的评论后邮件提醒开发者，并支持按应用、评分星级设置不同的提醒开关。注意：邮件提醒默认是关闭的，需要手动开启。请按下列步骤操作。

Google开发者后台 - 设置 - 个人邮件通知（这个只会改你个人的通知设置，不会改整个团队的）图片.png

按需将邮件提醒开关打开，修改后记得保存。
图片.png

如果你的账号拥有开发者账号下多个App的权限，默认是所有应用都给你发邮件，点击下图位置，可以选择哪些应用接收邮件。图片.png

收到新的评论后，Google会给你推邮件，模板样式如下，包含了应用名称、评分星级、评论内容，不用打开Google后台就能看到评论内容，很方便。
注意：如果你接收了多个应用的邮件，请留意邮件标题里App的名字。

图片.png

2、查看和回复用户评论

（1）网页端

Google后台 - 应用 - 监控与改进 - 评分与评价。

Google后台的评论，Google会默认帮你翻译成你的语言，很贴心。如果你想看原始评论，点击“显示原评论”查看。你也可以在这里回复用户的评论。
图片.png

（2）官方 Google Play Console App

Google也像苹果一样，提供了官方的供开发者维护自己App的应用，Google Play Console App。你可以通过它在移动端方便的看评分和回复评论。

iOS端：apps.apple.com/cn/app/goog…
安卓端：play.google.com/store/apps/…

Google Play Console App

Google Play Console App 核心功能：

查看数据指标：监控安装量、卸载量、更新量以及应用的崩溃率（ANR/Crash）。
回复用户评论：及时查看并回复用户的评价，这对于维护 App 评分至关重要。
订单管理：查看应用内购买和订阅的订单详情，甚至可以进行简单的退款操作。
发布状态监控：跟踪应用版本的审核进度和发布状态。

3、Google不支持重置评分评论

Google不像苹果那样可以主动重置评分。虽然你不能手动重置，但 Google Play 的评分系统是动态权重的，更加偏重于近期（Recent）的用户评分权重会更高。

这意味着：
（1）如果你的应用过去因为有 Bug 而评分很低，只要你在新版本中修复了问题，随着新用户和老用户在近期的好评增多，你的平均分会逐渐回升。
（2）时间是最好的解药：只要新版本的体验确实提升了，评分曲线会自动向好的方向修正。

三、结束语

其实维护应用商店的评论，并不需要多么复杂的流程或高深的技巧，但你做了和没做，用户感受是不一样的，每个人都希望被尊重，用真诚打动你的用户吧！

希望这篇文章能给你一点帮助。如果你有更好的监控方法，欢迎留言交流。

参考文档
【苹果官方文档】查看评分和评论

iOS设备崩溃日志获取与查看

掘金 iOS

iOS日常

2026年2月28日 17:14

1）如何从 iPhone 获取崩溃日志

路径：设置 → 隐私与安全性 → 分析与改进 → 分析数据
这里的崩溃日志通常是 .ips 文件。

.ips 原始内容示例（节选）：

{"app_name":"hello","timestamp":"2026-02-28 15:05:24.00 +0800","app_version":"1.0","bundleID":"com.example.hello","bug_type":"309","os_version":"iPhone OS 26.3 (23D127)","incident_id":"2B7A2F77-7F64-42DA-A184-AA496AD61AAC"}
{
  "modelCode" : "iPhone18,3",
  "captureTime" : "2026-02-28 15:05:24.5689 +0800",
  "procName" : "hello",
  "bundleInfo" : {"CFBundleShortVersionString":"1.0","CFBundleVersion":"1","CFBundleIdentifier":"com.example.hello"}
}

2）如何将 `.ips` 转成可查看的崩溃日志

把 .ips 文件复制到 Mac（如桌面），直接双击。
系统会用 控制台（Console） 打开，并自动转成可读格式（Translated Report）。

转换后示例（节选）：

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Incident Identifier: 2B7A2F77-7F64-42DA-A184-AA496AD61AAC
Process: hello [1056]
Identifier: com.example.hello
Version: 1.0 (1)
OS Version: iPhone OS 26.3 (23D127)

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Triggered by Thread: 0

Thread 0 Crashed:
0   libswiftCore.dylib   _assertionFailure(...)
1   hello.debug.dylib    ViewController.click(_:)

说明：这是一个 Demo 在真机调试运行时产生的崩溃日志，符号信息完整，不需要额外 dSYM 符号化也能直接看到具体崩溃代码位置（如 ViewController.click(_:)）。

Xcode 垃圾清理

掘金 iOS

iOS日常

2026年2月27日 17:42

一、可清理目录总览

场景	目录	是否可删	影响	建议
模拟器数据	`~/Library/Developer/CoreSimulator`	可删	模拟器数据会被清空	不用模拟器时可重点清理（如 `devices`）
真机调试符号	`~/Library/Developer/Xcode/iOS DeviceSupport`	可删（建议选择性）	删掉后下次连接对应 iOS 版本会自动重建	删除不用的设备版本，常用版本保留
打包归档	`~/Library/Developer/Xcode/Archives`	可删	会失去历史归档（.xcarchive）	先保留线上版本再清理
构建缓存	`~/Library/Developer/Xcode/DerivedData`	可删	下次打开/编译变慢，需要重新索引与构建	优先清理（最直接释放缓存空间）

二、分项说明

1) 模拟器（CoreSimulator）

路径：~/Library/Developer/CoreSimulator
说明：包含模拟器设备数据。
结论：可以删除；如果基本不用模拟器，可删除 devices 目录内容来释放较大空间。

2) 真机（DeviceSupport）

路径：~/Library/Developer/Xcode/iOS DeviceSupport
说明：真机调试时生成的设备符号文件。
结论：建议选择性删除不用的设备版本；常用设备版本保留，避免频繁重建影响调试效率。

3) 打包（Archives）

路径：~/Library/Developer/Xcode/Archives
说明：Xcode 打包归档历史。
结论：可以删除，但要先确认是否需要保留线上版本的归档记录。

4) 项目缓存（DerivedData）

路径：~/Library/Developer/Xcode/DerivedData
说明：构建缓存与索引。
结论：建议优先清理；能快速释放缓存空间。代价是后续首次编译和索引会变慢。

三、实操建议（个人整理）

优先清理：DerivedData（快速释放缓存空间）。
选择性清理：iOS DeviceSupport（删除不用的设备/系统版本，常用的保留）。
按需清理：CoreSimulator（尤其不用模拟器时）。
补充清理：过期 Archives（先保留可回滚版本）。
清理前先确认：
- 是否有线上紧急回滚需要的归档；
- 哪些真机系统版本仍在日常调试；
- 是否有正在使用的模拟器环境数据需要保留。

四、快速命令（可选）

先看大小再删，避免误操作。

# 查看各目录体积
sudo du -sh ~/Library/Developer/CoreSimulator \
  ~/Library/Developer/Xcode/iOS\ DeviceSupport \
  ~/Library/Developer/Xcode/Archives \
  ~/Library/Developer/Xcode/DerivedData

# 删除 DeviceSupport
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# 删除 Archives
rm -rf ~/Library/Developer/Xcode/Archives/*

# 删除 DerivedData（谨慎）
rm -rf ~/Library/Developer/Xcode/DerivedData/*

五、一句话总结

Xcode 清理的核心是：优先清理 DerivedData 释放缓存；DeviceSupport 只删不用的设备版本，常用版本保留；再按需处理模拟器与旧归档。

不越狱能抓到 HTTPS 吗？在未越狱 iPhone 上抓取 HTTPS

掘金 iOS

开心就好2025

2026年2月27日 15:49

这个问题在 iOS 调试中反复出现。

很多人听到“HTTPS”“证书校验”“SSL Pinning”，第一反应就是，是不是必须越狱？

这篇文章在不越狱设备上分别测试三种情况：

普通 HTTPS
启用证书校验的 App
启用双向认证的 App

环境：

iPhone（未越狱）
一台 Windows + 一台 Mac
代理工具（Charles / Proxyman）
设备本机抓包工具 SniffMaster

一、代理抓包：不越狱的第一条路径

先测试最基础的方式：代理抓包。

操作步骤

启动 Charles（或 Proxyman）
确认代理端口正在监听
iPhone 与电脑连接同一 Wi-Fi
在 iPhone 的 Wi-Fi 设置中填写代理地址与端口
在手机上安装并信任证书
用 Safari 打开一个 HTTPS 网站

如果 Safari 能完整显示请求和响应，说明：

代理路径没问题
HTTPS 解密生效
不需要越狱

二、普通 App 的 HTTPS 测试

在同样的代理环境下，打开一个普通测试 App。

结果：

请求可以出现在 Charles 中
HTTPS 内容可正常解密
请求体与响应体完整

这一步可以确认在未启用额外安全校验的情况下，不越狱完全可以抓到 HTTPS。

三、遇到证书校验（SSL Pinning）

接下来测试一个启用了证书校验的 App。

操作保持不变，只替换测试 App。

现象：

App 提示网络错误
Charles 中只出现握手失败或无请求记录

代理路径仍然有效，Safari 仍然可以抓到数据。

说明：

阻断发生在 App 内部
系统信任代理证书不代表 App 会信任

在这里继续重复安装证书不会改变结果。

四、是否必须越狱才能继续？

不越狱依然有两种路径可以尝试。

路径一：分析握手层

可以通过底层抓包确认：

是否存在 TLS ClientHello
是否建立 TCP 连接

如果 TLS 握手存在，说明流量确实发出，只是代理无法接管。

路径二：设备本机抓包

这里切换抓包方式。

使用 SniffMaster 进行设备本机 HTTPS 抓包

SniffMaster 支持通过 USB 在电脑上直接抓取 iOS 设备流量。

操作步骤

用 USB 将 iPhone 连接电脑
保持设备解锁并点击“信任此电脑”
启动 SniffMaster
在设备列表中选择对应 iPhone
按提示安装驱动与描述文件
进入 HTTPS 暴力抓包模式
点击开始
触发 App 请求

没有配置 Wi-Fi 代理，也没有安装代理证书。暴力抓包

五、证书校验 App 的抓包结果

在设备抓包模式下测试同一个启用证书校验的 App。

结果：

请求可以看到
HTTPS 内容显示正常
未出现握手失败

区别来自抓包场景。

代理模式依赖替换证书，设备直接抓包不依赖中间人证书。

六、当请求体为空时的判断

如果抓到的 HTTPS 中：

URL 可见
Header 可见
Body 为空

这与越狱无关，而与签名有关。

若测试的是 App Store 下载的应用，需要：

获取 IPA
使用 iOS 开发证书重签
重新安装
再次抓包

完成后，请求体与响应体可完整显示。

七、双向认证（mTLS）的测试

在双向认证场景中：

代理抓包会在握手阶段失败
设备级抓包仍可观察到 TLS 会话

关键点是抓包工具是否依赖代理替换证书

参考链接：www.sniffmaster.net/tutorial/zh…

iOS相机权限获取

掘金 iOS

傅里叶

2026年2月27日 11:25

语言：Flutter
问题：获取相机弹窗的权限不出来，iOS系统设置里面对应app也没有相机选项。是宏没有打开
解决方法：打开宏

Podfile

# post_install do |installer|
#   installer.pods_project.targets.each do |target|
#     flutter_additional_ios_build_settings(target)
#     # 为所有 Pod 目标启用 dSYM 生成
#     target.build_configurations.each do |config|
#       if config.name == 'Release'
#         config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
#       end
#     end
#   end
# end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)

    target.build_configurations.each do |config|

      if config.name == 'Release'
        config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
      end

      # ⭐ permission_handler 必须的宏配置
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [
        '$(inherited)',

        'PERMISSION_CAMERA=1',

      ]

    end
  end
end

这段 Podfile 的 post_install 配置是正确的

一、post_install 是什么 🔧

post_install do |installer|

意思是：

CocoaPods 安装完成后执行这段脚本。

也就是在执行：

pod install

之后运行。

用途：

修改 iOS 编译参数
给插件加配置
修复 Flutter / iOS 插件问题

Flutter 权限插件基本都用这个。

二、installer.pods_project.targets.each do |target|

installer.pods_project.targets.each do |target|

意思是：

遍历所有 Pod 插件。

例如：

permission_handler
mobile_scanner
ffmpeg_kit
camera
etc

这段代码会对 所有插件生效。

相当于：

给所有插件统一设置编译参数。

三、flutter_additional_ios_build_settings(target)

flutter_additional_ios_build_settings(target)

意思：

Flutter 自动生成的 iOS配置。

它会自动设置：

Swift版本
架构支持
Bitcode
iOS版本兼容性

这是 Flutter 官方必须的一行。

不能删。

四、target.build_configurations.each do |config|

target.build_configurations.each do |config|

意思：

遍历 Debug / Release 编译模式。

iOS有三种模式：

Debug（开发）
Profile（性能分析）
Release（发布）

这段代码：

对每个模式分别设置参数。

五、DEBUG_INFORMATION_FORMAT = dwarf-with-dsym

if config.name == 'Release'
  config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
end

意思：

Release版本生成 dSYM 文件。

作用：

崩溃日志解析
Crashlytics
TestFlight 崩溃分析

否则：

崩溃日志看不懂

这是一个好习惯配置 👍

和权限无关。

六、最重要的一段（权限宏）⭐

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [  '$(inherited)',  'PERMISSION_CAMERA=1',]

这是关键。

意思：

给 iOS 编译器设置宏定义。

等价于：

#define PERMISSION_CAMERA 1

告诉 permission_handler：

编译相机权限代码。

七、$(inherited) 是什么

'$(inherited)',

意思：

保留系统原来的设置。

如果不写：

可能破坏 Flutter 默认配置。

必须保留。

相当于：

在原来的基础上增加权限宏。

八、PERMISSION_CAMERA=1 是什么 ⭐

'PERMISSION_CAMERA=1',

意思：

打开相机权限模块。

permission_handler 内部代码类似：

#if PERMISSION_CAMERA
// 相机权限代码
#endif

如果没有：

#if PERMISSION_CAMERA

条件不成立。

相机代码不会编译进去。

结果就是：

request() 不弹窗
denied
设置里没有权限

之前就是这个问题。

九、整体逻辑总结（核心理解）

配置现在等价于：

安装所有插件
Flutter配置生效
Release版本生成崩溃符号
开启相机权限模块

流程：

pod install
   ↓
执行 post_install
   ↓
给所有插件加 PERMISSION_CAMERA=1
   ↓
Xcode 编译
   ↓
permission_handler 包含相机权限代码
   ↓
request() 正常弹窗

十、建议升级为完整权限配置（推荐）🔥

建议改成：

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [  '$(inherited)',  'PERMISSION_CAMERA=1',  'PERMISSION_PHOTOS=1',  'PERMISSION_MICROPHONE=1',]

原因：

以后大概率会用：

相册
麦克风
视频

否则未来又会踩坑。

十一、最关键结论

现在这段：

'PERMISSION_CAMERA=1',

就是让：

Permission.camera.request();

真正生效的原因。

没有它：

iOS 会表现为：

不弹窗
denied
设置没有权限

阅读视图

🗺️ 通关路线图

🎯 第 1 关：安装 FVM

目标

为什么需要 FVM

📋 操作

✅ 验证

🎯 第 2 关：克隆鸿蒙版 SDK

目标

为什么不能直接 fvm install

📋 操作

✅ 验证

🎯 第 3 关：修复版本"身份证"

目标

为什么要做这步

📋 操作

✅ 验证

🎯 第 4 关：指定鸿蒙 SDK 路径

目标

为什么不用环境变量

📋 操作

✅ 验证

🎯 第 5 关：全绿验证

目标

📋 操作

✅ 验证

🔧 附加关：FVM 的"碎碎念"

🏆 通关总结

iOS PDF 阅读器段评实现：如何从 PDFSelection 精准还原一个自然段

背景：段评是什么，难在哪里

整体架构：四层流水线

第一层：行提取与噪声过滤

第二层：几何连通分块

第三层：阅读顺序还原与段落切分

3.1 列识别：X 轴区间合并

3.2 段落切分：三条几何规则

第四层：跨栏语义合并（最难的部分）

4.1 判断标准：段尾 + 段首

4.2 列检测：中心 X 聚类

4.3 合并过程：倒序扫描 + 链式追踪

段落 ID 的设计

几个值得关注的工程细节

局限性与未来方向

小结

一、IAP 基本概念

二、StoreKit 1 与 StoreKit 2

2.1 StoreKit 1 核心类

2.2 StoreKit 2 核心类

三、购买流程

3.1 正常购买流程

3.2 异常场景处理

3.3 收据验证

四、服务端通知（Server-to-Server Notifications）

4.1 主要通知类型

4.2 通知格式

五、App Store Connect 配置

六、常见的架构策略

6.1 项目分层

6.2 防掉单策略

七、一些 2025 年新动向

1.H5 上架

1.1打包 H5 应用

1.2部署到服务器

1.3配置域名与 HTTPS

1.4测试与发布

2.小程序上架

2.1打包小程序

2.2上传到微信开发者工具

2.3调试与测试

2.4提交审核

2.5发布

3.iOS 上架

3.1打包 iOS 应用

3.2配置 App Store Connect

3.3上传应用

3.4提交审核

3.5发布

4.Android 上架

4.1打包 Android 应用

4.2配置 Google Play Console

为什么不能直接 `fvm install`