企业官网建设流程全解析

Unity开发里，自定义游戏界面形状/分辨率是个埋了很多暗坑的主题。我前阵子接手一个模拟项目X，美术给了一套圆形小地图、圆角按钮和不规则面板的设计稿，第一版是在固定模拟分辨率下做出来的，看着很正常。结果一上真机，长屏上小地图被挤到安全区外，底部按钮被手势条挡住，圆形技能的点击响应还带着矩形死角。那段时间我基本把所有和UI形状、分辨率相关的方案都试了一遍，这篇就把我认为真正能落地的做法从头梳理一遍，包括Canvas怎么配置、RectTransform锚点怎么摆、异形界面用什么路线做、点击区域怎么和视觉同步，以及异形屏安全区怎么处理。适合正在做多机型适配、或者被“UI会变形/乱跑”困扰的开发者参考。

整篇的核心逻辑其实就一句话：先搞清楚坐标系，再谈形状和适配。很多问题不是数值填错，而是没有理解Unity UI的尺寸在什么空间里被计算。下面我从最基础的坐标系讲起，逐步把每个环节的实操细节拆开。

1. 为什么游戏UI会变形：从屏幕坐标系到Canvas模式的对应关系

1.1 分辨率变形的根因在“参考坐标系”

先说一个最常见的误解：很多人以为Unity UI的坐标单位就是屏幕像素，但实际上Canvas有一套独立的坐标空间，单位是“Canvas Unit”。默认情况下Canvas Scaler会把Canvas单位换算到屏幕像素，换算系数就是缩放因子。不同手机屏幕宽度和高度不同，这个系数也会变。

打个比方：你把一张100x100的图片放在Canvas里，如果Canvas Scaler按绝对像素模式工作，它在任何分辨率下都显示为100像素大小。小屏幕手机上它可能占了屏幕四分之一，大平板上它只有指甲盖大；而如果换成按屏幕宽度缩放，图片在宽度上始终占据固定的百分比，形状的比例关系就稳定了。

所以“UI会变形/跑偏”的根因，通常不是某个按钮坐标不对，而是没有统一的参考系。你需要先有一个明确的设计分辨率，再让所有UI元素在这个分辨率下按比例映射到真实屏幕上。这个映射过程由Canvas Scaler完成，但Canvas有三种渲染模式，选错了参考系也会出问题。

1.2 Canvas三种渲染模式的选择逻辑

Unity的Canvas有三种Render Mode，它们对坐标和像素换算的影响完全不同，我直接用表格梳理：

实际操作中，界面适配基本都用Screen Space Overlay。好处是坐标系直观，CanvasScaler把所有缩放都处理好，不需要担心相机投影带来的额外变形。Screen Space Camera多数用于特殊HUD，比如要跟摄像机做景深互动或后处理特效时；World Space则很少用来做常规界面，因为它的尺寸是世界单位，不随屏幕分辨率变化。

1.3 一个典型问题：不同机型上按钮位置“跑偏”的排查思路

我之前在项目里遇到一个“开始”按钮，用固定Position写死，设计分辨率下在正中偏下，结果一到高分辨率长屏手机，按钮跑到屏幕中间偏上，四角元素直接被刘海遮挡。排查时先看CanvasScaler，发现这个Canvas连CanvasScaler组件都被误删了，UI自然按绝对像素显示。

正确的排查链路应该是：

1. 检查Canvas上是否挂CanvasScaler，UI Scale Mode是不是Scale With Screen Size。
2. 确认Reference Resolution和你的设计稿一致。
3. 检查按钮的锚点是否使用了“居中/边缘停靠/拉伸”等相对模式，而不是靠绝对坐标硬顶。
4. 在Game视图手动切几个常见分辨率，观察RectTransform的虚线框是否按预期拉伸。
5. 最后再看SafeArea是否有影响。

大多数“跑偏”问题，在锚点和CanvasScaler正确之后就已经解决了，根本不需要写一堆屏幕判断逻辑去手动改位置。

2. 分辨率自适应的核心操作：Canvas Scaler参数与锚点布局的实战搭配

2.1 Canvas Scaler的参数到底怎么填

CanvasScaler的UI Scale Mode有三种，实际主力配置是Scale With Screen Size，但很多人不知道Match Width or Height里的match值到底在算什么。

Unity的计算公式是：

