企业官网建设流程全解析

1. 从一个被忽略的缩放问题说起

如果你在UE4里用UMG搭过UI，大概率遇到过这样的场景：在自己电脑上调试时，控件位置精准、字体大小合适，一切看起来都很完美。但把项目打包发给同事，或者换了一台分辨率不同的显示器，整个界面要么变得巨大无比、控件互相重叠，要么小得跟蚂蚁一样、根本看不清。更让人抓狂的是，有时候在编辑器里预览是正常的，运行起来却完全变了样。

这个问题的根源，十有八九出在DPI缩放上。

UMG（Unreal Motion Graphics）是UE4的UI框架，它本身的设计是支持多分辨率适配的，但“支持”和“自动帮你处理好”是两码事。很多开发者第一次接触UMG时，会默认觉得引擎应该帮自己搞定所有屏幕适配问题，结果在实际项目中才发现，DPI缩放策略、锚点设置、控件尺寸单位这些东西如果不主动去理解和配置，UI在不同设备上的表现会千差万别。

这篇内容主要面向已经用过UMG、但对DPI缩放机制还不够清晰的开发者。我会从DPI缩放的基本概念讲起，拆解UE4中UMG的DPI缩放体系是怎么运作的，然后给出具体的配置方案和实操步骤，最后分享一些我在实际项目中踩过的坑和总结出来的经验。读完你应该能搞清楚：为什么UI会“跑偏”、DPI缩放曲线怎么配、不同平台下应该怎么选策略，以及那些官方文档里不会写的细节。

2. DPI缩放在UMG里到底解决了什么问题

2.1 先搞清楚“像素”和“屏幕尺寸”的关系

要理解DPI缩放，得先回到一个最基础的问题：我们在UMG里拖控件时，填的那些数值到底代表什么？

在UMG的Canvas Panel里放一个按钮，你设置它的Size是200×60，这个200和60的单位是“像素”。但这里的“像素”并不是屏幕上的物理像素，而是UE4的Slate UI系统内部使用的一种逻辑单位。Slate是UE4底层UI框架，UMG是构建在Slate之上的可视化封装。Slate在渲染时，会根据当前的DPI缩放系数，把这些逻辑单位转换成实际的屏幕像素。

举个例子：假设你的设计分辨率是1920×1080，你在UMG里放了一个宽度占满屏幕的控件，宽度设为1920。当程序运行在一个1920×1080的显示器上，DPI缩放系数是1.0，那这个控件刚好占满屏幕。但如果运行在3840×2160的4K显示器上，如果不做任何处理，这个控件只占屏幕宽度的一半，右边会空出一大块。

这就是DPI缩放要解决的核心问题：让UI在不同分辨率和不同物理尺寸的屏幕上，保持一致的视觉比例和可读性。

2.2 UE4的DPI缩放体系是怎么设计的

UE4的DPI缩放体系由几个核心概念组成，理解它们之间的关系是配置正确的前提。

DPI缩放曲线（DPI Scale Curve）是整个体系的基础。它本质上是一条映射曲线，横轴是屏幕的短边像素值（或者说是“屏幕尺寸”的一个度量），纵轴是对应的DPI缩放系数。UE4在运行时会根据当前屏幕的实际尺寸，从这条曲线上采样出一个缩放系数，然后把这个系数应用到所有UMG控件的渲染上。

DPI曲线在项目设置里的位置是：Project Settings → Engine → User Interface → DPI Scaling。这里有一个“DPI Scale Rule”下拉框，默认是“Shortest Side”，意思是根据屏幕短边的像素值来查曲线。还有“Longest Side”“Horizontal”“Vertical”等选项，后面会详细说什么时候该换。

默认DPI曲线是一条从0到1的平滑曲线，在屏幕短边大约720px时缩放系数约为0.5，在1080px时约为0.75，在1440px时约为1.0，在2160px时约为1.5。这条曲线是UE4团队根据常见设备尺寸给出的一个经验值，但它不一定适合你的项目。

DPI缩放系数最终会影响到几个方面：UMG控件的渲染大小、字体的大小、以及Slate的命中检测（也就是点击区域）。这意味着如果你把缩放系数调得太大，不仅视觉上控件变大，点击区域也会跟着变大，这在触屏设备上尤其需要注意。

2.3 为什么很多人第一次用会“翻车”

