摘要
在macos 26上，chromium 中打开 Save File Dialog后主进程cpu上涨到20%+，在macOS 其他版本没有问题，只有chromium 存在问题，Firefox / safari 没有问题，通过 Instruments 定位到问题所在并给 Chromium 提交修复。
分析过程
对于这种必现的单场景问题比较好排查，通过instrument 抓一个trace，发现这里的罪魁祸首是firstBselineOffsetFromTop的调用。
接着找到SaveFileDialog在chromium代码的位置：components/remote_cocoa/app_shim/select_file_dialog_bridge.mm
这里首先需要了解两个概念：AccessoryView 和 firstBaselineAnchor 对齐规则。
- AccessoryView： macOS在打开文件选择框时候，有一个自定义的区域，允许代码传入一个自定义的view显示在文件选择框的下方，比如这里的foramt 就是自定义的区域，也被称作AccessoryView。
- firstBaselineAnchor：是指两个view的文本的首行文本的基线对齐
查阅了一些资料发现firstBaselineAnchor 基线对齐本身的开销相对其他的top，bottom 对齐开销要高一些。
所以问题就出在了AccessoryView中的布局规则上。
接着在macos safari 中打开文件选择框，发现cpu 并不高，用instrument 分析macos safari 的accessoryView，会发现，在macOS 26上，safari 使用了centerY 属性来对齐 popupButton、label 以及外层的 stackView（见图 safari on macOS 26.png）。
有意思的是，在macOS14上，safari 使用的对齐规则也是基线对齐（last base line），从一定程度说明了，safari 也发现了macOS 26上的性能问题，因此在macOS 26上修改了布局规则。
因此，我们可以考虑采用这种方式，将 firstBaselineAnchor 替换为 centerY 属性。修改后cpu 恢复正常。
给 chromium 提交 CL 并合入：https://chromium-review.googlesource.com/c/chromium/src/+/6947045