Unity移动端横竖屏适配全攻略：从基础设置到实战避坑

1. 项目概述：为什么移动端横竖屏适配如此重要？

在移动应用开发领域，尤其是使用Unity引擎时，横竖屏适配是一个看似基础、实则暗藏玄机的核心议题。我见过太多项目，在开发阶段一切正常，一到真机测试，特别是面对市面上五花八门的安卓和iOS设备时，屏幕方向问题就层出不穷：UI错位、场景拉伸、输入错乱，甚至直接闪退。这背后，不仅仅是屏幕宽高比的变化，更涉及到UI布局逻辑、摄像机设置、输入系统、第三方SDK兼容性等一系列连锁反应。

简单来说，横竖屏适配的目标是：无论用户如何旋转他们的手机或平板，你的应用都能提供稳定、一致且美观的体验。这不仅是用户体验的底线，也直接关系到应用商店的审核通过率（例如，某些功能强制要求特定方向）和用户留存率。一个在屏幕旋转时崩溃或布局混乱的应用，会立刻让用户失去信心。

本攻略将从最基础的Unity编辑器设置讲起，逐步深入到运行时动态检测与响应，最后汇总那些“坑”过无数开发者的常见问题及其解决方案。无论你是刚接触Unity移动端的新手，还是遇到过适配难题的老手，都能在这里找到系统性的方法和实战技巧。

2. 基础设置：在项目源头锁定方向

适配的第一步，不是在代码里修修补补，而是在项目设置中打好地基。很多问题源于初始配置的不严谨。

2.1 Player Settings 中的方向锁定

这是最直接、最常用的控制方式。在 Unity Editor 中，通过File -> Build Settings选择目标平台（iOS 或 Android），然后点击Player Settings，找到Resolution and Presentation区域（对于不同Unity版本，标签名称可能略有不同，如Resolution and Presentation或直接位于Player设置页）。

在这里，你会看到Default Orientation或Screen Orientation选项。它通常有以下几种模式：

• Portrait：强制竖屏。Home键在下或在上，取决于具体设备。
• Portrait Upside Down：强制反向竖屏。Home键在上。
• Landscape Left：强制横屏，Home键在右。
• Landscape Right：强制横屏，Home键在左。
• Auto Rotation：允许自动旋转。这是最灵活，但也最需要小心处理的选项。

选择策略与实操心得：

对于大多数游戏，尤其是核心玩法依赖于固定视角（如竖屏跑酷、横屏动作游戏），我强烈建议在项目初期就锁定一个方向（如Landscape Left）。这能避免后续UI设计、摄像机控制、物理模拟等环节出现大量不可预知的问题。锁定方向意味着操作系统不会发送屏幕旋转事件，一切都在可控范围内。

如果你的应用确实需要支持旋转（例如，一款阅读器或画廊应用），则选择Auto Rotation，并务必勾选下方你希望支持的具体方向（如 Portrait 和 Landscape Left）。一个关键技巧是：即使你允许自动旋转，也最好在代码中设置一个默认的、首选的方向，用于处理应用启动时的状态，这能有效避免启动瞬间的布局闪烁。

2.2 针对iOS与Android平台的特殊设置

两个主流移动平台在屏幕方向处理上存在细微差别，需要分别关注。

iOS (Xcode项目设置)：在Unity导出Xcode工程后，你还需要在Info.plist文件中确认UISupportedInterfaceOrientations和UISupportedInterfaceOrientations~ipad键值对，它们定义了应用支持的设备方向。Unity的Player Settings通常会帮你生成这些，但如果你进行了手动修改或使用了某些插件，最好检查一下是否一致。不一致可能导致审核被拒或运行时行为异常。

Android (AndroidManifest.xml)：在Android中，屏幕方向主要通过AndroidManifest.xml文件中的android:screenOrientation属性来控制Activity。Unity在构建时会根据你的Player Settings自动生成这个属性。但如果你需要更复杂的控制（例如，某个特定Activity需要不同的方向），你可能需要后处理生成的Manifest文件。注意：在Unity 2018及以后版本，可以通过Player Settings -> Publishing Settings -> Build区域下的Custom Main Manifest选项来提供你自己的Manifest文件，从而进行覆盖和定制。

注意：对于Android，还有一个常见陷阱是android:configChanges属性。Unity默认会在Manifest中为Main Activity添加android:configChanges="orientation|screenSize|keyboardHidden"。这告诉系统：当屏幕方向改变时，不要重启Activity，而是由应用自己处理（Unity引擎会收到相关事件）。除非你非常清楚后果，否则不要移除这个配置，否则屏幕旋转会导致Activity重建，可能引发游戏状态丢失、资源重新加载等严重问题。

