这个开头，是不是还挺符合这本书的写作风格的？哈哈。

在这个注意力高度分散的年代，各种短视频平台上，常常会有刘震云这种文人参加综艺的切片。起的标题往往是：刘震云怒怼XXX，点进去就会发现，文化人怼人确实厉害，不动声色地怼得对方哑口无言。而他说话的那种不慌不忙地、慢吞吞地感觉，就和读他的书的感觉是一致的。

这本书里，也大多都是短句，用词也并不深奥偏僻，甚至有点朴实。对话描写经常是说一句话，“又说”。。。“又说”。。。每句也都是短句。

但他就是用这种风格，写出了两个时代的同一种落寞。上部我认为大概是发生在民国时期后期或者刚建国时期的故事，下部却大概是世纪交接的年代。虽然时代不同，但主人公确是有一丝丝联系的，而且人物的关系网也都是最底层的劳动人民。可以看出，作者确实也是底层出身，观察非常细致，积累也非常深厚。

总之，在我看来这书挺艺术的。但一句顶一万句，那句话到底是什么话，直到最后也都没有说，突然就结束了，就有点难受。。。不过我也理解这是一种写作手法，哈哈！

剧情就不展开说了，不然算剧透，也不太好。听说有部同名电影，是刘震云担任编剧，还是他女儿执导的，我这就去找来看看。

The post 《一句顶一万句》读书笔记 first appeared on I am LAZY bones?.

为了充分利用这些窗口，我就想让这几个窗口卡在我自己定的点上——5:58、10:59、16:00、21:01，一天四个，首尾正好接得上。

办法也很土：到点了自动发一句 hello 过去，窗口就开了。但我平时是在MacBook和Mac mini上跑claude，”到点自动跑”这件事，在 macOS 上还真有个坑，值得写一篇，分享给有需要的朋友。

别用 cron，用 launchd

第一反应肯定是 crontab，写四行就完事。但 Mac 是会睡觉的。cron 在机器睡眠期间错过的任务，醒来之后不会补——那一条 hello 就这么静悄悄地没了，窗口也就没开成。

launchd 不一样。StartCalendarInterval 错过的时间点，会在唤醒后立刻补执行一次。对”激活窗口”这个目的来说，这个行为正合适。

而且四个时间点不用建四个 plist，StartCalendarInterval 直接收一个数组：

<key>StartCalendarInterval</key>
    <array>
        <dict>
            <key>Hour</key><integer>5</integer>
            <key>Minute</key><integer>58</integer>
        </dict>
        <dict>
            <key>Hour</key><integer>10</integer>
            <key>Minute</key><integer>59</integer>
        </dict>
        <dict>
            <key>Hour</key><integer>16</integer>
            <key>Minute</key><integer>0</integer>
        </dict>
        <dict>
            <key>Hour</key><integer>21</integer>
            <key>Minute</key><integer>1</integer>
        </dict>
    </array>

plist 放 ~/Library/LaunchAgents/，然后 load 一下就生效：

plutil -lint ~/Library/LaunchAgents/com.lly.claude-keepalive.plist
launchctl load ~/Library/LaunchAgents/com.lly.claude-keepalive.plist
launchctl list | grep claude-keepalive

最后那行输出里，中间那个数字是上次的退出码，是 0 就说明跑通了。plist 的其它字段没什么特别的，launchd.info 上都有，照抄即可。

脚本本身：记得用 haiku

被调起来的脚本没什么内容，核心就一行：

"$CLAUDE" -p "hello" --model haiku >> "$LOG" 2>&1

这里的 --model haiku 是关键。5 小时窗口是账号级的，任何模型的第一条消息都会把它打开，那当然挑最便宜的来开——总不能为了开个窗口，先请 Opus 出来打个招呼吧，哈哈。

几个注意点

1. 路径必须写全。 launchd 拉起来的进程不走你的 shell 配置，~/.local/bin 根本不在默认 PATH 里，脚本里直接写 claude 是找不到的。要么在 plist 的 EnvironmentVariables 里把路径补上，要么脚本里写死绝对路径。我两个都做了，保险。

