移动端UI设计最佳实践（第二部分）

测试与优化UI性能是设计与开发流程的关键组成部分，也是游戏成功不可或缺的一部分。

在这第二部分采访中，我们与Outfit7的资深软件工程师Aleksander Gregorka、三星的开发者关系工程师Søren Klit Lambaek，以及Unity的资深技术产品经理Benoit Dupuis，来继续讨论发售性能高、体验棒的游戏的最佳方法。

在第二段访谈里，几位分享了UI的实现、测试、性能优化和分析。

接上一篇文章：哪些是不用代码制作用户界面的最佳实践？

Benoit Dupuis：如果使用的是Unity UI，有几种简单的办法可以建立一张带功能的线框图，比如用Unity Events启用或禁用元素。它们作为可互动的UI元素暴露于检视器里，譬如按钮或选框。你可以将特定GameObject添加到Unity Event，并选择按钮被按下时所触发的动作。

这个例子模仿了启用游戏对象的流程。OnClick Event将调用SetActive(true)，启用名为NewPopUp 的对象，并禁用PopUp对象。

这里还有几点需要记住的提示：

• 触发游戏功能的Unity Events或UI Toolkit 同样可以利用可视化编程无代码地创建。
• UI Builder可与UI Toolkit一起用于实现UI。一般都是开发者负责将UI Toolkit的UI元素与代码相关连。可视化创作工具UI Builder能让你直观地创建整个界面。这种流程的优点在于设计师与程序员互不干扰，双方的协作依赖于共通的命名约定，比如“主开始键”。

上方就是UI Builder，下方是代码。工具将在代码里扫描整个元素的架构，称为视觉元素树（Visual Element Tree），并记下需要互动的元素。比如，游戏按钮将被保存在变量中，当按钮被按下时，你可以监听这些回调。设计师和程序员只需要知道按钮是怎样被调用的。

• 我们推荐在视觉元素和样式表（Style Sheet）上采用Block Element Modifier（BEM）命名约定。因为一眼就可以从某个元素的BEM命名上看出它的作用、出现位置以及其与周围其他元素的关系。

  BEM命名示例：

  menu__home-button
  menu__shop-button
  menu__shop-button--small
  button-label
  Button-label--selected

怎样设计代码结构来应用并测试各类UI修改？

Aleksander：拆分逻辑与图像组件。UI改动难以预测，但UI视图的逻辑不应该改变。UI必须只展示收到的内容，可以直接接收，也可以通过观察数值或接收事件。此时，你可以轻松地替换渲染逻辑，即便整个UI系统经过了修改。

一般哪些人负责测试UI？

Aleksander：我们有多种测试UI的方法。其中一种称为“用户测试”，邀请目标用户来试玩游戏。我们会观察并记下玩家的行为，在必要时做出调整。

另一种方法称为“内部测试”，让员工们试玩游戏并上报问题。我们经常会收到大量的反馈，因为测试人员的要求很高，也有许多的相关经历。

如果没有折叠设备，要怎样测试UI呢？

Søren：三星有远程测试实验室（Remote Test Labs）。我们准备了许多机器，任何人只要有三星账号就能预订。系统允许上传APK文件到实机并开展测试。

哪些是移动端UI最可怕的性能杀手？

Aleksander：最大的性能杀手是过度绘制，频繁重绘包含大量动态元素的画布（Canvas），包含大量元素的长画布，以及文本网格（text mesh）的生成。我们对这些尤其小心，因为游戏需要支持很多种设备。

Søren：很大张的光栅UI画起来很慢，UI图形必须在设备内存容量范围之内。在运行期间渲染3D的UI图形也能极大地拖累性能，这也包括小地图和物品栏系统。

你们有哪些最棒的UI优化技巧？

Aleksander：把UI元素按组分配到多张画布（或子画布）上来防止过度的重绘。只要有一个元素发生修改，整张画布就会变“脏”，需要重绘。这个过程可耗费大量性能，所以动态元素最好被放在一张或多张自己的画布上。

