老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

文章

🐎 使用 @_private(sourceFile:) 测试 Swift 私有成员

@阿权：私有成员一直是单元测试的难题，以往的做法要么公开其成员，要么封装供测试的接口，本文提出可以用 @_private(sourceFile:) 测试私有成员。该标识是非公开 API，是编译器专用的接口，可绕过访问控制。不过前提需要为目标模块添加编译标志 -enable-private-imports，允许其私有成员被外部测试访问，并需用条件编译宏包裹，以防后续编译器更新导致 API 不可用。

通过这种方式，可以在完全不修改原有接口的前提下自由地编写单元测试代码。

Building 17 Agentic AI Patterns and Their Role in Large-Scale AI Systems

@EyreFree：本文聚焦大规模 AI 系统构建，提出 17 种智能体架构及应用场景，含多智能体系统、集成决策、思维树（ToT）等。以 LangChain、LangGraph、LangSmith 为工具栈，详细解析各架构实现流程，如反思架构通过生成 - 批判 - 优化提升输出质量，ReAct 架构借 “思考 - 行动 - 观察” 循环解决多步骤问题，PEV 架构增验证环节应对工具失效。还介绍组合架构思路，强调不同架构协同可实现复杂任务，且附 GitHub 代码库供实践，为大规模 AI 系统开发提供全面参考，在做 AI 相关开发的同学可以看看。

🐎 iOS 26 你的 property 崩了吗？

@Kyle-Ye: iOS 26 Runtime 在 objc_storeStrong 实现中引入了哨兵值机制（0x400000000000bad0），主动暴露 nonatomic 属性的并发访问问题。新实现在写入新值之前，会先向属性地址写入哨兵值，创建一个"危险窗口"。任何在此窗口期间的并发读写操作都会必然触发 EXC_BAD_ACCESS 崩溃，而不再依赖于对象引用计数等不确定因素。文章详细剖析了写写并发（objc_release 崩溃）和读写并发（objc_retain 崩溃）两种典型场景，并介绍了快手自研的 Ekko 安全气垫框架如何通过兜底 Mach 异常来进行崩溃止损。对于维护线上 App 稳定性的开发者来说，这个系统级变更影响全量版本，建议重点关注 nonatomic 属性的线程安全问题，必要时改用 atomic 或添加额外的安全气垫机制进行兜底。

🐕 Build Your First 24/7 Agentic Loop

@Cooper Chen：如果你想了解“ AI Agent 是否能真正实现持续自主执行任务”，WeZZard 的文章与配套项目是极具价值的入门参考。

该文章提出了一个极简且可工程化复用的方法论：
Contract（合同）＋ Loop（循环）＋ Runtime（运行时）。借助高阶模型（如 Claude 4 或未来的 GPT-5），通过结构化 JSON 协议与工具调用，系统即可在评估者（Evaluator）与执行者（Executor）之间持续推进任务，实现 24/7 agentic 工作流。

配套开源仓库 《agentic-loop-playground》实现了一个完整示例：

• 自动扫描并处理代码中的 TODO/FIXME
• evaluator 决策，executor 执行
• 循环驱动任务直至完成

这是一种无需复杂框架即可落地的智能代理构建方式，非常适合开发者快速启动个人或团队级 Agent 流程。

🐕 Understanding Live Activities: visual micro-storytelling

@AidenRao：这篇文章是关于 iOS 16 引入的 Live Activities（实时活动）功能的设计指南。

• Live Activities 是一种实时微界面，可以在锁屏、灵动岛等处显示应用动态更新。适用于有时间敏感、状态变化的任务，例如：
  • 状态跟踪：如外卖配送、出行导航。
  • 计时器：如烹饪、停车计时。
  • 阶段进程：如电商订单进度。
  • 实时更新：如体育比赛得分。
• 不适用情况：静态信息（如天气温度）或非关键更新（如社交点赞），应使用通知或小组件。

Live Activities 的核心是帮助用户快速获取关键动态信息，减少频繁打开应用的需要。设计时应以用户需求为中心，避免滥用。

🐎 iOS 17 + SwiftUI TextField 内存泄漏分析