2. 补跑是把双刃剑。 前面夸 launchd 会补跑，但反过来说：如果 5:58 的时候机器是睡着的，八点你才掀开盖子，那次补跑就发生在八点，窗口也就从八点开始算——精心排的那套首尾相接的节奏，当天就错位了。这个绕不过去，属于”别漏掉”和”要准时”之间必须二选一。

3. 日志记得轮转。 一天四次，每次都往同一个文件里追加 Claude 的回复，攒几个月也挺可观。脚本开头加一句超过 1MB 就 mv 成 .1，两行的事儿。

两天后才发现：其实一直在假装成功

上线两天后回头翻日志，好家伙——除了第一次，后面十次全认证失败，报错是 OAuth session expired and could not be refreshed。但脚本每次都记着”退出码=0″，日志表面干干净净，窗口压根没开成也看不出来。

根子是 launchd 起的进程摸不到交互终端那份浏览器登录状态，用 launchctl start 手动触发一次就能稳定复现。解法是换成不依赖这份易失效登录的长期令牌：

claude setup-token   # 生成一个 sk-ant-oat01-... 开头的长期令牌，存进 .zshrc ，据说这个令牌能管1年。

因为我把令牌存在了 .zshrc 里，但 launchd 不会加载它，脚本里得自己挖出来：

eval "$(grep '^export CLAUDE_CODE_OAUTH_TOKEN=' ~/.zshrc)"

一个教训：退出码不能全信，认证失败时它照样是 0。真要验证，就拿 launchctl start 手动戳一次，肉眼看日志内容。

顺带

这套东西是我让 Claude Code 自己写的——描述完需求，脚本、plist、load 命令一条龙全办了，中间它还顺手看了眼我已有的那个备份任务的 plist，把格式风格对齐了过来（EnvironmentVariables 那段的写法就是照抄我自己之前写的）。让 AI 给自己写定时唤醒脚本，这个循环还挺有意思的。

The post 给 Claude 的 5 小时窗口掐个点 first appeared on I am LAZY bones?.

前几天晚上在家里那台上开 Claude CLI，聊到一半我才反应过来——它什么都不记得。。。那些”这个坑我们上个月踩过””这个方案试过不行”的结论，全都留在公司那台上了。我这边还得从头解释一遍。

于是花了个把小时把这事儿彻底解决掉。方案本身不复杂，但中间挖出来的几个东西挺有意思，值得写一篇，分享给需要有需要的朋友。

先搞清楚：记忆到底存在哪？

Claude Code 的记忆不是存在云端的，就是本地文件：

~/.claude/projects/<路径slug>/memory/*.md      # 每个项目的记忆，一条一个文件
~/.claude/projects/<路径slug>/memory/MEMORY.md # 该项目的记忆索引
~/.claude/CLAUDE.md                            # 全局偏好

关键在那个 slug。它是项目绝对路径转义出来的，规则很简单粗暴——非字母数字的字符统统换成短横线：

re.sub(r'[^a-zA-Z0-9]', '-', path)

所以我的 /Users/luyang.li/dev/notchy 就变成了 -Users-luyang-li-dev-notchy。注意用户名里那个点也被转成了横线，@、_ 同理，全都一视同仁。

统计了一下，我这边一共有 111 条记忆。数量不算多，但都是真金白银试出来的结论，重新攒一遍的成本可不低。

哪些能同步，哪些碰都别碰

第一反应可能是”把整个 ~/.claude 丢进 iCloud 不就完了”。千万别。

我扫了一遍那个目录，能同步的其实就这么几样：

1. projects/*/memory/ —— 各项目记忆
2. skills/ —— 自定义 skills
3. CLAUDE.md —— 全局偏好
4. settings.json —— 全局设置
5. mcp.json —— MCP 配置

其余的全是本机运行时状态，同步过去只会互相打架：history.jsonl、sessions/、各项目下的 *.jsonl 会话记录（我这边光这项就 364M）、file-history/（30M）、shell-snapshots/、plugins/ 缓存、telemetry/、还有 daemon 的认证文件。

更要命的是 ~/.claude.json——注意是家目录根下那个，不是 .claude/ 里面的。我打开一看，好家伙，某个 MCP server 的明文 access token 就躺在里面。这玩意儿要是跟着仓库推上去，那可就热闹了！

