akinIan’s Blog

WWDC26中的性能优化：Apple 到底优化了什么

Tue, 09 Jun 2026 00:00:00 GMT

一、这次 Apple 给出的几个性能结果二、App 启动最高快 30%：系统提前准备关键数据相机启动：App 启动优化最具体的样板三、首帧不是终点：还要看用户什么时候真正可用四、照片加载最高快 70%：让内容更快出现在用户面前五、AirDrop 最高快 80%、iPad 外置盘最高快 5 倍：传输速度也是体验六、CPU scheduler：让旧设备也更 responsive 七、网络切换：减少用户手动处理连接的次数八、交互流畅性：100ms、8.3ms、5ms 九、SwiftUI：让数据流更懒、更少重复十、官网里其他性能相关专题：语言、图像、GPU、资源与系统服务 Swift 和 Foundation：把性能控制权下放到代码层 Core Image RAW：把重计算搬到更合适的硬件和管线里 Metal 和游戏：用更低渲染成本换更稳定帧率 Core AI 和 Foundation Models：AI 功能也要看延迟、内存和首用成本 App Intents：系统入口越多，性能越要可扩展十一、给 App 开发者的启发

性能优化在发布会上通常不太抢镜，但它往往最影响日常体验。

WWDC26 里，Apple 把几个很常见的等待场景放在一起讲：点开 App、拍完照片、传文件、切换网络、滑动系统界面、在旧设备上跑更重的任务。它们看起来分散在系统不同角落，但对用户来说，感受其实很简单：是不是更快出现，是不是更少卡住，是不是更少需要自己处理。

所以这次这些性能更新，不太像传统意义上的“跑分提升”，更像是在系统的很多路径上一起减少摩擦：系统动画、App 启动、照片加载、AirDrop、iPad 文件传输、CPU scheduler、Wi-Fi 和蜂窝网络切换。背后共同指向一件事：

⚡

减少用户感知到的等待。

一、这次 Apple 给出的几个性能结果

在 WWDC26 Keynote 的 Platform improvements 段，Apple 先说今年花了很多时间优化 fundamentals，包括 memory usage、CPU utilization、networking operations、display rendering。随后给了几组非常具体的结果：

场景	提升	补充说明
App 启动（iPhone / iPad）	最高快 30%	第三方 App 同样适用；系统预加载关键数据
新拍照片进入图库	最高快 70%	缩短“产生内容 → 看到内容”的等待
AirDrop 传输	最高快 80%	—
iPad 浏览文件 / 外置盘传输	最高快 5 倍	体验接近 Mac Finder
系统动画	更顺	主屏滑动、Mission Control、Spaces 切换
CPU scheduler	进一步优化	覆盖到 iPhone 11 这类旧机型
Wi-Fi ↔ 蜂窝切换	更无缝	减少用户手动开关 Wi-Fi

这些优化不是同一类技术，但它们有一个共同目标：让用户觉得系统一直在跟手、内容一直在路上、操作不用等。

二、App 启动最高快 30%：系统提前准备关键数据

我最关注的还是 App 启动最高快 30%。原因很简单：Apple 明确说，这个提升也适用于第三方 App。

但这里要先把边界说清楚。Apple 在 keynote 里公开解释这个 30% 时，只说了一个核心原因：系统会在 App 打开前预加载 App 需要的关键数据，让 App 在用户点开时更 ready to go。Apple 没有在 keynote 里展开底层实现，所以不能把它直接写成“靠 dyld”“靠 prewarm”或者“靠 launch closure”。这些是理解启动链路的背景，不是 Apple 对 30% 的逐项拆解。

不过，把这句话放回 Apple 的启动文档里看，方向已经很清楚了：启动优化正在从“用户点图标之后再开始抢时间”，变成“系统尽量提前准备可预测的部分”。

UIKit 启动序列文档把 App launch 拆成一条流水线：main()、UIApplicationMain、willFinishLaunching、state restoration、didFinishLaunching、scene connection，最后才是 UI 出现在用户面前。文档还提到系统可能会 prewarm App：提前创建进程、加载链接库，但不运行 App 代码，然后把进程挂起，等真正需要时再继续标准启动序列。

这说明一件事：Apple 能优化的是启动链路里系统可以掌控、可以预测、可以提前准备的那部分。但首屏之前 App 自己到底做了多少事，仍然是开发者自己的责任。

如果一个 App 启动时同步初始化十几个 SDK，立刻打开数据库，读一堆配置文件，做全量 migration，恢复复杂页面状态，拉远端开关，解码首屏大图，再顺手把埋点、Push、IM、支付、直播、广告都启动一遍，那么系统帮你省下来的时间，很可能会被业务初始化重新吃掉。

Apple 的 Reducing your app's launch time 文档里有几个很直接的抓手。

第一，减少动态库和三方 framework。你的代码运行前，dyld 需要找到并加载可执行文件和依赖库，解析动态符号。Apple 明确说，每额外加载一个三方 framework 都会增加启动时间。虽然系统会用 launch closure 缓存很多工作，但 launch closure 的大小，以及加载后剩余工作，仍然和库的数量、大小有关。

第二，审计 main() 之前就运行的代码。C++ static constructors、Objective-C +load、__attribute__((constructor))、__DATA,__mod_init_func 都可能在 App 进入 main() 前执行。也就是说，有些启动耗时不是藏在 didFinishLaunching 里，而是藏在你还没进 main() 之前。

第三，别把 AppDelegate 当杂物间。Apple 文档说得很直白：willFinishLaunching 和 didFinishLaunching 在主线程同步执行，launch cycle 要等它们返回。任何昂贵任务都会拖慢启动。真正需要放在启动期的，应该只有首屏必要配置、必要依赖和入口路由；非首屏 SDK、完整用户画像、缓存清理、日志上传、推荐刷新，都应该尽量延后。

第四，首屏只取必要数据。Apple 文档举了一个照片图库例子：默认启动时只需要展示一屏缩略图占位，再在启动后填充真实缩略图；不需要一开始就加载完整大图。换句话说，首屏不是“把所有数据都准备好”，而是“把用户眼前这一屏准备到足够可用”。

相机启动：App 启动优化最具体的样板

这也是为什么我觉得相机启动应该放在 App 启动这部分一起看。Build a responsive camera app that launches quickly 这场 session，其实是 Apple 对“启动优化怎么做”的一次具体拆解。

相机 App 的用户感知非常极端。用户不是在等一个 App 打开，用户是在等取景画面出现。Apple 在 session 里明确说，让 camera launch 感觉快，最关键的是 preview frame 多快出现在屏幕上。换句话说，相机的 first useful frame 就是第一帧 preview。

Apple 把相机启动链路拆成几个阶段：App launch，配置 AVCaptureSession，start session，初始化 capture outputs，最后 preview 开始 streaming，frames 流到 App。这里面最贵的部分之一，就是 capture outputs 的初始化。因为 session 一旦 start，所有 output 对象都要初始化，而初始化成本会随着 output 数量和质量设置增加。

但对“第一帧 preview”来说，App 并不需要所有 output 都准备好。比如只是展示取景画面，通常只需要 AVCaptureVideoPreviewLayer 或一个用于 preview 的 output。AVCapturePhotoOutput、movie file output 这些和拍照、录像相关的 output，不一定需要在第一帧 preview 前完成初始化。