@DylanYang：iOS 17 引入的 AutoFillUI 框架使得在使用 UITextField 时会发生不预期的内存泄漏，当 UITextField 成为第一响应者且用户离开视图时就会发生。由于在 SwfitUI 中 TextField 可以通过 .environmentObject() 保持对大型对象图的引用，因此在 SwiftUI 中内存泄漏的问题会更严重一点。对问题起因和绕过方式感兴趣的同学可以阅读本文作进一步了解。

内推

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

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

新手推荐

🐎 Understanding Deflate

@xiaofei86：本文通过手工解码一个 gzip 文件，简单探究了其压缩算法 Deflate 的工作机制，Deflate 结合了 LZ77 算法与 Huffman 编码，通过用 “复制指令” 替代重复片段实现无损压缩。作者以字符串 "TOBEORNOTTOBEORTOBEORNOT" 为例，先解析 gzip 文件头尾结构，再根据 Deflate 规范逐位还原压缩块内容，实现了从 24 字节到 16 字节的压缩。感兴趣的同学可以阅读更多文章了解 ~

文章

🐢 Code along with the Foundation Models framework

@Cooper Chen：这篇文章介绍了 Apple 在 WWDC 2025 推出的 Foundation Models 框架，展示了如何在 iOS 与 macOS 应用中直接调用系统内置的大语言模型，实现真正的 on-device AI。通过一个“旅行行程生成器”的示例，作者带你一步步完成从文本生成到结构化输出的全过程，深入展示 Apple Intelligence 的开发潜力。

主要亮点包括：

• 隐私与安全：模型完全在设备上运行，无需上传数据或调用云端接口。
• 结构化输出：利用 @Generable 让模型直接生成 Swift 类型的数据，而非普通文本。
• 提示优化技巧：通过 instructions、示例（one-shot）提升输出质量与稳定性。
• 流式响应：实时展示生成过程，让用户体验更自然流畅。
• 工具调用（Tool Calling）：让模型能主动调用外部函数或服务，融合实时数据与智能生成。

这篇文章不仅是一份技术指南，更是 Apple 对 AI 未来方向的实践展示。
它强调 隐私优先、系统原生、开发高效 的理念，是每位希望深入了解 Apple Intelligence 的开发者必读之作。

🐎 Enabling enhanced security for your app

@Damien：这篇文章介绍了如何在 Xcode 中为应用启用增强安全性的方法，包括启用地址空间布局随机化（ASLR）、栈保护、堆保护、整数溢出检查和缓冲区溢出检查等编译器安全功能，以防御常见漏洞并提升应用抗攻击能力。

🐕 How to install Xcode 26's Metal Toolchain on CI/CD

@Barney：我来帮您获取并总结这篇文章的内容。这篇文章介绍了 Xcode 26 不再默认包含 Metal 工具链的问题及解决方案。在本地开发时可通过 Xcode 偏好设置安装，但在 CI/CD 环境（包括 Xcode Cloud）中需要使用 xcodebuild 命令行工具手动下载和安装。文章提供了具体的脚本代码，建议在 Xcode Cloud 中作为 post clone 脚本运行。

工具

swift-profile-recorder

@Smallfly：Swift Profile Recorder 是一款「进程内」采样分析器，专为受限容器环境而生：不需要 CAP_SYS_PTRACE，就能在 Linux 与 macOS 上抓取 on-CPU 与 off-CPU 样本，定位真实的性能瓶颈。你只需以 Swift 包集成并启用内置服务器，即可用一次 curl 拿到已符号化的 Linux perf 格式数据，直接拖到 Speedscope / Firefox Profiler 或用 FlameGraph 生成火焰图。集成轻量、开销可控，特别适合线上 Kubernetes/Docker 场景的故障排查与持续优化。

内推

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

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

文章

🐢 We Need to Talk About Observation

@Smallfly：这篇文章深度探讨了 Swift 观察机制的新旧范式更迭，从 ObservableObject + Combine 的旧时代到 @Observable 宏 + Observations 结构体的新生态，揭示了迁移过程中的关键挑战与设计考量。核心内容包括：

• 旧范式的价值：回顾 @Published + Combine 在对象间观察（如 UserCoordinator 与 SyncEngine）的简洁性——自动管理订阅生命周期、支持跨对象响应，为复杂业务逻辑提供低耦合解决方案。
• 新范式的突破与局限：分析 @Observable 宏在 SwiftUI 集成（属性访问优化、嵌套支持）的优势，同时指出 withObservationTracking（单次触发需递归调用）与 Observations 结构体（任务生命周期管理复杂）在非 UI 场景的不足——订阅取消需手动管理 Task、对象弱引用易出错。
• 迁移建议：强调选择方案时需超越 UI 层考量，关注业务逻辑中对象间观察的实际需求，避免因新特性的「表面简洁」忽略生命周期管理的潜在风险。

