其它 on 土土哥的技术 Blog

开源项目 Claude Code Notifier Plus：让 Claude Code 真正需要你时再提醒你

Sun, 12 Jul 2026 16:30:00 +0000

前言

最近这段时间用 Claude Code 比较多，慢慢发现一个很实际的问题：AI 写代码的时候人不应该一直盯着它。

比如我让它跑一个重构任务，然后切到浏览器查资料、看文档，或者去另一个项目里继续处理事情。几分钟后切回来，发现它早就停在权限确认那里了；再或者任务已经结束，但我完全不知道。项目窗口一多，这种反复切换就更明显了。

所以我写了一个小工具：Claude Code Notifier Plus。它的目标很简单：当 Claude Code 需要我注意时，用系统通知提醒我，并且点击通知能回到对应的 VS Code 窗口或终端窗口。

Github: https://github.com/zekunyan/claude-code-notifier-plus

为什么还要再做一个通知插件

Claude Code 本身有 Hook 机制，理论上我们可以监听通知事件，然后调用系统通知工具即可。最开始我也是这么想的。

但实际用下来有个坑：在 VS Code 扩展模式下，依赖 Notification hook 的方式并不可靠。Claude Code 的 VS Code 扩展会在自己的 webview 内部处理一部分交互，很多 CLI 模式下可用的通知逻辑，到了 VS Code 里就会悄悄失效。

所以这个插件没有继续依赖单一的 Notification hook，而是直接注册更具体的事件：

场景	Claude Code Hook
请求工具权限	`PermissionRequest`
需要用户确认/回答	`Elicitation`
主任务结束	`Stop`
Subagent 结束	`SubagentStop`

这样 CLI 和 VS Code 扩展模式都能覆盖到。通知的触发条件也更清楚：不是“任何通知都弹一下”，而是围绕我真正需要回去处理的几个节点。

功能点

当前版本是 1.5.0，主要能力如下：

双模式支持：终端里的 Claude Code、VS Code 扩展里的 Claude Code 都能触发。
纯 CLI fallback：即使 VS Code 没有启动，也可以直接发系统通知。
点击跳转：macOS 上配合 terminal-notifier，点击通知可以跳回对应 VS Code 项目窗口，或者 Terminal / iTerm2 / Warp 等终端窗口。
任务上下文：通知里会带项目名和任务摘要，不用靠猜是哪一个窗口。
多实例安全：多个 VS Code 窗口同时运行时，通过 marker、lock、去重逻辑避免重复弹。
焦点感知和延迟通知：VS Code 已经在前台时可以不弹，也可以设置延迟，让 VS Code 内部 popup 有机会先被手动取消。
选中代码发送到 Claude Code：选中代码后可以通过右键、快捷键、编辑器按钮，把 @file#line 引用插入 Claude Code 输入框。

快速安装

VS Code 扩展商店搜索 Claude Code Notifier Plus，或者命令行安装：

code --install-extension tutuge.claude-code-notifier-plus

如果在 macOS 上希望支持点击通知后跳转到准确窗口，推荐安装：

brew install terminal-notifier

还需要给 terminal-notifier 一次辅助功能权限：

系统设置 -> 隐私与安全性 -> 辅助功能 -> 开启 terminal-notifier

这个权限的作用不是读取内容，而是允许它把对应窗口 raise 到前台。没有这个权限时，点击通知通常只能激活 App，不能精确切到某个项目窗口。

整体架构

先看整体流程：

实现上拆成几块：

extension.js：VS Code 扩展入口，负责安装 hook、监听 pipe 文件、读取配置、发通知。
hooks/notify.js：真正被 Claude Code hook 调用的脚本，负责把不同事件整理成统一 payload。
lib/hook-installer.js：自动修改 ~/.claude/settings.json，注册事件 hook。
lib/system-notification.js：封装 macOS / Windows / Linux 系统通知，以及 macOS 上的点击跳转。
lib/payload.js：解析 payload、过滤事件类型。

简单来说，Claude Code 事件先进入 notify.js，再写入一个固定文件；VS Code 扩展监听这个文件，最后根据配置决定要不要发系统通知。