新的 deferred start API 就是围绕这个目标设计的：把不影响 launch 的 output initialization 延后到 preview started 之后。Apple 的建议很明确：defer all outputs except the output used to render preview。

实现上，开发者可以给不需要参与首帧 preview 的 output 设置 isDeferredStartEnabled = true。自动模式下，AVCaptureSession.automaticallyRunsDeferredStart = true，系统会在 preview 出现后选择合适时间运行 deferred start。App 还可以通过 AVCaptureSessionDeferredStartDelegate 接收 sessionWillRunDeferredStart 和 sessionDidRunDeferredStart，知道延迟初始化什么时候开始、什么时候结束。

如果 App 需要自己用 AVCaptureVideoDataOutput 渲染 preview，比如要做逐帧处理、滤镜、分析或自定义渲染，就不能完全依赖 automatic mode。session 里给出的做法是：先 disable 对这个 preview output 的 deferred start，等第一帧真正 present 后，再调用 runDeferredStartWhenNeeded()，让系统开始初始化那些被延后的 output。

这里还有一个很重要的选择：AVCaptureVideoPreviewLayer 和 AVCaptureVideoDataOutput 不是同一个成本模型。前者更适合只是展示 camera feed，Apple 说它针对低延迟 preview 做了优化，也能更自然地使用 automatic deferred start；后者给了 App per-frame access 和更多控制，但成本更高，也需要手动处理 deferred start 的时机。

这场 session 里 Apple 做了一个很直观的实验：不开 deferred start 时，示例相机启动接近 1 秒；开启 deferred start 后，launch cut in half。这个结果不是泛泛地说“少做点事会更快”，而是很具体地说明：把不影响第一帧的 output 初始化从启动路径里移出去，启动体验会立刻变化。

不过 Apple 也没有把话说得过满。它提醒说，preview 更快，不代表 first capture 一定更快。因为 photo output 被延后后，用户虽然更早看到了 preview，但首拍能力可能还没完全 ready。所以 session 里还建议配合 responsive capture，让用户即使在 photo output 尚未完全 ready 时，也能更快捕捉瞬间。

这就是我觉得普通 App 最应该借鉴的地方：启动优化不是把所有东西都做快，而是判断什么东西必须出现在第一帧前，什么东西可以在第一帧后补。相机的 preview frame，其实就是所有 App 的 first useful frame。

信息流 App 的 first useful frame，可能是本地缓存的前几条内容。电商 App 可能是首页框架和一屏可点的商品。剪辑 App 可能是项目缩略图和时间线骨架。办公 App 可能是最近文档列表，而不是等全文索引和云同步都完成。

相机场次后半段还补了一个重要视角：启动快只是第一步，持续稳定才是体验。Preview running 之后，steady framerate and cadence 仍然关键。Apple 建议用 hardwareCost 判断 capture session 配置是否超过设备能力，在 commit configuration 后确认成本在设备能力内；同时观察 systemPressureState，在压力上升时降级配置。高码率视频写入则可以使用 AVProVideoStorage，让 ProRes 这类 high data-rate codec 的写入性能更稳定。

这个部分和 App 启动 30% 放在一起看，逻辑会更完整：系统在尽量提前准备关键数据，而 App 自己也应该把“第一帧前必须完成的工作”压到最小，把非关键能力延后，把持续性能和恢复能力作为启动之后的第二阶段。

三、首帧不是终点：还要看用户什么时候真正可用

Xcode Organizer 和 MetricKit 的启动口径是 time to first draw，也就是用户点击图标，到静态 launch screen 之后第一帧绘制出来。但 Apple 文档也提醒，如果第一帧出来后 App 还在渲染文档、展示 loading、替换占位界面，用户仍然会把这段等待感知为启动时间。

所以 App 团队不应该只量 tap to first draw，还应该量 first draw to first useful。前者是系统和工具能统一统计的指标，后者才更接近用户体感。Apple 文档建议可以用 os_signpost 和 Points of Interest 记录这些额外启动活动，把“首屏可见”和“首屏可用”拆开看。

WWDC26 的 MetricKit session 也和这个方向一致。iOS 27 里 MetricKit 有新的 Swift-first MetricManager API，可以通过 AsyncStream 接收 MetricReport 和 DiagnosticReport。iOS 27 release notes 还提到，MetricKit 可以结合 StateReporting，让 metrics 和 diagnostics 带上开发者定义的业务状态。

这对启动优化很有用。不要只问“iOS 27 有没有让我的 App 快 30%”，而是要看真实用户的 p50、p90，按系统版本、设备型号、入口场景、业务状态拆开。比如默认首页、Push 入口、Deep Link 入口、恢复上次复杂页面，启动路径完全不同，混在一起看平均值没有太大意义。

四、照片加载最高快 70%：让内容更快出现在用户面前

Keynote 里另一个数字是，新拍照片进入图库最高快 70%。Apple 在这里举的场景很具体：过去拍完照片后，照片进入图库可能要等一下；现在新照片出现得更快。

这部分 Apple 没有在 keynote 里展开底层实现，所以不能擅自写成某个具体算法。但可以确定的是，Apple 优化的是一条非常典型的内容可见路径：用户刚刚产生了内容，系统要尽快让内容出现在下一处用户会查看的地方。

这对 App 开发者也很有启发。很多 App 的“慢”不是启动慢，而是内容到达界面慢：拍完、发完、保存完、导入完、同步完，用户下一秒就会去另一个页面找结果。如果这个结果没有及时出现，用户会怀疑刚才的操作是不是失败了。

对应到 App 设计里，应该尽量让关键内容先可见，再慢慢补齐非关键细节。例如先展示本地结果，再后台同步；先展示缩略图，再加载原图；先展示最新一条记录，再补全排序、索引、推荐和云端状态。用户不一定要求所有东西都瞬间完整，但会非常在意自己刚刚产生的东西有没有被系统接住。

SwiftUI 这次也有相关的小优化。WWDC26 SwiftUI guide 提到，AsyncImage 默认支持标准 HTTP caching，会尊重 server cache headers；需要更多控制时，可以传自定义 URLRequest，或者配置带自定义 URLCache 的 URLSession。这类改动不是很炫，但很实用：少重复加载，少重复等待，让内容更自然地复用缓存。

五、AirDrop 最高快 80%、iPad 外置盘最高快 5 倍：传输速度也是体验

Apple 还提到，AirDrop 传输最高快 80%；iPad 浏览文件、把文件传到外置盘最高快 5 倍，并接近 Mac Finder 的体验。

这两个点很容易被当成系统功能更新，但它们其实也是性能优化。因为文件传输是最典型的“用户无法假装没在等”的场景：文件没传完，用户就不能继续下一步。

Apple 没在 keynote 里公开 AirDrop 和 Files 的底层实现细节，所以这里不能乱猜。但对 App 开发者来说，可以借到同一套工程原则：

大文件导入导出尽量流式处理，不要整文件读进内存。

能分块就分块，减少一次性大对象复制。

文件保存和转码不要阻塞主线程。

长时间传输要有进度、取消和失败恢复。

能复用系统文件协调、URLSession、PhotoKit、AVFoundation，就不要自己造一套脆弱管线。

相机场次里讲到的 AVProVideoStorage 也是同一个方向。Apple 说它用于高码率视频的确定性文件写入，让 ProRes 这类高数据率场景的 write performance 更稳定。换句话说，性能不只是峰值速度，也包括持续稳定：不要一开始很快，后面突然卡住、掉帧、写盘抖动。

