1. 异形屏适配为什么成了Unity移动端发布绕不开的坎做过Unity移动端项目的朋友大概都有过这种体验在编辑器里用Game视图的几种标准分辨率跑得好好的UI一旦真机打包出来要么顶部被刘海挡住一截要么底部被手势条压住要么左右两边在曲面屏上被裁掉一块。这不是你的UI做得不好而是屏幕形态的碎片化已经远远超出了几年前16:9打天下的时代。所谓异形屏指的是带有刘海、挖孔、水滴、曲面边缘、圆角以及底部手势指示条的非规则屏幕。从早期的单摄刘海到现在的居中挖孔、屏下摄像头再到折叠屏展开后的方形比例Android阵营的屏幕比例从16:9一路演变到20:9、21:9甚至更极端。iOS这边虽然机型数量少但刘海和灵动岛区域的安全区处理同样不能忽视。这些变化对UGUI的布局系统提出了一个很现实的要求你的Canvas不能假设自己拥有一块完整的矩形画布。这篇内容我想聊的是在Unity里发布iOS和Android包时UGUI面对异形屏到底该怎么适配。我会从安全区的底层逻辑讲起把Canvas Scaler的选型、锚点策略、真机验证流程、以及那些文档里不会写的坑一条条拆开说清楚。不管你是刚接触移动端发布的新手还是被某个机型适配问题卡了半天的老手应该都能从里面找到能直接抄作业的东西。需要先明确一个前提异形屏适配不是加一个SafeArea组件就完事这么简单。它涉及到UI整体布局策略、单个元素锚点、Canvas渲染模式、以及不同平台安全区API的差异这几个层面。只处理其中一层往往会在某些机型上翻车。下面我按实际项目里的处理顺序从最外层的画布配置一路讲到最细的元素级调整。2. 安全区机制与Unity里的获取方式2.1 安全区到底是个什么东西安全区Safe Area是系统给出的一个矩形区域告诉应用这块区域内的内容不会被刘海、圆角、挖孔或手势条遮挡。你可以把它理解成屏幕这块地皮上真正可以安全盖房子的那块地。屏幕的物理分辨率是整块地安全区是扣掉了边角障碍之后的有效区域。在iOS上这个信息通过UIView.safeAreaInsets暴露出来Unity在Screen.safeArea里做了封装。Android这边情况复杂一些早期版本没有统一的安全区概念需要通过WindowInsets来获取Unity从2019版本之后逐步在Screen.safeArea里做了兼容。但要注意不同Android厂商对安全区的实现并不完全一致有些厂商在特定场景下返回的安全区可能不准确这是后面要专门讲的坑。Screen.safeArea返回的是一个Rect坐标是相对于屏幕左下角原点的像素值。它的x和y是安全区左下角的位置width和height是安全区的尺寸。关键点在于这个Rect的坐标系和UGUI的坐标系不是一回事直接拿来用会出问题必须做转换。2.2 把安全区映射到Canvas上UGUI的Canvas在Screen Space - Overlay模式下它的坐标系原点在屏幕中心或者左下角取决于你的锚点设置。而Screen.safeArea用的是屏幕像素坐标原点在左下角。这两者之间需要一个映射。常见的做法是拿到安全区后计算出它相对于整屏的四个边距比例Rect safeArea Screen.safeArea; Vector2 anchorMin safeArea.position; Vector2 anchorMax safeArea.position safeArea.size; anchorMin.x / Screen.width; anchorMin.y / Screen.height; anchorMax.x / Screen.width; anchorMax.y / Screen.height;算出来的anchorMin和anchorMax就是归一化后的锚点值可以直接赋给一个全屏RectTransform的anchorMin和anchorMax。这样这个RectTransform就会自动贴合安全区里面的UI元素再基于它做布局就能避开异形区域。这里有个容易忽略的细节Screen.safeArea在Awake阶段可能还没准备好。尤其是在Android上安全区信息有时候要等到第一帧渲染之后才准确。如果你在Awake里读一次就完事可能会拿到全屏的默认值。稳妥的做法是在Start里读或者监听屏幕方向变化和分辨率变化的事件在变化时重新计算。2.3 安全区不是万能的我得泼一盆冷水安全区只保证内容不被物理遮挡但它不保证视觉上的舒适。比如一个按钮刚好贴着安全区边缘虽然没被挡住但视觉上会显得很挤用户点起来也别扭。所以实际项目里我通常会在安全区的基础上再留一圈视觉边距一般上下各留8到16个像素按参考分辨率算让内容看起来更从容。另外安全区在横屏和竖屏下的表现完全不同。竖屏时刘海在顶部安全区主要影响上边距横屏时刘海跑到左侧或右侧安全区就变成影响左右边距了。如果你的游戏支持横竖屏切换安全区的计算逻辑必须跟着屏幕方向走不能写死。3. Canvas Scaler的三种模式选错了后面全是坑3.1 Constant Pixel Size为什么它几乎不适合移动端Constant Pixel Size模式下UI元素的大小以像素为单位固定不随屏幕分辨率缩放。这意味着在1080p手机上看着正好的按钮到了2K屏上会变得很小到了720p屏上又会显得很大。对于需要覆盖多种机型的移动端项目这个模式基本可以直接排除。它唯一适用的场景是那种对像素精度要求极高、且目标机型分辨率高度统一的项目比如某些工业控制界面。普通游戏和应用不要碰。3.2 Scale With Screen Size移动端的主流选择这是绝大多数移动端项目该用的模式。它通过一个参考分辨率把UI按比例缩放到实际屏幕上。核心参数有两个Reference Resolution和Match。Reference Resolution一般设成你美术出图时用的分辨率常见的是1920x1080或者1080x1920竖屏。这个值本身不影响最终效果它只是一个基准真正决定缩放行为的是Match值。Match值在0到1之间。0表示完全按宽度匹配1表示完全按高度匹配0.5表示宽高各占一半。这个值的选择直接决定了你的UI在不同宽高比屏幕上的表现Match值行为适用场景风险0宽度优先宽度铺满高度按比例横屏游戏、宽内容为主高瘦屏上上下留黑边或内容溢出1高度优先高度铺满宽度按比例竖屏应用、列表为主宽屏上左右留白或内容被裁0.5均衡宽高折中通用场景极端比例下两边都不完美我的经验是竖屏项目Match设0.5到0.7之间横屏项目设0.3到0.5之间。具体值要拿目标机型列表跑一遍看UI元素有没有溢出或者过度留白。没有一个万能值必须实测。3.3 Constant Physical Size被低估的选项这个模式按物理尺寸英寸、厘米来缩放UI理论上能让按钮在大小不同的屏幕上保持一致的物理大小。听起来很美好但实际用的人很少原因是它依赖Screen.dpi这个值而很多Android设备的dpi上报是不准确的导致UI大小飘忽不定。除非你的项目对物理尺寸有硬性要求比如某些医疗或测量类应用否则不建议用。3.4 Canvas Scaler和异形屏的配合选好模式之后还要注意Canvas Scaler和前面说的安全区容器怎么配合。我的做法是Canvas Scaler负责整体缩放安全区容器负责避让异形区域两者各管各的。安全区容器是一个全屏的RectTransform它的锚点被安全区归一化值驱动Canvas Scaler的缩放作用在它上层。这样无论屏幕怎么变缩放和避让是解耦的调试起来清晰。如果反过来把安全区逻辑塞进Canvas Scaler里一旦出问题就很难定位是缩放错了还是避让错了。分层处理是更稳的工程做法。4. 锚点与布局让每个UI元素自己会躲4.1 锚点系统的本质UGUI的锚点Anchor决定了子元素相对于父元素的位置关系。很多人对锚点的理解停留在四个小三角其实它的本质是一套比例定位系统。当父元素尺寸变化时子元素的锚点会按比例重新计算位置。举个具体的例子一个按钮的锚点设成左上角anchorMin和anchorMax都是(0,1)那么无论父容器怎么缩放这个按钮永远贴着左上角。如果锚点设成四角拉伸anchorMin(0,0)anchorMax(1,1)那么按钮会跟着父容器一起拉伸。理解了这个异形屏适配就成功了一半。4.2 顶部和底部元素的锚点策略异形屏适配里最容易出问题的就是顶部和底部的元素。顶部有刘海或挖孔底部有手势条。我的处理原则是顶部元素锚点统一设为顶部但不要贴死屏幕顶边而是贴安全区容器的顶边。这样刘海区域自然被避开。底部元素同理锚点设为底部贴安全区容器底边避开手势条。中间元素锚点设为居中它们不受异形区域影响正常处理即可。关键在于所有顶部和底部元素都应该是安全区容器的子物体而不是直接挂在Canvas下。这样安全区容器一动它们跟着动不需要每个元素单独写适配代码。4.3 全屏背景图怎么处理背景图是个特殊存在。它需要铺满整个屏幕包括异形区域否则刘海旁边会出现黑边很难看。但背景图又不能被安全区限制否则就铺不满了。我的做法是背景图挂在Canvas下锚点四角拉伸不放进安全区容器。这样它铺满全屏异形区域也被覆盖。而前景的UI元素放进安全区容器避开异形区域。背景和前景分层处理各取所需。如果背景图有重要的视觉信息比如logo、角色立绘那这些信息要放在安全区内背景的纯色或纹理部分可以延伸到异形区域。这需要美术出图时就考虑好安全区范围留出可裁切的边缘。4.4 用Layout Group时的注意事项用Horizontal Layout Group、Vertical Layout Group这类自动布局组件时要特别注意它们和锚点的配合。Layout Group会覆盖子元素的锚点设置按自己的规则排列。如果安全区容器里放了Layout Group容器尺寸变化时Group内的元素会重新排列这通常是想要的效果。但如果Group的padding设置不当元素可能还是会挤到安全区边缘。我的建议是在Layout Group的padding里预留安全区边距或者把Group放进安全区容器后再给Group本身加一层padding。具体加多少按参考分辨率换算一般上下各留20到40像素比较舒服。5. 真机验证编辑器里永远测不出真问题5.1 为什么Game视图靠不住Unity编辑器的Game视图可以模拟各种分辨率甚至能模拟刘海屏。但它模拟的安全区是理想化的和真机有差距。尤其是Android不同厂商对安全区的处理千差万别编辑器里模拟出来的效果只能作为参考不能作为最终依据。我踩过的最典型的坑是编辑器里安全区显示正常真机上某个品牌的手机安全区返回了错误的值导致UI整体偏移。这种问题只有在真机上才能发现。5.2 建立真机测试矩阵不要指望一台手机测完就发布。至少要覆盖以下几类设备iOS带刘海的机型、带灵动岛的机型、无刘海的旧机型各一台。Android不同厂商各一台重点覆盖曲面屏、挖孔屏、折叠屏。分辨率至少覆盖1080p、2K、以及一种非标准比例如20:9。如果手头设备有限可以用云真机平台补充。测试时重点看顶部状态栏区域、底部手势条区域、左右曲面边缘这三处的UI有没有被遮挡或裁切。5.3 运行时调试安全区真机调试时我习惯加一个临时的调试开关把安全区的边界画出来。用一个半透明的Image或者OnGUI画四条线标出安全区的范围。这样一眼就能看出UI有没有超出安全区。void OnGUI() { if (!debugSafeArea) return; Rect sa Screen.safeArea; // 注意GUI坐标系y轴向下需要翻转 float y Screen.height - sa.y - sa.height; GUI.color Color.red; GUI.DrawTexture(new Rect(sa.x, y, sa.width, 2), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x, y sa.height - 2, sa.width, 2), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x, y, 2, sa.height), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x sa.width - 2, y, 2, sa.height), Texture2D.whiteTexture); }这个调试代码在发布前记得关掉或删掉别带到正式包里。5.4 屏幕旋转和分辨率变化的监听移动设备会旋转屏幕折叠屏会改变形态这些都会触发安全区变化。必须监听Screen.orientation和分辨率变化在变化时重新计算安全区并更新容器。void Update() { if (lastSafeArea ! Screen.safeArea || lastOrientation ! Screen.orientation) { RefreshSafeArea(); lastSafeArea Screen.safeArea; lastOrientation Screen.orientation; } }每帧比较Screen.safeArea有一点性能开销但很小可以接受。如果追求极致可以只在orientation变化时刷新但有些Android设备旋转时orientation不一定及时更新所以比较safeArea更保险。6. 那些年我在异形屏上踩过的坑6.1 Android安全区返回全屏的诡异情况前面提过某些Android设备在特定场景下Screen.safeArea会返回全屏也就是没有安全区。这时候如果你完全依赖安全区UI就会贴到刘海下面。我的应对策略是设置一个最小安全边距兜底。如果检测到安全区等于全屏或者边距小于某个阈值就手动应用一个默认边距比如顶部留30像素、底部留20像素按参考分辨率。这个兜底值不需要很精确它的作用是防止UI完全贴边而不是精确适配。真机上大部分情况安全区是准的兜底只是应对异常。6.2 曲面屏边缘的误触和裁切曲面屏的左右边缘是弧形的安全区通常会把这块排除掉但有些厂商的安全区给得比较保守导致左右留白过多UI显得很窄。另一种情况是安全区没排除曲面区域UI元素被弧边裁掉一部分。处理曲面屏我的经验是左右各留至少16像素的额外边距即使安全区没要求。因为曲面边缘不仅影响显示还影响触控用户手指在弧边上的点击可能不准确。留出边距既是为了显示也是为了操作体验。6.3 折叠屏展开后的比例突变折叠屏从折叠态到展开态屏幕比例可能从21:9变成接近正方形。这时候如果Match值设得不好UI会严重变形。我的做法是为折叠屏单独准备一套布局参数在检测到屏幕比例超过某个阈值时切换。Unity没有内置的折叠屏检测API但可以通过屏幕宽高比来判断比如宽高比小于1.2时认为是展开态。6.4 打包后的首帧闪烁有时候打包出来第一帧UI会闪一下然后才跳到正确位置。这是因为安全区在第一帧还没算好UI先按默认位置渲染了一帧。解决办法是在安全区计算完成前先把UI容器隐藏或者透明度设为0算好之后再显示。虽然只闪一帧但用户能察觉到体验不好。6.5 iOS和Android的安全区差异iOS的安全区比较规范刘海和灵动岛的处理一致。Android则碎片化严重同一个安全区API在不同厂商那里行为可能不同。我的建议是针对Android做更宽松的兜底不要假设安全区一定准确。iOS可以相对信任系统返回值Android则要留一手。7. 一套可复用的适配方案落地7.1 整体架构设计把前面讲的东西串起来一套完整的适配方案包含这几层Canvas层Canvas Scaler用Scale With Screen SizeMatch值按项目类型设定。背景层全屏拉伸覆盖异形区域。安全区容器层全屏RectTransform锚点由安全区归一化值驱动。内容层所有前景UI作为安全区容器的子物体按锚点规则布局。兜底层安全区异常时应用默认边距。调试层开发期可视化安全区发布前移除。这个架构的好处是职责清晰每一层只管自己的事。出问题时能快速定位是哪一层的问题。7.2 核心代码实现安全区容器的核心脚本大概长这样using UnityEngine; public class SafeAreaFitter : MonoBehaviour { [SerializeField] private bool debugDraw false; [SerializeField] private float minTopMargin 30f; [SerializeField] private float minBottomMargin 20f; private RectTransform rectTransform; private Rect lastSafeArea; private ScreenOrientation lastOrientation; void Awake() { rectTransform GetComponentRectTransform(); ApplySafeArea(); } void Update() { if (lastSafeArea ! Screen.safeArea || lastOrientation ! Screen.orientation) { ApplySafeArea(); } } void ApplySafeArea() { Rect safeArea Screen.safeArea; lastSafeArea safeArea; lastOrientation Screen.orientation; Vector2 anchorMin safeArea.position; Vector2 anchorMax safeArea.position safeArea.size; anchorMin.x / Screen.width; anchorMin.y / Screen.height; anchorMax.x / Screen.width; anchorMax.y / Screen.height; // 兜底安全区异常时应用最小边距 if (anchorMin.y * Screen.height minBottomMargin) { anchorMin.y minBottomMargin / Screen.height; } if ((1 - anchorMax.y) * Screen.height minTopMargin) { anchorMax.y 1 - minTopMargin / Screen.height; } rectTransform.anchorMin anchorMin; rectTransform.anchorMax anchorMax; rectTransform.offsetMin Vector2.zero; rectTransform.offsetMax Vector2.zero; } void OnGUI() { if (!debugDraw) return; Rect sa Screen.safeArea; float y Screen.height - sa.y - sa.height; GUI.color Color.red; GUI.DrawTexture(new Rect(sa.x, y, sa.width, 2), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x, y sa.height - 2, sa.width, 2), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x, y, 2, sa.height), Texture2D.whiteTexture); GUI.DrawTexture(new Rect(sa.x sa.width - 2, y, 2, sa.height), Texture2D.whiteTexture); } }把这个脚本挂到安全区容器上容器下的所有UI就自动避让异形区域了。minTopMargin和minBottomMargin按你的参考分辨率调整。7.3 和美术的协作规范适配不只是程序的事美术出图时就要考虑安全区。我会给美术一份安全区模板标出不同机型下哪些区域是安全的、哪些可能被裁切。重要视觉元素logo、按钮、文字放在安全区内装饰性元素可以延伸到边缘。具体做法是按最窄的安全区通常是刘海屏竖屏画一个内框所有关键内容放内框里。外框到内框之间的区域作为可裁切区放背景纹理、渐变之类的元素。这样一套图能适配绝大多数机型。7.4 发布前的检查清单打包前我会过一遍这个清单[ ] Canvas Scaler模式正确Match值经过真机验证[ ] 安全区容器脚本已挂载兜底边距已设置[ ] 所有顶部和底部UI都是安全区容器的子物体[ ] 背景图全屏拉伸未被安全区限制[ ] 调试代码已关闭或移除[ ] 至少3台不同形态真机验证通过[ ] 横竖屏切换测试通过[ ] 折叠屏如有测试通过这个清单看起来简单但每一条都是踩过坑之后加上的。尤其是最后几条很多团队发布前会漏掉结果上线后被用户反馈才发现。7.5 性能上的考量安全区适配本身性能开销很小主要开销在每帧比较Screen.safeArea。如果项目对性能敏感可以改成只在orientation变化时刷新或者用事件驱动。但说实话这点开销在绝大多数项目里可以忽略没必要过度优化。真正需要注意的是安全区容器的层级不要嵌套太深。每多一层RectTransform布局计算就多一次。把安全区容器放在Canvas下的第一层内容直接挂在它下面层级越扁平越好。8. 关于适配这件事我最后想说的异形屏适配说到底是一个**假设屏幕是矩形到承认屏幕不是矩形的思维转变**。很多老项目在16:9时代积累的布局习惯到了异形屏时代就不适用了。与其在每个机型上打补丁不如从架构上就把安全区当成一等公民来对待。我个人的体会是适配工作最值钱的部分不是写代码而是建立一套可验证的流程。代码网上都能搜到但知道在什么机型上测什么、怎么判断适配是否合格、出问题怎么定位这些才是经验的价值。上面那套方案和清单是我在多个项目里反复打磨出来的你可以直接拿去用也可以根据自己的项目特点调整。最后分享一个小技巧如果项目周期紧来不及做完整的真机测试矩阵至少要把最极端的两种机型测了——最宽的屏和最窄的屏。这两种机型能覆盖大部分适配问题剩下的边角情况可以上线后根据反馈再修。当然这只是应急方案有条件还是老老实实把测试矩阵跑全。