我见过不少项目，UI在开发机上跑得好好的，一到测试机就出问题。总结下来，翻车的原因通常有这几个：

第一个原因是设计时没有确定基准分辨率。有些团队在UMG里拖控件时，每个人用的画布尺寸都不一样，有人用1920×1080，有人用2560×1440，结果合并到一起后，控件的相对位置全乱了。DPI缩放只能解决“整体等比缩放”的问题，解决不了“设计基准不统一”的问题。

第二个原因是锚点（Anchor）设置随意。UMG的锚点决定了控件在父容器尺寸变化时如何定位和拉伸。如果锚点全设在左上角，那屏幕变大时控件不会跟着移动，只会保持和左上角的固定距离。DPI缩放会放大控件本身，但不会改变锚点的行为。这两个机制是独立的，需要配合使用。

第三个原因是字体没有跟随DPI缩放。UMG的Text控件有一个“Font Size”属性，这个值默认是不受DPI缩放影响的。如果你不手动开启字体缩放，在大屏上文字会小得看不清。开启的方式是在Text控件的属性里勾选“Auto Wrap Text”下面的“Scale Font Size By DPI”选项，或者在C++里设置对应的Slate属性。

3. DPI缩放曲线的配置与调优实操

3.1 找到并理解默认曲线

打开Project Settings，搜索“DPI”，在Engine分类下找到User Interface设置。这里你会看到“DPI Scale Rule”和“DPI Scale Curve”两个关键项。

点开DPI Scale Curve，你会看到一条默认曲线。这条曲线的横轴范围是0到2560左右，纵轴范围是0到2.0左右。曲线的关键点大致是：

这张表是我根据默认曲线的大致采样值整理的，实际曲线是平滑插值的，不是阶梯式的。你可以双击曲线上的关键点来查看和修改具体数值。

默认曲线的设计思路是：小屏幕上缩小UI，避免控件太大放不下；大屏幕上放大UI，避免控件太小看不清。但这个“缩放”的幅度是相对保守的，因为UE4团队要考虑各种类型的项目，不能太激进。

3.2 根据项目类型定制曲线

默认曲线不一定适合你的项目，你需要根据项目的实际需求来调整。调整的核心思路是：确定你的基准分辨率，然后让曲线在基准分辨率处返回1.0。

假设你的项目基准分辨率是1920×1080，你希望在这个分辨率下UI的缩放系数是1.0，也就是你设计时看到的大小就是最终运行的大小。那你就需要在曲线上找到横轴1920对应的点，把它的纵轴值改成1.0。然后根据你的需求调整其他点的值。

对于移动端项目，屏幕尺寸跨度很大，从5寸手机到12寸平板都有。我的建议是让曲线在短边600px以下时缩放系数不要低于0.6，否则文字会小到无法阅读。在短边1200px以上时可以适当放大到1.2左右，但不要超过1.5，否则控件会显得过于臃肿。

对于PC端项目，屏幕尺寸相对集中，常见的是24寸1080p和27寸1440p。这种情况下曲线可以更平缓一些，在1080p到1440p之间保持1.0左右，在4K分辨率下放大到1.5左右即可。

对于主机项目，因为输出分辨率基本固定（1080p或4K），DPI缩放的需求反而不大。但如果你要同时支持手持模式和底座模式（类似Switch那种），就需要针对两种模式分别配置。

3.3 修改曲线的具体操作步骤

在编辑器里修改DPI曲线很简单，但有几个细节需要注意。

第一步，在DPI Scale Curve的编辑面板里，你会看到一条曲线和若干关键点。右键点击曲线可以添加新的关键点，拖动关键点可以调整位置。

第二步，调整关键点时要注意保持曲线的单调递增。也就是说，屏幕越大，缩放系数应该越大或者至少不变。如果曲线出现下降，会导致大屏幕上的UI反而比小屏幕小，这显然不合理。

第三步，调整完曲线后，一定要在实际设备上验证。编辑器的预览窗口虽然可以模拟不同分辨率，但它的DPI缩放行为和实际运行时有差异。最可靠的方式是打包一个测试版本，在目标设备上跑一遍。

第四步，如果你在项目里用了多个UI层级（比如HUD、菜单、弹窗），要确认它们都受到DPI缩放的影响。有些开发者会把某些UI放在单独的Widget里，如果那个Widget的DPI缩放设置被覆盖了，就会出现部分UI缩放、部分不缩放的情况。

