Skip to content

Commit 5903c52

Browse files
ChengzhiHuangChengzhiHuang
committed
refactor: 363 期发布前整理
1 parent 74de292 commit 5903c52

File tree

2 files changed

+90
-55
lines changed

2 files changed

+90
-55
lines changed

‎Reports/2026/#363-2026.01.26.md‎

Lines changed: 14 additions & 55 deletions
Original file line numberDiff line numberDiff line change
@@ -5,40 +5,16 @@
55

66
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 提出。
77

8-
## 新闻
9-
10-
> 行业相关的新闻、趣事、看法
11-
12-
##  Developer - 设计开发加速器
13-
14-
> 设计开发加速器相关活动
15-
16-
## 新手推荐
17-
18-
> 收集一些对新手友好且质量不错的文章
19-
208
## 文章
219

22-
> 写的不错的技术博客，包含但不局限于 iOS、多端统一、设计、产品等
23-
24-
### 🐎 [Dart 官方再解释为什么放弃了宏编程，并转向优化 build_runner ? 和 Kotlin 的区别又是什么？](https://mp.weixin.qq.com/s/wwe9Lq392VqrCKhjfIKoXg)
25-
26-
[@Crazy](https://github.com/jiyan135960)：本文主要介绍了 Dart 官方放弃宏编程改为优化 build_runner 的原因，在读本文之前，要先明白什么是宏编程。文章中介绍了 Dart 在实现宏编程的过程中试用的方案与思考，放弃的原因总结起来有三个:
27-
28-
1. 编译会卡在一个“先有鸡还是先有蛋”的死结
29-
2. 工具链双前端导致宏支持会引发“工作量爆炸 + 性能灾难”
30-
3. 即使做成了，也“高不成低不就”：替代不了 build_runner，不如直接扩展 build_runner 能力
31-
32-
文章最后还对比了 Kotlin 的 Compiler Plugins、KSP 与 Swift 的 Swift Macros 的差距，总的来说 build_runner 还有很长的一段路要走。
33-
34-
### 🐕 [精通 UITableViewDiffableDataSource——从入门到重构的现代 iOS 列表开发指南](https://mp.weixin.qq.com/s/Uk2wcMrNpTKQVTt7Z2iEQg)
10+
### 🐕 [精通 UITableViewDiffableDataSource ——从入门到重构的现代 iOS 列表开发指南](https://mp.weixin.qq.com/s/Uk2wcMrNpTKQVTt7Z2iEQg)
3511

3612
[@阿权](https://github.com/bqlin)：本文围绕 iOS 现代列表 `UITableViewDiffableDataSource` 展开，核心是替代传统数据源代理模式，解决列表开发中的崩溃、状态不一致等痛点，并在最后提供一个轻量工具集 [DiffableDataSourceKit](https://github.com/kingnight/DiffableDataSourceKit) 来简化系统 API 的调用。文章核心内容如下：
3713

38-
1. 使用 `UITableViewDiffableDataSource` API，通过声明式的“快照”来管理数据状态，系统自动计算并执行 UI 更新动画，从而一劳永逸地解决了传统模式中数据与 U状态不同步导致的崩溃问题。
39-
2. 全文通过构建一个音乐播放列表App来贯穿始终，从移除Storyboard、定义遵循 `Hashable` 协议的数据模型开始，一步步教你初始化数据源和填充数据。
14+
1. 使用 `UITableViewDiffableDataSource` API，通过声明式的“快照”来管理数据状态，系统自动计算并执行 UI 更新动画，从而一劳永逸地解决了传统模式中数据与 U 状态不同步导致的崩溃问题。
15+
2. 全文通过构建一个音乐播放列表 App 来贯穿始终，从移除 Storyboard、定义遵循 `Hashable` 协议的数据模型开始，一步步教你初始化数据源和填充数据。
4016
3. 文章还详细讲解了：
41-
* 自定义多样化的单元格：包括使用传统的 Auto Layout 布局，以及利用iOS 14+的 `UIContentConfiguration` 进行现代化配置。
17+
* 自定义多样化的单元格：包括使用传统的 Auto Layout 布局，以及利用 iOS 14+ 的 `UIContentConfiguration` 进行现代化配置。
4218
* 实现核心交互：具体涉及了拖拽重排、滑动删除，以及如何通过 Cell 的代理事件处理等交互。
4319
* **处理复杂逻辑**：特别讲解了如何利用模型的 `Hashable` 来实现“原地刷新”而非替换的刷新机制。
4420

@@ -63,22 +39,23 @@
6339

6440
架构的演进一般是为了提高研效、减少出错。一个合理、高效的代码架构，在当业务需求变得复杂的时候，业务调用代码不会随业务的复杂而线性增长，而是逐渐减少。
6541

66-
### 🐕 [@_exported import VS public import](https://alexanderweiss.dev/blog/2026-01-16-exported-import-vs-public-import)
42+
### 🐎 [Dart 官方再解释为什么放弃了宏编程，并转向优化 build_runner ? 和 Kotlin 的区别又是什么？](https://mp.weixin.qq.com/s/wwe9Lq392VqrCKhjfIKoXg)
6743

68-
[@AidenRao](https://weibo.com/AidenRao)：Swift 6 带来了全新的 `import` 访问级别控制：`@_exported import`。它和我们熟悉的 `public import` 有什么不同？简单来说，`public import` 只是将一个模块声明为公开 API 的一部分，但使用者仍需手动导入它；而 `@_exported import` 则是将依赖的符号完全“吸收”，调用方无需关心底层依赖。文章深入对比了两者的意图和应用场景，并给出了明确建议：日常开发中应优先选择官方支持的 `public import`，仅在封装 SDK 或构建聚合模块（Umbrella Module）这类希望为用户简化导入操作的场景下，才考虑使用 `@_exported`。
44+
[@Crazy](https://github.com/jiyan135960)：本文主要介绍了 Dart 官方放弃宏编程改为优化 build_runner 的原因，在读本文之前，要先明白什么是宏编程。文章中介绍了 Dart 在实现宏编程的过程中试用的方案与思考，放弃的原因总结起来有三个 :
6945

70-
### 🐕 [Swift Modules and Code/Assets Duplication](https://pfandrade.me/blog/swift-modules-and-codeassets-duplication/)
71-
[@Smallfly](https://github.com/iostalks)：这篇文章针对 Swift 模块化开发中的代码与资源重复问题，提供了简洁高效的解决方案。核心内容包括：
46+
1. 编译会卡在一个“先有鸡还是先有蛋”的死结
47+
2. 工具链双前端导致宏支持会引发“工作量爆炸 + 性能灾难”
48+
3. 即使做成了，也“高不成低不就”：替代不了 build_runner，不如直接扩展 build_runner 能力
7249

73-
- **模块化痛点**：使用 Swift Package 拆分模块后，静态链接导致代码在主应用与扩展（如 Action Extension）中重复；资源文件（图片、本地化字符串等）会生成独立 bundle 并被复制到每个依赖 target，增加包体积。
74-
- **代码去重**：创建动态框架聚合所有模块，通过 `Package.swift` 配置动态库目标，让主应用与扩展依赖该框架，避免代码重复链接。
75-
- **资源去重**：利用 Run Script 脚本将模块资源 bundle 移动到动态框架内，删除主应用与扩展中的重复 bundle；结合 `Bundle.module` 的查找逻辑，确保资源访问路径正确。
50+
文章最后还对比了 Kotlin 的 Compiler Plugins、KSP 与 Swift 的 Swift Macros 的差距，总的来说 build_runner 还有很长的一段路要走。
7651

77-
文章通过具体代码示例与目录结构对比，展示了优化前后的效果，为 Swift 开发者解决模块化带来的包体积问题提供了可落地的实践方案。
52+
### 🐕 [@_exported import VS public import](https://alexanderweiss.dev/blog/2026-01-16-exported-import-vs-public-import)
53+
54+
[@AidenRao](https://weibo.com/AidenRao)：Swift 6 带来了全新的 `import` 访问级别控制：`@_exported import`。它和我们熟悉的 `public import` 有什么不同？简单来说，`public import` 只是将一个模块声明为公开 API 的一部分，但使用者仍需手动导入它；而 `@_exported import` 则是将依赖的符号完全“吸收”，调用方无需关心底层依赖。文章深入对比了两者的意图和应用场景，并给出了明确建议：日常开发中应优先选择官方支持的 `public import`，仅在封装 SDK 或构建聚合模块（Umbrella Module）这类希望为用户简化导入操作的场景下，才考虑使用 `@_exported`。
7855

7956
### 🐕 [MVVM + Reducer Pattern](https://www.fractal-dev.com/blog/mvvm-and-reducer-pattern)
8057

81-
[@含笑饮砒霜](https://weibo.com/chinafishnews/)：这篇文章主要讲述如何将 MVVM 架构与 Reducer 模式结合来提升 iOS 应用中状态管理的可控性和可维护性。作者指出：传统的 MVVM 模式在复杂状态下易出现分散的状态变更和难以追踪的问题，这会导致难调试、隐式状态转换、竞态条件等不良后果；而 Reducer 模式（受 Redux/TCA 启发）通过 “单一状态源 + 明确 action + 纯函数 reduce” 的方式，使状态变更更可预测、更易测试。文章建议在 ViewModel 内部局部引入 reducer，把所有状态通过单一 reduce(state, action) 处理，并把副作用（如异步任务）当作 effects 处理，从而达到更明确、可追踪且易单元测试的效果，同时保留 MVVM 和领域层的清晰分层，不强依赖某个框架。
58+
[@含笑饮砒霜](https://weibo.com/chinafishnews/)：这篇文章主要讲述如何将 MVVM 架构与 Reducer 模式结合来提升 iOS 应用中状态管理的可控性和可维护性。作者指出：传统的 MVVM 模式在复杂状态下易出现分散的状态变更和难以追踪的问题，这会导致难调试、隐式状态转换、竞态条件等不良后果；而 Reducer 模式（受 Redux/TCA 启发）通过 “单一状态源 + 明确 action + 纯函数 reduce ” 的方式，使状态变更更可预测、更易测试。文章建议在 ViewModel 内部局部引入 reducer，把所有状态通过单一 reduce(state, action) 处理，并把副作用（如异步任务）当作 effects 处理，从而达到更明确、可追踪且易单元测试的效果，同时保留 MVVM 和领域层的清晰分层，不强依赖某个框架。
8259

8360
### 🐢 [用第一性原理拆解 Agentic Coding：从理论到实操](https://mp.weixin.qq.com/s/Zlwn42KyfjgwfX6lp-JthQ)
8461

@@ -92,10 +69,6 @@
9269

9370
[@Damien](https://github.com/ZengyiMa)：文章揭示了 Universal Links 在大规模应用中的隐藏复杂性：AASA 文件缺乏 JSON 模式验证导致静默失效，Apple CDN 缓存延迟使问题修复滞后，苹果特有通配符语法和 substitutionVariables 变量无现成工具支持。作者提出通过 CI 集成模式验证、CDN 同步检查、自定义正则解析和 staging 环境测试的完整方案，并开源了 Swift CLI 工具实现全链路自动化验证。
9471

95-
### 🐕 [The Magic Behind UUID\(\) in Swift, How Your App Generates Truly Unique Identifiers](https://www.swiftdifferently.com/blog/swift/the-magic-behind-uuid-in-swift)
96-
97-
[@Barney](https://github.com/BarneyZhaoooo)：本文介绍 Swift 中 UUID () 的原理与特性，默认生成 Version 4 随机 UUID。它基于 122 位加密安全随机数，从硬件、系统等多源收集熵值，经 CSPRNG 处理，按 RFC 4122 格式化，唯一性几乎绝对。还提及 Version 1（时间 + MAC 地址）和 Version 7（时间 + 随机），并说明 UUID 高效且无碰撞顾虑。
98-
9972
### 🐕 [How I use Codex GPT 5.2 with Xcode (My Complete Workflow)](https://www.youtube.com/watch?v=o4iKnSYlhBQ)
10073

10174
[@JonyFang](https://github.com/JonyFang): 本视频深入介绍了如何让 AI 代理（如 Codex GPT 5.2）真正提升 iOS/macOS 开发效率的三个核心策略：
@@ -110,24 +83,10 @@
11083

11184
## 工具
11285

113-
> 开发过程中常用的工具，及一些新工具的介绍
114-
11586
### 🐎 [Skip Is Now Free and Open Source](https://skip.dev/blog/skip-is-free/)
11687

11788
[@Crazy](https://github.com/jiyan135960)：Skip 框架正式免费并且开源，该库从 2023 年开始开发，已有三年的开发历程。该库的目的是让开发者能够仅用一套 Swift 与 SwiftUI 代码库，同时打造 iOS 与 Android 上的高品质移动应用——而且不必接受那些自“跨平台工具诞生以来就一直存在”的妥协。因为 Skip 是采用编译为 Kotlin 与 Compose 的方式，所以相应的执行效率是非常高的。相较于其他的跨平台开发，效率高，并且使用的是 Swift 语言。既然已经免费并开源，移动端开发的时候又多了一个可供选择的跨端技术。
11889

119-
## 代码
120-
121-
> 库，代码段，开源app
122-
123-
## 书
124-
125-
> 比较不错的书的推荐和书评
126-
127-
## 音视频
128-
129-
> 比较不错的书的推荐和书评
130-
13190
## 内推
13291

13392
重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

‎Reports/2026/#364-2026.02.09.md‎

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
# 老司机 iOS 周报 #364 | 2026-02-09
2+
3+
![ios-weekly](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/weekly-header/364.jpg?raw=true)
4+
5+
在各位读者们的陪伴下老司机技术又度过了一年春秋，这一年大模型的发展出乎意料的快，我们也添加了不少相关的实践与经验，拥抱大模型享受红利也是大势所趋。下一期我们的相见就在年后了，老司机的编辑们给大家拜年了，新春快乐！
6+
7+
老司机 iOS 周报，只为你呈现有价值的信息。
8+
9+
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 提出。
10+
11+
## 新闻
12+
13+
> 行业相关的新闻、趣事、看法
14+
15+
##  Developer - 设计开发加速器
16+
17+
> 设计开发加速器相关活动
18+
19+
## 新手推荐
20+
21+
> 收集一些对新手友好且质量不错的文章
22+
23+
## 文章
24+
25+
> 写的不错的技术博客，包含但不局限于 iOS、多端统一、设计、产品等
26+
27+
### 🐕 [The Magic Behind UUID\(\) in Swift, How Your App Generates Truly Unique Identifiers](https://www.swiftdifferently.com/blog/swift/the-magic-behind-uuid-in-swift)
28+
29+
[@Barney](https://github.com/BarneyZhaoooo)：本文介绍 Swift 中 UUID () 的原理与特性，默认生成 Version 4 随机 UUID。它基于 122 位加密安全随机数，从硬件、系统等多源收集熵值，经 CSPRNG 处理，按 RFC 4122 格式化，唯一性几乎绝对。还提及 Version 1（时间 + MAC 地址）和 Version 7（时间 + 随机），并说明 UUID 高效且无碰撞顾虑。
30+
31+
### 🐕 [Swift Modules and Code/Assets Duplication](https://pfandrade.me/blog/swift-modules-and-codeassets-duplication/)
32+
[@Smallfly](https://github.com/iostalks)：这篇文章针对 Swift 模块化开发中的代码与资源重复问题，提供了简洁高效的解决方案。核心内容包括：
33+
34+
- **模块化痛点**：使用 Swift Package 拆分模块后，静态链接导致代码在主应用与扩展（如 Action Extension）中重复；资源文件（图片、本地化字符串等）会生成独立 bundle 并被复制到每个依赖 target，增加包体积。
35+
- **代码去重**：创建动态框架聚合所有模块，通过 `Package.swift` 配置动态库目标，让主应用与扩展依赖该框架，避免代码重复链接。
36+
- **资源去重**：利用 Run Script 脚本将模块资源 bundle 移动到动态框架内，删除主应用与扩展中的重复 bundle；结合 `Bundle.module` 的查找逻辑，确保资源访问路径正确。
37+
38+
文章通过具体代码示例与目录结构对比，展示了优化前后的效果，为 Swift 开发者解决模块化带来的包体积问题提供了可落地的实践方案。
39+
40+
## 工具
41+
42+
> 开发过程中常用的工具，及一些新工具的介绍
43+
44+
## 代码
45+
46+
> 库，代码段，开源app
47+
48+
## 书
49+
50+
> 比较不错的书的推荐和书评
51+
52+
## 音视频
53+
54+
> 比较不错的书的推荐和书评
55+
56+
## 内推
57+
58+
重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考
59+
60+
具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）
61+
62+
## 关注我们
63+
64+
我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。
65+
66+
**关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参**
67+
68+
![](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/qrcode_for_wechat.jpg?raw=true)
69+
70+
同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。
71+
72+
## 说明
73+
74+
🚧 表示需某工具，🌟 表示编辑推荐
75+
76+
预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

0 commit comments

Comments
 (0)