ArrangementView：谋而后定
内容提要
ArrangementView 是苹果为 iPhone Duo 等折叠设备设计的双视图容器，通过 arrangement 规则决定视图的显示与布局。它声明视图间的关系而非几何，但 split 与 overlay 共用 primary/secondary 名称却含义不同，切换时只能硬切，且缺少集中反映最终布局的接口。它适合内容关系与设备规则吻合的场景，否则宜用标准容器。
延伸解读
主次语义随模式而变
在 split 中，primary 是空间不足时优先保留的视图；而在 overlay 中，primary 却位于 secondary 上方。同一对名称在不同 arrangement 下含义不同，开发者必须根据当前模式重新赋义。苹果示例中切换模式时交换了 PlayerView 与 UpNextView 的主次位置，正说明了这一点。若忽视这种差异，可能导致内容层级与用户预期不符。
模式切换是硬切而非过渡
split 与 overlay 在 SwiftUI 中是不同的具体类型，切换意味着 if-else 和视图标识改变，即使通过自定义 ArrangementViewStyle 包装，本质仍是条件分支，添加动画也只是 transition。在 UIKit 中调用 updateArrangement(_:animated: true) 测试，结果同样是硬切。因此，若产品需要平滑过渡，开发者需自行处理状态与动画，不能依赖容器提供连续布局状态。
缺少最终布局的集中反馈
容器替应用决定了最终布局，但子视图难以直接获知结果。overlayArrangementZIndex 为 0 无法区分视图在底层还是已转为并排；splitArrangementAxis 只表达轴向，不反映完整可见性。开发者只能结合零散信号自行推断，增加了复杂度。若子视图需根据最终排列调整内容，应用不得不重新组织这些信息，这在大规模场景中尤为明显。
适用边界与选择建议
ArrangementView 的舒适区是 iPhone Duo 等折叠设备，能自然处理分割区域避让与空间重分配。但苹果建议优先使用标准自适应组件，仅当需要自定义分割或叠放时才考虑它。若两个视图有稳定的主次或前景背景关系，且子视图只需少量调整，它会很顺手；反之，若关系含混或模式切换是核心逻辑，从 HStack、VStack、ZStack 或标准导航容器出发更合适。
Q&A
ArrangementView 是什么？它主要解决什么问题？
ArrangementView 是苹果为 iPhone Duo 等折叠设备设计的双视图容器，通过 arrangement 规则决定视图的显示与布局。它把两个视图之间的关系放进一组布局规则中，再结合可用空间、宽高比、尺寸类别及设备分割区域，决定视图是否显示、显示在哪里。
ArrangementView 的 split 和 overlay 中 primary/secondary 的含义有什么不同？
在 split 中，primary 是当约束使分割无法成立时被优先保留的视图；在 overlay 中，primary 位于 secondary 上方。这与 overlay modifier 的语感不一致，后者是在原视图之上添加一层，原视图位于下方。因此一个视图在 split 中是应被保留的主体，在 overlay 中未必是合适的前景。
在 split 和 overlay 之间切换时，ArrangementView 能平滑过渡吗？
不能。在 SwiftUI 中，.split 与 .overlay 是不同的具体类型，切换意味着 if else，视图标识改变；即使通过自定义 ArrangementViewStyle 在 makeBody 内部按值选择，本质上也只是另一层 if else 的包装，添加动画后得到的仍只是 transition。在 UIKit 中使用 updateArrangement(_:animated: true) 测试时，结果同样是硬切（Xcode 27.1 beta）。
ArrangementView 缺少什么关键接口？为什么这会造成不便？
它缺少一个集中表达最终布局结果的接口。开发者可以知道 split 的轴向、overlay 的层级，也可以查询设备的保留区域，却很难直接回答当前用户看到的究竟是哪一种排列结果。例如，overlayArrangementZIndex 的值为 0 无法区分视图是位于底层还是 overlay 已转为并排；splitArrangementAxis 表达的是 split 的轴向，而不是完整的可见性状态。一旦子视图需要根据最终排列调整内容，应用就不得不重新推断容器已经完成的判断。
什么情况下适合使用 ArrangementView？什么情况下应避免？
适合当界面需要自定义的分割或叠放，且两个视图有稳定的“主内容／细节”或“前景／背景”关系，空间不够时谁退场、重叠时谁在上能共用一套主次语义，子视图只需少量调整就能适应最终结果，并且系统针对折叠区域提供的编排能力确实省去了应用原本需要维护的布局判断。反之，如果答案含混，或者关系之间的切换本身就是产品的核心逻辑，更愿意从 HStack、VStack、ZStack、标准导航容器或自定义布局出发。
苹果对 ArrangementView 的使用优先级有什么建议？
苹果建议优先选择最高层级的抽象：先是标准的自适应组件，其次才是 ArrangementView，再往下是保留区域，铰链数据则只在确有必要时使用。
