Unity3D技术之平台间的工程移植浅析

狂风大尉

平台间的工程移植

大部分 Unity API 和工程架构对所有支持的平台都是相同的。有些情况下可直接重建工程，以便在不同设备上运行。但是，硬件和部署方法最基本的不同意味着工程的某些部分如果不做变更，可能不能在平台之间移植。以下列出了一些常见的跨平台问题细节和解决建议。

输入

平台间行为不同的最显著示例在于硬件提供的输入法。

键盘和手柄

Input.GetAxis 函数在台式机平台上非常方便，可强化键盘和手柄输入。然而该函数对依靠触摸屏输入的移动平台来说毫无意义。同样，对任何内容来说标准台式机键盘输入都无法很好地移植到移动装置，键入文本除外。如果考虑以后会移植到其他平台，可以在输入代码中添加一个抽象层。举一个简单的示例，如果想制作一个驾驶类游戏，您可能想创建自己的输入类，将 Unity API 调用包含在自己的函数内：-

1. // Returns values in the range -1.0 .. +1.0 (== left .. right).
   
2. function Steering() {
   
3.         return Input.GetAxis("Horizontal");
   
4. }
   
5. 
   
6. 
   
7. // Returns values in the range -1.0 .. +1.0 (== accel .. brake).
   
8. function Acceleration() {
   
9.         return Input.GetAxis("Vertical");
   
10. }
    
11. 
    
12. 
    
13. var currentGear: int;
    
14. 
    
15. // Returns an integer corresponding to the selected gear.
    
16. function Gears() {
    
17.         if (Input.GetKeyDown("p"))
    
18.                 currentGear++;
    
19.         else if (Input.GetKeyDown("l"))
    
20.                 currentGear--;
    
21. 
    
22.         return currentGear;
    
23. }

复制代码

像这样将 API 调用包在类中有一个好处，就是都集中在单个源文件中，可轻松找到并替换。更重要的是要根据游戏中输入的逻辑含义设计自己的输入函数。这样有助于将其余的游戏代码与特定平台使用的具体输入法分离开来。比如可对上面的 Gears 函数进行修改，使真正的输入来自移动设备的屏幕触摸事件。使用整数表示所选 gear 在所有平台上都正常工作，如果将指定平台的 API 与其余的代码混合会出现问题。您会发现使用依赖平台的编译非常方便，可在相同源文件中合并执行不同的输入函数，避免手动互换。

触摸和单击

Input.GetMouseButtonXXX 函数被设计出来，即使没有“鼠标”，也能明显地合理解读移动设备，单点触摸屏幕报告为左键单击，只要手指触摸屏幕，Input.mousePosition 属性就能给出点击位置。也就是说带简单鼠标互动操作的游戏通常可在台式机和移动平台上正常工作。当然，两者之间的转换往往要复杂得多。台式机游戏能利用一个以上鼠标按键，而移动游戏可同时检测到多点触摸。

和 API 调用一样，这个问题可以通过用其余游戏代码当时使用的逻辑值来表示输入得到部分解决。例如，移动设备上移动缩放的手势可以用台式机上的 +/- 按键代替；输入函数只返回指定缩放系数的浮点数。同样，两指触击移动装置代替台式机中的右击也是可行的。如果输入设备的属性为游戏整体的一部分，就不太可能在不同平台上改造。这意味着游戏完全无法移植或需要大量修改输入和/或游戏设置。

加速计、罗盘、陀螺仪和 Gps

这些输入来源于手持式设备的移动性，所以台式机上可能没有任何有意义的对应物。一些用例使用简单的镜像标准游戏控制设备，可以轻易移植。例如，驾驶游戏可以从移动设备倾斜中实施转向控制（由加速器控制）。同理，输入 API 调用通常很容易替换，如加速器输入可能被按键替换。但是可能有必要重新校准输入或更改游戏的难度，以考虑不同输入法。倾斜设备较慢，最终比按键更费力，甚至让人更难集中注意力，观看游戏播放。这可能导致难以在移动设备上掌控游戏，因此可以合理放慢游戏速度或给每个关卡留出更多时间。这就需要设计游戏代码，以便轻松调整这些因素。

内存、存储和 CPU 性能

移动设备的存储、内存及 CPU 功率值比台式机低，导致难以简单移植游戏，原因在于低功率硬件无法满足其性能。某些资源问题可以得到解决，但如果冲击台式机硬件的极限，移植到移动平台时可能不宜选择该游戏。

影片播放

目前，移动设备在很大程度上依赖硬件是否支持影片播放。这导致播放选择有限，无法像 MovieTexture 资源在台式机平台上那样灵活。影片可在移动设备上全屏播放，但是在游戏中将其用于纹理对象时无任何范围限制（所以无法在游戏的电视屏幕上播放影片等等）。就可移植性来说，将影片用作介绍、剧情画面、说明及其它简单的演示还是不错的。如果影片要在游戏世界中可见，则应考虑移动播放选项是否充足。

存储要求

视屏、音频，甚至是纹理都可能占用大量存储空间。如果想移植游戏，须牢记这一点。对台式机来说，存储空间（通常还对应下载时间）通常不是问题，但对于移动设备来说则不然。此外，移动应用程序商店 (app store) 通常会限定提交产品的最大大小。开发游戏时可能需要进行规划，解决这些问题。例如，为了节省空间，需要为移动设备提供删节版资源。另一种可能是需要设计游戏，这样，较大资源可以在需要时下载，而不是作为应用程序初始下载的一部分。

自动内存管理

Unity 自动从“不活动”对象中恢复未使用的内存，这一操作在台式机上进行时往往难以察觉。然而，移动设备的内存较小、CPU 功率较低就意味着要更频繁地回收垃圾，耗费的时间会大大影响性能（导致玩游戏时出现意外停顿等）。即使游戏在可用内存中运行，仍有必要优化代码，避免出现垃圾回收停顿。

CPU 功率

在台式机上运行良好的游戏在移动设备上的帧速率却极低，可能仅仅是因为移动设备的 CPU 难以应付这么复杂的游戏。将工程移植到移动平台时，需要格外关注代码的效率。

hariboot

Thanks for sharing！