文章以开发者视角对比新旧机制的工程实践差异，为理解 Swift 观察体系演进提供了务实的参考。

🐕 Xcode Migrations: From Stone Age to AI Mastery

@Barney：这篇文章讲述了 Qonto 团队如何将 Xcode 升级从三周噩梦转变为一天自动化流程。
背景： 60+ iOS 工程师团队面临 Xcode 升级瘫痪开发流程的问题，依赖管理冲突和构建失败频发。
核心改进：

• 架构优化：移除 CocoaPods，统一使用 Swift Package Manager
• 自动化监控：Swift 构建的 Xcode Release Checker，CI 监控版本发布并 Slack 通知
• 沟通策略：建立迁移门户和可视化时间线，团队理解度从 33% 提升至 90%
• CLI 工具：Swift 自动化迁移流程，包括分支创建、构建清理、版本更新等
• AI 集成：构建 Swift MCP 工具和 Xcode Migrator AI 助手，提供 24/7 技术支持

⠀效果： 迁移时间从 21+ 天缩短至 5 天（75% 减少），60+ 工程师零工作中断。通过持续改进理念，将最大痛点转化为竞争优势，目标进一步缩短至 1 小时。

🐢 iOS Rendering Documentation

@Kyle-Ye: 这份文档深入剖析了 iOS 渲染系统的底层架构，详细阐述了从 UIView 到 CALayer、CAContext 再到 FBSScene 的完整渲染管道。文档特别解释了 Front Board Scene (FBS) 的工作机制以及 CAContext 的 contextID 如何用于跨进程 IPC 通信。内容涵盖了层级合成模型、场景管理、渲染同步、动画协调等核心概念，为理解 iOS 图形系统提供了前所未有的技术深度。对于需要进行系统级渲染研究、性能优化或底层拦截开发的高级 iOS 开发者来说，这是一份极其宝贵的参考资料。

🐎 Should you opt-in to Swift 6.2 ’ s Main Actor isolation?

@DylanYang：Xcode26 为工程带来了新的 actor 隔离默认配置值，允许全局的代码默认运行在 main actor 上。作者通过一些 demo 讲述了启动此配置后能帮助我们简化大量的标记 @mainactor 的代码，降低了并发代码的复杂度。同时作者建议大部分情况下可以默认开启此配置，并通过 @Concurrent 标记来让特定代码去后台线程运行。感兴趣的开发者可以阅读本文详细了解下开关带来的实际影响。

🐎 Flutter 官方 LLM 动态 UI 库 flutter_genui 发布，让 App UI 自己生成 UI

@Crazy：现今在开发者领域 AI 已经进入了日常开发的方方面面，AI 生成 UI 也是大模型落地的一个方面，Flutter 官方更是开发了一个可以利用大模型动态生成 UI 的库，该库用“受控、可组合、可回传状态”的运行时 UI 替代文本，显著提升 AI 交互质量，并且与主流 LLM 框架的顺滑对接。但是更新也更加频繁，UI 的更新消耗也是很大的。该库主要的五个概念分别为 :UiAgent、Widget Catalog、AiClient、GenUiManager、GenUiSurface。关于具体的生成，可以看文章中的实例与图片演示。文章中提到的 Filebase 与 Gemini，都是由 Google 开发的，对国内开发者都不是很友好。

内推

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

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

新闻

🌟 🐕 Swift 6.2 正式发布

@kemchenj：随着 Swift 语言本身走向成熟，每年的更新慢慢的已经不是集中在语言功能上，投入了更多的精力到工具链和生态建设上。

更加平易近人的 Concurrency

• 默认使用 @MainActor，减少显式的 isolation 标记
• 更加直观的 async 函数，默认在 caller 的上下文里执行，让 class 类型里可以用更简洁直观的方式去实现没有数据竞争的逻辑
• 新增 @concurrent 函数注解，把任务派发到全局任务池

前两个功能都是可以手动开启和关闭的，由于前面两个功能开启后，非 actor 环境下的 async 函数全部都会派发到 @MainActor 执行，导致主线程负载变大，所以新增 @concurrent 可以制定任务派发到全局线程。这几套组合拳下来大大加强了 Concurrency 的易用性。