六、CPU scheduler：让旧设备也更 responsive

Keynote 里 Apple 单独讲了 CPU scheduler。它说 scheduler 是管理 CPU resources across workloads 的关键系统组件，目标是让正确的工作在正确的时间执行。今年 Apple 进一步优化了 scheduler，让它处理 performance-intensive workloads 时更高效，并把能力带到 iPhone 11 这类旧机型。

这部分对开发者的启发很直接：不要和 scheduler 对着干。

系统可以更聪明地调度 CPU，但 App 也要表达正确的意图。不要启动时无脑开一堆高优先级任务，不要把后台同步、日志刷盘、图片处理、数据库 compact、缓存清理都堆到用户刚打开 App 的时刻，也不要把这些任务都塞进 Main Actor。

Swift Concurrency 的 priority、cancellation、actor 隔离、后台 task 都应该认真设计。系统 scheduler 再聪明，也救不了一个把所有工作都标成“现在立刻必须做”的 App。

七、网络切换：减少用户手动处理连接的次数

Apple 还提到，iPhone 在蜂窝网络和 Wi-Fi 之间的切换会更无缝。Keynote 里举的例子很日常：路过熟悉的 Wi-Fi 热点、刚下飞机、设备还连着一个看似有信号但实际不好用的网络，用户过去可能会去 Control Center 手动关 Wi-Fi，强行切到蜂窝。

这也是性能体验的一部分。用户不关心网络状态机怎么工作，只关心“我现在点了，内容有没有继续加载”。如果连接切换卡住，用户感知到的不是网络问题，而是 App 或系统没反应。

对 App 开发者来说，系统网络切换更好是好事，但 App 自己也要尽量具备恢复能力：

网络请求要能重试，而不是一次失败就让用户重新操作。

上传下载要支持断点、后台和取消。

UI 上要区分“正在恢复连接”和“操作失败”。

不要把首屏完全绑定在一次实时网络请求上。

弱网和网络切换场景要纳入性能测试。

这和 App 启动是同一个问题：不要把用户卡在一个不可恢复的等待里。

八、交互流畅性：100ms、8.3ms、5ms

Apple 的 Improving app responsiveness 文档给了几个很有用的阈值：离散点击里的同步主线程工作，粗略目标是小于 100ms；120Hz 设备一帧约 8.3ms，60Hz 一帧约 16.7ms；如果主线程用于更新屏幕的工作少于约 5ms，通常更容易赶上下一帧。

场景	阈值	含义
离散点击后主线程同步工作	< 100ms	超过后手感开始变钝
120Hz 设备一帧	~8.3ms	多几毫秒就可能掉帧
60Hz 设备一帧	~16.7ms	—
主线程更新屏幕的预算	< ~5ms	更容易赶上下一帧

所以卡顿不一定是“慢很多”才算。滚动时多几毫秒，就可能错过一帧；点击后超过 100ms，手感就开始变钝。性能优化很多时候不是把 1 秒变成 0.5 秒，而是把 12ms 变成 5ms。

WWDC26 Instruments session 给了一个很实用的排查方法：先看 CPU saturation，再看采样数据，再看 execution contention，最后看 system blocking。Time Profiler 看 CPU，Top Functions 找最重函数，Swift Executors 看任务是不是挤在 Main Actor 上，System Trace 看低 CPU 时主线程是不是 blocked 在 I/O、锁或系统调用上。

这里有两个特别值得写进团队 checklist 的例子。

一个是缩略图渲染。session 里，多个 renderThumbnail task 看起来是异步任务，但实际继承了 Main Actor context，每个任务在 Main Actor 上跑几百毫秒，和关键 UI 更新抢执行权。加 @concurrent 后，任务从 Main Actor track 移到 global executor track，UI hang 消失，还能并行渲染。

也就是说，Swift Concurrency 不等于自动后台化。async 只是表达挂起点，不代表你的重活一定离开了 Main Actor。

另一个是文件保存。session 里保存文件时 UI 短暂卡住，但 CPU 不高。Time Profiler 看不出“忙”，System Trace 才能看到主线程 blocked，等待外部资源。把 file saving 移出主线程后，Main Actor 才被释放。

⚠️

这类问题最容易误判：低 CPU 不代表没有性能问题，可能只是主线程在等磁盘、等锁、等系统调用。

九、SwiftUI：让数据流更懒、更少重复

Apple 这次在 SwiftUI 里的几个性能更新，也和上面的方向一致。

WWDC26 SwiftUI guide 提到，AsyncImage 默认支持标准 HTTP caching，会尊重 server cache headers；需要更多控制时，可以传自定义 URLRequest，或者配置带自定义 URLCache 的 URLSession。@State 变成 macro 后，class 存储在 @State 里会 lazy initialization，并且每个 View lifetime 只创建一次。

SwiftUI 新的 Document API 也支持 asynchronous、incremental disk operations，并通过 Foundation Subprogress API 报告进度。这对大文档读写很重要：不要每次都全量、同步、阻塞式处理，而是尽量增量、后台、可进度化。

SwiftUI 性能文档还提醒，View body 必须快速计算，因为系统需要在下一帧渲染前完成 View update。Instruments 的 SwiftUI template 会标出 Long View Body Updates，超过 500 microseconds 标橙，超过 1000 microseconds 标红。常见问题不是某个函数慢得离谱，而是一个看起来便宜的 body 被计算了太多次，或者在 body、onAppear、gesture onChanged 里做了复杂工作。

这些改动的共同点是减少不必要工作：少重复加载，少重复分配，少在 UI 出来前抢资源。

十、官网里其他性能相关专题：语言、图像、GPU、资源与系统服务

除了 keynote 里的启动、照片、AirDrop、外置盘这些结果，WWDC26 官网还有一批更工程向的性能内容。它们不一定都给了一个“提升多少百分比”的数字，但能看出 Apple 这次性能优化的覆盖面：不是只优化系统启动路径，而是从语言、框架、媒体管线、GPU、资源下载和工具链一起往前推。

Apple 甚至专门安排了 Power and Performance Group Lab，介绍里说可以和 Apple 工程师、设计师深入讨论 WWDC26，并 follow up 这一周最大的 power and performance announcements。这个 lab 页面本身没有展开技术细节，所以我不把它当成某个具体优化的证据；但它说明，性能和功耗并不是这次发布里零散出现的附属话题，而是一个被单独组织起来的主题。

Swift 和 Foundation：把性能控制权下放到代码层

What’s new in Swift 里有一段专门讲 Performance Tuning。这里的重点不是“Swift 自动更快了”这么简单，而是 Apple 在给性能敏感代码更多可控性。

session 提到的 optimizer control 包括 @inline(always) 和 @specialized。这两个工具并不是让业务代码到处加标记，而是给库作者、框架作者、性能敏感路径一个更明确的方式：当你知道某个泛型函数、热路径函数在真实场景里会被频繁调用，就可以更主动地影响编译器优化策略。

同一个 session 还把 Swift 的 ownership system、noncopyable types、borrow/mutate accessors 放在性能语境下介绍。它们背后的方向很清楚：减少不必要的 copy，让 API 能更准确表达“这里是借用”“这里会修改”“这里不应该复制”。对 App 开发者来说，这类能力短期内可能更多出现在底层组件、媒体处理、数据结构和 SDK 里，但它会慢慢改变 Swift 写高性能代码的边界。

