1. 接到“iPhone Duo适配”需求时我先澄清了它到底改什么1.1 为什么“Duo”这个词值得单独立项先说明一下这里的“Duo”我指的不是某个第三方App而是以双屏、可折叠设备为代表的一类多形态硬件。很多团队把这类设备的适配工作单独立项代号就叫“Duo适配”。iPhone侧的开发者第一次听到这个需求时普遍会觉得iPhone又不会变成两块屏幕凭什么要我们适配这个直觉是错的。双屏和折叠屏设备对App的影响不是简单的“屏幕变宽了”而是把一套原本建立在“单个稳定窗口”假设上的UI体系推进了一个充满动态变化的窗口环境里。iPhone虽然自身形态固定但iPadOS上的多任务分屏、外接显示器、台前调度以及越来越普遍的单手模式、横竖屏切换都在制造和Duo设备高度相似的运行条件。换句话说如果你只在“布局模型”上打补丁那这个适配项目做完了App该崩的地方还是会崩。这个项目我最想记录的经验是适配工作的重心不在Auto Layout不在SwiftUI布局而在窗口几何、生命周期、事件路由和用户状态这四个层面。布局模型只是最表层的东西真正需要重构的是你对“一个App实例到底活在几个窗口里”这个问题的回答。1.2 布局模型只是最容易看见的那一层大多数团队接到适配任务第一反应是打开Xcode把约束重新拉一遍。这个动作没错但它只覆盖了“静态布局正确”这一件事。举个例子早期iPhone App使用window?.rootViewController直接取值这种写法默认了App只有一个UIWindow只有一个rootViewController而且这两个东西从头到尾不会换。双屏场景下这个假设直接不成立。第二个窗口出现时系统不会把旧的rootViewController让给你而是新建一个scene新起一套window。你的业务代码如果到处写着UIApplication.shared.windows.first那么看上去只是“布局变了”实际报错会表现为按钮点不了、页面显示一半、数据不刷新、甚至直接闪退。所以这轮适配的第一步不是改约束而是做一次全局代码审计把对“单窗口”的隐性依赖全部翻出来。这也是我后面几章要展开的主线布局之外哪些东西被双屏打破了。2. 最先失控的是窗口几何从单窗口假设到多场景矩阵2.1 UIScreen的坑两个屏幕不等于两块屏要理解双屏适配为什么从窗口几何开始得先搞清楚一个概念Duo设备上的一块逻辑窗口不等于一块物理显示屏。以比较典型的双屏形态为例单个屏幕上显示的宽度只有整体宽度的一半但两个屏幕中间隔着一道物理铰链。系统给出的逻辑bounds可能是“整块跨屏区域的总宽”也可能只是“当前单屏的宽度”取决于你的窗口配置和系统版本。这块踩坑最深的地方在UIScreen.main.bounds。我在接手适配项目时做了一个全项目搜索发现至少有三十几处代码依赖这个属性来判断iPhone机型、计算比例、设置圆角。单屏环境下UIScreen.main就是那个唯一的、人人可用的全局答案双屏环境下系统不会像变魔术一样告诉你“你现在在左屏还是右屏”你必须自己维护当前窗口的尺寸和位置。正确的做法是在SceneDelegate里拿到UIWindowScene通过windowScene.screen.bounds、windowScene.statusBarManager?.statusBarFrame、以及UIWindow.frame这些组合去计算实际可用区域。还有一个特别容易忽略的点viewWillTransition(to:with:)里的CGSize是新尺寸但UITraitCollection里可能有不止一次的尺寸变化回调前后间隔可能在数秒内连续触发两次。你如果按照一次回调就重排布局的逻辑去写第一次回调用的旧约束还没解锁第二次回调已经来了最终Layout会乱。我在项目里加的防护是在根容器视图里重写layoutSubviews把“真正的布局计算”收敛到这一步而不是依赖viewWillTransition的回调顺序。凡是看到尺寸变化只标记一个needsLayout下一帧系统自然会用最终尺寸去布局。实测下来这套逻辑在单屏、双屏、外接显示器三种场景下都稳。2.2 安全区与键盘瞬时状态是崩溃重灾区窗口几何的变化还会连带影响两个跟“瞬时状态”强相关的东西安全区和键盘。先说安全区。iPhone上你已经习惯了safeAreaInsets那一套刘海屏、Home Indicator、底部横条改一改约束就能适配。双屏设备上安全区的变化不止发生在横竖屏切换时还会发生在窗口从一个屏幕拖到另一个屏幕时。此时safeAreaInsets会在几帧之内连续跳动如果某个约束依赖safeAreaInsets.bottom而你在viewDidLoad里就把它缓存成了一个静态值那等窗口真正落位后页面底部要么被遮挡要么空出一大块。我当时的解决方案是把安全区相关的约束做成“每次布局时重新计算”的表达式不在布局外缓存。具体来说用constraint.constant view.safeAreaInsets.bottom extraPadding这类写法并且确保它在viewSafeAreaInsetsDidChange回调里重新触发。注意这个回调名字很多人听过但没认真用双屏适配时它出场频率极高。再说键盘。键盘弹起会改变keyboard frame而这个frame在不同窗口下的坐标系不一样。单屏时keyboardWillChangeFrameNotification里的endFrame直接取就行双屏时键盘可能挂在任意一个scene上甚至同时影响两个窗口比如跨屏输入时。我在项目里遇到过键盘把输入框顶到屏幕外、但页面底部约束没有任何变化的情况排查半天定位到是键盘通知被两个scene同时监听第二次监听拿到了另一个坐标系里的frame直接把约束撑爆了。修正方式是监听UITextField所在的window作为基准再用convert(_:from:)把键盘frame统一转换到当前视图坐标系。这套处理不复杂但必须在适配阶段写清楚等用户真机上一遍遍输入时再排查成本很高。3. 生命周期反向工程一个页面真的能“同时”活在两个窗口里吗3.1 SceneDelegate接管后AppDelegate思路全废双屏适配对生命周期的影响可以说是所有改动里最考验既有代码架构的一环。传统的iOS开发AppDelegate负责启动启动完之后创建window设置rootViewController然后App进入一个相对稳定的运行状态。你不需要考虑“同一个App突然又创建一个新window”这件事。SceneDelegate的时代这个前提已经松动。一个App可以有多个scene每个scene对应一个UIWindowScene而sceneDidBecomeActive和sceneWillResignActive会在不同窗口之间交替触发。你在AppDelegate里监听didBecomeActiveNotification来判断“App回到前台”的代码到了双屏场景就失灵了——因为左边窗口可能变成活跃状态右边窗口还在后台两个scene的状态已经不同步。我在适配项目里做了这样的调整把“App级状态”和“窗口级状态”拆分。App级状态走UIApplicationDidBecomeActiveNotification窗口级状态走sceneDidBecomeActive并且每个scene内部的业务状态由它自己管理。最直接的变化是以前写在全局单例里的currentUserState、currentPlayingItem这类共享数据现在必须带窗口上下文否则两个scene同时跑单例里的值会互相覆盖。还有一点很多团队上来就把所有页面都放进一个导航栈里这种做法在双屏下会带来一个诡异现象用户从左边窗口进入页面A从右边窗口进入页面B同一个导航控制器实例被两个窗口同时持有返回时A和B的状态串了。我当时没有时间把所有页面改造成独立导航栈但至少把根导航控制器换成了UINavigationController的子类让每个scene各自new一个实例并且对push/pop操作加了锁避免跨窗口并发改动。3.2 状态保存双屏下最容易丢的就是“用户刚才在干嘛”苹果在iOS 13以后主推状态恢复State Restoration但直到我做双屏适配之前说实话状态恢复对我来说只是个“锦上添花”的功能。单屏设备上App被系统杀掉再恢复本身频率就不高用户感知也不强。双屏设备上状态恢复变成了刚需因为窗口从双屏折叠成单屏时系统会释放一个scene用户在那边窗口里正在编辑的内容、正在浏览的位置如果没有妥善保存就会无声无息地消失。这里有个非常反直觉的点用户不会清楚地区分“我在用左屏还是右屏”他只知道自己刚才在看的内容突然不见了。我第一次测双屏折叠恢复时还跟同事说这不就是个普通的scene销毁吗结果用户一反馈才发现页面重新打开后回到了默认首页既没有恢复到之前的滚动位置也没有恢复到编辑框里的文字。这个体验比闪退更令人恼火因为闪退至少还提示“App异常退出”这种恢复失败则像失忆。针对这个问题我在涉及内容阅读、表单填写、列表浏览的页面里全部实现了encodeRestorableState(with:)和decodeRestorableState(with:)。注意不仅仅是UIViewController要实现业务对象也要支持序列化否则场景切换时内存里的ViewModel一刷新就没了。具体踩坑的地方是状态恢复回调的时机不固定有时候在viewDidLoad之前有时候在viewDidAppear之后所以恢复的逻辑不能放在初始化里要放在application:shouldSaveApplicationState和application:shouldRestoreApplicationState返回true的前提下再结合scene的scene:willConnectToSession:options:去恢复。恢复过程中identifier要带窗口编号否则两个窗口恢复的是同一份数据。4. 手势、焦点和多点触控用户的手指不会按你的约束来4.1 跨屏拖拽看起来是布局问题其实是事件路由问题布局模型解决的是“东西放在哪”但双屏适配另一个大头是“用户的手势落在哪”。iPhone的单屏交互里手势的hitTest路径很清晰——触摸事件从UIWindow往下分发命中哪个view就由谁处理。双屏环境多出一个物理铰链区域和跨屏连续视觉触摸事件的归属就变得暧昧起来。我做过一个跨屏拖拽组件最初实现思路很简单用户把一个卡片从左边屏幕拖到右边屏幕我监听UIPanGestureRecognizer根据手指位置更新卡片位置。单屏跑得挺好一到双屏就翻车。原因在于拖拽跨越铰链区域时手势的translation依然在一个窗口的坐标系里累计但视觉上卡片已经进入另一个窗口系统不会帮你把坐标自动转换过去。这类问题正确解法是在手势开始阶段锁定一个参考窗口比如gesture.view?.window然后整个拖拽过程中的location(in:window)都相对这个参考窗口计算。当坐标跨越铰链中线时手动把目标视图removeFromSuperview并addSubview到另一边的窗口容器里同时把“视觉位置”的基准坐标也切换过去。这看着像布局切换本质上是事件路由的转换。你如果只在布局模型中把卡片位置改到右边事件处理仍然停在上一个窗口就会出现“卡片过去了但点不动”的灵异现象。4.2 指针与焦点把桌面端那套UE规则搬进来第二个容易忽略的是非触摸交互。Duo设备支持外接键盘和触控板这是iPhone用户不常遇到的使用方式。虽然iOS本身有完善的焦点引擎但大多数iPhone App从来没有认真处理过UIFocusEnvironment。我的体会是如果你的App未来要走向“多形态设备通用”那焦点管理现在就要开始做。具体来说至少要做到三件事每个可交互控件要有明确的accessibilityLabel和accessibilityFrame这不仅是无障碍需求也是键盘/指针聚焦的基础弹出的模态视图要重置焦点序列不能把焦点停在被遮挡的控件上跨屏后重新布局时要主动调用setNeedsFocusUpdate()否则焦点可能停留在屏幕外的旧位置键盘用户会觉得自己“卡住了”。我很喜欢在适配文档里写一句话“不要把用户限制成一根手指。” 双屏设备的用户可能是用键盘输入的可能是用触控板点击的也可能是拿着手写笔在铰链旁边划拉的。你的适配方案如果只验证了触摸场景那大概率只配好了最普通的那条路。5. 调试双屏适配的实操链路没有真机的轮子怎么转5.1 三个层次的验证环境如果你手头没有双屏硬件我刚开始也没有调试工作可以通过三个层次来推进越往后越接近真机效果。第一层是模拟器。Xcode自带的模拟器虽然不支持真正意义的双屏但支持Window Physical Size和旋转还有多窗口场景。你可以用Shift Command H回到主屏幕从dock里把App拖成多窗口模拟两个scene同时存活。这层主要用于验证生命周期拆分是否正确以及前面说的状态恢复是否生效。第二层是外接显示器。用一根Lightning转HDMI或Type-C转HDMI的线把iPhone/iPad接到外接屏上再到系统设置里开启“第二屏幕”或者台前调度模式。这时候系统会为外接屏单独创建一个UIWindowScene跟Duo设备的双窗口体验非常接近。我后面很多窗口几何、安全区问题都是在这层发现的。第三层才是真机测试。有条件就借一台双屏或折叠屏设备跑一遍核心流程。我重点跑的场景包括横竖屏切换、单双屏切换、跨屏拖拽、输入框激活、系统弹窗出现以及带刘海/圆角区域的按钮点击。这个清单看起来简单但它能覆盖90%的常见崩溃点。5.2 我常用的五类日志埋点因为没有硬件前期排查问题基本靠日志。我在项目里埋了五类日志对接下来的调试帮助极大窗口生命周期日志打印scene.session.configuration.name、scene.activationState记录每个scene什么时候活跃、什么时候退到后台。窗口几何变化日志记录window的frame变化、safeAreaInsets变化以及viewWillTransition(to:with:)回调里的size。重点对比“布局回调”和“实际显示”的差异。键盘事件日志记录keyboardWillShow的endFrame、当前响应view的窗口、转换后的坐标系一条一条对应起来看。焦点变化日志实现UIFocusUpdateContext相关的代理方法把焦点移动的时间点和目标描述打出来。状态恢复日志在encodeRestorableState和decodeRestorableState里打印当前类名和保存的key确认恢复内容是否覆盖完整。这套日志体系我后来甚至带到了其他项目里因为它的核心价值不在于“针对双屏”而在于把一个复杂动态环境拆成可观测的维度。单屏App排查触摸失效、布局错乱也照样用得上。6. 适配优先级与成本边界哪些改动值得做6.1 按“用户旅程”排序而不是按页面难度双屏适配的改动量很大如果不排优先级团队容易陷入“每个页面都要适配”的泥潭。我的建议是按用户旅程来排序不要按页面的技术难度来排。我当时把用户旅程拆成三条主线主线一浏览内容阅读资讯、查看列表、播放视频主线二输入操作登录注册、发帖评论、表单填写主线三多任务处理一边看文档一边做笔记、一边视频会议一边查资料。这三条线覆盖了大多数场景的高频操作。我让人力集中在这些旅程涉及的关键页面而不是去适配全部设置项和历史遗留页面。具体适配策略是信息展示型页面列表、详情、播放器优先适配双屏/多窗口因为它们最可能被用户留在副屏上持续观看表单输入型页面需要重点处理键盘和焦点因为“键盘从哪个窗口弹出”直接决定用户体验低频运营页、纯展示页可以暂时保留单屏布局只要不崩溃、不遮挡留到后续迭代慢慢补。6.2 明确不做的部分也算适配决策做适配项目最容易犯的错误是“什么都想改”最后什么都没改完。我在项目中期做了一次范围收敛明确了三类不做的事情第一不做完全差异化的双屏专属UI。很多双屏设备提供跨屏API理论上可以让App在左右屏显示不同内容但iPhone生态里没有这种用户心智强做只会让维护成本翻倍。我的策略是优先保证“单窗口体验稳定”再考虑“多窗口协同”跨屏联动功能等有真机、有用户反馈后再排期。第二不为了适配而引入重型依赖。看到很多团队上来就集成第三方双屏适配框架最后发现框架本身就一堆bug。我的原则是能自己写清楚的就自己写布局和状态管理这种核心逻辑尽量掌握在自己手里。第三不做无数据支撑的“未来适配”。有些需求比如手写笔、特定外设交互目前用户反馈极少我会做一个小类别归类但不会投入完整排期。等实际使用数据出来再决定是否要做深度适配。这样收敛之后整个适配周期缩短了大概三分之一而且核心体验的稳定度反而更高。我自己最大的体会是适配这类工作最难的不是技术方案而是想清楚哪些变化值得被一个具体项目的代码承接。做大而全的适配方案画图很好看上线后维护的人会非常痛苦。