注意：修改DPI曲线后，编辑器的UMG设计器视图可能不会立即更新。你需要关闭并重新打开UMG编辑器窗口，或者点击设计器工具栏上的“Refresh”按钮，才能看到新的缩放效果。

3.4 DPI Scale Rule的选择逻辑

“DPI Scale Rule”决定了UE4用屏幕的哪个维度来查曲线。默认是“Shortest Side”，也就是屏幕短边。这个选择在大多数情况下是合理的，因为短边决定了UI的“紧凑程度”。

但在某些场景下，你可能需要换一个规则。比如你的项目是横屏为主的赛车游戏，UI主要分布在屏幕左右两侧，那用“Horizontal”可能更合适，因为水平方向的像素数直接决定了UI的横向空间。

再比如竖屏的移动应用，用“Vertical”可能更合理，因为竖屏的纵向像素数变化范围更大。

切换Scale Rule后，曲线的横轴含义会变，你需要重新调整曲线上的关键点。这个操作不可逆，建议在切换前先截图保存当前曲线配置。

4. 锚点、尺寸与DPI的配合使用

4.1 锚点不是DPI的替代品

很多新手会把锚点和DPI缩放混为一谈，觉得设好锚点就不需要管DPI了。这是个误解。

锚点解决的是控件在父容器尺寸变化时的相对定位问题。比如你把一个按钮的锚点设在屏幕右下角，那当屏幕变大时，按钮会跟着右下角移动，保持和右下角的固定距离。但按钮本身的大小不会变，除非你同时设置了尺寸跟随锚点拉伸。

DPI缩放解决的是整体UI的等比缩放问题。它会让所有控件（包括按钮）按比例放大或缩小，但不会改变控件之间的相对位置关系。

两者是互补的：锚点管“位置”，DPI管“大小”。一个完整的适配方案需要同时用好这两个机制。

4.2 不同锚点模式下的DPI表现

UMG的锚点有几种预设模式：左上、中上、右上、左中、中心、右中、左下、中下、右下，以及自定义。每种模式下，控件对DPI缩放的响应是不同的。

以左上角锚点为例：控件固定在屏幕左上角，DPI缩放会让控件本身变大，但控件和左上角的距离（也就是Position X/Y）也会按比例缩放。这意味着如果你把Position X设为100，在DPI缩放系数为1.5时，实际渲染的偏移量是150像素。

以中心锚点为例：控件以屏幕中心为基准定位，DPI缩放时控件会围绕中心点放大，Position的偏移量同样按比例缩放。这种模式适合做弹窗、加载提示这类需要居中的UI。

以拉伸锚点为例：控件的尺寸会跟随父容器变化，DPI缩放会在此基础上再叠加一层缩放。这种模式下要特别注意，如果父容器本身已经因为DPI缩放变大了，控件的实际渲染尺寸可能是“父容器尺寸 × 锚点拉伸比例 × DPI缩放系数”，很容易超出预期。

4.3 尺寸设置的常见误区

在UMG里设置控件尺寸时，有几个容易踩的坑。

第一个坑是混用绝对尺寸和相对尺寸。比如一个按钮的宽度设为200（绝对像素），但它的父容器是一个占满屏幕的Canvas Panel。在DPI缩放后，父容器变大了，但按钮还是200逻辑像素宽，视觉上按钮会显得越来越小。正确的做法是把按钮的宽度设为“Fill”或者用百分比，让它跟随父容器缩放。

第二个坑是忽略Size Box的作用。Size Box是一个常用的容器控件，它可以强制子控件保持特定尺寸。但Size Box的尺寸设置也受DPI缩放影响。如果你在Size Box里设了固定尺寸，DPI缩放会让这个固定尺寸也按比例变化。如果你希望某个控件始终保持物理尺寸不变（比如一个必须精确点击的小按钮），那需要把Size Box的尺寸设为“Auto”或者用其他方式绕过DPI缩放。

第三个坑是字体尺寸没有单独处理。前面提到过，UMG的Text控件默认不跟随DPI缩放。你需要手动开启“Scale Font Size By DPI”。开启后，字体会根据DPI缩放系数自动调整大小。但要注意，字体缩放和控件缩放是独立计算的，如果两者不匹配，会出现文字溢出控件边界或者文字太小留白太多的情况。我的经验是让字体缩放系数和控件缩放系数保持一致，这样文字和控件的比例关系不会变。