3. UI系统适配：UGUI与Canvas的布局艺术

当屏幕方向或分辨率改变时，UI是最直观感受到变化的元素。Unity的UGUI系统提供了强大的工具来应对，但需要正确使用。

3.1 Canvas Scaler：适配策略的核心

Canvas Scaler组件是UI自适应布局的“大脑”。它的UI Scale Mode决定了UI元素如何随屏幕尺寸变化。

• Constant Pixel Size：UI元素保持固定的像素大小。不推荐用于需要适配多种屏幕的移动端项目，因为在高分辨率设备上UI会显得很小。
• Scale With Screen Size：这是移动端最常用、最推荐的模式。它根据一个参考分辨率来缩放整个Canvas。
  • Reference Resolution：设定一个设计分辨率（如 1920x1080）。这是你进行UI设计时的画布尺寸。
  • Screen Match Mode：这是精髓所在。
    • Match Width or Height：根据屏幕宽高比，在宽度和高度之间进行匹配。通过Match滑块（0到1）控制。通常设置为0.5，表示同时兼顾宽高，这在横竖屏切换时能提供相对平衡的缩放效果。如果应用以竖屏为主，可以偏向Height（值接近1）；以横屏为主，可以偏向Width（值接近0）。
    • Expand：画布尺寸永远不会小于参考分辨率，可能会扩展。这可能导致在窄屏上两侧超出视野。
    • Shrink：画布尺寸永远不会大于参考分辨率，可能会收缩。这可能导致在大屏上两侧留有黑边。
• Constant Physical Size：尝试保持物理尺寸（英寸/厘米）一致，依赖于设备的DPI，在移动端比较复杂，较少使用。

实操要点：对于需要横竖屏切换的应用，我通常会创建两个独立的Canvas，一个针对竖屏布局（参考分辨率如 1080x1920），一个针对横屏布局（参考分辨率如 1920x1080）。然后通过脚本根据当前方向激活对应的Canvas。虽然这会增加一些资源开销，但能保证两种布局都经过精心设计，避免单一Canvas通过锚点“硬适配”带来的布局妥协或怪异效果。

3.2 锚点（Anchors）与相对布局

锚点是UGUI布局的“骨架”。它定义了UI元素相对于父矩形（通常是Canvas或另一个UI面板）的位置关系。

• 预设锚点：Unity提供了几种快捷预设（如拉伸全屏、居中等）。理解其原理比记住预设更重要。
• 自定义锚点：你可以手动拖动锚点图标。锚点的四个小三角形分别对应父物体矩形四条边的相对位置（0到1）。例如，将一个按钮的锚点设置为左下角，并将其PosX和PosY设置为（10，10），那么无论屏幕多大，它都会距离左下角（10，10）像素。
• Stretch模式：当锚点左右或上下分开时，UI元素会“拉伸”。此时，Left、Right、Top、Bottom属性不再是绝对坐标，而是相对于父物体对应边的距离。这是实现自适应面板的利器。例如，一个作为背景的面板，可以设置锚点四角拉伸到父物体四边，然后Left/Right/Top/Bottom都设为0，它就会始终填满整个屏幕。

在横竖屏切换中的运用：当屏幕旋转时，Canvas的尺寸首先被Canvas Scaler重新计算。然后，每个UI元素会根据其自身的锚点设置，自动调整其位置和大小。例如，一个锚定在屏幕右上角的关闭按钮，在旋转后依然会停留在右上角。一个水平方向锚点拉伸、垂直方向锚定在底部的血条，在横竖屏下都能保持宽度适配屏幕、底部对齐。

3.3 使用Aspect Ratio Fitter与Content Size Fitter

这两个组件是处理动态内容尺寸的“神器”。

• Aspect Ratio Fitter：强制GameObject（通常是带有Image或RawImage的UI元素）保持特定的宽高比。这在显示头像、固定比例的广告图或视频播放器时非常有用。你可以设置其为Width Controls Height或Height Controls Width，或者直接指定一个Aspect Ratio。
• Content Size Fitter：根据子物体或自身内容（如Text组件的文本）自动调整RectTransform的大小。Horizontal Fit和Vertical Fit可以设置为Unconstrained、Min Size或Preferred Size。这在制作动态列表项、聊天气泡等场景中必不可少。