Swift 标准库也新增了 UniqueBox、UniqueArray、Ref、MutableRef 这些类型。它们适合表达唯一所有权、引用语义和可变引用这类更底层的性能需求。Foundation 侧则提到 Data、NSURL、CFURL 有性能改进。也就是说，性能优化并不只发生在 UIKit、SwiftUI 这种 UI 框架里，语言和基础库本身也在减少内存、复制和桥接成本。

还有一个很有意思的点：Swift 的 WebAssembly / JavascriptKit 改进里，Apple 提到 Swift 和 JavaScript 之间的 safe bridging 最高可以快 40 倍。这个数字不直接服务大多数原生 App，但它很能说明 Apple 的性能方向：跨语言、跨运行时、跨边界的成本，也在被当成正式问题处理。

Core Image RAW：把重计算搬到更合适的硬件和管线里

Core Image RAW processing 是另一条很典型的性能线索。RAW 9 使用 Core ML model 来改进 demosaic 和 denoise，并且可以利用 Apple Neural Engine。这里的重点不是“AI 修图更强”，而是图像管线正在把一部分昂贵计算交给更适合的硬件。

这场 session 还把交互编辑和导出分开讲，细节很值得 App 开发者借鉴。交互编辑时，用户拖动滑杆、调曝光、调色温，需要的是低延迟反馈，不一定每一帧都全分辨率、最高质量。Apple 提到可以用 scaleFactor 以屏幕分辨率反复渲染 RAW，用 cacheIntermediates 缓存中间结果，用 Extended Virtual Addressing entitlement 支撑更大的地址空间，还可以渲染到 Metal-backed MTKView。

但导出是另一个目标：用户要最终质量和稳定输出，不是每次拖动时的即时反馈。所以导出时，策略会变成关闭 cacheIntermediates、调 memoryLimit、使用 heifRepresentation / jpegRepresentation 这类 API 生成结果。它提醒我们一个很重要的原则：同一个功能，在“交互预览”和“最终输出”里应该有不同的性能策略。

Core Image 还在 CIImageProcessor 里提供了更明确的 tile size 和 temporary buffer 能力。换成人话就是：当处理大图、复杂滤镜或自定义图像算子时，不要假设系统一定能神奇地一次性吞下所有工作。把图像拆成合适的块、控制临时内存、控制中间结果，往往比单纯追求某个滤镜函数更快更重要。

Metal 和游戏：用更低渲染成本换更稳定帧率

WWDC26 Metal guide 和 WWDC26 Games guide 里，性能主题更集中在 GPU、游戏和工具链。

MetalFX temporal upscaler 是一个很典型的例子。官网说它可以从更低的渲染分辨率重建细节，从而在更高画质设置下保持流畅帧率。对游戏和实时 3D 来说，这个思路非常直接：不要每一帧都用最高成本硬算全部像素，而是用时间信息、运动向量和上采样把感知质量补回来。

Metal guide 还提到，可以处理 subrectangles 来支持 dynamic resolution，传入 motion vectors 来节省预处理时间，并用 distortion fields 处理后处理效果。这些细节背后其实是同一个目标：让 GPU 工作量更贴近屏幕真正需要的内容，而不是一刀切地渲染、处理、再丢弃。

在机器学习和图形交叉的地方，Metal 也补了量化 tensor formats 和 scale factors，Metal Performance Primitives 可以压缩 weights，并在 M5 Pro / M5 Max 上使用 Neural Accelerators。这类优化对普通 App 可能不是每天都会碰到，但对本地模型、实时图像、视频和创作工具很关键：模型不是只看参数效果，也要看内存带宽、权重大小和专用硬件利用率。

Games guide 还有两个对 App 开发者很实用的点。一个是 MetricKit 现在可以在报告里包含 Metal frame rate information，用来定位和修复游戏性能问题。也就是说，Apple 在把“帧率”这种过去更依赖自建埋点或开发期工具的指标，往系统级诊断里放。

另一个是 Managed Background Assets。官网举的场景是语言包这类 essential assets 可以在第一次打开前下载，非必要资源继续在后台下载，从而减少 title screen 上的等待。这个方向和 App 启动优化非常像：把真正必须的东西提前准备，把不必阻塞首屏的东西挪到后台。

Core AI 和 Foundation Models：AI 功能也要看延迟、内存和首用成本

WWDC26 官网还有一组和 AI 性能直接相关的内容。Meet Core AI 把 Core AI 定位成设备端 AI 模型部署框架，覆盖模型转换、App 集成、性能优化、模型 specialization 等完整流程，并强调它会利用 Apple Silicon 上的 CPU、GPU、ANE。这个信息很关键：当越来越多 App 把模型放到本地跑，性能问题就不只是“推理快不快”，还包括模型第一次加载要多久、内存占多少、是否需要提前编译、能不能命中缓存。

官网里 Integrate on-device AI models into your app using Core AI 的摘要更直接：它提到可以下载、运行、benchmark 针对 Apple silicon 优化的模型，也会讲 model compilation、on-device specialization，用来 speed up first-time model load，并用 Xcode 里的 Core AI tools profile and optimize runtime performance。换成 App 体验语言，就是 AI 功能也有自己的“启动优化”：第一次点开某个 AI 能力时，不应该把模型准备、specialization、缓存未命中、UI 等待全部堆到用户面前。

Dive into Core AI model authoring and optimization 则把问题推进到模型作者和底层优化：custom Metal kernels、platform-aware compression、Core AI Debugger、optimized on-device execution。这里的方向和 Metal tensor、量化、MPS 权重压缩是连在一起的：模型质量之外，还要看模型在真实设备上的内存带宽、权重体积、硬件映射和调试可见性。

另外，Debug and profile agentic app experiences with Instruments 也值得放进性能视角里。它介绍 Xcode 里的 FoundationModels instrument，可以 inspect prompts、analyze latency、trace control flow，尤其是多个 LanguageModelSession 和 profiles 组合起来的 agentic flows。对 App 开发者来说，这意味着 AI 交互不能只看“最终答出来没有”，还要看每一步延迟来自哪里：prompt 构造、模型调用、工具调用、会话切换，还是控制流本身。

所以，AI 相关性能其实延续了前面所有原则：能提前准备的提前准备，能缓存的缓存，能分阶段的分阶段；不要把模型加载、specialization、网络请求、工具调用和 UI 阻塞揉成一个黑盒。

App Intents：系统入口越多，性能越要可扩展

App Intents session 里也有性能相关内容。官网摘要提到 EntityCollection improves performance，SyncableEntity 用来跨设备扩展实体同步，long-running intents 需要能处理取消。

这块不如启动、相机、Metal 那么显眼，但很有现实意义。现在 App 的入口不只是点图标：Spotlight、Siri、Shortcuts、系统搜索、智能体式交互都可能触发 App 的能力。如果每个入口都要临时查库、拉网、初始化一堆对象，系统入口越多，性能问题就越容易扩散。App Intents 的性能优化本质上是在提醒开发者：实体查询、同步、取消和长任务，也要按系统级入口的规模去设计。

把这些官网内容合起来看，WWDC26 的性能主题其实更完整：启动速度是最容易被感知的入口，交互流畅性是用户每天都在感受的底线，传输和网络是跨设备体验的基础，而 Swift、Core Image、Metal、Core AI、Foundation Models、App Intents 这些专题，则是在告诉开发者性能优化应该落到每一层。