5. 多平台适配中的DPI策略差异

5.1 PC平台的特殊性

PC平台的特点是分辨率种类极多，从1366×768的老笔记本到3840×2160的4K显示器都有。而且PC用户习惯自由调整窗口大小，这意味着你的UI需要能适应任意窗口尺寸。

在PC平台上，我建议把DPI Scale Rule设为“Shortest Side”，曲线在1080p处返回1.0，在720p处返回0.8左右，在4K处返回1.5左右。这样在大多数常见分辨率下，UI的视觉大小都比较合理。

另外PC平台要特别注意窗口模式下的DPI行为。当用户把窗口拖得很小的时候，DPI缩放系数会降得很低，UI会变得很小。这时候可以考虑设置一个最小缩放系数，比如0.5，防止UI小到无法操作。设置的方式是在DPI曲线的低端加一个平台期，让曲线在短边低于某个值后不再下降。

5.2 移动端平台的注意事项

移动端的情况更复杂，因为除了分辨率，还有物理尺寸的差异。同样是一块1080p的屏幕，5寸手机和7寸平板的像素密度完全不同，UI的视觉大小也会差很多。

在移动端，我建议把DPI Scale Rule设为“Shortest Side”，但曲线的形状要更陡一些。小屏幕上（短边<800px）缩放系数可以低到0.5，大屏幕上（短边>1200px）可以高到1.3。这样能保证在手机和平板上都有合理的UI大小。

移动端还有一个特殊问题：安全区域。很多手机有刘海、挖孔或者圆角，UI不能铺满整个屏幕。UE4提供了Safe Zone的API，可以在UMG里通过一个专门的Safe Zone控件来处理。但Safe Zone和DPI缩放是独立计算的，你需要确保Safe Zone的边距也按DPI缩放系数调整，否则在大屏设备上安全区域会显得过窄。

5.3 主机平台的简化处理

主机平台的输出分辨率通常是固定的（1080p或4K），而且玩家距离屏幕的距离也相对固定（客厅沙发到电视的距离）。这种情况下DPI缩放的需求其实不大，你可以把曲线设得平缓一些，甚至在某些情况下可以禁用DPI缩放，直接用固定尺寸。

但如果你要支持“手持模式”和“底座模式”的切换（类似某些混合型设备），那就需要两套DPI配置。UE4本身不直接支持运行时切换DPI曲线，但你可以通过修改DPI曲线的采样逻辑来实现。一种常见的做法是在游戏开始时检测设备模式，然后动态调整UMG控件的缩放系数。

6. 实际项目中的踩坑记录与排查思路

6.1 编辑器预览和实际运行不一致

这是最常见的问题之一。在UMG设计器里看到的UI布局，和打包后运行的效果不一样。原因通常是编辑器的预览窗口没有正确应用DPI缩放。

排查方法：在编辑器里打开UMG设计器，点击工具栏上的“Preview”下拉菜单，选择“DPI Scaling”选项，然后手动设置一个缩放系数。这样可以看到在不同DPI下的预览效果。但要注意，这个预览和实际运行仍然可能有差异，因为编辑器的渲染管线和运行时不完全一样。

最可靠的验证方式还是打包运行。如果打包太慢，可以创建一个专门的测试关卡，里面只放UI相关的Widget，然后直接用“Standalone Game”模式运行，这样比完整打包快很多。

6.2 字体模糊或锯齿

在DPI缩放系数不是整数倍时（比如1.35），字体渲染可能会出现模糊或锯齿。这是因为字体在缩放后需要重新栅格化，而Slate的字体缓存可能没有及时更新。

解决方法：在项目设置里找到“Font”相关的选项，开启“Use Font Size Scaling”或者调整字体缓存的大小。另外，尽量使用矢量字体（如Roboto、Open Sans）而不是位图字体，矢量字体在缩放时表现更好。

如果问题依然存在，可以尝试把DPI缩放系数限制为整数倍（1.0、1.5、2.0），但这会牺牲一些适配精度。我的经验是，对于大多数项目来说，非整数倍的轻微模糊是可以接受的，不必过度追求完美。

6.3 点击区域和视觉区域不匹配

有时候UI看起来正常，但点击按钮没反应，或者点击位置和按钮位置有偏移。这通常是DPI缩放影响了Slate的命中检测，但某些控件的命中区域没有正确更新。