结合横竖屏的思考：在横屏模式下，屏幕更宽，你可能希望某些列表水平排列；而在竖屏模式下，则垂直排列。这可以通过在方向切换时，动态改变父物体的布局组件（如Horizontal Layout Group切换为Vertical Layout Group）并结合Content Size Fitter来实现。虽然听起来复杂，但预先设计好这种响应式UI结构，能极大提升应用在不同方向下的表现力。

4. 摄像机与游戏视图适配

UI适配好了，但游戏主视图（由摄像机渲染的3D/2D世界）也可能需要调整。特别是对于2D游戏或3D游戏中的固定视角。

4.1 正交摄像机的Size适配

对于2D游戏，摄像机通常是正交（Orthographic）的。其Size属性定义了视口高度的一半（以世界单位计）。当屏幕宽高比改变时，为了保持游戏内容在水平方向不被裁剪，我们需要动态计算摄像机的Size。

一个常见的做法是，在脚本中根据当前屏幕宽高比，调整摄像机的orthographicSize。基本逻辑是：以设计时的宽高比为基准，如果当前屏幕更“宽”（宽高比更大），则需要增大Size，以在水平方向显示更多内容。

// 挂载在主摄像机上 using UnityEngine; public class CameraAspectAdapter : MonoBehaviour { public float designAspectWidth = 16f; // 设计宽高比 16:9 public float designAspectHeight = 9f; public float designOrthographicSize = 5f; // 设计时的摄像机Size private Camera _camera; void Start() { _camera = GetComponent<Camera>(); if (_camera == null) _camera = Camera.main; AdaptCameraToAspect(); } void Update() { // 如果允许运行时旋转，可以在检测到分辨率变化时调用 // 更高效的做法是在Screen.orientation或Screen.width/height变化时调用，这里用Update简单演示 AdaptCameraToAspect(); } void AdaptCameraToAspect() { float designAspect = designAspectWidth / designAspectHeight; float currentAspect = (float)Screen.width / Screen.height; if (_camera.orthographic) { // 核心公式：如果当前屏幕比设计屏幕“更宽”，则按比例增加Size if (currentAspect > designAspect) { _camera.orthographicSize = designOrthographicSize * (designAspect / currentAspect); } else { _camera.orthographicSize = designOrthographicSize; } } // 对于透视摄像机，可能需要调整FOV，逻辑更复杂，通常用于特定类型的3D游戏 } }

4.2 透视摄像机的FOV与视口矩形

对于3D游戏，情况更多样。如果游戏是自由的3D视角，屏幕旋转可能意味着玩家需要转动视角，而非摄像机自动适配。此时，你可能需要锁定摄像机旋转，或者将设备旋转映射为游戏内的视角旋转。

如果仍需适配，一种方法是调整透视摄像机的Field of View（视野）。更宽的屏幕可能需要更宽的视野。另一种更高级的方法是使用Camera.rect来设置视口矩形，例如在横屏时让游戏视图占据屏幕一部分，另一部分显示UI。但这需要精细的布局计算。

个人经验：对于大多数3D手游，尤其是动作、RPG类，我倾向于锁定游戏画面为横屏，UI部分则做好横竖屏适配（如果UI需要独立旋转）。将设备旋转直接作为游戏内摄像机旋转输入的做法，虽然沉浸感强，但极易引起玩家眩晕，需谨慎设计。

5. 运行时高级检测与响应

当你的应用设置为Auto Rotation时，就需要在代码中监听和处理方向变化事件。Unity提供了多种方式。

5.1 监听Screen.orientation与分辨率变化

最直接的方法是轮询Screen.orientation属性。你可以在Update中检查其变化。