logWidth = Log2(screenWidth / referenceWidth) logHeight = Log2(screenHeight / referenceHeight) scaleFactor = Exp2(logWidth * (1 - match) + logHeight * match)

这个公式不用背，但要理解含义：

• match = 0，表示完全以宽度为准缩放，竖屏游戏在宽度固定后，高度方向会溢出或留黑。
• match = 1，表示完全以高度为准缩放，横屏游戏常用这种方式。
• match = 0.5，是宽度和高度各取一半权重，适合横竖屏都有需要、UI元素没有极端贴边的项目。

实际项目里我的习惯是：竖屏主界面参考分辨率设成1080x1920，match设0.5，用SafeArea再做一圈收边；横屏战斗界面参考分辨率设成1920x1080，match同样0.5，重点按钮全部用锚点固定在安全区域附近。

需要注意的是Constant Pixel Size模式，它不做任何缩放，1个Canvas单位永远是1像素。像素风游戏、需要绝对像素级控制的局部控件可以用，但绝不可能用来做跨分辨率主界面。Constant Physical Size则更适合做需要物理尺寸一致的UI，比如打印、或者AR中需要按真实长度显示的悬浮标签，游戏常规UI很少用到。

2.2 锚点、Pivot与四角吸附：UI不跑偏的实战排布

RectTransform是UI布局的核心，这里面的锚点体系必须熟练掌握。锚点的本质是：把父物体的某几个参考点，映射到子物体自身的对应位置。你可以把锚点理解成图钉，图钉钉在父物体什么位置，子物体就贴在那里缩放。

几个高频配置我直接列出来：

其中全屏背景是最好记的：锚点min设为(0,0)，max设为(1,1)，偏移全部清零。这样不管屏幕比例变成多少，背景都会自动撑满，不会露黑边。

底部居中按钮则用“点锚点”的思路：min和max设同一个值，按钮的锚点就缩成一个点。配合Pivot在底部中心，再用anchoredPosition设置相对父锚点的距离，这个距离在Canvas Scaler的缩放体系下会随参考分辨率等比变化，所以逻辑上是自适应的。

一个常见的错误是直接改RectTransform.position，在World Space或Screen Space Camera下可能看不出来，但Overlay模式下一遇到Canvas缩放就会出问题。UI元素改动位置，尽量走anchoredPosition，不要走position。

2.3 用GridLayout和AspectRatioFitter处理动态数量和比例

很多时候界面变形不只是单个按钮的问题，而是动态列表在不同分辨率下换行完全不一样。比如背包格子，竖屏一行4个，横屏一行8个，如果每个格子固定100x100，很容易出现最后一行留空或挤压。

GridLayoutGroup的Constraint设为Fixed Column Count，然后指定Column Count，Unity会自动计算行数。这样在竖屏下固定4列，横屏下会保持4列但格子变宽；如果你想让横屏时列数也动态变化，就需要在代码里根据Screen.aspect或Canvas引用分辨率实时改Column Count，并在Awake或分辨率变化回调里触发。

保持格子不变形可以用AspectRatioFitter，AspectMode选FitInParent，AspectRatio设1，让格子的宽度始终等于高度，但这个方法要放在GridLayoutGroup计算完之后，如果你在同一个物体上同时用GridLayoutGroup和AspectRatioFitter，要注意执行顺序，否则格子会被拉伸出来。

经验上，动态列表的适配原则是：列数可控、间距可调、个体不变形。宁可让列表区域变长，也不要让格子被压成非正方形。

3. 把界面“抠”成任意形状：Mask、九宫格与代码动态生成的三条路线

3.1 图片边缘要圆角/异形：Shape与Sprite的边界

先给一个观念：大多数异形UI，美术出带透明通道的图片就够了，不需要代码去“画形状”。真正需要代码介入的是两种情况：一是图片数量多、加载量大，想用纯程序化几何减少资源；二是需要动态改变形状，比如圆环、多边形按钮的形状跟随玩家状态变化。

如果只是圆角按钮、圆角面板，Unity的Image组件本身就有Sliced类型。在Sprite Editor里设置好Border，四个角的图像会被保留，中间区域自动拉伸，这样圆角不会变形。很多新手直接给Image拉大，把圆角图片的角部拉伸成椭圆，就是因为没有用Sliced模式。

Image还有Filled模式，配合FillMethod可以做圆形技能冷却、扇形技能范围、血条从满到空等效果。注意Radial 360和Radial 90的起始角度不同，不同项目的圆环起点方向也不一致，写之前先调好。