排查方法：在UMG里给按钮加一个“On Hovered”事件，然后在屏幕上显示鼠标位置和按钮的实际边界。如果两者不匹配，说明命中检测的缩放计算有问题。

常见的修复方式是在Widget的构造函数里手动设置“Render Transform”的缩放，而不是依赖DPI缩放。但这样做会失去DPI缩放的自动适配能力，需要自己处理所有分辨率的适配逻辑。

6.4 多个UI层级之间的缩放冲突

如果项目里同时存在HUD、菜单、弹窗等多个UI层级，每个层级可能在不同的Widget里实现。如果这些Widget的DPI缩放设置不一致，就会出现部分UI缩放、部分不缩放的情况。

解决方法是统一在一个地方配置DPI缩放，比如在GameInstance或者PlayerController里设置全局的DPI缩放系数，然后所有Widget都从这个全局配置读取。UE4的DPI缩放默认是全局的，但如果你在某个Widget里手动覆盖了缩放设置，就会破坏全局一致性。

提示：在调试DPI问题时，可以在屏幕上实时显示当前的DPI缩放系数。在PlayerController的BeginPlay里获取“Get DPIScale”节点，然后把值输出到一个Debug Text控件上。这样在运行时就能直观地看到当前缩放系数是多少。

7. 一些实用的配置建议和参数参考

7.1 推荐的基础配置

根据我做过的一些项目经验，下面这套配置在大多数情况下表现比较均衡：

这套配置不是万能的，但可以作为起点，然后根据实际测试结果微调。

7.2 调试DPI问题的工具和方法

UE4提供了一些内置工具来帮助调试DPI问题。在编辑器的“Developer Tools”菜单下，有一个“Widget Reflector”工具。它可以显示当前屏幕上所有Slate Widget的层级结构、尺寸、位置和DPI缩放系数。这个工具在排查UI布局问题时非常有用。

另外，你可以在控制台输入“Slate.DPI”相关的命令来查看和修改DPI设置。比如“Slate.DPI.Debug 1”可以在屏幕上显示DPI调试信息。

对于更复杂的问题，可以在C++里重写“GetDPIScale”函数，加入自定义的日志输出。这样可以在运行时记录DPI缩放系数的变化，帮助定位问题出现的时机。

7.3 性能方面的考量

DPI缩放本身对性能的影响很小，因为它只是在渲染前对控件的变换矩阵做一次乘法。但如果你的UI层级很深、控件数量很多，每次DPI变化时重新计算所有控件的布局可能会有性能开销。

优化建议：尽量避免在运行时频繁修改DPI缩放系数。如果确实需要动态调整（比如窗口大小变化时），可以加一个防抖逻辑，等窗口大小稳定后再更新DPI。另外，对于不经常变化的UI（比如背景图），可以考虑用固定尺寸而不是跟随DPI缩放，减少布局计算量。

8. 关于DPI缩放的一些个人体会

做了几个项目之后，我对UMG的DPI缩放最大的感受是：它不是一个“设好就不用管”的功能，而是一个需要持续关注和调整的机制。每次新增UI、修改布局、适配新设备，都可能需要重新检查DPI相关的设置。

我的习惯是在项目初期就确定好基准分辨率和DPI曲线，然后在UMG里统一使用一套尺寸规范。比如所有按钮的高度都用同一个数值，所有字体大小都用同一套比例。这样在DPI缩放时，UI的整体比例关系不会乱。

另外，我强烈建议在项目的CI流程里加入UI截图对比。每次构建后自动截取几个关键界面的截图，和基准截图做对比。如果DPI缩放出了问题，截图对比能第一时间发现，而不是等到测试阶段才暴露。

最后说一个容易被忽略的点：DPI缩放不仅影响视觉，还影响交互。按钮的点击区域、拖拽的判定范围、文本的选择区域，都会受到DPI缩放的影响。在做交互测试时，一定要在不同DPI设置下都验证一遍，确保操作体验一致。

这个主题其实还有不少可以展开的地方，比如DPI缩放和UMG动画的配合、和3D UI（Widget Component）的交互、以及和不同渲染管线的兼容性。这些内容我打算在后续的内容里继续聊。如果你在项目里遇到了什么奇怪的DPI问题，也欢迎一起讨论。