这个设计看起来多绕了一层，但它解决了一个实际问题：hook 脚本和 VS Code 扩展不在同一个进程里。hook 是 Claude Code 启动的 Node 进程，扩展运行在 VS Code extension host 里，两边需要一个足够简单、跨环境稳定的通信方式。

自动注册 Hook

插件启动时会把 hook 写到 ~/.claude/settings.json。核心逻辑大概是这样：

const VSCODE_HOOK_EVENTS = [
 'PermissionRequest',
 'Elicitation',
 'Stop',
 'SubagentStop',
];

function buildHookEntry(notifyScriptPath, options) {
 return {
 type: 'command',
 command: `node "${notifyScriptPath}" # claude-code-notifier-plus`,
 ...options,
 };
}

这里有两个细节：

hook entry 里带了一个 sentinel：# claude-code-notifier-plus。
每次安装前会先清理旧的 managed hook，再写入新的 hook。

为什么要这么做？因为用户自己的 settings.json 里可能已经有别的 hook，插件不能粗暴覆盖整个 hooks 配置。sentinel 的作用就是只识别自己管理的那一段：

function isManaged(hookEntry) {
 return Array.isArray(hookEntry.hooks) &&
 hookEntry.hooks.some((h) =>
 typeof h.command === 'string' && h.command.includes(SENTINEL)
 );
}

这样后续升级、路径变化、卸载时，都可以只处理插件自己的 hook，尽量不影响用户已有配置。这个地方是写工具类扩展时很容易忽略的：自动化配置要可回收、可重复执行、不能污染用户配置。

Payload 归一

Claude Code 传给 hook 的数据不应该直接透传到通知层。不同事件的数据结构不一样，通知层也不需要知道所有细节，所以 notify.js 会先做一次归一：

const EVENT_MAP = {
 PermissionRequest: (data) => ({
 event: 'permission_prompt',
 text: `🔐 Requesting permission: ${data.tool_name || 'a tool'}`,
 }),
 Elicitation: () => ({
 event: 'elicitation_dialog',
 text: '❓ Claude has a question for you',
 }),
 Stop: () => ({
 event: 'idle_prompt',
 text: '✅ Task completed',
 }),
 SubagentStop: () => ({
 event: 'subagent_stop',
 text: '🤖 Subagent finished',
 }),
};

最终写给扩展侧的是统一格式：

{
 event,
 text,
 project,
 taskTitle,
 cwd,
 termBundleId,
 ts: Date.now()
}

其中 project 来自 cwd 的目录名，taskTitle 会从 transcript 里取第一条用户消息并截断。这样通知里就不是只有一句“任务完成”，而是能看到类似：

📂 MyBlog · 💬 写一篇 Claude Code Notifier Plus 的文章
✅ 任务完成

项目窗口一多，这个上下文非常重要。否则通知弹出来以后，还要自己回忆“这是哪个任务”，体验就差很多。

Pipe、Marker 和 Lock

扩展和 hook 之间用了三个文件：

const CLAUDE_DIR = path.join(os.homedir(), '.claude');
const NOTIFY_FILE = path.join(CLAUDE_DIR, 'notify-plus.pipe');
const MARKER_FILE = path.join(CLAUDE_DIR, 'notify-plus.active');

notify-plus.pipe 不是严格意义上的 Unix pipe，而是一个固定路径的普通文件。hook 把 JSON payload 写进去，扩展用 fs.watch 监听变化：

fileWatcher = fs.watch(NOTIFY_FILE, () => {
 handleNotification();
});

如果 fs.watch 不可用，再 fallback 到 fs.watchFile：

fs.watchFile(NOTIFY_FILE, { interval: 500 }, (curr, prev) => {
 if (curr.mtimeMs > prev.mtimeMs) handleNotification();
});

notify-plus.active 用来记录当前活着的 VS Code extension host PID。hook 运行时会检查这个文件，如果发现扩展没有启动，就直接走 CLI fallback 发通知：