3.2 Mask与RectMask2D的取舍：可控裁剪与性能

圆形头像、异形面板、滚动窗口这些要“裁剪显示”的场景，Unity提供了Mask和RectMask2D两个组件。原理上两者都基于模板缓冲，但使用方式和性能差别很大。

Mask组件要挂在一张图片上，用图片的透明或者形状作为裁剪区域。步骤很简单：

1. 创建一个Image作为遮罩父物体。
2. 给这个Image加上Mask组件。
3. 把Shader设置成默认UI即可，子物体超出父物体形状的部分会被裁掉。

Mask的裁剪非常灵活，镂空形状也支持，但代价是它会引入额外的模板写入，往往会破坏UI合批，同一Canvas下大量使用Mask时，Canvas会被拆成很多小批次，DrawCall上升很明显。RectMask2D则只做矩形裁剪，性能好很多，适合聊天窗、滑动列表、任务面板这类矩形区域。

另外经常有人问SpriteMask能不能给UI用。SpriteMask是2D精灵遮罩，只影响SpriteRenderer，不影响UGUI的Image和Text，所以别用它来做UI裁剪，方向完全不同。

3.3 运行时代码生成不规则几何UI：动态Mesh + 顶点颜色

如果你不想依赖美术图片，又需要圆形、环形、六边形之类的界面基础形状，最稳定的做法是自定义一个MaskableGraphic子类，在OnPopulateMesh里直接生成网格。

下面这段代码可以生成一个圆环，内半径和外半径可调，也可以改成多边形按钮、盾牌形状等：

using UnityEngine; using UnityEngine.UI; [ExecuteAlways] public class RingGraphic : MaskableGraphic { [Range(3, 128)] public int segments = 64; public float radius = 100f; public float thickness = 20f; protected override void OnPopulateMesh(VertexHelper vh) { vh.Clear(); Vector2 center = rectTransform.rect.center; float outer = radius; float inner = Mathf.Max(0f, radius - thickness); int baseVert = 0; for (int i = 0; i < segments; i++) { float a0 = (float)i / segments * Mathf.PI * 2f; float a1 = (float)(i + 1) / segments * Mathf.PI * 2f; Vector2 p0 = center + new Vector2(Mathf.Cos(a0), Mathf.Sin(a0)) * outer; Vector2 p1 = center + new Vector2(Mathf.Cos(a1), Mathf.Sin(a1)) * outer; Vector2 p2 = center + new Vector2(Mathf.Cos(a1), Mathf.Sin(a1)) * inner; Vector2 p3 = center + new Vector2(Mathf.Cos(a0), Mathf.Sin(a0)) * inner; Color32 col = color; vh.AddVert(p0, col, new Vector2(0f, 1f)); vh.AddVert(p1, col, new Vector2(1f, 1f)); vh.AddVert(p2, col, new Vector2(1f, 0f)); vh.AddVert(p3, col, new Vector2(0f, 0f)); vh.AddTriangle(baseVert, baseVert + 1, baseVert + 2); vh.AddTriangle(baseVert, baseVert + 2, baseVert + 3); baseVert += 4; } } }

代码里的segments控制多边形逼近圆形的精细度，越大越圆，但顶点数也越多。实际项目里60个分段足够，不要默认填512，会产生不必要的网格开销。

使用这个组件时，直接在代码里AddComponent 即可，或者给类加上[AddComponentMenu("UI/RingGraphic")]让它出现在编辑器菜单里。属性变化后，务必调用SetVerticesDirty通知Canvas重新生成网格，否则改圆角、厚度不会刷新。

如果你需要的不只是一个圆环，而是任意封闭多边形，也可以在这个基础上修改，顶点坐标用多边形的顶点列表代替圆环内外圈，三角形索引用耳切法或简单扇形生成。

4. 可点击区域的形状同步：让每个像素的交互都和视觉一致

4.1 为什么圆形按钮点击一个角也有反应：Graphic的默认包围盒逻辑

假设你现在做了一颗圆形技能按钮，视觉上是圆形的，但玩家点击按钮左上角的透明区域，技能还是触发了。因为UGUI的GraphicRaycaster默认会把整个Image的矩形包围盒当成可点击区域，透明像素并不影响判定。