安全的系统级编程功能

• InlineArray：固定大小的内联数组
• Span：可以理解为类型安全的 Buffer 类型
• 嵌入式 Swift：新增全套 String / InlineArray / Span API
• C++ 互操作：可以通过 header 标注混合使用两个语言里的 Span 的类型

工具链

• VSCode 插件更新
• 更加细化的编译警告控制
• 更快的 Macro 编译速度（通过下载预编译的 swift-syntax 包）
• 优化 async 调试功能的体验和稳定性

核心库更新

• Subprocess：一套全新的 Swift 原生进程接口
• Foundation：NotificationCenter 新增一套类型安全，拥抱 Concurrency 的接口
• Observation：提供更加易用的 async sequence 接口
• swift-testing：新增 API 提高测试代码的表达能力

更多详细信息请查看原文。

文章

🌟 🐢 KMP on iOS 深度工程化：模块化、并发编译与 98% 增量构建加速

@JonyFang: 本文主要介绍了 Bilibili KMP 在 iOS 工程化的一些深度改造，达成模块化、并发编译与 98% 增量构建加速的目标。主要通过对 Kotlin/Native 编译管线的深度拆解与重构，系统性地解决了其在模块化、编译并发和增量构建方面的核心瓶颈。

在构建系统与编译速度上 ：实现了 Parallel Compilation，将每个 Kotlin 模块独立编译为 .a 文件，在一些日常的底层修改的场景下最终产物编译耗时降低 98% 。这充分释放了 Bazel 的高并发优势，结合可靠的 remote cache 机制达到 Never clean build 的预期。

在编码与跨语言交互上：摆脱了 KMP 默认的“大一统”框架模式。通过为每个 Kotlin 模块生成独立的 Clang module ，并以 @ObjCExport 注解精确控制导出，实现了真正的模块化。

在调试与工程化上：通过修复 source-map 路径和实现可靠的 implementation_deps ，保证了跨语言调试的稳定性和构建的确定性，解决了社区方案中的常见痛点。

也推荐几篇前几期的相关阅读：

• 探讨跨平台技术与跨平台 UI 框架及 Kotlin Multiplatform 在 bilibili 的实践
• 工程化视角的 Kotlin Multiplatform 核心解读及优化
• B 站在 KMP 跨平台的业务实践之路

🐎 Automating Github Action Workflows For Swift

@Damien：作者重启搁置的 ActionBuilder 项目，通过扫描 Package.swift 实现零配置生成 GitHub Actions tests.yml，借 Swiftly 自动识别 Swift 版本并调度 Linux/macOS runner，对 iOS 等 Apple 平台则调用 Xcode 构建且已适配 Swift 6.0-6.2，未来将以轻量 CLI 取代插件，可直接嵌入 Xcode build phase 随编译自动更新工作流。

🐕 认知负荷才是关键

@zhangferry：编程领域有很多指导性的理论知识，但这些业界的实践，为什么并非总是有效呢？基于这个问题本文引出认知负荷这个概念：认知负荷是指开发者为了完成一项任务需要动多少脑子。从人的视角出发，以是否便于理解来衡量代码好坏，并给出了以下 4 个降低认知负荷的原则：

• 模块设计：不应一味的强调小方法，小模块，这会导致过多的接口和代码关联，增加认知负荷。深方法，深模块，一定程度把复杂度限定在特定范围，整体维护成本更低。

• 架构选择：不应为体现技术水平采用过于复杂的架构，易懂、易理解的架构才更合适。文中还建议在架构评审时可以让初级开发者参与，以识别过于复杂的设计。

• 抽象和代码组织：不应过于追求 DRY（不要重复自己），而大量使用设计模式，微服务等，少量的重复比不必要的依赖更好。

• 心智模型：传统推崇的心智模型（领域驱动设计 DDD）有其优势，但副作用是会引入很多主观理解，这个基础之上开发的代码往往会有更高的认知负荷。好的代码应该便于理解，而不是追求优雅和复杂。

延伸的几种观念，可能只看名称你就能知道个大概了：「可能是时候停止推荐《代码整洁之道》」、「小型函数的弊端」、「为什么我讨厌“框架”」、「设计牺牲」

🐢 阿权的开发经验小集