十一、给 App 开发者的启发

如果把 WWDC26 这些性能点放在一起，我觉得 Apple 传递的不是“跑分更高”，而是一种更具体的体验目标：

🎯

用户不应该感知到系统在准备。

App 启动时，关键数据最好已经在路上。照片拍完后，图库应该尽快可见。传文件时，吞吐应该稳定。网络切换时，连接不应该让用户操心。交互发生时，主线程应该空出来响应用户。旧设备上，调度也应该尽量把有限资源用在刀刃上。图像、模型、资源下载、GPU 渲染和系统入口，也都应该有对应的性能策略，而不是等用户卡住之后再补救。

对 App 开发者来说，WWDC26 的启发其实很直接：

不要把启动当成一个函数优化，要把它当成一条用户路径优化。

不要把首帧当终点，要把“可用”当终点。

不要只问“App 为什么慢”，先判断瓶颈属于启动、内容加载、I/O、网络、渲染、模型、系统入口还是工具链。

不要只看平均值，要看 p90、老设备、弱网、网络切换和入口场景。

不要把所有初始化都塞进启动期，要分清必须、可延迟、可缓存、可取消。

不要让主线程承担业务洁癖，很多工作可以晚一点、轻一点、后台一点。

不要把 async 当成自动性能优化，要确认任务是不是真的离开了 Main Actor。

不要只优化峰值速度，也要优化持续稳定性、恢复能力和失败体验。

不要把预览和导出、首屏和后台、关键资源和非关键资源混成同一套策略。

🚪

Apple 这次帮系统把路铺得更早了。但每个 App 还要自己决定：用户点开你的那一秒，你是先把门打开，还是先在门口整理仓库。

MCP：Make AI Great Again！

Wed, 02 Apr 2025 00:00:00 GMT

MCP使用分享：Make AI Great Again！

一、前言+什么是MCP？

MCP是什么？

二、如何使用MCP？

1. 选取MCP Client

在这里我选用 VSCode + Cline 作为MCP客户端。安装方法很简单，只需要在VSCode的插件市场中搜索并安装Cline，并且逐步完成注册、配置即可。

我的Cline模型配置(这里我选择了一个免费的DeepSeek版本)

2. 通过MCP进行信息检索

点击Cline的MCP服务器市场，并搜索安装 Github

安装Github的MCP服务器

这里的安装过程也很有趣，点击安装后会自动拉起一个AI聊天窗口，一步一步地问我是否要执行命令来安装，颇有一种 “请了一个AI助手，根据我的命令干活” 的感觉。

这里的两张图片里，AI一步一步的引导我绑定自己的github账号

在我允许“助手”访问我的Github账户（给了他Token）后，助手主动的帮我生成了我的mcp配置。

没错，连 mcp配置这一步都帮我完成了！完全不需要我自己处理

对于Github MCP工具的使用，也很有想象力

自动帮我在Github检索符合我要求的仓库

自动帮我clone指定的仓库，并打开项目，进行修改自动clone并打开项目：

自动修改代码并commit+push：

而创建仓库、分支、分析commit、更新issue、提MR等一系列功能，这个MCP组件也同样支持AI的自动调用！

而添加了file system插件之后，更惊喜的一幕出现了，我让他在本地的一个文件夹中帮我找一下tcprelay的脚本位置，他发现没有找到后，首先把搜索范围扩展到了整个电脑，在电脑中没有找到后更是直接在brew中帮我检索到了usbmuxd然后帮我下载...

3. MCP真正接管浏览器！

项目地址：https://github.com/AgentDeskAI/browser-tools-mcp?tab=readme-ov-file

完成了浏览器插件的安装与MCP插件的安装后，我打开了Keep热力图的页面，并且让MCP简单的帮我分析一下当前页面的网络请求：

下一步我尝试选中了热力图的展示与列表区，让MCP帮我分析一下当前选中的内容

随后我还让他帮我分析了视图遮挡页面的网络日志，帮我总结了一份视图遮挡的报告，并且也可以辅助分析网页的网络攻击风险：

当然，除此之外还有很多其他的用法：如直接操控电子设备、接入SQL数据库等更富有想象力的用法还有待探索！

设想一下可以通过与AI Agent的一句话，让他直接去数据库中分析今天的稳定性/用户体验报告，或者给给Agent描述一个看板，而它直接完成前后端与数据任务的开发与部署，给出看板链接...

三、快捷的DIY MCP！

接下来来创建一个最简单的MCP Server！功能是获取桌面的文件列表

然后创建一个Python文件：MyMCPServer.py

并且在MCP的配置中添加如下配置，就可以使用MCP了！

在四、中会提到使用腾讯云开发MCP

四、更多可能性...

现在，许多大厂也开始进行了MCP相关的布局：

支付宝MCP：自动计算报价并管理、自动处理支付、售后等https://www.npmjs.com/package/@alipay/mcp-server-alipay?activeTab=readme

腾讯云 + MCP：快速构建小程序、Web/H5、云函数、数据库等应用https://tcb.cloud.tencent.com/

在腾讯云中，支持DIY MCP服务并托管在腾讯云上
也支持把这些MCP功能赋予给腾讯云Agent
并且支持通过Agent或者本地MCP Host的方式调用，也支持通过SDK把MCP的能力赋予到小程序或Web中。

附录、几个有趣的链接

MCP工具库：https://smithery.ai/

MCP国内工具库：https://www.modelscope.cn/mcp

AI工具坟墓：https://dang.ai/ai-graveyard

KMCP：自动写Team（来自天昊） https://npm.corp.kuaishou.com/-/web/detail/@ks-kmcp/team-operator/v/1.0.2/

Android火焰图里常见的Slice，他们都是什么？

Sun, 23 Nov 2025 00:00:00 GMT

🔥

火焰图是什么？

虽然这篇文章只是准备介绍一些常见的Slice，帮助初学者更好的理解火焰图，但是我认为还是有必要在这里简单介绍一下火焰图：

火焰图（Flame Chart）是一种性能分析可视化工具。它以时间为横轴，调用栈深度为纵轴，用不同颜色的矩形块展示程序运行时各方法的执行时间和调用关系。

火焰图的主要特点：

横轴代表时间——从左到右显示程序执行的时间线

纵轴代表调用栈深度——越往上调用层级越深

矩形块的宽度——表示方法执行的耗时

颜色区分——不同颜色代表不同的线程、进程或方法类型

开发者可以通过火焰图快速识别性能瓶颈，找出最耗时的方法调用，进行针对性优化。

Perfetto 示例：

Perfetto 是 Google 开发的性能分析工具，可以生成详细的火焰图。你可以访问以下示例查看实际效果：Perfetto UI - 示例火焰图

打开火焰图后，你可以看到如下的样式

下边我们来分别介绍一下火焰图视角，双端的App常规运行过程以及常见Slice含义：

一、火焰图的基本视角

在分析性能问题时，火焰图提供了多个观察维度：

时间轴视角：横向查看程序执行的完整时间线，识别哪些时间段最耗时

调用栈视角：纵向查看方法调用的层级关系，找出深层调用链

线程视角：区分不同线程的工作负载，识别主线程卡顿或后台线程竞争

热点视角：通过矩形块宽度快速定位最耗时的方法或系统调用

二、Android App 常规运行过程与常见 Slice

🔥

