近日，一条关于 Flutter 开发中的“避坑”警告在开发者社区引发热议：部分开发者在应用入口 main() 函数中直接锁定屏幕方向，导致 iPad 设备上的分屏（Split View/ Slide Over）功能被彻底“封杀”，用户无法同时使用其他应用，体验大打折扣。这一问题并非孤例，许多新手甚至资深开发者都可能在不经意间“踩雷”。本文将深入剖析这一隐患的根源、影响，并给出正确的实践建议。

问题溯源：main() 中的“粗暴”锁定

在 Flutter 应用中，控制屏幕方向通常通过 SystemChrome.setPreferredOrientations() 实现。许多开发者为了强制 App 保持竖屏或横屏，习惯在 main() 函数中直接调用：

void main() {
  WidgetsFlutterBinding.ensureInitialized();
  SystemChrome.setPreferredOrientations([DeviceOrientation.portraitUp]);
  runApp(MyApp());
}

这段代码在大部分手机设备上似乎“完美”工作——应用确实被锁定在了竖屏模式。然而，当用户在 iPad 上尝试使用分屏功能时，问题暴露无遗：iPad 的分屏机制依赖于应用能够动态响应不同的窗口尺寸和方向。一旦应用在启动阶段强行锁死方向，系统会认为该应用不支持多任务环境，从而直接禁用其参与分屏或侧滑的资格。

iPad 分屏是如何“被干掉”的？

iPad 的分屏功能（iPadOS 13+）允许用户同时运行两个应用，每个应用占据屏幕的一部分。系统在启动 App 时会检查其 Info.plist 或运行时是否支持所有方向（尤其是横竖屏切换）。如果应用通过 SystemChrome 在启动时直接锁定为单一方向，iPadOS 会将此视为应用拒绝适配多窗口的标志。具体表现包括：

  • 应用无法被拖入分屏区域；
  • 分屏后应用只显示在固定方向，无法随用户调整窗口尺寸而自适应；
  • 更严重的是，用户一旦开启分屏，应用可能会崩溃或显示异常。

实际上，SystemChrome.setPreferredOrientations 的设计初衷是全局性的偏好设置，但它一旦在 main() 中被调用，会在 runApp 之前修改系统层的行为，导致 Flutter 引擎在初始化时未正确注册对多窗口的支持。部分开发者反馈，即便后续在 initState 中重新设置方向，分屏功能也未必能恢复，因为初始锁定已“污染”了系统缓存。

影响范围：不仅仅是 iPad 用户

虽然标题聚焦 iPad，但这一问题同样波及 Android 平板、可折叠设备及 Chrome OS 等多窗口环境。随着跨平台应用日益普及，用户期望在一个屏幕上同时处理多个任务。如果应用锁死方向，不仅影响分屏，还可能破坏键盘外接、画中画等功能。对于游戏、视频类应用，强行锁定方向有其合理场景，但对于工具、阅读、社交等通用 App，盲目锁定等于自断功能。

专家建议：如何正确锁定方向而不伤及分屏？

多位 Flutter 社区核心贡献者给出了解决方案：

  1. 延迟锁定：不在 main() 中设置方向，而是在 runApp 之后、路由或特定页面中动态判断。例如，在 MaterialApp 的 builder 或第一个页面的 initState 中调用 setPreferredOrientations，此时 Flutter 引擎已正确初始化多窗口支持。

  2. 分场景锁定：仅在有需要的页面（如视频全屏、游戏）临时锁定方向，并在离开时恢复。使用 OrientationBuilder 或监听 MediaQuery 的变化，做到“该锁时锁，该放时放”。

  3. 尊重系统设置：利用 SystemChrome.setPreferredOrientations 的异步特性，可先不传任何参数，让系统默认支持所有方向。随后在特定逻辑中再追加限制。

  4. 检查 Info.plist / AndroidManifest：确保应用声明支持所有方向（UIInterfaceOrientationPortrait, UIInterfaceOrientationLandscapeLeft, UIInterfaceOrientationLandscapeRight 等），否则系统层面就会禁止分屏。

结语

Flutter 的灵活与强大让开发者能快速构建跨平台应用，但每一个 API 调用背后都可能隐藏着对系统生态的深刻影响。main() 函数作为应用的入口，绝不应成为“一刀切”设置方向的场所。在追求用户体验的今天，拥抱多窗口、多尺寸适配才是正道。下次编写 Flutter 应用时，请务必三思：你锁住的不只是屏幕方向，还有用户选择如何使用的自由。