顺带一提，插件不用同步。settings.json 里的 enabledPlugins 和 extraKnownMarketplaces 已经完整描述了装了哪些插件、从哪个 marketplace 拉，换台机器它自己会去下。我这边 plugins/ 目录 14M，绝大部分是缓存和 marketplace 的 clone，同步纯属浪费。

目录用软链接，单文件用拷贝

方案就是建个私有 git 仓库 ~/dev/claude-config，把要同步的东西搬进去，原地留软链接。

REPO=~/dev/claude-config
mkdir -p $REPO && git -C $REPO init

# 以 skills 为例
mv ~/.claude/skills $REPO/skills
ln -s $REPO/skills ~/.claude/skills

但这里有个分野，我一开始没想到：目录可以软链接，单个文件不行。

原因是 Claude Code 自己会重写 settings.json（你 /model 切一次它就重写一遍）。而很多程序的”原子写”是先写临时文件再 rename——那一 rename，你的软链接就被替换成实体文件了，链接直接断掉，后面的改动再也进不了仓库。目录被这样整个替换的概率极低，所以目录安全。

于是最终是混合方案：

skills/                     -> 软链接，改动实时进仓库
projects/*/memory/          -> 软链接，同上
CLAUDE.md / settings.json / mcp.json
                            -> 拷贝，按 mtime 双向同步，每次跑脚本时自愈

还有个细节让我挺满意的：我那 39 个 skills 里有 20 个本身就是指向另一个仓库的软链接。git 会把符号链接以 mode 120000 原样存下来（存的是目标路径，不是内容），clone 到另一台机器上它还是软链接。推完我特意查了一下远端：

gh api 'repos/bones7456/<repo名>/git/trees/main?recursive=1' \
  | python3 -c "import json,sys; t=json.load(sys.stdin)['tree']; \
    b=[x for x in t if x['type']=='blob']; \
    print(len(b), '个 blob,', len([x for x in b if x['mode']=='120000']), '个符号链接')"

548 个 blob, 20 个符号链接

两台机器用户名不一样怎么办

还记得前面那个 slug 规则吗，坑来了。

我这台的用户名是 luyang.li，另一台是 lly。同一个项目 ~/dev/notchy，在两台机器上算出来的 slug 完全不同：

-Users-luyang-li-dev-notchy    # 这台
-Users-lly-dev-notchy          # 那台

直接把仓库里的目录名照搬过去，记忆就对不上了。而且反过来从 slug 推路径也不行——横线可能对应 /，也可能对应 .、@，甚至本来就是横线，信息已经丢了。

解决办法是在仓库里存一份 origins.tsv，记录每份记忆对应的原始绝对路径：

-Users-luyang-li-dev-notchy	/Users/luyang.li/dev/notchy
-Users-luyang-li-dev-shi	/Users/luyang.li/dev/shi

安装脚本读这个文件，把路径里的 home 前缀换成本机的，再重算一遍 slug 建软链接。这样只要 home 之后的路径一致，两边就能对上同一份记忆。

（生成这个映射表也有讲究：我没去反推，而是拿 ~/.claude.json 里 projects 字典的 key——那些本来就是绝对路径——正向算 slug 建的对照，14 个全中。）

挂上 hooks，让它自己跑

同步脚本写好了，接下来是自动化。Claude Code 的 hooks 正好有两个合适的事件：

"hooks": {
  "SessionStart": [
    { "hooks": [{ "type": "command", "command": "\"$HOME/dev/claude-config/sync.sh\" pull", "timeout": 30 }] }
  ],
  "SessionEnd": [
    { "hooks": [{ "type": "command", "command": "\"$HOME/dev/claude-config/sync.sh\" push", "timeout": 30 }] }
  ]
}

这里用 $HOME 而不是绝对路径，因为 settings.json 这个文件本身也会被同步到另一台机器上去，写死路径那边就废了。

SessionEnd 到底什么时候触发？

配完我就犯嘀咕：SessionEnd 具体什么时候跑？关终端算不算？

翻了下 settings 的 schema，它只在事件名枚举里出现，没有说明。与其猜，不如直接从本机的 CLI 二进制里找。我这个版本是 2.1.247：

F=~/.local/share/claude/versions/2.1.247
grep -a -o -E '.{130}prompt_input_exit.{130}' "$F" | head -5

第一条就中了：

Vs=["clear","resume","logout","prompt_input_exit","other"],Qs=s(()=>a(Vs)),Zs=s(()=>h().and(t({hook_event_name:n("SessionEnd"),reason:Qs()})))

紧挨着 hook_event_name:"SessionEnd" 的就是 reason 的枚举，一共五个值：

1. clear —— 执行 /clear
2. resume —— 切走去别的会话
3. logout —— 执行 /logout
4. prompt_input_exit —— 从输入框正常退出
5. other —— 兜底

最意外的是 /clear 也算 SessionEnd。这意味着我的 push 不是”一天一次”，而是每次清上下文都会提交推送一遍，同步粒度比预想的细多了，挺好。

再往下挖，找到了执行时机：

async shutdown(e=0,t="other",n){
  if(this.shutdownInProgress)return;
  this.shutdownInProgress=!0, process.exitCode=e, ...
  let{executeSessionEndHooks:r,getSessionEndHookTimeoutMs:o}=await import("...");
  let s=o();
  this.armShutdownFailsafe(Math.max(5000,s+5000),e);

hooks 跑在 process.exitCode 设定之后、进程真正退出之前，而且有个失效保险：超过 max(5秒, 超时+5秒) 就强制退出。所以 SessionEnd hook 里别干重活，我这个只在本地 commit，真正的 git push 甩到后台跑。

那硬退出呢？我找到这么一行：

process.on("SIGTERM", () => process.exit())

裸的 process.exit()，不走 shutdown()，也就不跑 hook。SIGKILL 就更不用说了。（CLI 里 SIGTERM/SIGINT/SIGHUP 有好几处注册，分属不同上下文，我没法干净地判断直接关终端窗口走的是哪条路径，所以这条只能算”很可能”，不算证实。）

所以 pull 也得先 commit

上面这个结论直接推翻了我原本的脚本设计。

原来 pull 是这么写的：

git pull --rebase --autostash

--autostash 会把未提交的改动 stash 起来、rebase 完再放回来——但放回来之后它还是未提交状态。万一某次 SessionEnd 没跑成（进程被硬杀了），那批记忆就一直悬在工作区里，没提交更没推送，另一台机器永远看不到。

改法很简单：pull 开头先 commit 一次。

pull)
    link_dirs
    sync_files
    commit_local "recovered"          # 先落袋为安
    if has_remote; then
        git -C "$REPO" pull --rebase --autostash -q || echo "pull 失败，请手工查看"
        n=$(unpushed_count)
        [ "$n" -gt 0 ] && echo "  ↑ 补推 $n 个未推送的提交"
        push_background
    fi
    sync_files                        # 把刚拉下来的内容拷出去
    exit 0
    ;;

这样只要还能开一次会话，上次漏掉的东西就一定会被补上。提交信息前缀用 recovered，跟正常退出的 sync 区分开，翻 log 时一眼能看出这批改动是怎么进来的。

最后

整套跑下来，仓库 548 个文件、.git 才 2.9M，所有项目的记忆全接管了。现在的循环是这样：会话开始 pull，中间的改动经软链接实时落到仓库，会话结束（或者 /clear）commit 加后台 push。

顺带说一句，为什么不用 iCloud 或者 Dropbox——它俩当然也能跑，把仓库路径换成云盘目录、软链接照建就行，还省掉 hooks。但记忆这东西天然就是”一句话一个文件”，太适合版本化了；万一两台机器同时改了同一条，git 会明明白白报冲突让你处理，云盘则是悄悄给你生成一个”冲突副本”，你可能几个月都发现不了。。。

不说了，我去家里那台上 clone 一遍试试。要是 origins.tsv 那套换算真能对上，那 111 条记忆就算是彻底安全了——毕竟这里头有不少是当初排查内存泄露那种熬了半天才熬出来的结论，再丢一次我可真要哭了！

The post Claude Code 的记忆同步大法 first appeared on I am LAZY bones?.

这种”整夜监测只录到一半”的问题最难受的地方在于：它不报错、不崩溃、不留任何痕迹。App 就是在某个时刻悄无声息地没了，第二天你只看到一条被截断的记录。

这篇写的就是把这件事查清楚的全过程——从设备里的 JetsamEvent 报告，到 Instruments 的 Generation 快照，最后落到一行 SwiftUI 代码上。中间还有一段完整的、被自己推翻的错误推断，作为教训一并写了进来。

第一步：先确认它是”被杀的”还是”自己停的”

这两种情况的修法完全不同，不能靠猜。

我的 App 在监测过程中每 5 分钟往 UserDefaults 写一次检查点，进程要是被强杀，下次启动时会拿检查点的时间去补 endTime（不然历史里就是一条 endTime 为空的孤儿记录）。所以判据现成的：

开始 00:01:36
结束 02:06:36
差值 7500 秒 = 25 × 300

正好是检查点间隔的整数倍。如果是正常停止，endTime 会是任意时刻；只有走孤儿恢复才会精确落在检查点节拍上。 结论：进程在 02:06:36 到 02:11:36 之间没走正常的停止流程就没了。

顺带说个同一晚的另一个 bug，跟主线无关但挺典型的：

>>> import struct; struct.pack('>I', 2003329396)
b'what'

CoreAudio 的错误码经常是四字符码，2003329396 就是 'what'。触发路径是：点开始 → 5 秒预备倒计时 → 我顺手按了锁屏键 → 倒计时在后台结束 → 这时才去开麦。而 UIBackgroundModes: audio 这个豁免只保”已经在录的继续录”，不保”后台新开麦”，系统直接拒了。改法很简单：把开麦挪到倒计时之前，会话在麦克风激活之后，锁屏就管不着了。

JetsamEvent 报告怎么读

iOS 上的查看路径是 设置 → 隐私与安全性 → 分析与改进 → 分析数据，往下翻找 JetsamEvent-年-月-日-时分秒.ips。这个文件是两段 JSON 拼起来的：第一行是头，剩下是正文。

import json
raw = open("JetsamEvent-2026-08-16-020855.ips").read()
d = json.loads(raw.split("\n", 1)[1])
PS = d["memoryStatus"]["pageSize"]          # 16384
for p in sorted(d["processes"], key=lambda x: -x["rpages"])[:5]:
    print(f'{p["name"]:24} {p["rpages"] * PS / 1048576:8.1f} MB  prio={p["priority"]}')

几个关键字段：

1. rpages × pageSize 是各进程占的内存，注意 pageSize 现在是 16 KB 不是 4 KB。
2. physicalPages.internal 是 [clean, dirty]，脏页才是真正赖着不走的那部分。
3. age 单位是纳秒，用报告时间减一下就能反推每个进程什么时候启动的。
4. 带 reason 字段的那几条才是这次事件里被杀的，其余是快照。
5. largestProcess 直接告诉你当时谁最胖。

我这份 02:08:55 的报告里，NightSnore 压根不在进程列表里——说明它在这次事件之前就已经被杀了。当时整机也确实在雪崩：可用内存 162 MB、compressor 涨到 1.87 GB、最后三分钟有 172 个进程被杀了重启，连 SpringBoard 自己都撞了 per-process 上限。

真正的实锤在另一份 ips 文件里，因为我发现还有一份六天前的：

NightSnore   rss = 1814.3 MB   dirty = 1734 MB   purgeable = 0
             prio = 100   states = [active]   age = 29.5 分钟
largestProcess: NightSnore

监测跑了 29.5 分钟，进程涨到 1.8 GB，其中 1.73 GB 是脏内存。 全机最大。那次系统没杀它，而是把 180 多个闲置进程 idle-exit 掉给它让路。

到这儿性质就清楚了：不是什么玄学的后台调度问题，就是漏内存漏到撑爆。

证据不够的时候，别急着改代码

这一节是我这次最大的教训。

拿到 1.8 GB 这个数之后，我去读音频管线的代码，很快”找到”了三处无上界结构：波形显示每来一个音频 buffer 就起一个 Task { @MainActor } 把整块样本捕获进去；两级 DispatchQueue 都是无条件 async，处理端一慢就会无限堆积。三处加起来的量级估算下来跟观测值挺接近。

于是我给队列加了背压、给波形加了节流。改完确实好了一些——但这是推断，不是证据，这里其实浪费了很多时间。

Instruments 的 Generation 快照发现根因

Xcode 的 Memory Report 只能告诉你”在涨”：

(可以发现，除了内存一直涨，CPU也很高这个后面也一起修复了）

要知道”谁在涨”，得用 Instruments 的 Allocations，核心功能是 Mark Generation：

1. Product → Profile（⌘I），选 Allocations
2. Recorder Settings 里面的 Recording mode 要选 Immediate
3. 跑一分钟，点一下 Mark Generation
4. 再跑三分钟，再点一次
5. 展开第二个 Generation，看 Growth 列

Growth 只列”两次快照之间新增、且到现在仍然存活”的对象——这就是内存泄漏的定义。别的视图都会被大量正常的临时分配淹没，只有这个视图干净。

结果一眼就能看出问题：

UnknownObjectType                        5.71 MiB   25,584
_ContiguousArrayStorage<AnyViewTrait>    2.16 MiB    5,904
ImageProviderBox<NamedImageProvider>   553.50 KiB    5,904
LocalizedTextStorage                   461.25 KiB    5,904
AnyViewStorag<Label<Text, Image>>     369.00 KiB    5,904
TagIndexProjection<Int>                184.50 KiB    1,968
_TtCC5UIKit12_UITabButton…              96.00 KiB        6

跟音频、跟 CoreML、跟我改了半天的那些队列，一点关系都没有。全是 SwiftUI，而且全是 TabView 标签栏的零件：Label<Text, Image> 是三个 tab 项，NamedImageProvider 是 tab 图标，LocalizedTextStorage 是 tab 标题，TagIndexProjection<Int> 是 .tag()，最后还有 UITabButton 本体。

UnknownObjectType：

AnyViewTrait：

真正把结论钉死的是数字本身：

5,904 = 3 × 1,968     （三个 tab）
1,968 ÷ 180 秒 = 10.9 次/秒

10.9 次每秒——正好是音频 buffer 的到达频率。

根因：根视图订阅了高频 @Published

顺着这个频率回去看代码，一行就找到了：

struct ContentView: View {
    @ObservedObject private var monitoringService = MonitoringService.shared
    // ...
    TabView(selection: $selectedTab) {
        MonitoringView().tabItem { Label("监测", systemImage: "waveform.circle.fill") }.tag(0)
        SessionListView().tabItem { Label("历史", systemImage: "clock.fill") }.tag(1)
        SettingsView().tabItem { Label("设置", systemImage: "gearshape.fill") }.tag(2)
    }
}

MonitoringService 里有个 @Published var audioSamples: [Float]，监测时每秒更新约 11 次给波形图用。链条是这样的：

audioSamples 每秒发布 11 次
  → ContentView.body 每秒重算 11 次
    → 整个 TabView 连同三个 .tabItem { Label(...) } 重建
      → SwiftUI 把标签项的内部存储泄漏掉

一小时约 200 MB，整夜下来就是 GB 级。而且这跟屏幕亮不亮无关——锁屏后 SwiftUI 不渲染了，但 body 该重算还是重算。

根视图的 body 其实根本不依赖任何监测状态，它只是需要在两个字段变化时做点事而已。那就别观察整个对象，改成订阅具体的 publisher：

private let monitoringService = MonitoringService.shared   // 不再是 @ObservedObject

// ...
.onReceive(monitoringService.$finishedSessionForSummary) { _ in presentSummaryAfterPublish() }
.onReceive(monitoringService.$audioError)                { _ in presentSummaryAfterPublish() }

同样口径复测：

修之前              修之后
Growth       10.81 MiB          581 KiB
存活对象      61,631            609

字节数降了 19 倍，对象数降了 101 倍。后者才是关键信号——”每帧泄一批”的模式没有了。剩下那 581 KiB 里 80% 是 4 个 CALayer 后备存储和 1 次 SQLite 页缓存增长，都是一次性的。

支持，内存泄露的问题算是解决了，再去看CPU使用率，也从 75% 降到了 5% 不到。

几个坑

1. @Published 是在 willSet 时发布的。 换成 .onReceive 之后，闭包跑在属性真正写入之前，这时候回读那个属性拿到的还是旧值——比如 audioError 明明马上要变成 nil，读出来仍然非 nil，判断就全反了。要么用闭包参数带过来的新值，要么推到下一个主队列 turn 再处理。

2. 本进程不在 JetsamEvent 列表里，不代表这份报告没用。 它恰恰说明进程在这次事件之前就已经被杀了，应该去找更早的那份。iOS 不会为每次 kill 都写报告，也会轮转，所以未必找得到。

3. Xcode Organizer 的 Terminations / Memory 面板需要足够用户量。 我的 App 用户少，那儿一直显示 Insufficient usage data。真要在生产环境拿这个数据，得自己接 MetricKit——MXAppExitMetric.backgroundExitData 会把后台退出按原因分桶（memoryResourceLimit / memoryPressure / cpuResourceLimit / appWatchdog / normal），MXMemoryMetric.peakMemoryUsage 给峰值内存，而且不依赖样本量。注意 payload 是按天生成、日终才交付的，今天出的事明天才读得到。

4. 有界即可控，无论多大。 我中途一度去调小音频缓冲的上限、给队列加背压丢帧——那是让泄漏变慢，不是修泄漏，而且丢帧会漏掉真实的鼾声事件。判据应该是”有没有上界”，不是”占了多少”：有上限封顶的缓冲填到 80 MB 是可控的，无上界的队列涨到 10 MB 才是 bug。根因定位之后，那些基于错误推断做的改动我全部还原了。

5. 别给泄漏加兜底。 我还写过”剩余内存不足就自动结束监测”的保护，听起来很负责，实际上根因修掉之后它只剩下误停正常会话的风险。也删了。

回头看

整件事的证据链是这样一条：endTime 落在检查点整倍数上（判定被杀）→ JetsamEvent 报告（拿到 1.8 GB 这个量级）→ git log（作废错误推断）→ Instruments Generation（点名到具体对象）→ 对象个数 = 3 × body 重算次数（锁定根因）。

前面几步都是旁证，只有 Generation 快照那一步是真正指名道姓的。我在拿到它之前写的所有”修复”，事后看全是在给一个不存在的病开药。读代码能产生假设，但假设需要被证据杀死或者证实，中间那一段自己觉得”应该就是这个了”的笃定，最不可信。

不说了，我赶紧发新版本去了，这APP之前是下载就收费，刚改成免费试用+一次性买断的模式，结果免费用户就遇到了内存泄露，异常退出的大问题，实在是很不应该。。。对我的打击也实在是有点大！

The post 一个iOS APP内存泄露排查案例 first appeared on I am LAZY bones?.

而读书，也是这个道理。

虽然你不是亲自去某个地方，但通过文字，你就能感受到笔者所描述的世界，而且这个成本更低。不仅成本低，你还可以进入到“非现实的世界”，比如你读历史，可以进入“过去的世界”；你读玄幻类的，可以进入“虚拟的世界”。在某种意义上，这些都是超越旅行的存在。

当然，我最近读的《阿勒泰的角落》进入的倒是一个“真实的世界”，而且这个世界，说起来我还去过，2022年我来新加坡之前，曾经开着房车游过新疆。我花了半个月时间，在北疆转了一圈，但新疆真的太大了，即使半个月对打工的牛马来说，已经很奢侈了，但我肯定不能说对阿勒泰很熟了。我只是禾木、阿勒泰这样转了几个景点。

而本书的作者，虽然不是新疆人，但却感觉是土生土长在新疆的，而且体感上，应该比我大不了几岁（这个后来我查资料证实了）。从她自己的描述来看，她的学历应该不算高，但文笔却出奇地好，文字看着很舒服，不堆砌辞藻，但却很有画面感，就像你的邻居在给你讲述生活细节一样。呈现给读者的绝大部分是朴实到有点朴素的文字，偶尔镶嵌了恰到好处的“高光”。

内容是关于她在新疆生活的方方面面，包括开店经商的种种经历、谈恋爱又分手的经历、多次搬家的经历以及日常生活的一些细节，但因为那种生活是绝大部分读者所不会经历的，所以读起来就会很有意思。她们一家子人，虽然不是逐水草而居的游牧民族，但不同时期也住在阿勒泰的不同角落，因此也发生了很多不同的故事。

这里就不剧透太多细节的内容了，总之这是一本读起来很轻松的书，就像一次旅行，所以推荐给大家。

The post 《阿勒泰的角落》读书笔记 first appeared on I am LAZY bones?.