refactor: 发布前整理

ChengzhiHuang · ChengzhiHuang · commit 9ab21a94b290 · 2026-02-08T20:39:16.000+08:00
diff --git a/Reports/2026/#364-2026.02.09.md b/Reports/2026/#364-2026.02.09.md
@@ -57,7 +57,7 @@
 
 ### 🐎 [How to Avoid Double Updates When Filtering SwiftUI TextField Input](https://livsycode.com/swiftui/how-to-avoid-double-updates-when-filtering-swiftui-textfield-input/)
 
-[@阿权](https://github.com/bqlin)：文章为文本输入组件的文字 filter 提供了通用的解决方案。本文核心解决 SwiftUI TextField 过滤输入时的 “双重更新” 问题，核心思路封过滤/转换逻辑，以解耦上下游逻辑。具体思路如下：
+[@阿权](https://github.com/bqlin)：文章为文本输入组件的文字 filter 提供了通用的解决方案。本文核心解决 SwiftUI TextField 过滤输入时的 “双重更新” 问题，核心思路封过滤 / 转换逻辑，以解耦上下游逻辑。具体思路如下：
 
 1. 内部缓冲区隔离，引入 “内部缓冲区（internalText）” 与 “外部绑定（text）” 分离的设计：
    1. 用户输入路径：键盘输入 → 内部缓冲区 → 过滤 / 转换 → 同步到外部绑定（仅有效值）；
@@ -72,62 +72,30 @@
 
 ### 🐎 [InlineArray in Swift - Memory Efficient Fixed-Size Arrays](https://www.sagarunagar.com/blog/inlinearray-in-swift/)
 
-[@JonyFang](https://github.com/jonyfang):本文介绍了 Swift 6.2 新增的 InlineArray 类型，一种固定大小、值类型的内联数组。与标准 Array 的堆分配不同，InlineArray 将元素直接存储在值内部，消除了堆分配、引用计数和指针间接访问的开销。核心要点：
+[@JonyFang](https://github.com/jonyfang): 本文介绍了 Swift 6.2 新增的 InlineArray 类型，一种固定大小、值类型的内联数组。与标准 Array 的堆分配不同，InlineArray 将元素直接存储在值内部，消除了堆分配、引用计数和指针间接访问的开销。核心要点：
 
 - 声明与约束：大小是类型的一部分（如 InlineArray<Int, 4>），编译期即确定容量，必须提供恰好该数量的元素，不可 append 或 remove，提供强编译期保证。
 - 性能优势：元素连续内联存储，无需指针追踪，CPU 缓存命中率更高，适合数学运算、几何类型、小型缓冲区及框架内部结构等场景。
 - 实际应用：文章以 3D 向量为例，将 var values: [Float] 替换为 InlineArray<Float, 3>，在语义更清晰的同时实现零堆分配。支持标准 for-in 迭代，也可通过 Array(inline) 转换为普通数组。
 - 适用边界：适合小型固定集合、性能关键路径和框架内部实现；不适合需要 append()、filter()、map() 等动态操作的场景。文章强调 InlineArray 是专用工具而非通用集合，日常应用代码仍推荐标准 Array。
 
-### 🐕 [Should You Use All These Dependencies?](https://fractal-dev.com/blog/should-you-use-all-these-dependencies?lang=en)
-
-[@Barney](https://github.com/BarneyZhaoooo)：从 iOS 项目依赖选择角度出发，作者以项目中仅用到 3 处 RxSwift 却引入 3MB 体积与编译成本为例，讨论“能不用库就不用”的默认立场。核心内容包括：
-
-- **决策标准**：评估收益、迁移成本、团队熟悉度与长期维护负担，避免因熟悉而引入不必要抽象
-- **案例对比**：以 Alamofire vs URLSession 说明第三方并非总是更省时，功能范围与实际需求应匹配
-- **风险控制**：建议使用 Wrapper/Facade、版本锁定与定期依赖审计（工具 + 清单）降低锁定与弃坑风险
-
-最后强调每个依赖都是“当下效率”与“未来债务”的权衡，适合建立团队的依赖准入与清理流程。
+### 🐎 [Non-Sendable First Design](https://www.massicotte.org/blog/non-sendable-first-design/)
 
-### 🐕 [How Apple Hooks Entire Frameworks](https://bryce.co/swizzle-everything/)
+[@DylanYang](https://github.com/Dylan19Yang)：作者向我们讲述了借助 NonisolatedNonsendingByDefault ，Non-Sendable 类型目前成为了非常适合作为首选的类型，它更简单、没有额外的语法负担，也更通用，没有太多限制不像 Actor。当然 Non-Sendable 也有一些缺点，比如配合 Task 的场景等。开发者可以根据实际需求来做出适合的选择。
 
-[@Kyle-Ye](https://github.com/Kyle-Ye): 文章深入分析了 Apple 如何通过 Method Swizzling 实现对整个框架的 hook，以 Main Thread Checker 为例，展示了其如何大规模替换数万个方法。作者介绍了基于 trampoline 的实现方案——为每个被 hook 的方法生成唯一的跳板函数，通过共享的汇编处理程序保存和恢复寄存器状态，再调用统一的回调。文章还探讨了如何通过运行时内存映射动态创建 trampoline 以突破数量限制，以及使用私有 API `class_replaceMethodsBulk` 批量替换方法以减少锁竞争从而提升性能。对于对 Objective-C Runtime 底层机制和性能优化感兴趣的开发者值得一读。
 
 ## 工具
 
 ### [steve](https://github.com/mikker/steve)
 
 [@EyreFree](https://github.com/EyreFree)：steve 是基于 macOS 无障碍 API 开发的命令行工具，主打 Mac 应用的自动化操控，适用于自动化测试与 AI 代理控制场景。它支持通过命令完成应用的启动、聚焦、退出等基础管理，还能发现和定位应用界面元素，实现点击、输入、快捷键触发等交互操作，亦可对窗口、菜单栏进行操控，以及截取应用或指定元素的截图。工具默认输出结构化文本，也支持 JSON 格式，提供断言、等待等可靠性辅助功能，能通过 stderr 反馈错误。对 Mac 端应用自动化操作有需要的同学可以试试。
 
-### [Happy：为 Codex/Claude Code 提供无缝的移动端交互](https://github.com/slopus/happy)
-
-Happy (Happy Coder) 是一款开源的第三方配套应用，旨在为 Claude Code (以及 OpenAI Codex) 提供无缝的移动端交互体验。它并不是要取代你的桌面环境，而是通过“远程中继”方案，让你在离开工位时也能通过手机完全掌控 AI 的编程进度：
- 
-- **无感切换 (Seamless Handoff)**：在电脑终端运行 happy 启动 Claude。当你合上电脑出门时，打开手机 App 即可实时接管刚才的对话和代码上下文，状态完全同步。
-- **权限即时推送**：Claude Code 在执行高风险操作（如删除文件、运行复杂脚本）时需要授权。有了 Happy，你的手机会收到推送通知，点击即可远程“允许”或“拒绝”，无需死守在屏幕前。
-- **实时语音协作**：集成了语音交互功能。你可以像跟真人交互一样直接发语音，在走路或通勤时向 Claude 描述需求，看着它在远程电脑上自动写代码。
-- **端到端加密 (E2E)**：安全性是其核心。它采用类似 Signal 的加密协议，代码和对话在传输前即在本地加密，开发者服务器无法读取你的任何代码内容。
-
-### 🐎 [Non-Sendable First Design](https://www.massicotte.org/blog/non-sendable-first-design/)
-
-[@DylanYang](https://github.com/Dylan19Yang)：作者向我们讲述了借助 NonisolatedNonsendingByDefault ，Non-Sendable 类型目前成为了非常适合作为首选的类型，它更简单、没有额外的语法负担，也更通用，没有太多限制不像 Actor。当然 Non-Sendable 也有一些缺点，比如配合 Task 的场景等。开发者可以根据实际需求来做出适合的选择。
-
 ## 代码
 
-> 库，代码段，开源app
-
-### 🐎 [三国霸业/伏魔记重制版源码](https://github.com/erduoniba/baye-fmj-app/tree/main)
+### 🐎 [三国霸业 / 伏魔记重制版源码](https://github.com/erduoniba/baye-fmj-app/tree/main)
 
 [@Crazy](https://github.com/jiyan135960)：一个多平台游戏项目集合，包含几个移植版本的游戏，其中包括在电子词典上非常经典的《三国霸业》与《伏魔记》，尤其是《伏魔记》最后的师尊 boss 更是令人记忆犹新。该项目将多个经典的游戏进行和移植，并且将源码也提供了出来，大家可以在回味童年的时候去学习下小游戏的开发也是一种非常不同的感觉。
 
-## 书
-
-> 比较不错的书的推荐和书评
-
-## 音视频
-
-> 比较不错的书的推荐和书评
-
 ## 内推
 
 重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考
diff --git a/Reports/2026/#365-2026.03.02.md b/Reports/2026/#365-2026.03.02.md
@@ -1,6 +1,6 @@
 # 老司机 iOS 周报 #365 | 2026-03-02
 
-![ios-weekly](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/weekly-header/302.jpg?raw=true)
+![ios-weekly](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/weekly-header/365.jpg?raw=true)
 老司机 iOS 周报，只为你呈现有价值的信息。
 
 你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 提出。
@@ -21,10 +21,36 @@
 
 > 写的不错的技术博客，包含但不局限于 iOS、多端统一、设计、产品等
 
+
+### 🐕 [How Apple Hooks Entire Frameworks](https://bryce.co/swizzle-everything/)
+
+[@Kyle-Ye](https://github.com/Kyle-Ye): 文章深入分析了 Apple 如何通过 Method Swizzling 实现对整个框架的 hook，以 Main Thread Checker 为例，展示了其如何大规模替换数万个方法。作者介绍了基于 trampoline 的实现方案——为每个被 hook 的方法生成唯一的跳板函数，通过共享的汇编处理程序保存和恢复寄存器状态，再调用统一的回调。文章还探讨了如何通过运行时内存映射动态创建 trampoline 以突破数量限制，以及使用私有 API `class_replaceMethodsBulk` 批量替换方法以减少锁竞争从而提升性能。对于对 Objective-C Runtime 底层机制和性能优化感兴趣的开发者值得一读。
+
+### 🐕 [Should You Use All These Dependencies?](https://fractal-dev.com/blog/should-you-use-all-these-dependencies?lang=en)
+
+[@Barney](https://github.com/BarneyZhaoooo)：从 iOS 项目依赖选择角度出发，作者以项目中仅用到 3 处 RxSwift 却引入 3MB 体积与编译成本为例，讨论“能不用库就不用”的默认立场。核心内容包括：
+
+- **决策标准**：评估收益、迁移成本、团队熟悉度与长期维护负担，避免因熟悉而引入不必要抽象
+- **案例对比**：以 Alamofire vs URLSession 说明第三方并非总是更省时，功能范围与实际需求应匹配
+- **风险控制**：建议使用 Wrapper/Facade、版本锁定与定期依赖审计（工具 + 清单）降低锁定与弃坑风险
+
+最后强调每个依赖都是“当下效率”与“未来债务”的权衡，适合建立团队的依赖准入与清理流程。
+
+
 ## 工具
 
 > 开发过程中常用的工具，及一些新工具的介绍
 
+### [Happy：为 Codex/Claude Code 提供无缝的移动端交互](https://github.com/slopus/happy)
+
+Happy (Happy Coder) 是一款开源的第三方配套应用，旨在为 Claude Code (以及 OpenAI Codex) 提供无缝的移动端交互体验。它并不是要取代你的桌面环境，而是通过“远程中继”方案，让你在离开工位时也能通过手机完全掌控 AI 的编程进度：
+ 
+- **无感切换 (Seamless Handoff)**：在电脑终端运行 happy 启动 Claude。当你合上电脑出门时，打开手机 App 即可实时接管刚才的对话和代码上下文，状态完全同步。
+- **权限即时推送**：Claude Code 在执行高风险操作（如删除文件、运行复杂脚本）时需要授权。有了 Happy，你的手机会收到推送通知，点击即可远程“允许”或“拒绝”，无需死守在屏幕前。
+- **实时语音协作**：集成了语音交互功能。你可以像跟真人交互一样直接发语音，在走路或通勤时向 Claude 描述需求，看着它在远程电脑上自动写代码。
+- **端到端加密 (E2E)**：安全性是其核心。它采用类似 Signal 的加密协议，代码和对话在传输前即在本地加密，开发者服务器无法读取你的任何代码内容。
+
+
 ## 代码
 
 > 库，代码段，开源app