从火焰图的视角来看，一个 Android App 的典型运行过程可以分为以下几个阶段：

🔷 阶段 1：应用启动与初始化

当用户点击应用图标时，系统首先会通过 zygote 进程 fork 出新的应用进程。在火焰图中，你会看到：

bindApplication - 应用进程与 ActivityManagerService 建立连接

makeApplication - Application 对象的创建和初始化

activityStart → activityResume - 首个 Activity 的启动流程

这个阶段会有大量的 Binder 通信（binderTransaction），因为应用需要与系统服务频繁交互。

🔷 阶段 2：UI 渲染准备

Activity 进入 Resume 状态后，开始准备渲染 UI。火焰图中会出现：

inflate - 解析 XML 布局文件

performTraversals - 开始 View 树的遍历

measure → layout → draw - View 的测量、布局、绘制三大流程

VSync - 等待垂直同步信号

🔷 阶段 3：帧渲染循环（主线程 + RenderThread）

应用进入稳定运行状态后，每一帧的渲染都会在火焰图中呈现为一个完整的周期：

主线程（UI Thread）：

Choreographer#doFrame - 帧渲染的核心入口，理想情况下每 16.6ms 触发一次（60fps）

deliverInputEvent / dispatchInput - 处理用户触摸事件

animation / animator - 执行动画

performTraversals - 再次遍历 View 树，更新需要重绘的部分

RenderThread（渲染线程）：

RenderThread#doFrame - RenderThread 接管渲染任务

drawFrame - 构建绘制命令

issueDrawCommands - 向 GPU 发送绘制指令

eglSwapBuffers - 交换前后缓冲区，将内容显示到屏幕

GPU Completion - 等待 GPU 完成渲染

在这个过程中，主线程和 RenderThread 是并行工作的。你会在火焰图中看到它们在不同的轨道上同时执行。

🔷 阶段 4：列表滚动（RecyclerView 场景）

当用户滑动列表时，火焰图会显示密集的渲染活动：

RecyclerView#onBindViewHolder - 频繁出现，绑定数据到可见的 item

RecyclerView#layoutChildren - 重新布局子 View

GapWorker - 后台预加载即将显示的 item

Choreographer#doFrame - 持续的帧渲染

如果滑动不流畅，你会看到某些帧的 doFrame 超过 16.6ms，这就是丢帧。

🔷 阶段 5：后台任务与 I/O 操作

应用运行过程中，后台线程会处理各种任务。在火焰图的其他线程轨道上，你会看到：

ThreadPoolExecutor - 线程池执行的任务

Dispatchers.IO - Kotlin 协程的 I/O 操作

sqlite / sqliteQuery - 数据库查询

read / write - 文件 I/O

binderTransaction - 与系统服务的跨进程通信

⚠️ 警告信号：如果这些操作出现在主线程轨道上，说明存在严重的性能问题！

🔷 阶段 6：垃圾回收（GC）

火焰图中会周期性出现 GC 相关的 Slice：

Background concurrent copying GC - 后台并发 GC，对性能影响较小

Pause Young / Pause Old - STW（Stop-The-World）类型的 GC，会暂停应用执行

如果 GC 过于频繁或暂停时间过长，说明存在内存抖动或内存泄漏。

🔷 阶段 7：系统服务的协同工作

在火焰图的系统进程轨道上，你会看到：

SurfaceFlinger - 负责屏幕合成，将所有应用的 Surface 合成到屏幕上

ActivityManager - 管理 Activity 生命周期

WindowManager - 管理窗口显示

这些系统服务通过 binderTransaction 与应用进程通信，协调整个系统的运行。

📊 如何读懂这个流程

在 Perfetto 或其他火焰图工具中：

横向看时间线：从左到右观察应用启动 → UI 渲染 → 用户交互 → 后台任务的完整流程

纵向看调用栈：点击某个 Slice，查看它的父子调用关系

跨轨道看协作：主线程、RenderThread、后台线程、系统服务如何配合工作

关注宽度异常的 Slice：它们就是性能瓶颈

下面我们详细介绍各个阶段中常见 Slice 的具体含义：

🟦 1. 页面启动（Activity 启动）

这个阶段涵盖了从用户点击图标到页面完全可交互的整个过程。

关键 Slice：

activityStart - Activity 启动的开始标记

activityResume - Activity 进入前台可见状态

activityPause - Activity 失去焦点

activityIdle - Activity 完成所有初始化，进入空闲状态

bindApplication - 应用进程绑定到 ActivityManagerService

makeApplication - Application 对象创建

inflate - XML 布局文件解析和 View 对象创建

launchingActivity - 系统层面的 Activity 启动流程

RelayoutWindow - 窗口重新布局

项目中的自定义埋点：

K_onCreate_I - onCreate 生命周期埋点

K_onStart_I - onStart 生命周期埋点

K_onResume_I - onResume 生命周期埋点

K_finishApm_I:ApmTracker - APM 性能监控完成标记

性能优化关注点：

如果 inflate 耗时过长，考虑使用异步 inflate 或减少布局层级；如果 bindApplication 到 activityResume 之间时间过长，检查 Application 初始化和 onCreate 中的同步操作。

🟦 2. UI 渲染（主线程 + RenderThread）

Android 的 UI 渲染分为主线程的测量/布局/绘制和 RenderThread 的 GPU 渲染两个阶段。

主线程渲染 Slice：

Choreographer#doFrame - 帧渲染的核心入口，每 16.6ms（60fps）触发一次

performTraversals - View 树的遍历，包含 measure、layout、draw 三大流程

executeTraversal - 执行遍历的实际操作

ViewRootImpl#performTraversals - ViewRootImpl 层面的遍历

deliverInputEvent - 输入事件分发

InputDispatcher - 系统输入事件调度

dispatchInput - 输入事件派发到具体 View

RenderThread 渲染 Slice：

RenderThread#doFrame - RenderThread 的帧处理

drawFrame - 绘制一帧

flushLayers - 刷新图层到 GPU

issueDrawCommands - 发送绘制命令到 GPU

eglSwapBuffers - 交换前后缓冲区，显示到屏幕

GPU Completion - GPU 完成渲染

动画相关：

animation - 动画执行

animator - Animator 动画

updateViewHierarchy - 更新 View 层级

View#draw - View 的绘制方法

性能优化关注点：

如果 Choreographer#doFrame 超过 16ms，说明丢帧；如果 performTraversals 耗时长，检查 measure/layout 复杂度；如果 eglSwapBuffers 等待时间长，说明 GPU 过载或过度绘制。

🟦 3. View 测量和布局

这是 UI 渲染流程中的前两个阶段，决定了每个 View 的大小和位置。

关键 Slice：

measure - 测量阶段总体标记

onMeasure - 每个 View 的测量方法

performMeasure - 执行测量流程

layout - 布局阶段总体标记

onLayout - 每个 ViewGroup 的布局方法

performLayout - 执行布局流程

requestLayout - 请求重新布局

性能优化关注点：

频繁的 requestLayout 会导致重复测量和布局；嵌套过深的 ViewGroup（如多层 LinearLayout）会导致多次 measure；使用 ConstraintLayout 可以减少布局层级。

🟦 4. RecyclerView / ListView

列表是 App 中最常见的 UI 组件，其性能直接影响用户体验。

关键 Slice：

RecyclerView#onBindViewHolder - 绑定数据到 ViewHolder