尽量避免使用布局组，尤其是嵌套的，它们也会让画布变“脏”。如果有静态的UI，它的位置和大小最好是预先算好的。

禁用图形射线投射器（Graphic Raycasters），在不可互动的UI元素上向目标投射射线。图形射线投射器（Graphic Raycasters）会识别触碰是否在UI组件之内，这个识别过程非常耗能。

类似地，在显示全屏UI（比如对话）时禁用背景里的摄像机。这样被挡住的摄像机就不会产生额外的渲染成本。

使用纹理图集（Texture Atlas），并适当地将精灵拆分至多张图集上，仅在必要时加载对应的图集，借此来减少内存占用。

最后一条重要提示是在实机上分析游戏，然后再确定哪里需要修复。千万别盲目地照着别人列出的列表来优化。

Benoit：对于Unity UI，常见的做法是根据元素是否是静态的或需要经常更新来将其分配到不同的画布上每张画布在更新时会刷新所有的子元素，所以最好只刷新真正需要修改的元素。

避免重叠透明的像素，同时尽可能突出显示UI元素的图像。减少元素数量的一种方式是制作精灵图像，在运行时生成；精灵可以是扁平的图片，比如单色的指示图标，或一套emoji。这本电子书包含了一篇专门讨论UI性能的章节，请在书内了解更多细节。

UI对三星设备上的游戏性能有哪些影响？

Søren：迄今为止，我们还没碰到过UI消耗太多性能的情况。不过这种情况肯定会发生，比如界面设计得过于复杂，或者小地图等UI组件实现不当。

自适应性能（Adaptive Performance）同样和UI设计相关，它能带来什么好处吗？

Søren：自适应性能（Adaptive Performance）可以用于UI设计，然而在2D光栅图形上不宜过度优化，否则界面会变得模糊或产生其他不合适的效果。它更适合在运行时渲染到UI层的3D几何形。

至于设备资源管理和运行时优化，更好的做法是为每个面板制作独特的大型艺术资产，或者用小部件创建一个库，用于组装和分层。

Aleksander：这视情况而定。性能方面，使用大型艺术资产确实很好，但总的来说，使用小UI组成的库要安全得多。移动端的应用大小非常受限，所以我们尽量使用9格缩放（9-slice scaling）。

建立一个UI元素预制件库对于创建新项目很有帮助。可能在一开始要多花点时间，一旦库完成，你就能重新使用这些组件快速制作出UI。最重要的是，你能在整个游戏里保持统一的艺术风格。

Benoit：如果游戏的Unity UI风格非常独特，可以为主要的弹出菜单制作一张图片来提高运行时性能。至于纹理的尺寸，推荐使用精灵编辑器（Sprite Editor）的切片等功能，并尽可能减少子UI对象的数量。

在本地化方面，你们怎样管理文本的自动缩放？

Aleksander：自动缩放最好的管理方式就是不去管理。如果可以在屏幕上有足够的空间，最好是为每一种语言预留空白区域，或者为非动态文本创建一些预设。在缩放时，没有必要每帧都更新一次文本。时刻记住测试每一种翻译里多出来的文本，看看它能否适应屏幕。 

你们是否在工作流里整合了分析工具来验证设计的有效性？

Aleksander：我们自己的分析流程覆盖了游戏的方方面面，也包括UI。我们会检测哪些UI元素会被点击或忽略，据此来调整设计。

那些与关键性能指标（KPI）紧密相关的UI元素会被着重关注，比如视频位置、应用内购（IAP）等等。我们还试过用屏幕热力图来深入了解玩家行为。

这里的主要知识点是UI的测试、性能优化和数据分析没有万金油一般的策略。每种情况都会不同，但谨记这些最佳实践可以让游戏的性能尽可能高。

想了解更多？请参阅我们最新的在 Uniy 中设计与实现用户界面电子书。我们也邀请你前往Made with Unity论坛与他人分享自己有助于成功的提示。