@阿权：阿权的日常开发小集，记录了日常开发中踩过的大小坑，内容主要涵盖 Git、iOS、Swift、Xcode 等方面问题的总结。按需搜索，说不定有意外的惊喜。

🐕 iOS26 Runtime Changes:Concurrent mutation of nonatomic properties

@ChengzhiHuang：对于 NSObject 的 property 是 nonatomic 的对象类型时，多线程的 set/get 会存在线程安全问题(非对象一样存在问题，只是不会崩溃)，一个简单的修改方案是改为 atomic，注意这个只对一般对象有效。如果是 NSMutableDictionary 等容器对象，还需要考虑对其容器内内容的修改也要注意线程安全，一般得加锁解决；更极端需要多个属性同时保持同步则也得加锁。问题不仅在 property 中存在，全局变量也一样存在问题。具体可以参考我们推荐过的 头条稳定性治理：ARC 环境中对 Objective-C 对象赋值的 Crash 隐患 。

在 iOS 26 以前，一般概率发生的崩溃崩溃的栈顶也在 objc_retain/objc_release 中；在 iOS 26 及之后，则如果发生这种线程安全问题，栈顶函数不变的情况下，会有明确的 EXC_BAD_ACCESS(KERN_INVALID_ADDRESS) 地址为 0x400000000000bad0 让这种情况更容易被辨识。

当然这也会带来一定的副作用，由于实现方式是通过 objc_storeStrong 方法中插入汇编，实现在调用 objc_retain 前，将 0x400000000000bad0 写入 x1 ，再正常调用 objc_retain 方法（正常 objc_retain 只接收一个参数，因此只需要 x0 即可）。因此原本偶现的问题，概率是会被放大的（以前即使有问题，但也有概率不崩溃），因此 iOS 26 的崩溃率对大部分应用来说会上升。稳定性同学要面临年末指标上涨的压力了，毕竟 iOS 26 的覆盖率会快速提升。

但从更长的视角来看，在 iOS 26 暴露了更多问题后，开发者修复后，后续的新版本对低 OS 的用户也带来体验的提升，所以总体我还是偏正常得看待这个 feature 的，等于苹果开启了对一类问题的线上 TSan ，并且对性能的影响微乎其微。短期的阵痛后带来的是更长期的体验提升。美中不足的就是如果这项 feature 能像 malloc 的一些开关(malloc stack logging 等)，能让开发者自主控制按一定比例开启就更好了，能有更多时间修复以及控制对升级到 iOS 26 用户的影响。

更具体的一些细节可以看链接。

🐕 How to disable Liquid Glass

@Cooper Chen：在 iOS 26 中，苹果推出了全新的 Liquid Glass 设计系统，为界面带来了更透明、流动的视觉体验。但如果你的 App 还没做好适配，用户可能会遇到界面错乱的问题。作者在文章中给出了一个简洁的解决方案：通过在 Info.plist 中新增键值 UIDesignRequiresCompatibility = YES，就能让应用暂时保持旧版设计，避免因 Liquid Glass 引发的兼容性 bug。不过要注意，这只是临时方案，苹果计划在 iOS 27 移除该选项。也就是说，开发者需要尽快着手适配 Liquid Glass，以确保用户体验的连贯性和未来的稳定性。对于想稳妥过渡到新系统的团队来说，这是一个既务实又必须关注的技巧。

设计

🐕 marioaguzman Design Guidelines layout marioaguzman Design Guidelines toolbar

@含笑饮砒霜：这两篇文章系统阐述了 macOS 应用在窗口布局和工具栏设计上的核心规范与实践原则：在窗口布局上，需要遵循中心均衡、对齐、留白和视觉平衡的原则，合理安排常规、小型和迷你控件的位置与间距，并通过空白、分隔线或分组框组织控件，确保界面简洁一致；在工具栏设计上，应基于用户的心智模型挑选并排序常用功能，合理区分全局与界面项，正确处理侧边栏和检查器的切换，注意标题、副标题、溢出优先级与居中项的使用，同时结合不同样式（统一、紧凑、扩展、偏好）以及底部栏、附加栏和系统内置特殊控件，实现美观、直观且高效的用户体验。

内推

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

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

What's Changed

• Close #5143 by @JonyFang in #5155
• fix #5136 by @BarneyZhaoooo in #5156

Full Changelog: #351...#352