RecyclerView#onCreateViewHolder - 创建新的 ViewHolder

RecyclerView#layoutChildren - 布局子 View

recycler#bind - 回收池绑定操作

recycler#prefetch - 预取机制，提前创建/绑定即将显示的 item

GapWorker - RecyclerView 的后台预加载工作线程

性能优化关注点：

如果 onBindViewHolder 耗时长，避免在其中进行复杂计算或 I/O 操作；如果 onCreateViewHolder 频繁出现，检查 RecycledViewPool 配置；启用 setItemViewCacheSize 和预取机制可以改善滑动流畅度。

🟦 5. I/O 与 Binder 通信

I/O 操作和跨进程通信是常见的性能瓶颈。

Binder 相关 Slice：

binderTransaction - Binder 事务

binderCallback - Binder 回调

transact - Binder 调用

I/O 相关 Slice：

read - 文件读取

write - 文件写入

FileSystem#read - 文件系统读操作

FileSystem#open - 打开文件

sqlite - SQLite 数据库操作

sqliteQuery - SQL 查询

cursorWindow - Cursor 数据窗口操作

系统调用：

epoll_wait - 等待 I/O 事件

futex - 线程同步原语

性能优化关注点：

主线程中出现 read、write、sqlite 说明存在主线程 I/O，应移到后台线程；频繁的 binderTransaction 可能导致跨进程通信开销过大。

🟦 6. 线程池与协程

Android 中的并发编程工具。

关键 Slice：

ForkJoinPool - Fork/Join 框架

ThreadPoolExecutor - 线程池执行器

AsyncTask - 异步任务（已废弃）

HandlerThread - 带 Looper 的后台线程

Looper - 消息循环

JobScheduler - 系统任务调度

WorkManager - 后台任务管理

Dispatchers.IO - Kotlin 协程 IO 调度器

Dispatchers.Default - Kotlin 协程默认调度器

性能优化关注点：

合理配置线程池大小，避免线程数过多导致上下文切换；使用协程可以减少线程创建开销。

🟦 7. GC（垃圾回收）

GC 会暂停应用执行，是卡顿的常见原因。

关键 Slice：

Background concurrent copying GC - 后台并发复制 GC

Concurrent mark sweep - 并发标记清除

Concurrent mark - 并发标记阶段

Concurrent sweep - 并发清除阶段

Pause Young - 年轻代 GC 暂停

Pause Old - 老年代 GC 暂停

HeapTrim - 堆内存整理

TrimHeap - 堆内存裁剪

项目中的自定义标记：

G_onTrimMemory - 内存裁剪回调

GC_YoungGeneration - 年轻代 GC

GC_Concurrent - 并发 GC

性能优化关注点：

频繁的 GC 说明内存抖动，检查是否有大量临时对象创建；Pause 类型的 GC 会导致明显卡顿。

🟦 8. 系统服务

Android 系统服务的调用。

关键 Slice：

SurfaceFlinger - 屏幕合成服务

HWUI - 硬件加速 UI 渲染

VSync - 垂直同步信号

performSurfaceTransaction - Surface 事务

WindowManager - 窗口管理服务

ActivityManager - Activity 管理服务

PackageManager - 包管理服务

zygote64 - 应用进程孵化器

dex2oat - DEX 到 OAT 编译

dexopt - DEX 优化

性能优化关注点：

首次安装或系统升级后的 dex2oat 会导致应用启动变慢；频繁的 WindowManager 调用可能影响 UI 响应。

三、iOS App 常规运行过程与常见 Slice

🟦 1. 页面启动与生命周期

iOS 的页面生命周期与 Android 类似，但使用不同的方法名。

关键 Slice：

-[UIApplication _run] - UIApplication 运行循环

-[UIViewController viewDidLoad] - 视图加载完成

-[UIViewController viewWillAppear] - 视图即将出现

-[UIViewController viewDidAppear] - 视图已经出现

-[UIViewController viewWillDisappear] - 视图即将消失

applicationDidFinishLaunching - 应用启动完成

applicationWillEnterForeground - 应用即将进入前台

loadView - 加载视图

performLayout - 执行布局

项目中的自定义埋点：

PageStart - 页面启动

PageAppear - 页面出现

LoadView - 视图加载

性能优化关注点：

避免在 viewDidLoad 中执行耗时操作；将重量级初始化延迟到 viewDidAppear 之后。

🟦 2. Runloop（主线程事件循环）

Runloop 是 iOS 主线程的核心机制，卡顿分析的关键。

关键 Slice：

kCFRunLoopBeforeTimers - 即将处理 Timer

kCFRunLoopBeforeSources - 即将处理 Source

kCFRunLoopBeforeWaiting - 即将进入休眠

kCFRunLoopAfterWaiting - 刚从休眠中唤醒

kCFRunLoopExit - 退出 Runloop

dispatch_main - 主队列任务

dispatch_async - 异步任务分发

mach_msg - Mach 消息传递

性能优化关注点：

如果 kCFRunLoopBeforeSources 到 kCFRunLoopBeforeWaiting 之间时间过长，说明主线程有耗时操作；监控 Runloop 状态可以实现卡顿检测。

🟦 3. Core Animation 渲染

iOS 的渲染框架，负责所有动画和屏幕更新。

关键 Slice：

CA::Transaction::commit - Core Animation 事务提交

CA::Render::Frame - 渲染一帧

CA::Display::DisplayLink - 显示链接（类似 Android 的 Choreographer）

prepareCommit - 准备提交

commit - 提交渲染

render - 渲染操作

layoutSubviews - 布局子视图

drawRect: - 自定义绘制

UIRenderingServer - UI 渲染服务

常见卡顿点：

CA::Transaction::commit - CPU 到 GPU 的数据传输和同步

presentation update - 呈现更新

CA::Render::Server - 渲染服务器处理

性能优化关注点：

如果 CA::Transaction::commit 耗时长，检查 layer 数量和复杂度；避免在 drawRect: 中进行复杂绘制；使用 shouldRasterize 可以缓存复杂 layer。

🟦 4. AutoLayout / SwiftUI

iOS 的布局系统。

AutoLayout Slice：

-[UIView _layoutSubviews] - 布局子视图

AutoLayout - 自动布局计算

layoutEngine - 布局引擎

SwiftUI Slice：

SwiftUI.Update - SwiftUI 更新

SwiftUI.Render - SwiftUI 渲染

SwiftUI.Body - SwiftUI body 计算

性能优化关注点：

复杂的 AutoLayout 约束会导致计算耗时；减少约束数量或使用 frame 布局可以提升性能；SwiftUI 的 body 应尽量轻量。

🟦 5. TableView / CollectionView

iOS 的列表组件。

关键 Slice：

cellForRowAtIndexPath: - 获取 cell

heightForRowAtIndexPath: - 计算行高

willDisplayCell: - cell 即将显示

layoutSubviews - cell 布局子视图

reloadData - 重新加载数据

performBatchUpdates - 批量更新

性能优化关注点：

缓存 cell 高度避免重复计算；在 cellForRowAtIndexPath: 中避免耗时操作；使用 estimatedRowHeight 可以提升加载速度。

🟦 6. I/O 与系统调用

iOS 的文件和网络操作。

关键 Slice：

read - 读取

write - 写入

fsync - 文件同步

open - 打开文件

close - 关闭文件

SQLITE - SQLite 数据库