Unity的Image组件提供了一个属性alphaHitTestMinimumThreshold，可以按透明度裁剪点击区域。使用前提是Sprite纹理必须开启Read/Write Enabled，且纹理不是压缩格式。这个方案简单直接，适合按钮数量少、且单张纹理可控的小项目。

但我个人不太喜欢到处开Read/Write，因为会显著增加内存，尤其是图集纹理，开了之后整张图集都要常驻内存。所以对于异形按钮，我更推荐下一种纯数学方式。

4.2 为什么不建议用Collider做UI点击：渲染与事件坐标不一致

不少人第一反应是给UI加PolygonCollider2D，然后用物理射线检测。但Screen Space Overlay模式下没有实际的世界坐标空间，GraphicRaycaster并不走Physics，Collider自然不会被事件系统拾取。就算切换到Screen Space Camera并配置PhysicsRaycaster，也还要处理Canvas的缩放、EventCamera的投影矩阵，复杂度直线上升。

物理碰撞体更适合处理真正的场景物体点击，不适合做UI点击区域。UI点击检测应该由GraphicRaycaster的Raycast环节决定，而它允许我们通过实现ICanvasRaycastFilter来告诉系统“哪些位置无效”。

4.3 ICanvasRaycastFilter实现任意多边形点击检测：从理论到代码

ICanvasRaycastFilter是UGUI内置的接口，发送UI事件时会调用每个Graphic上的IsRaycastLocationValid。我们只要返回false，这个Graphic就会从候选中剔除。用这个机制，可以完全用数学判断多边形命中，不需要物理碰撞体，也不需要纹理可读。

射线法判断点在多边形内的思路很简单：从目标点向某一方向画一条射线，统计它穿过多边形边的次数，次数为奇数说明点在内部，偶数说明在外部。下面是我实际使用的一个工具组件：

using UnityEngine; using UnityEngine.UI; [RequireComponent(typeof(RectTransform))] public class PolygonRaycastFilter : MonoBehaviour, ICanvasRaycastFilter { [SerializeField] private Vector2[] localPoints; public bool IsRaycastLocationValid(Vector2 sp, Camera eventCamera) { RectTransform rect = (RectTransform)transform; RectTransformUtility.ScreenPointToLocalPointInRectangle(rect, sp, eventCamera, out Vector2 local); local -= rect.rect.center; return PointInPolygon(local, localPoints); } private bool PointInPolygon(Vector2 p, Vector2[] poly) { bool inside = false; for (int i = 0, j = poly.Length - 1; i < poly.Length; j = i++) { Vector2 a = poly[i]; Vector2 b = poly[j]; if ((a.y > p.y) != (b.y > p.y) && p.x < (b.x - a.x) * (p.y - a.y) / (b.y - a.y) + a.x) { inside = !inside; } } return inside; } }

使用步骤分三步：在目标按钮上挂这个组件，把localPoints数组里的点按“以物体中心为原点”的本地坐标填写好；或者写一个小编辑器工具，从Sprite的Alpha轮廓自动提取顶点数组；再或者使用PolygonCollider2D的points作为来源，因为2D碰撞体的points正好是本地坐标，但要注意它会随Sprite旋转，使用时别让UI又被意外旋转。

这个方案相比alphaHitTest的好处是：不依赖纹理可读、不增加内存、不依赖物理引擎，纯数学计算性能极高；缺点是顶点数组需要自己维护，如果美术改了形状，轮廓也要同步更新。所以建议把顶点生成工具一起做好，“形状变了重刷顶点”应该是编辑器里一键完成的事。

这里还有一个重要提示：如果只用Mask裁剪了视觉但没挂PolygonRaycastFilter，异形按钮的点击区域依然是矩形。比如圆形小地图，即使视觉被裁剪成了圆形，点击区域也必须单独处理，否则玩家点小地图四角空区域时，画面还是会有响应。视觉裁剪和点击裁剪是两个独立环节，不要混在一起。

5. 异形屏与运行时分辨率变化：SafeArea、动态视口和压测清单

5.1 刘海屏安全区的适配：SafeArea组件原理与实现

异形屏不只是圆形、圆角游戏UI，物理屏幕上的刘海、挖孔、手势条也会真正影响界面布局。Unity提供了Screen.safeArea接口，它返回一个以像素为单位的Rect，表示当前屏幕中真正可安全显示内容的区域。

最简单的落地方式是在Canvas下建一个专门的“内容根节点”，所有界面元素都放到这个节点里，再用脚本根据safeArea动态调整它的锚点比例。代码很短：