function isExtensionActive() {
 const pids = content.split('\n').filter(Boolean).map(Number);
 return pids.some(pid => {
 try {
 process.kill(pid, 0);
 return true;
 } catch (_) {
 return false;
 }
 });
}

还有一个 lock 文件：notify-plus.pipe.lock。多个 VS Code 窗口都可能监听同一个 pipe，如果没有 lock，同一条 payload 可能被多个窗口同时读到并弹多次。所以扩展处理通知前会先抢锁：

function acquireLock() {
 const lockFile = NOTIFY_FILE + '.lock';
 const fd = fs.openSync(lockFile, 'wx');
 fs.closeSync(fd);
 return true;
}

这里用的是 wx，也就是文件不存在时才创建成功。这个方式很朴素，但足够处理“多个扩展进程同时抢同一条通知”的问题。

另外扩展里还有一个 2 秒窗口的去重：

function isDuplicate(event, text) {
 const key = `${event}:${text}`;
 const now = Date.now();
 if (key === lastNotifKey && now - lastNotifTime < 2000) return true;
 lastNotifKey = key;
 lastNotifTime = now;
 return false;
}

Lock 解决跨窗口竞争，dedup 解决短时间内同一事件重复触发。两个点关注的问题不一样，都需要有。

CLI 和 VS Code 的区分

点击通知要跳回哪里？这个问题比“发一条通知”复杂。

如果 Claude Code 跑在 VS Code 扩展里，点击通知应该回到 VS Code 项目窗口。如果 Claude Code 跑在 iTerm2 或 Warp 里，点击通知应该回到对应终端。最麻烦的是：VS Code 里也可能有 terminal，进程树判断很容易误判。

所以 hook 里优先检查 VSCODE_PID：

const isVSCode = !!process.env.VSCODE_PID ||
 process.env.TERM_PROGRAM === 'vscode';

const detectedTermBundleId = isVSCode
 ? ''
 : (getTerminalBundleId() || '');

如果是 VS Code 环境，就不再尝试检测终端，避免把 VS Code 内部 terminal 误认为外部终端。只有纯 CLI 场景，才去看 TERM_PROGRAM、LC_TERMINAL，再不行就沿进程树往上找：

if (/^Terminal$/.test(comm)) return 'com.apple.Terminal';
if (/iTerm/i.test(comm)) return 'com.googlecode.iterm2';
if (/[Ww]arp/.test(comm)) return 'dev.warp.Warp-Stable';

这个判断并不是追求覆盖所有终端，而是优先保证主流场景不要跳错。工具类插件里，“不支持某些边缘终端”通常比“跳到错误窗口”更容易接受。

macOS 点击跳转

macOS 普通 osascript display notification 能发通知，但点击行为不好控制。所以增强模式下使用 terminal-notifier。

发通知时会带上 -activate 和 -execute：

const args = [
 '-title', '✨ Claude Code',
 '-message', safe,
 '-activate', activateBundleId,
 '-group', groupId,
];

args.push('-execute', `${executeScript}; ${removeCmd}`);

-activate 负责激活 App，-execute 负责进一步执行 AppleScript，把具体窗口 raise 到前台。VS Code 场景下会按窗口标题匹配项目名：

set wins to every window whose title contains "MyBlog"
if (count of wins) > 0 then
 perform action "AXRaise" of item 1 of wins
end if

这个实现依赖辅助功能权限，所以插件第一次启动时会提示用户授权。没有授权也不是完全不可用，只是从“跳到具体项目窗口”降级成“激活 VS Code / 终端 App”。

另外通知里带了 groupId，点击后会执行：

terminal-notifier -remove 'claude-notif-...'

这样点完通知以后，通知中心里不会一直堆着旧消息。这个细节对高频使用来说挺重要，不然一天跑下来通知中心会很乱。

选中代码发送到 Claude Code

除了通知之外，插件还加了一个小功能：把选中的代码快速发给 Claude Code。

入口有几个：

编辑器右上角按钮。
右键菜单。
Lightbulb code action。
快捷键 Cmd+Shift+I / Ctrl+Shift+I。
资源管理器里右键某个文件。