URLSession - 网络请求

CFNetwork - Core Foundation 网络

mach_msg_trap - Mach 消息陷阱

futex_wait - 线程等待

性能优化关注点：

主线程中出现 I/O 操作应移到后台队列；使用异步 I/O 避免阻塞。

🟦 7. Swift / Objective-C 运行时

语言层面的性能开销。

关键 Slice：

swift_release - Swift 对象释放

swift_retain - Swift 对象引用计数增加

objc_msgSend - Objective-C 消息发送

objc_retain - ObjC 引用计数增加

objc_release - ObjC 引用计数减少

objc_autoreleasePoolPop - 自动释放池清空

性能优化关注点：

频繁的 retain/release 说明对象生命周期管理不当；过多的 objc_msgSend 可能是动态派发导致。

🟦 8. 内存管理

iOS 的内存分配和释放。

关键 Slice：

malloc - 内存分配

free - 内存释放

zone_malloc - 内存区域分配

vm_allocate - 虚拟内存分配

vm_deallocate - 虚拟内存释放

dirty_pages - 脏页（内存压力指标）

性能优化关注点：

频繁的 malloc/free 说明内存抖动；监控 dirty_pages 可以预防内存警告。

四、总结

通过理解这些常见的 Slice，你可以：

快速定位性能瓶颈：在火焰图中识别耗时的关键路径

针对性优化：根据 Slice 类型选择合适的优化策略

建立性能基线：对比不同版本的 Slice 耗时，量化优化效果

跨平台理解：掌握 Android 和 iOS 的性能特征，进行双端对比分析

在实际分析中，建议结合具体业务场景，关注那些占比最大、出现最频繁的 Slice，优先优化收益最高的部分。

通过Delegate&Protocol解决Pod循环应用实战

Thu, 29 May 2025 00:00:00 GMT

😀

这里写文章的前言：之前曾经在另一篇文章中分享了Protocol与Delegate到底是什么：

🗃️

Protocol 与 Delegate

而现在在工作中，恰好遇到了一个Pod循环引用的问题，正好记录下尝试使用Protocol与Delegate进行解耦的流程。

💬 问题背景

因为隐私原因，这里使用代称。

首先让我们看一下今天要设计的两个Pod：

PodBase：部门的基础Pod

PodSubTool：一个功能相对独立的Pod，用于检测一些场景

现在我遇到的问题如下：

PodBase 中包含了启动各个独立功能Pod的代码，即 PodBase 会调用 PodSubTool 的start方法，来开启SubTool的检测功能。

为了提升 PodSubTool 的检测准确率，现在需要使用 PodBase 中的一个工具方法。

由于以上两点，达成一个 PodBase 与 PodSubTool 需要循环引用的局面

需要注意的是，这两个Pod，都被同一个主工程 MainProject 所依赖

🔧 解决流程

首先我们先提出一个基本的解决思路：

PodSubTool 定义协议并持有 delegate，不依赖 PodBase；

MainProject 中创建一个桥接对象（Bridge/Adapter），实现该协议，内部调用 PodBase；

最终在 MainProject 中由 PodBase 创建 PodSubTool 时，顺便设置 delegate。

iOS中的Touch响应全链路

Wed, 30 Apr 2025 00:00:00 GMT

Author：akinIan
部分知识源于网络学习，如有错误欢迎指正

一、前言

尝试学习了iOS响应触摸方式的某些步骤后，发现大部分文章都会选择性的省略某些步骤，阅读后还是会有一知半解的感觉，所以决定自己从头分析一下我们手中的iPhone是如何处理我们的每一次点击、滑动的。

二、交互过程

1. 从触摸屏幕，到系统对触摸事件的封装

我们手中的iPhone使用的屏幕，大都是 “电容触控屏”，这样的屏幕由一个覆盖着透明导电材料的感应网格组成，当我们的手指靠近或者触摸屏幕的时候，屏幕网格上的电场分布会变化，而手机就会通过检测到的电荷变化，来推测出手指的坐标位置。

采集到触摸信息后，通过 触摸控制器芯片 把采集到的信息，打包成标准输入事件，并且交给驱动、I/O Kit来处理。

而 I/O Kit 会通过与iOS的BackBoard的配合，由BackBoard来进行原始触摸数据的解析，并判断他属于哪个App的窗口。一旦系统判断发现了这个触摸事件应该交给前台App进行处理，那么就会将这个事件 转入UIKit层 来进行处理！

💡

SpringBoard 与 BackBoard

SpringBoard是iOS系统中的一个核心进程，主要负责管理应用程序的启动、切换和显示。它控制着主屏幕（Home Screen）的显示、应用图标的布局、通知中心等UI元素，可以说是用户与iOS系统交互的主要界面管理者。

BackBoard是iOS系统中的另一个重要组件，主要负责处理底层的触摸事件和硬件输入。它作为系统和硬件之间的中间层，接收来自触摸控制器的输入事件，并将其转发给合适的应用程序或系统组件。BackBoard的存在使得触摸事件的处理更加高效和统一。

这两个组件的协同工作，保证了iOS系统流畅的触摸响应体验：BackBoard负责接收和预处理触摸事件，而SpringBoard则负责根据这些事件执行相应的UI操作。

2. 当事件分配给App，初步进入UIKit层后…

在这里先介绍两个核心的概念：什么是UIApplication？什么是Runloop？

OC中的GCD (Grand Central Dispatch)

Tue, 25 Feb 2025 00:00:00 GMT

什么是GCD（Grand Central Dispatch）

GCD是Apple开发的一个多核编程的解决方案，它让开发者可以更加方便地进行多线程编程。GCD的核心是dispatch queue（调度队列）。

主要队列类型

1. 串行队列（Serial Dispatch Queue）

串行队列按照先进先出（FIFO）的顺序执行任务，同一时间只能执行一个任务。

2. 并发队列（Concurrent Dispatch Queue）

并发队列可以同时执行多个任务，但任务完成的顺序是不确定的。

3. 主队列（Main Queue）

主队列是一个特殊的串行队列，专门用于在主线程上执行任务，通常用于UI更新。

队列使用方式

1. 同步派发（Sync）

同步派发会阻塞当前线程，直到任务执行完成。

2. 异步派发（Async）

异步派发不会阻塞当前线程，任务会在后台执行。

常见使用场景

网络请求：使用异步队列处理网络操作，完成后在主队列更新UI

图片处理：在后台队列处理图片，避免阻塞主线程

文件操作：使用后台队列进行文件读写操作

注意事项

避免在主队列中执行耗时操作

警惕死锁情况，例如在主队列中同步派发到主队列

合理使用串行队列和并发队列，根据实际需求选择

注意内存管理，防止循环引用

理解和正确使用GCD队列对于开发高性能的iOS应用至关重要。合理利用不同类型的队列和派发方式，可以显著提升应用的响应性和用户体验。

例子

这段代码中主要使用了以下几种dispatch方式：

使用全局并发队列进行异步操作： dispatch_async(dispatch_get_global_queue(0, 0), ^{ ... }) 用于处理热图模型数据，避免阻塞主线程

延迟派发到主队列： dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ ... }) 用于处理图片上传中的情况，延迟5秒后在主队列执行上报操作

这种使用方式符合GCD的最佳实践：

将耗时操作放在后台队列处理

UI相关的操作（如更新状态）放在主队列执行

合理使用异步操作来提高应用性能和响应性