using UnityEngine; [RequireComponent(typeof(RectTransform))] public class SafeAreaFitter : MonoBehaviour { private RectTransform rectTransform; private Vector2 lastSafeAreaSize = Vector2.zero; private void Awake() { rectTransform = GetComponent<RectTransform>(); Apply(); } private void Update() { if (Screen.safeArea.size != lastSafeAreaSize) { Apply(); lastSafeAreaSize = Screen.safeArea.size; } } private void Apply() { Rect safe = Screen.safeArea; Vector2 anchorMin = safe.position; Vector2 anchorMax = safe.position + safe.size; anchorMin.x /= Screen.width; anchorMin.y /= Screen.height; anchorMax.x /= Screen.width; anchorMax.y /= Screen.height; rectTransform.anchorMin = anchorMin; rectTransform.anchorMax = anchorMax; rectTransform.offsetMin = Vector2.zero; rectTransform.offsetMax = Vector2.zero; } }

注意一个常见误区：全屏背景不应该放在SafeRoot里面，否则刘海屏的时候背景会被压缩，四周出现黑边。背景层应为独立全屏层，栅栏到屏幕边缘；游戏内容层再放到SafeRoot里，让按钮和文案都待在安全区内部。只有背景图为了视觉沉浸感可以延伸到不被系统遮挡的死角。

Android的异形屏情况比iOS更复杂，不同厂商的挖孔和圆角尺寸差异很大，SafeArea虽然能拿到一个安全范围，但误差依然存在。所以安全区组件做完之后，一定还要留一层可配置的安全边距，方便后期用配置表微调各类机型。

5.2 运行时切换屏幕方向或分辨率：Canvas Rebuild与Camera Aspect

如果游戏允许用户切换横竖屏，CanvasScaler会在切换时自动重新计算ScaleFactor，锚点做得正确的话，UI布局会自动适配。但自定义网格画出来的UI不会自动跟随，比如前文的RingGraphic，它只在OnPopulateMesh里用了一次rectTransform.rect，分辨率切换后，rect尺寸变了，顶点坐标却不会自动更新。

解决办法是在组件里重写OnRectTransformDimensionsChange，然后调用SetVerticesDirty：

protected override void OnRectTransformDimensionsChange() { base.OnRectTransformDimensionsChange(); SetVerticesDirty(); }

这样每当RectTransform尺寸变化，Canvas就会重新构建网格。如果自定义Graphic比较多，要注意避免在失效回调里做太重的计算，不然切屏瞬间容易卡顿。

PC窗口分辨率动态变化时，也可以手动调用Screen.SetResolution，但不要放在Update里每帧调用。正确做法是监听实际的尺寸变化事件，或者在外面拖动窗口时做一次延迟检测，防止频繁触发系统级切换。

5.3 真机压测清单：覆盖常见比例和交互误点

最后的验证我建议按下面这个清单走，比临时想起来测试哪个机型要高效很多：

• 长屏竖屏（19.5:9左右）和标准竖屏（16:9）对比：背景是否铺满，底部按钮是否在SafeRoot内。
• 平板（4:3或3:2）测试：横屏时两翼是否有大量留白，布局是否太偏。
• 带刘海/挖孔屏真机：状态栏是否遮挡文案，圆角是否盖住按钮。
• 自定义异形按钮测试：点击按钮边缘透明区域、四角死区、内部镂空区，确认没有误触。
• 横竖屏切换：所有锚点、SafeArea、自定义Graphic是否都跟随变化。
• 动态列表：切换分辨率后GridLayoutGroup是否重新计算列数，格子有没有变形。

压测时我习惯在按钮上临时挂一个调试脚本，打印每次点击的本地坐标，再结合PolygonRaycastFilter的判断结果显示一个红点，这样能直观看到“哪里可以点、哪里不可点”，比反复猜测高效很多。

最后分享一个小习惯：我在每个新UI场景启动时，都会切一遍Game视图的设备模拟列表，再配合SafeAreaFitter和CanvasScaler，把常见比例全部截图保存。这个习惯帮我避开了很多“真机才出现”的适配事故。自定义界面形状和分辨率适配，本质上不是某个特效技巧，而是一套从坐标系、锚点、遮罩、点击过滤到安全区校验的完整流程，把每一环都做扎实，UI换什么设备都不会乱。