实现上并没有重新发明一套与 Claude Code webview 通信的协议，而是复用 Claude Code 扩展已有的命令：

await vscode.commands.executeCommand('claude-vscode.insertAtMention');

如果 Claude Code 面板还没打开，就先打开最近的 Claude Code，再插入：

try {
 await vscode.commands.executeCommand('claude-vscode.insertAtMention');
} catch {
 await vscode.commands.executeCommand('claude-vscode.editor.openLast');
 await vscode.commands.executeCommand('claude-vscode.insertAtMention');
}

这个功能看起来和通知没什么关系，但实际工作流里很顺手：选中一段代码，按快捷键，Claude Code 输入框里就会出现 @file#line-range 引用。它拿到的是文件引用，而不是单纯复制文本，所以后续还能基于完整上下文继续读文件。

配置项

目前配置都放在 claudeCodeNotifierPlus.* 下：

{
 "claudeCodeNotifierPlus.notifyOnPermissionRequest": true,
 "claudeCodeNotifierPlus.notifyOnQuestion": true,
 "claudeCodeNotifierPlus.notifyOnTaskComplete": true,
 "claudeCodeNotifierPlus.notifyOnSubagentStop": false,
 "claudeCodeNotifierPlus.systemNotification": true,
 "claudeCodeNotifierPlus.sound": false,
 "claudeCodeNotifierPlus.notificationDelay": 0,
 "claudeCodeNotifierPlus.showVSCodePopup": false,
 "claudeCodeNotifierPlus.clickToFocus": "window",
 "claudeCodeNotifierPlus.suppressWhenFocused": false
}

这里默认不开 subagent_stop，是因为 subagent 在复杂任务里可能比较频繁，如果每个子任务完成都弹一下，会比较吵。默认只提醒主流程真正需要注意的事件。

notificationDelay 这个配置也比较实用。比如你同时打开了 VS Code popup 和系统通知，可以设置几秒延迟；如果你在这几秒里手动点掉 VS Code popup，就取消系统通知，避免重复打扰。

总结

Claude Code Notifier Plus 本质上不是一个复杂项目，它解决的是一个很具体的效率问题：让 Claude Code 在需要人介入时把我叫回来，而不是让我一直盯着它。

这次实现里我自己比较关注几个点：

不依赖单一 Notification hook，而是监听更明确的事件。
hook 和 VS Code extension host 之间用固定文件通信，简单、可调试、跨环境稳定。
CLI 和 VS Code 场景分开处理，避免点击通知跳错窗口。
自动修改用户配置时，用 sentinel 标记自己的内容，做到可重复安装和可清理。
多窗口场景下用 marker、lock、dedup 处理重复通知。

总的来说，AI Coding 工具越来越强以后，工程师的工作方式也会跟着变化。以前我们关注的是“怎么让工具更聪明”，现在也要关注“怎么让工具在合适的时候打断我”。打断太少会错过确认，打断太多又会变成噪音。这个插件就是在这个小问题上的一次实践。

参考

九年之后，重新整理一下过去写过的文章

Wed, 01 Jul 2026 00:00:00 +0000

前言

距离上一次写博客已经过去 9 年了。回头看了一下最后几篇文章的时间，确实有点恍惚，时光荏苒这句话放在这里还挺合适。

这几年技术变化很快，尤其随着 AI 时代的来临，查资料、整理脉络、校对文字、补齐上下文的成本都低了不少。以前写一篇文章，很多精力会花在资料整理和表达打磨上；现在这些环节可以被工具分担一部分，反而更应该把项目里的问题、判断和思考沉淀下来。

所以接下来还是想把博客重新写起来，并且尽量不间断地继续更新。在继续写新的内容之前，先把过去几年写过的文章做一次总结和索引，也算是给这个博客重新接上线。