public class OrientationMonitorSimple : MonoBehaviour { private ScreenOrientation _lastOrientation; void Start() { _lastOrientation = Screen.orientation; } void Update() { if (Screen.orientation != _lastOrientation) { _lastOrientation = Screen.orientation; Debug.Log($"屏幕方向改变为: {_lastOrientation}"); OnOrientationChanged(_lastOrientation); } } void OnOrientationChanged(ScreenOrientation newOrientation) { // 在这里执行你的适配逻辑，如切换Canvas、调整布局等 if (newOrientation == ScreenOrientation.Portrait || newOrientation == ScreenOrientation.PortraitUpsideDown) { // 切换到竖屏UI布局 } else if (newOrientation == ScreenOrientation.LandscapeLeft || newOrientation == ScreenOrientation.LandscapeRight) { // 切换到横屏UI布局 } } }

同时，屏幕分辨率也可能在旋转时改变（例如，从1920x1080旋转为1080x1920）。你可以同时监听Screen.width和Screen.height的变化。为了性能，通常将这类检查放在协程中，以较低频率进行。

5.2 使用UnityEvent与自定义事件系统

轮询虽然简单，但不够优雅且耗电。更高效的方式是利用Unity的事件系统或自定义观察者模式。

一个常见的模式是创建一个全局的DeviceOrientationManager单例类，它内部进行轮询检测，但在方向变化时，触发一个UnityEvent或 C# 标准event。

using UnityEngine; using UnityEngine.Events; public class DeviceOrientationManager : MonoBehaviour { public static DeviceOrientationManager Instance; public UnityEvent<ScreenOrientation> onOrientationChanged; public UnityEvent<Vector2Int> onResolutionChanged; // Vector2Int (width, height) private ScreenOrientation _currentOrientation; private Vector2Int _currentResolution; void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); _currentOrientation = Screen.orientation; _currentResolution = new Vector2Int(Screen.width, Screen.height); } void Update() { // 检测方向变化 if (Screen.orientation != _currentOrientation) { _currentOrientation = Screen.orientation; onOrientationChanged?.Invoke(_currentOrientation); } // 检测分辨率变化（通常伴随方向变化） Vector2Int newRes = new Vector2Int(Screen.width, Screen.height); if (newRes != _currentResolution) { _currentResolution = newRes; onResolutionChanged?.Invoke(_currentResolution); } } }

这样，任何需要响应方向变化的脚本（如UI管理器、摄像机控制器、游戏逻辑控制器），只需订阅这个事件即可，解耦了检测逻辑和响应逻辑。

5.3 处理Input.acceleration与重力感应

有些时候，你可能需要更精细的控制，或者想要实现类似“摇一摇”切屏的效果。这时可以利用设备的加速度计Input.acceleration。

通过读取加速度计数据，你可以判断设备在三维空间中的倾斜角度，从而推断用户意图。例如，当设备从竖屏自然旋转到接近横屏角度时，就触发界面切换。

public class TiltOrientationDetector : MonoBehaviour { public float landscapeThresholdAngle = 30f; // 与垂直方向夹角超过30度认为是横屏 public float portraitThresholdAngle = 10f; // 夹角小于10度认为是竖屏 public UnityEvent onBecameLandscape; public UnityEvent onBecamePortrait; private bool _isLandscape = false; void Update() { // 获取加速度计数据，忽略Z轴（前后倾斜） Vector3 acceleration = Input.acceleration; // 计算设备与垂直方向（重力方向）的夹角 float tiltAngle = Vector3.Angle(Vector3.up, acceleration); if (!_isLandscape && tiltAngle > landscapeThresholdAngle) { _isLandscape = true; onBecameLandscape?.Invoke(); } else if (_isLandscape && tiltAngle < portraitThresholdAngle) { _isLandscape = false; onBecamePortrait?.Invoke(); } } }

注意事项：加速度计数据比较“嘈杂”，直接使用可能导致界面在临界点频繁切换。务必加入迟滞区间（Hysteresis）和低通滤波（Low-pass filter）来平滑数据，提升体验。上面的landscapeThresholdAngle和portraitThresholdAngle设置不同值，就是简单的迟滞处理。

6. 第三方插件与SDK的兼容性处理

这是横竖屏适配中最令人头疼的“深水区”。许多第三方SDK（如广告、支付、社交分享、数据分析）有其自己的界面或活动（Activity），它们可能不遵循你的应用方向设置。

6.1 广告SDK的适配难题

大多数广告SDK（如AdMob, Unity Ads, IronSource）在展示插屏、横幅或激励视频时，会弹出自己的全屏界面。这些界面通常由SDK内部控制方向。

• 横幅广告：通常需要你指定其期望的方向（横屏或竖屏）。如果设置不当，在屏幕旋转时，横幅可能错位或消失。解决方案：在方向改变事件中，销毁旧的横幅视图，并按照新方向重新请求和创建横幅。注意处理可能出现的请求延迟和空白期。
• 插屏与激励视频：这些是全屏活动。许多SDK允许你设置广告的“方向”，但实际行为取决于广告素材本身和SDK的实现。最佳实践：在请求广告时，传入当前应用的方向作为参数。如果SDK不支持，你可能需要暂时锁定屏幕方向（通过Screen.orientation = ScreenOrientation.XXX）再展示广告，广告关闭后再恢复自动旋转。务必在OnApplicationPause等生命周期函数中测试，确保应用从后台返回时方向状态正确。

6.2 Android与iOS原生界面集成

如果你通过UnityEngine.iOS或AndroidJavaClass调用了原生系统的界面（如日期选择器、相册、文件浏览器），这些界面会遵循系统或它们自身的默认方向。

• iOS：你可以通过UnityAppController的修改来影响所有视图的方向，但这需要编写原生插件（Objective-C/Swift代码），比较复杂。
• Android：如前所述，方向由Activity的android:screenOrientation控制。如果你启动了一个新的Activity（例如，通过AndroidJavaClass调用相机），这个新Activity的方向可能由它的Manifest决定。一个折中的办法是，在启动原生界面之前，将Unity的Activity也锁定到某个方向，待原生界面返回后再解锁。但这会影响用户体验。

通用建议：在项目初期就调研所有计划集成的SDK对横竖屏的支持情况。查阅其官方文档，寻找关于屏幕方向或Activity生命周期的配置项。在测试阶段，必须对每个SDK功能进行横竖屏旋转测试，尽早发现问题。

7. 常见问题排查与解决方案实录

以下是我在多年开发中积累的“踩坑”记录和解决方案，希望能帮你节省大量调试时间。

7.1 问题：屏幕旋转后UI布局“跳动”或错位

现象：旋转屏幕瞬间，UI元素会先跳到错误位置，然后再动画或瞬间调整到正确位置。根因：这通常是因为UI元素的布局计算（Layout Group, Content Size Fitter）和Canvas Scaler的缩放计算在不同帧完成，存在一帧的延迟或顺序问题。解决方案：

1. 强制重建布局：在方向变化后，手动调用LayoutRebuilder.ForceRebuildLayoutImmediate(RectTransform root)。你可以遍历所有受影响的Canvas或顶级UI面板。

   Canvas.ForceUpdateCanvases(); // 先强制更新所有Canvas LayoutRebuilder.ForceRebuildLayoutImmediate(yourRootRectTransform);

2. 使用协程延迟一帧：有时问题是因为同一帧内多次修改布局导致的。可以将布局调整代码放在yield return null;之后执行，确保在下一帧所有属性都已更新完毕。
3. 检查锚点动画：如果你使用了DoTween、LeanTween等动画插件来移动UI，确保在旋转时正确停止了旧动画并开始了新动画，避免动画目标值冲突。

7.2 问题：横竖屏切换时，游戏画面出现黑边或拉伸

现象：3D游戏场景在旋转后，两边或上下出现黑色区域，或者场景被压扁/拉长。根因：摄像机视口（Viewport Rect）或投影矩阵（Projection Matrix）没有根据新的屏幕宽高比正确调整。解决方案：

1. 对于正交摄像机：使用第4.1节中的脚本动态计算orthographicSize。
2. 对于透视摄像机：
   • 如果希望场景始终填满屏幕，可以动态计算摄像机的fieldOfView或使用Camera.projectionMatrix。一个常见公式是：verticalFOV = 2 * arctan(tan(horizontalFOV/2) / aspectRatio)，但更简单的方法是保持垂直FOV不变，让水平FOV随宽高比变化，这通常更符合人眼感知。Unity的透视摄像机默认就是保持垂直FOV不变。
   • 如果你希望游戏画面保持固定比例（如4:3），而在其他比例屏幕上显示黑边（“信箱模式”），则需要计算并设置Camera.rect。例如，在16:9的屏幕上显示4:3内容，左右会有黑边。你需要计算出一个居中的、宽度为屏幕宽度*(3/4)的矩形作为视口。

   float targetAspect = 4.0f / 3.0f; float windowAspect = (float)Screen.width / Screen.height; float scaleHeight = windowAspect / targetAspect; Camera camera = GetComponent<Camera>(); if (scaleHeight < 1.0f) // 屏幕更窄 { Rect rect = camera.rect; rect.width = 1.0f; rect.height = scaleHeight; rect.x = 0; rect.y = (1.0f - scaleHeight) / 2.0f; camera.rect = rect; } else // 屏幕更宽 { float scaleWidth = 1.0f / scaleHeight; Rect rect = camera.rect; rect.width = scaleWidth; rect.height = 1.0f; rect.x = (1.0f - scaleWidth) / 2.0f; rect.y = 0; camera.rect = rect; }

7.3 问题：Input.touch 坐标在旋转后不正确

现象：触摸位置，特别是在处理拖拽、点击判断时，旋转屏幕后坐标对不上。根因：Input.touch.position返回的是基于屏幕像素的坐标（左下角为(0,0)）。当屏幕旋转，坐标系也随着设备物理方向旋转，但你的UI或游戏世界坐标系可能没有同步转换。解决方案：

1. 对于UI点击检测：直接使用EventSystem.current.IsPointerOverGameObject(touch.fingerId)来判断是否点在UI上。UGUI的GraphicRaycaster会自动处理坐标转换。
2. 对于世界空间点击（如3D物体）：使用Camera.ScreenToWorldPoint或Camera.ScreenPointToRay时，确保传入的屏幕坐标是正确的。在旋转后，用于射线检测的摄像机（如主摄像机）的视口可能已通过Camera.rect调整过，ScreenToWorldPoint会考虑这一点。但如果你有多个摄像机或自定义的输入逻辑，需要确保传入的坐标是相对于正确视图的。
3. 自行转换坐标：如果你需要原始的、与方向无关的坐标，可以使用Input.GetTouch(0).rawPosition（如果平台支持），或者根据Screen.orientation手动转换Input.touch.position。例如，在横屏LandscapeLeft模式下，物理屏幕的(0,0)可能在逻辑左下角，但你的游戏可能将逻辑(0,0)定义在左下角（无论方向），这时就需要一个旋转矩阵来转换。更简单的方法是：始终使用Screen.width和Screen.height来归一化触摸坐标，将其转换到[0,1]区间，再乘以你的逻辑分辨率。

7.4 问题：应用从后台唤醒后，屏幕方向错乱

现象：用户将应用切到后台，旋转了设备，再切回应用，发现方向没有更新，或者UI布局状态不对。根因：应用进入后台（OnApplicationPause(true)）时，Unity可能暂停了部分协程或更新逻辑。当应用回到前台（OnApplicationPause(false)）时，Screen.orientation或分辨率可能已经改变，但你的检测脚本可能错过了这次变化。解决方案：

1. 在OnApplicationPause中处理：当pause为false（回到前台）时，强制检查一次当前方向并应用适配。

   void OnApplicationPause(bool pauseStatus) { if (!pauseStatus) // 回到前台 { // 立即更新方向 StartCoroutine(ForceUpdateOrientationNextFrame()); } } IEnumerator ForceUpdateOrientationNextFrame() { yield return null; // 等待一帧，确保Unity内部状态已更新 // 调用你的方向更新函数 OnOrientationChanged(Screen.orientation); }

2. 使用OnRectTransformDimensionsChange消息：UI元素上的脚本可以实现OnRectTransformDimensionsChange方法。当Canvas或UI元素的RectTransform尺寸因屏幕旋转而改变时，此方法会被调用。你可以在这里触发布局刷新。这对于纯UI的适配非常直接。

7.5 问题：WebGL或模拟器上的方向测试不准

现象：在Unity Editor或WebGL构建中，通过快捷键或菜单旋转游戏视图，效果与真机不一致。根因：Editor和某些平台（如WebGL）对屏幕方向的模拟是有限的。Screen.orientation在Editor中可能返回ScreenOrientation.Unknown或ScreenOrientation.AutoRotation。解决方案：

1. 在Editor中测试：使用Game视图顶部的“Aspect Ratio”下拉菜单，手动切换不同的分辨率（如 9:16 Portrait, 16:9 Landscape）来模拟。同时，编写一个测试脚本，用键盘按键（如空格键）来手动触发你的方向切换逻辑，模拟Screen.orientation变化。
2. 构建到真机测试：这是唯一可靠的方式。尤其要测试不同厂商的安卓设备（三星、小米、华为等），因为它们的系统对方向管理的细节可能有差异。iOS设备相对统一，但也需要测试不同型号。
3. 使用条件编译：在代码中，对于方向检测，可以使用#if UNITY_EDITOR ... #else ... #endif来区分编辑器逻辑和真机逻辑，确保测试的便捷性。

横竖屏适配是一个贯穿移动端开发始终的细节工程。它没有太多高深的理论，但极其考验开发者的细心、耐心和对系统机制的理解。我的建议是，在项目原型阶段就确定好方向策略，并尽早开始在真机上进行多方向测试。将适配逻辑模块化、事件化，避免散落在代码的各个角落。记住，稳定的体验远比炫酷的效果更能留住用户。