最近接连接到好几个类似的求助，描述几乎一模一样：系统版本是 iOS 27，操作是 iPad 分屏模式下双手一拉，屏幕就直接卡死，转圈转到天荒地老，只能强制重启。提问的人里既有普通用户，也有在做 iOS 适配的同事，甚至还有人怀疑是不是自己买的 iPad 体质有问题。
这个问题有意思的地方在于“双手一拉”这个动作本身。它既不像常见的捏合缩放，也不完全是拖拽某个控件，而是在分屏场景中，一只手拖住中间的分隔条，另一只手还在另一侧的 App 里滑动或者输入。换句话说，俩手势在同一屏不同区域同时进行，系统直接懵了。
我用 iOS 开发的老思路处理了这件事：先稳定复现，再抓日志，最后定位和修复。这篇就把完整过程写出来，同时把 iOS 手势冲突、主线程卡死这类问题讲清楚。如果你正在做 iOS 分屏适配、iOS 自动化测试，或者只是准备升级适配下一个系统大版本，这一篇能帮你省不少冤枉时间。
1. 项目概述：现象、影响与初步判断
1.1 “双手一拉就卡死”到底是个怎样的现象
先说实际现象，不然很多人以为是网速问题或者 App 卡了。用户反馈里最典型的一个场景是：一台升级到 iOS 27 的 iPad Pro，打开“设置”和“备忘录”，在分屏模式下把分隔条拖到屏幕中间。左手指还按在分隔条上，右手在右侧备忘录里往上滑动内容，屏幕立刻失去响应。
这时候有几个特征需要注意：画面还在，但不是冻结成静态图，而是那种背板上的“转菊花”出现，肉眼能看到的卡顿发生在所有窗口上；物理按键有反应，按 Home 键或电源键能退出到某个界面，但 App 切换器拉不出来；锁屏再解锁之后有一定概率恢复，但绝大多数情况下只能强制重启。
另一个高频触发场景是分屏里出现输入框。左侧是网页登录页，右侧是微信小程序，左侧使用输入法弹出键盘，同时右侧用双指滚动页面，键盘区域和页面区域同时有触摸序列，也会出现同样的卡死。这就不是单指能解释的问题了，明显是系统层在同时处理多指触摸时出了问题。
还有一个小众场景：在 iPad 的分屏“侧拉”悬浮窗口模式下，拖动悬浮窗的位置，同时另一只手在主窗口中双指缩放，也会卡住。说明问题并不局限于“分屏分隔条”，而是任何“系统级拖拽手势 + 应用内多指手势”的组合。
1.2 哪些场景最容易触发
统计了一下我这边能复现的环境，主要聚集在这三类：
分屏拖分隔条 + 另一侧触摸滚动。 这是最常见的触发方式，尤其是分隔条拖到一半停住不动，再在另一侧滑动时，卡死概率接近八成。
键盘弹出状态下 + 双指横滑。 左侧 App 的输入框已聚焦，系统虚拟键盘覆盖在底部，右侧 App 同时响应双指滑动或双指缩放，触发概率也很高。
控制中心/通知中心下拉 + 手势动画未结束时快速触摸屏幕。 在 iOS 27 上，从屏幕右上角下拉控制中心，动画还没完全展开时，另一只手在屏幕其他地方滑动，偶尔也会冻结。
这三类情况的共同点都是短时间内在屏幕的不同区域产生了多路触摸事件，而且其中至少一路走了系统级手势识别。更关键的是，它们都是在 iOS 27 上才暴露出来，上一代系统在同一台设备上没有这个问题。
1.3 初步筛选：开发者模式、模拟器和真机
我拿到反馈后的第一反应是先排除硬件问题，于是准备了一台装有 iOS 27 开发者预览版的 iPad Pro，一台运行最新版 Xcode 的 Mac，并把设备开启开发者模式进行验证。结果很有价值：在 Xcode 的 iOS 设备模拟器里，用鼠标模拟出来的点击和拖拽很难复现，因为模拟器对多点触控的支持本身就不完整，鼠标事件在多数情况下会被识别成单指。而一旦换到真机上，用两台 iPhone 通过“随航”或“屏幕使用时间”里的辅助触控模拟第二根手指，卡死几乎立刻出现。
这条信息本身就说明了一个重要结论：问题大概率不是某个 App 的代码 bug，而是系统级手势争抢或主线程渲染阻塞的问题。因为模拟器不复现、真机复现、跨 App 复现，这已经超出了普通开发者能靠改业务代码直接绕开的范围。但我没有就此打住，既然不是单纯某个 App 的问题，就更值得把后面这层原理抠开看。
2. 核心细节解析：iOS 手势冲突与界面冻结为什么发生
2.1 先补一个基础：iOS 手势识别链路
要搞懂这个问题，得先理解 iOS 是怎么处理触摸的。当一个或多个手指接触屏幕，系统会生成 UITouch 对象，并分发到对应的 UIWindow 上。一个 UIView 通过 hitTest:withEvent: 找到自己，然后触摸事件沿响应链走。
在这之上，UIKit 提供了 UIGestureRecognizer，用来把多个触摸点归纳成用户能理解的语义，比如点击、滑动、捏合、拖拽。手势识