之前写文章的时候基本都是遇到一个问题、做了一个控件、踩了一个坑，然后顺手整理出来。时间长了以后，单篇文章之间其实是有脉络的：有些是 iOS 工程结构，有些是 Runtime 和内存管理，有些是 UI 交互和开源控件，还有一些是读书笔记、翻译和服务端相关的小实践。本文就把它们按主题重新整理一下，方便以后自己回头查，也方便刚好搜到某一篇的同学顺着同一类问题继续看下去。

整体回顾

目前博客里的旧文章主要集中在 2014 到 2017 年，一共 42 篇。现在回头看，这些文章当然带着很明显的时间痕迹：Objective-C、Masonry、CocoaPods、早期 Swift、Runtime、反编译，这些都是当时做 iOS 开发绕不开的话题。

不过很多问题并没有过时，只是换了技术栈和工具形态。比如代码怎么拆、接口怎么设计、复杂页面怎么优化、遇到奇怪问题怎么验证，这些到现在依然是工程里每天都会遇到的事情。

大致按年份看：

2014 年，主要是刚开始写 Blog，以及一个 Android 开源控件。
2015 年，文章最多，覆盖了 iOS 项目结构、Objective-C 基础、UITableView 性能、GCD、Auto Layout、Runtime、Swift 控件等。
2016 年，更多是在总结工程化、模块化、代码组织、API 设计，也有一些更底层的内存管理和消息发送内容。
2017 年，主要集中在 Runtime、反编译、Xcode Bug 分析，以及几个控件和工具库。

如果按阅读路线来分，则可以这样看：

想看 iOS 工程实践，可以先看项目结构、模块化、代码组织。
想看 Objective-C 底层，可以从 @autoreleasepool、__autoreleasing、objc_msgSend、methodSignatureForSelector: 这几篇开始。
想看 UI 实现，可以看 Auto Layout 系列、UITextView 图文混排、几个 TTG 开源控件。
想查具体问题，就直接按下面的主题索引找。

工程结构、架构与协作

这一类文章主要讨论“代码应该怎么放、怎么拆、怎么协作”。很多观点放到现在不一定是唯一答案，但是问题本身一直存在：项目变大以后，如何让代码还能被理解、修改和复用。

iOS项目的目录结构-原创
比较早的一篇工程结构整理，重点是从目录层面把业务、工具、资源、第三方代码分清楚。
Entity和Model的不同-关于代码的数据层
讨论数据层对象的职责边界，适合和后面的 ViewModel、数据加工、接口返回设计一起看。
利用NSProxy实现消息转发-模块化的网络接口层设计-原创
从 NSProxy 和消息转发切入，把网络接口层做成更清晰的调用入口。
对组件化与模块化的思考与总结
当时读了不少组件化文章后做的一次整理，重点是“模块”和“组件”的区别，以及如何从业务、技术、界面、数据几条线去拆分。
总结一些iOS项目中组织代码的方法
从 CocoaPods 私有库、Carthage、Xcode Group、Category、#pragma mark 等不同粒度整理代码组织方法。
API返回结果设计经验与总结
虽然分类放在服务端，但本质也是客户端和服务端协作的接口契约问题。
一次审核被拒的经历-关于iCloud到底应该备份什么数据
一个偏实践的审核问题，记录了 iCloud 备份数据边界，属于踩坑型文章。

Objective-C、Runtime 与内存管理

这一组文章是我自己回头看时比较有连续性的部分：一开始是内存和属性行为，后面慢慢过渡到 Runtime、消息转发、反编译和系统实现。

