翻译Unity中文版的初衷是因为官方提供的中文版存在缺陷，而且翻译的不全。现在基于Unity2023.2版本对官方文档进行翻译。

跨平台注意事项 🔗

大多数 Unity 的 API 和项目结构对于所有支持的平台都是相同的，有时候一个项目可以重新构建以在不同的设备上运行。然而，硬件和部署方法上的基本差异意味着项目的某些部分可能不能在不同平台之间移植而不需要进行更改。本页面列出了一些常见的跨平台问题以及解决方案的建议。

输入 🔗

不同平台之间行为差异最明显的示例是硬件提供的输入方法。

键盘和手柄 🔗

Input.GetAxis函数在桌面平台上很方便，可以将键盘和手柄的输入进行组合。但是，在依赖触摸屏幕输入的移动平台上，这个函数并不适用。标准的桌面键盘输入只适用于将键入文本移植到移动设备上。如果你考虑将来移植到其他平台，可以在你的输入代码中添加一个抽象层。例如，如果你正在制作一款驾驶游戏，那么你可以创建自己的输入类，并在自己的函数中封装 Unity API 调用：

// Returns values in the range -1.0 .. +1.0 (== left .. right).
function Steering() {
    return Input.GetAxis("Horizontal");
}


// Returns values in the range -1.0 .. +1.0 (== accel .. brake).
function Acceleration() {
    return Input.GetAxis("Vertical");
}


var currentGear: int;

// Returns an integer corresponding to the selected gear.
function Gears() {
    if (Input.GetKeyDown("p"))
        currentGear++;
    else if (Input.GetKeyDown("l"))
        currentGear--;

    return currentGear;
}

将 API 调用封装在一个类中，可以将它们置于一个单独的源文件中，并使调用易于定位和替换。你应该根据你的游戏中输入的逻辑含义来设计你的输入函数。这有助于将游戏的其余代码与特定平台使用的输入方法隔离开来。

例如，你可以修改上面的 Gears 函数，使实际的输入来自移动设备屏幕上的触摸。使用整数表示所选择的档位适用于所有平台，但如果将平台特定的 API 调用与代码的其余部分混合在一起，可能会导致问题。你还可以使用平台相关编译来将不同实现的输入函数组合在同一个源文件中，避免手动交换。

触摸和点击 🔗

Input.GetMouseButtonXXX函数的设计在移动设备上有明显的解释。屏幕将简单的触摸报告为左键点击，Input.mousePosition属性提供触摸的位置，只要手指触摸屏幕。具有简单鼠标交互的游戏通常可以在桌面和移动平台之间透明地工作。

转换通常没有这么简单。例如，桌面游戏可以使用多个鼠标按钮，而移动游戏可以同时检测到屏幕上的多个触摸。为了帮助管理这些，您可以用逻辑值来表示输入，然后由游戏的其他代码使用这些值。

例如，你可以用桌面上的 +/- 按键来替代移动设备上的捏合手势进行缩放；输入函数可以返回一个浮点值，指定缩放因子。同样，你可以通过移动设备上的两指点击来替代桌面上的右键点击。然而，如果输入设备的属性是游戏的一个重要部分，那么就可能无法在不同平台上进行重新模拟。这可能意味着你无法移植游戏，或者需要对输入或游戏玩法进行广泛修改。

加速度计、罗盘、陀螺仪和 GPS 🔗

这些输入来源于手持设备的便携性，因此在桌面上可能没有任何有意义的等效物。然而，有些用例仅仅是为了简单地复制标准的游戏控制，并且在移植时容易实现。例如，一个驾驶游戏可以根据移动设备的倾斜（通过加速度计确定）来实现转向控制。在这种情况下，输入 API 调用通常很容易更改，因此可以将加速度计输入替换为按键。

但是，可能需要重新校准输入或调整游戏难度以适应不同的输入方法。倾斜设备比按键操作更慢且更费力，这使得难以集中注意力在显示上。这可能会使得在移动设备上掌握游戏变得更加困难，因此可能适当降低游戏速度或让每个关卡的时间更长。这需要设计游戏代码来调整这些因素。

存储器、存储和 CPU 性能 🔗

移动设备可用的存储空间、内存和 CPU 功率都比台式机低，因此一个游戏可能很难移植，因为它在低功率硬件上的性能不能满足要求。如果你的台式机硬件已经达到了极限，那么这个游戏可能不适合移植到移动平台上。

存储需求 🔗

视频、音频和纹理可能占用大量的存储空间。如果要移植游戏，就需要有效地管理存储空间。存储空间（通常也对应于下载时间）在台式机上通常不是问题，但在移动设备上可能有限。移动应用商店通常对提交产品的最大大小有限制。在游戏开发过程中，可能需要一些规划来解决这些问题。

例如，你可能需要为移动设备提供简化版本的资源以节省空间。另一个可能性是，游戏可能需要设计成可以按需下载大型资源，而不是作为应用程序的初始下载的一部分。

自动内存管理 🔗

Unity 会自动处理来自 “死” 对象的未使用内存的回收，通常在桌面机器上几乎不会被注意到。然而，移动设备上较低的内存和 CPU 功率意味着垃圾回收可能更加频繁，影响性能并导致游戏中不必要的暂停。即使游戏在有效的内存中运行，也可能需要优化代码以避免垃圾回收暂停。

有关更多信息，请参阅内存管理页面。

CPU 功率 🔗

在台式机上运行良好的游戏可能在移动设备上出现帧率低下的情况，因为移动 CPU 无法处理复杂的游戏。当项目移植到移动平台时，要注意代码的效率。

结论 🔗

搬砖愉快！