一、前言

我之前在开发一个 App 时踩了个大坑，而且这个坑藏得特别深，整整三个月都没人发现。

当时为了图省事，为了保证 App 在不同设备上的视觉效果一致，我在 main() 函数里随手写了一行代码，直接把 Orientation 给锁死了，只允许竖屏。我们在测试 iPhone 和 Simulator 时一切正常，直到后来看到用户评价说：“这个 App 不支持多任务处理（Multitasking）”，我才猛然发现：我们亲手把 App 在 iPad 上的分屏功能搞没了。

二、问题复现

最坑的地方在于：这完全没有报错，也不会导致 App 崩溃。

你打包出的 IPA 在 iPad 上安装运行得好好的，界面也没问题。但问题在于，当你尝试使用 iPad 的 Slide Over（滑动置顶）或者 Split View（分屏）功能时，你会发现你的 App 根本进不去，或者即便进去了，也无法像其他 App 那样灵活切换。

我当时并不是通过测试设备发现的，而是因为一个用户反馈。当我拿到一台真实的 iPad 开始复现时，发现问题非常明显：

// 这行代码在 iPhone 上表现完美，但在 iPad 上是“分屏杀手”
await SystemChrome.setPreferredOrientations([
  DeviceOrientation.portraitUp,
]);

三、原理分析

为什么在 iPhone 上好好的代码，到了 iPad 上就变味了？这背后其实是 Apple 对多任务处理（Multitasking）的硬性规定。

通过对比，我们可以很直观地看到 iPhone 和 iPad 对 SystemChrome 处理逻辑的差异：

设备类型	SystemChrome 锁定行为	对多任务的影响
iPhone	强制锁定当前方向，旋转屏幕时界面不随之变化	无影响。用户习惯于单屏操作，锁定方向是符合预期的。
iPad	锁定方向会被视为放弃“多任务能力”	致命影响。由于无法响应旋转，App 会被排除在 Split View 和 Slide Over 之外。

核心逻辑是： Apple 的设计哲学是，如果你想在 iPad 上支持分屏（Split View），你的 App 必须能够支持所有的界面方向。因为分屏时，左右两个 App 的尺寸是动态变化的，它们必须能够根据环境的变化进行 Reflow（重排）。如果你在代码层面强制锁死了方向，iPad 系统就会认为你的 App 不具备多任务处理的资格，从而直接让你“退出分屏资格”。

四、解决方案

既然知道了这个坑，我们该如何优雅地处理屏幕方向呢？这取决于你的业务需求。

1. 如果你的 App 真的完全不支持横屏

如果你的 App 确实是那种只能竖屏的业务（比如某些表单密集的工具），且完全不考虑在 iPad 上分屏，那么千万不要在 main() 里用 SystemChrome 动态锁定。

你应该通过原生配置来告诉系统：这个 App 本来就没打算支持横屏。这样虽然还是不能分屏，但至少逻辑是清晰的，不会因为运行时代码的行为导致系统误判。

• iOS: 在 Info.plist 中配置 UISupportedInterfaceOrientations。

• Android: 在 AndroidManifest.xml 中设置 screenOrientation。

2. 如果你只是想在特定页面锁定方向

这是我目前最推荐的方案。如果你的 App 大部分场景都支持旋转，只是在某些特定页面（比如全屏播放视频、或者某个特定的交互界面）需要强制竖屏，你应该采取 “局部锁定，用完即释放” 的策略。

在需要锁定的页面，利用 initState 进行锁定，并在 dispose 时务必记得释放：

// 在必须竖屏的页面中进行局部锁定
@override
void initState() {
  super.initState();
  // 進入页面时锁定竖屏
  SystemChrome.setPreferredOrientations([
    DeviceOrientation.portraitUp,
  ]);
}

@override
void dispose() {
  // 离开页面时，一定要把控制权还给系统！
  // 传入空列表，让系统根据设备旋转状态自动处理
  SystemChrome.setPreferredOrientations([]);
  super.dispose();
}

这样做的好处是：

1. App 的全局环境依然支持旋转和分屏。

2. 只有当前页面会被“强制”在竖屏显示。

3. 当用户从该页面返回上一级，或者切换其他 App 时，一切逻辑都符合 iPad 的多任务标准。

五、最后

总结一下：永远不要在 main() 函数里使用全局锁定的方式来处理屏幕方向。

这个操作在 iPhone 上是“无伤大雅”，在 iPad 上就是“自废武功”。如果你需要控制方向，请尽量把控制范围限制在页面级别，把旋转的自由还给用户。

如果你在开发 Flutter 时也遇到过类似的“隐形坑”，欢迎在评论区交流分享。