NSString的Copy与内存分配
从 NSString、NSMutableString 的 copy 行为入手，看对象拷贝和内存分配。
@autoreleasepool-内存的分配与释放
整理 @autoreleasepool 的基本行为，是后面看 __autoreleasing 的基础。
结合访问Out Parameters出现EXC_BAD_ACCESS的例子，反编译汇编解读__autoreleasing
通过 Out Parameters 的 crash 例子，继续看 __autoreleasing 和 autorelease pool 的关系。
翻译-为什么objc_msgSend必须用汇编实现
一篇翻译文章，但对理解 Objective-C 消息发送、寄存器、调用约定很有帮助。
用Runtime的手段填充任意NSObject对象的nil属性
一个用 Runtime 遍历属性并填充默认值的小实践，适合理解属性列表和动态处理。
解决iOS项目的版本兼容问题-结合宏、Category和Runtime
用宏、Category、Runtime 做版本兼容处理，属于工程实践和 Runtime 的交叉。
在对象dealloc的后期执行Task-开源库TTGDeallocTaskHelper
围绕对象销毁阶段执行任务，涉及生命周期、关联对象和封装方式。
反编译分析Xcode8的Bug, release下连续两次调用有二级指针参数的空方法会Crash
一个比较典型的“写 Demo 验证 -> 反编译分析 -> 总结原因”的问题排查过程。
反编译分析并模拟实现methodSignatureForSelector方法
从 methodSignatureForSelector: 的行为差异出发，最后尝试模拟实现，适合作为 Runtime 深入阅读的一篇。

并发、性能与小技巧

这一类文章更偏“项目里马上能用到”的经验。现在很多技术栈已经变化了，但里面的一些判断方式仍然有参考意义，比如提前计算、缓存、减少重复创建、明确线程上下文等。

提升UITableView性能-复杂页面的优化
从复杂动态页面入手，总结 Cell 复用、高度缓存、数据预处理、View 缓存等优化点。
GCD使用经验与技巧浅谈
对 GCD 常见使用方式做了一次整理，包括队列、同步异步、延迟执行等。
为GCD队列绑定NSObject类型上下文数据-利用__bridge_retained(transfer)转移内存管理权
一个更细的问题：如何给 GCD 队列绑定 Objective-C 对象，并正确处理内存管理权。
Block类型变量-缓存Http请求与回调
通过 Block 保存回调，解决重复请求和回调分发问题。
有关宏定义的经验与技巧-简化代码-增强Log
记录了一些宏定义用法，重点是让重复代码更少、调试信息更清楚。

UI、布局与交互实现

这一组基本都是“先有一个效果，再拆解实现”的文章。相比纯理论，我自己更喜欢这种写法：先把画面、交互、约束关系摆出来，再一点点推到代码。

UITextView编辑时插入自定义表情-简单的图文混编
记录 UITextView 中插入自定义表情的基础实现。
UITextView编辑时插入自定义表情-续-自定义表情图片的大小
继续处理 NSTextAttachment 图片大小的问题，是上一篇的补充。
有趣的Autolayout示例-Masonry实现
Auto Layout + Masonry 系列第一篇，用有趣的布局示例解释约束。
有趣的Autolayout示例2-Masonry实现
Auto Layout 系列第二篇，继续通过示例练习约束关系。
有趣的Autolayout示例3-Masonry实现
Auto Layout 系列第三篇。
有趣的Autolayout示例4-Masonry实现
Auto Layout 系列第四篇。
有趣的Autolayout示例5-Masonry实现
Auto Layout 系列第五篇，也是这个系列后面的一次补充。
用QuartzCode快速实现一个收藏动画
通过 QuartzCode 快速做收藏动画，重点是工具生成动画代码后的理解和使用。

开源项目与控件实现

这些文章基本都围绕一个具体控件或工具展开：为什么做、最终效果是什么、API 怎么设计、关键实现点在哪里。现在看起来，有些库可能已经偏老了，不过当时做开源项目时对封装、文档、Demo 的训练还是很有价值。

Android开源库-LinkTextView-原创
早期的 Android 开源控件，用来处理文本中的链接点击。
Swift写的库-TTGSnackbar
一个 Swift 写的 Snackbar 控件，重点在交互展示和 API 封装。
Swift开源项目: TTGEmojiRate的实现
基于 UIBezierPath、手势和绘制实现 Emoji 评分控件。
开源项目-TTGTagCollectionView
标签布局控件，适合看布局计算、数据源和代理 API 的设计。
Swift开源Mac App - BingWallPaper
一个 macOS 菜单栏应用，用 Swift 获取 Bing 壁纸并设置桌面背景。
开源项目-拼图验证控件TTGPuzzleVerify的实现
拼图验证控件，包含图片裁剪、遮罩、滑动验证等实现点。
在对象dealloc的后期执行Task-开源库TTGDeallocTaskHelper
既是开源库，也可以归到 Runtime 和对象生命周期相关内容里。

读书笔记与翻译

这部分主要是阅读《Effective Objective-C》和技术文章后的整理。它们不算完整翻译，更像是把书里的点和自己的理解合在一起做记录。

Effective-Objective-C-读书笔记-Item-1
Effective Objective-C 系列笔记开头。
Effective-Objective-C-读书笔记-Item-2
继续整理 Objective-C 基础概念。
Effective-Objective-C-读书笔记-Item-3
读书笔记第三篇。
Effective-Objective-C-读书笔记-Item-4-如何正确定义常量
重点是常量定义方式，也是实际项目里很常见的问题。
Enum-枚举的正确使用-Effective-Objective-C-读书笔记-Item-5
整理枚举的正确使用方式，包括位掩码等内容。
翻译-为什么objc_msgSend必须用汇编实现
这篇同时也属于 Runtime 主题，放在这里是因为它本身是翻译文章。

服务端、跨端与其它

虽然博客大部分是 iOS，但也有几篇不是纯 iOS 的内容。

RPC框架Thrift例子-PHP调用C++后端程序
用一个小例子记录 Thrift、PHP、C++ 后端之间的调用。
API返回结果设计经验与总结
从接口返回结构出发，讨论 code、message、data 等字段的设计。
Android开源库-LinkTextView-原创
Android 控件文章，也算是早期跨端尝试的一部分。
第一篇Blog
真正意义上的第一篇，更多是一个开始的记录。

按年份索引

如果不按主题，而是按时间看，脉络会更明显一些。

2014

2015

2016

2017

总结

这次整理之后再看，过去这些文章其实大致围绕几个关键词：工程结构、Objective-C 底层、UI 实现、性能优化、开源封装。

单篇文章写的时候往往只是解决一个具体问题，但放在一起看，就能看到当时学习和做项目的路径：先解决页面和业务问题，再关注代码组织和模块拆分，最后慢慢深入到 Runtime、内存管理和反编译验证。

隔了 9 年再重新开始写博客，感觉像是把一个很久没打开的项目重新拉起来。代码可以重新编译，文章也可以继续更新。AI 工具会让整理和表达的成本更低，但真正值得记录的，还是项目里遇到的问题、做判断时的取舍，以及过一段时间后依然能回头看的经验。

后面新的文章也会沿着这个索引继续补充。这样博客就不只是按时间堆在一起，而是能变成一份可以回头查、也可以顺着阅读的技术笔记了。

第一篇Blog

Fri, 31 Oct 2014 16:13:15 +0000

拖了很久，终于开始写博客了。一直觉得自己的知识储备不够，一直都在学习，一直都在积累。（其实就是懒好吗=。=）

说点啥呢，想到啥就说啥吧~

从小就喜欢模型、乐高积木，喜欢拆东西，印象最深的就是把家里的高级录音机拆了，装不回去，塞到了床底下。。。

上了学之后，又开始捣鼓四驱车，自己做马达，绕线圈，家里零件一大堆，串联一堆电池，组装遥控车，唯一的遗憾，就是没有做成遥控飞机（没钱=、=）。

接着，家里有了电脑！！！这要感谢老爹，当时花了一万多，液晶显示器，刚上市的奔腾4啊！

于是，我又开始拆电脑。。。换显卡、超频，跑分，再超频，再跑分，3DMark就是俺的祖宗啊~

终于，走上了编程这条“不归路”，义无反顾，一直到了现在。

用Dev-C++折腾C语言，数据结构、算法，接着又是C++，Window API，QT（这个真觉得不错），MFC（软件课设），Java，Python，Android（上线了几个小应用，拿了Google全国大学生Android应用开发大赛华中地区三等奖），iOS（上线应用，青桔音乐），Linux，还有各种MySQL、MongoDB等数据库的纠结，看各种博客。。。

每天看的很多，想的也不少，但是终究不够精通，路还很长啊~开写吧～～～～～～