简介这套实战源码围绕Unity引擎5.x版本与C#语言展开跨平台游戏开发面向希望掌握组件化架构、脚本编写及多平台发布流程的初中级开发者。项目通过实际场景演示了变换组件、网格渲染器与自定义脚本的协同方式并说明了脚本基类中Awake、Start、Update等生命周期方法的调用时机便于读者理解C#面向对象特性与引擎机制的结合。资源包为7z压缩格式大小约130MB内含场景文件、C#脚本、预设体、纹理、音频、着色器与材质等工程资源同时附有开发笔记和代码注释。从场景环境搭建、预设体复用到脚本逻辑管理、多平台导出配置能够支撑一条完整的学习与动手路线。目前已有490人学习浏览既可充当课程项目的补充素材也能作为独立实践的作品基础通过修改脚本参数、调整着色器与材质设置读者还可直观感受不同平台适配、性能优化及渲染效果的变化。 做了这么多年Unity项目最值得复盘的反而不是那些引擎高级特性而是Unity5 C#这套组合如何把一个游戏稳稳妥妥地搬到多个平台。我之前用Unity5开发过一个轻量级2D横版闯关游戏同时要出Windows、Android、WebGL三个版本。项目代码规模不大但输入、UI、存档、资源加载这些常规模块一个都躲不掉最有价值的不是某个功能多华丽而是把所有平台差异封在了一层代码里后续不管构建到哪个平台只用改配置不用动玩法逻辑。这篇文章就围绕着这份项目源码聊一聊多平台开发里的设计思路、关键实现和那些真正踩过的坑。写这篇内容不是想炫技而是给正在用Unity做小游戏的开发者一个可复制的工程骨架。如果你手头正好有Unity5项目要同步发布到多个平台或者想看看C#代码在跨平台时怎么组织最省心又或者只是对“源码怎么拆才不烂”这件事感兴趣这篇都值得往下看。1. 项目定位与整体设计思路1.1 为什么选Unity5 C#而不是其他方案当年做这个项目时可选择的技术栈其实不少Cocos2d-x、原生Java、H5游戏引擎都能做2D闯关。但最终选了Unity5核心原因是它的构建管线对多平台太友好了。我只需要维护一份C#逻辑代码其余渲染、音频、资源管理等底层问题全部交给引擎处理这在当时是性价比最高的方案。C#语言本身也帮了大忙。对比CC#的GC机制减少了手动管理内存的负担写UI逻辑、状态机、数据解析这类业务代码效率很高。而且Unity社区里大量插件、源码示例都是用C#写的遇到问题可以直接看反编译出来的IL或者官方脚本API不用在文档和论坛之间来回折腾。对于一个小团队或者个人开发者来说能快速出包、快速验证玩法比追求极致性能更重要。另外要特别说一句Unity5已经支持IL2CPP脚本后端Android平台可以告别Mono时代的一些兼容性问题代码在正式发包前能被提前编译成C再生成二进制运行效率和安全性都有提升。这个特性对多平台发布非常关键后面的构建部分我会再细说。1.2 目标平台选定不是越广越好不少新手拿到多平台需求后的第一反应是“能发布的所有平台都勾上”。我自己一开始也这么干过结果就是UI适配、输入差异、音频格式、加载策略全都要重新处理一遍项目进度被拖慢了一倍。所以这个项目一开始就定了三个主目标Windows、Android、WebGL。Windows负责桌面体验Android覆盖移动端WebGL用于快速分享Demo。iOS当时没排进来是因为团队没有苹果电脑和测试机签证书、上架这些流程没法闭环。做技术选型时一定要想清楚目标用户在哪哪些平台是必须的哪些只是“如果顺手就发”。平台每增加一个维护成本不是线性增长而是成倍增长。这三个平台的差异也很有代表性。Windows用键鼠输入Android靠触摸和物理返回键WebGL藏在浏览器里既没有完整的文件系统体验又对音频和纹理格式有严格限制。正因为差异够大做适配方案时才能把问题暴露得足够充分。如果这个项目只发Windows我后续根本不会有意识去抽象输入层和加载层。1.3 源码结构规划先把目录立起来很多Unity项目最后变得不可维护不是代码写得烂而是一开始目录结构就没规划。我在这个项目里强制把脚本放进了几个固定目录后续加功能、修Bug都很快找到位置。Assets/ Scripts/ Core/ # 游戏入口、主循环、全局管理器 Input/ # 所有输入相关封装 UI/ # 界面控制与组件逻辑 Data/ # 存档、配置、序列化模型 Platform/ # 平台差异代码与条件编译 Utils/ # 扩展方法、工具类 Prefabs/ Scenes/ Resources/ # 运行时动态加载的资源 Texture/ Audio/这套结构不是灵光一现而是吃过亏之后才定的。以前我喜欢把脚本按场景分比如MainScene、GameScene各建一个文件夹结果多个场景共用的逻辑被到处复制。现在改成按模块分场景只是组装层脚本通过生命周期和事件驱动项目后期改起来轻松很多。如果你在Unity5里建新项目我强烈建议先搭这套骨架不要等代码堆到两万行再重构。2. 核心玩法与关键模块的实现2.1 输入系统抽象把“按键”从平台里剥出来2D横版闯关最核心的操作是左右移动、跳跃、攻击。一开始为了省事我直接在逻辑代码里写Input.GetAxis(Horizontal)和Input.GetKeyDown(KeyCode.Space)Windows跑得很欢。但打包到Android后问题就来了手机上根本没有键盘触摸按键区域又和UI混在一起甚至一个不小心点到了屏幕边缘角色就开始抽搐。后来我把输入全部收进了一个静态类由它统一判断当前运行平台并返回逻辑操作。玩法代码只关心“玩家是否按下跳”不关心是键盘空格、屏幕虚拟按键还是手柄X键。public static class InputAdapter { public static bool GetJumpDown() { #if UNITY_ANDROID || UNITY_IOS return VirtualButton.GetJumpDown(); #else return Input.GetKeyDown(KeyCode.Space); #endif } public static float GetAxis() { #if UNITY_ANDROID || UNITY_IOS return VirtualJoystick.GetAxis(); #else return Input.GetAxis(Horizontal); #endif } }这个抽象层看起来简单但价值极大。之后加入手柄支持、键盘重映射都不用改玩法逻辑。我甚至发现以前写死的Input调用散落在十几个脚本里改输入方式要全项目搜索现在只需要改InputAdapter这一个类。2.2 UGUI适配不同分辨率下的Canvas设置多平台开发里最让人头疼的往往是UI而不是游戏逻辑。同一个界面在Windows的16:9显示器上显示正常到了Android的全面屏上可能按钮被挖孔遮挡或者底部多出一截黑边。Unity5时代的UGUI已经比NGUI好用很多但前提是Canvas设置正确。我的做法是所有核心界面都放在一个Canvas下Canvas Scaler模式设为Scale With Screen Size参考分辨率用1280x720Screen Match Mode选择MatchWidthOrHeight并把比例调到0.5。这样在接近16:9的设备上不会出现明显拉伸在带鱼屏或平板这类极端比例下也能保持基本可读。// UI加安全区适配时我会在根节点上挂一个SafeAreaAdapter RectTransform rect GetComponentRectTransform(); rect.anchorMin new Vector2(0, Screen.safeArea.yMin / Screen.height); rect.anchorMax new Vector2(1, Screen.safeArea.yMax / Screen.height); rect.offsetMin Vector2.zero; rect.offsetMax Vector2.zero;代码里的Screen.safeArea是在引擎里读取系统安全区信息适配屏幕挖孔和圆角非常好使。不过Unity5早期部分版本对safeArea的支持不够完善需要先用平台宏判断再在Android上通过调用原生代码获取否则就退回默认Rect。这也算是跨平台坑的一个典型不要假设每个引擎版本都能帮你把所有细节兜住。2.3 存档与数据处理别在PlayerPrefs里放结构体很多小项目喜欢把玩家的金币、关卡进度直接塞进PlayerPrefs字符串拼一拼就完事。这个项目早期也是这样但后来发现两个问题一是PlayerPrefs在部分平台上编辑不方便测试人员看不到完整存档二是多处读写的键名一旦拼错数据就乱了还很难排查。我后来把存档统一成一份可序列化的存档模型用JsonUtility序列化成字符串再写入文件。存档类长这样[System.Serializable] public class SaveData { public int gold; public int maxLevel; public bool isMusicOn; public string playerName; } public static class SaveManager { private static SaveData data new SaveData(); public static void Save() { string json JsonUtility.ToJson(data); string path Path.Combine(Application.persistentDataPath, save.json); File.WriteAllText(path, json); } public static void Load() { string path Path.Combine(Application.persistentDataPath, save.json); if (File.Exists(path)) { string json File.ReadAllText(path); data JsonUtility.FromJsonSaveData(json); } } }Unity5的JsonUtility不能直接序列化Dictionary和部分复杂类型遇到这种需求我会用数组或嵌套类绕过去。写存档时记得先备份旧文件再写入新文件避免中途断电导致整个存档损坏。后来我又给Save类加了版本号字段以后字段结构变化时可以做兼容迁移。这个经验是从线上玩家反馈“更新版本后金币清零”学来的别看存档简单做不好一样翻车。2.4 资源与场景加载保持简单的加载策略小体量游戏其实用不上复杂的AssetBundle方案Resources.Load足够撑起大部分需求。我当时的做法是UI图标、音效、敌人预制体都丢在Resources目录下游戏启动时预加载必要资源战斗过程中按需加载。var enemyPrefab Resources.LoadGameObject(Prefabs/Enemies/NormalEnemy); Instantiate(enemyPrefab, spawnPoint.position, spawnPoint.rotation);Resources.Load的缺点是资源会无脑打进包体而且不容易做增量更新。Unity5时代做多平台时我记得不同平台对Resources目录中的资源压缩规则还不完全一样所以图集和纹理格式我都尽量统一避免“Android构建正常WebGL却花了十分钟加载”这种情况。后来随着包体变大我引入了AssetBundle来拆分平台资源和热更内容但那时候把核心逻辑稳定下来更重要。建议新手别一上来就折腾AssetBundle先把Resources这条简单的路走通再考虑热更新性能优化否则很容易陷入加载框架的泥潭里出不来。3. 多平台构建与代码层适配3.1 构建前必须检查的Player Settings很多人写代码写得很欢一到出包就卡在设置上。Unity5的Player Settings面板里有几个选项直接影响多平台构建是否成功我每次出包前都会逐项确认。Company Name和Product Name不能带中文和特殊字符Android包名建议用com.company.product这种格式。Default Icon每个平台最好都手动指定图标否则某些平台会用Unity默认图标看起来非常业余。Scripting BackendAndroid平台我用IL2CPPWindows则用Mono这样兼容性和迭代速度都比较好。OrientationAndroid和iOS要注意屏幕方向横版游戏就锁定Landscape千万别留AutoRotation。API Compatibility Level如果引用了.NET Framework特性在Unity5里要选.NET 2.0或4.x否则编译直接报错。这些设置之所以要重点检查是因为它们不参与代码编译报错通常不会第一时间出现在Console里。有一次我WebGL构建失败原因只是Player Settings里的WebGL模板被设置成了空模板加载界面直接白屏查了半个多小时。3.2 Windows、Android、WebGL的真实差异用表格看这三个平台的差异最直观这也是我在项目里总结出来的比较项WindowsAndroidWebGL输入方式键鼠、手柄触摸、重力、返回键键鼠、触摸屏浏览器持久化Application.persistentDataPath可写应用私有目录可写受限建议用PlayerPrefs或后端文件访问支持同步IO支持同步IO但低端机可能卡顿不直接支持文件流音频格式WAV/MP3/OggMP3/Ogg效率要好Ogg为首选MP3兼容性差纹理格式常用DXTETC/ASTCWebGL对尺寸有严格限制构建体积相对较小需带IL2CPP库包体变大压缩后较小但要考虑网络加载这段表格我建议截图存下来。每次换平台构建时先对照一遍比盯着Console报错一个个试靠谱得多。比如WebGL不能直接读写本地文件我就把存档策略从文件改成了PlayerPrefs再加个云端同步接口彻底解决了跨设备问题。3.3 条件编译一份代码兼容所有平台Unity的C#编译器会根据当前构建目标自动设置宏比如UNITY_ANDROID、UNITY_WEBGL、UNITY_STANDALONE。合理利用条件编译可以把平台差异代码放在同样的逻辑流程里而不是写几套重复脚本。public class PlatformEventHandler : MonoBehaviour { void OnApplicationFocus(bool hasFocus) { #if UNITY_ANDROID // Android切后台时保存存档 SaveManager.Save(); Debug.Log(Android focus lost, save data.); #elif UNITY_WEBGL // WebGL页面隐藏时暂停游戏 PauseGame(); #else if (!hasFocus) SaveManager.Save(); #endif } }用条件编译要克制不能把整个游戏逻辑都包进去。我的原则是只放平台API调用不放业务逻辑。比如Android返回键处理、iOS震动画、WebGL浏览器关闭事件这些必须用宏区分但角色属性、敌人AI这些和平台无关的逻辑必须保持完全一致否则两个平台玩起来手感都不一样。代码里宏如果超过三处嵌套我就会把相关逻辑抽到一个独立方法里防止可读性崩掉。3.4 真机调试与日志查看编辑器里跑不出来的Bug往往一到真机就露馅。Android平台最常用的是Unity的Development Build加Android Logcat窗口。我习惯在每次打包时勾上Development Build和Script Debugging然后在真机上复现问题把Logcat里的异常栈拉出来看。WebGL平台的调试比Android更隐蔽因为Unity脚本是编译成WebAssembly跑的异常信息经常丢帧。我在JavaScript层挂了一个错误捕获把Unity的Application.logMessageReceived事件输出到浏览器控制台这样查起问题来和编辑器里差不多。void Awake() { Application.logMessageReceived (condition, stackTrace, type) { // 浏览器控制台里会显示Unity日志 Debug.LogWarning($UnityLog: {type} {condition}\n{stackTrace}); }; }真机调试时还有一个容易被忽略的问题构建机器的显卡驱动和Shader效果会和开发机不一样。我在Windows上跑得很正常的描边效果到Android真机上莫名其妙出现了黑边最后发现是Shader里用了半精度浮点导致。遇到这种渲染差异优先检查是否用了高精度变量、贴图格式以及压缩纹理的采样方式。4. 实践中踩过的坑与排查技巧4.1 中文乱码老项目最容易翻车的地方Unity5项目里的中文乱码通常是两个原因脚本文件编码不是UTF-8或者运行时文本编码与平台默认编码不匹配。Windows上旧版Mono默认使用GBK读取C#文件如果脚本被保存成了带BOM的UTF-8某些情况下字符串里的中文会变成“锟斤拷”字体。我的处理办法很简单所有C#脚本统一用UTF-8 with BOM保存并且不要在脚本里硬编码用户可见文案。提示文本全部放在Resources下的TextAsset或ScriptableObject配置里运行时加载。private string GetText(string key) { TextAsset config Resources.LoadTextAsset(Lang/zh-CN); return ParseJsonString(config.text, key); }这样处理同时给后面做多语言版本留了后路。Unity5的JsonUtility对中文转义处理得没有后来的Newtonsoft.Json顺手我那时候直接用正则去解析问题也不大。总之记住一句话不要让中文裸奔在逻辑代码里。4.2 纹理内存和加载卡顿多平台发布最常见的内存杀手就是纹理。一张2048x2048的PNG在Windows上看着不大但打包到Android后如果用了RGBA32非压缩格式显存占用直接翻好几倍。之前我的角色立绘占用内存超过200MB低端机打开就闪退。后来我在项目里给所有UI纹理设置了合理的Max Size和FormatAndroid用ETC2、Windows用DXT5。WebGL平台对纹理尺寸还有额外限制个别旧移动浏览器根本不支持NPOT非2的幂次纹理所以我在导入设置里把All Platforms的Non-Power of 2处理设成了ToNearest。测试阶段最好用真机资源分析工具看看运行时到底加载了哪些大图而不是凭感觉压缩纹理。配置纹理格式是导入设置里的小事但直接决定你的游戏能不能在目标平台平稳运行。4.3 Android返回键、焦点丢失和生命周期桌面上玩家点关闭按钮游戏就能退出Android却有一套完整的生命周期。按下Home键、切到后台、来电打断这些情况都会触发OnApplicationPause或OnApplicationFocus。我在早期版本中直接把状态保存写在Update里频率高又乱后来统一改成在生命周期回调里集中处理。Android返回键在Unity里也有自己的一套如果忽略它游戏会直接退出如果处理不当又会和UI的关闭逻辑冲突。我给每个界面做了一个返回键拦截接口优先让UI决定是否消费事件只有所有UI都不拦截时才执行退出确认逻辑。这样桌面版的Esc键和Android的返回键可以共用一套逻辑避免平台差异导致操作割裂。void Update() { #if UNITY_ANDROID if (Input.GetKeyDown(KeyCode.Escape)) { if (!UIManager.Instance.HandleBackKey()) { ShowQuitDialog(); } } #endif }4.4 源码阅读从项目源码和UGUI源码里学东西多平台项目做到后面瓶颈往往不在功能而在代码维护效率。我养成了一个习惯每三天读一遍自己最近写的核心代码站在下一个人接手的角度去看能不能少踩几个坑。注释不用多但是每个平台差异宏所在的位置必须写清楚为什么。源码不是写完就完的它是后期所有修复和扩展的地基。另外Unity5的UGUI源码在官方仓库里能看到编译器也会把引擎生成的源码临时缓存到安装目录。想搞明白ScrollRect为什么会跳动、Mask为什么裁剪不干净直接看源码比看博客猜原因快得多。有些朋友觉得读引擎源码门槛高其实不一定要全懂重点找自己项目中卡住过的类和方法比如LayoutGroup、GraphicRaycaster把关键逻辑读透后续查UI问题会豁然开朗。踩过几次坑之后我现在接手的任何Unity项目都会先花半天把脚本目录和平台宏分布翻一遍。旧项目里往往藏着很多人为约定新功能如果不理解这些约定改一处坏三处。多平台开发更是这样代码结构清楚构建流程稳定比多写两个华丽功能更能支撑一个项目走到最后。如果你正准备把Unity5老项目搬到新平台建议先从小范围试点开始挑一个简单界面完整走一遍“代码拆分—适配—构建—真机验证”的流程再全面铺开。我当初没有这么做结果一边改输入系统一边处理UI适配两头都顾不上。后来把平台差异拆成独立模块整个项目的节奏才变得可控。C#的多平台编码能力再强也需要你提前把边界画清楚这大概是我在整个项目里收获最大的一点。本文还有配套的精品资源点击获取
Unity5+C#多平台开发实战：输入适配与构建避坑指南
简介这套实战源码围绕Unity引擎5.x版本与C#语言展开跨平台游戏开发面向希望掌握组件化架构、脚本编写及多平台发布流程的初中级开发者。项目通过实际场景演示了变换组件、网格渲染器与自定义脚本的协同方式并说明了脚本基类中Awake、Start、Update等生命周期方法的调用时机便于读者理解C#面向对象特性与引擎机制的结合。资源包为7z压缩格式大小约130MB内含场景文件、C#脚本、预设体、纹理、音频、着色器与材质等工程资源同时附有开发笔记和代码注释。从场景环境搭建、预设体复用到脚本逻辑管理、多平台导出配置能够支撑一条完整的学习与动手路线。目前已有490人学习浏览既可充当课程项目的补充素材也能作为独立实践的作品基础通过修改脚本参数、调整着色器与材质设置读者还可直观感受不同平台适配、性能优化及渲染效果的变化。 做了这么多年Unity项目最值得复盘的反而不是那些引擎高级特性而是Unity5 C#这套组合如何把一个游戏稳稳妥妥地搬到多个平台。我之前用Unity5开发过一个轻量级2D横版闯关游戏同时要出Windows、Android、WebGL三个版本。项目代码规模不大但输入、UI、存档、资源加载这些常规模块一个都躲不掉最有价值的不是某个功能多华丽而是把所有平台差异封在了一层代码里后续不管构建到哪个平台只用改配置不用动玩法逻辑。这篇文章就围绕着这份项目源码聊一聊多平台开发里的设计思路、关键实现和那些真正踩过的坑。写这篇内容不是想炫技而是给正在用Unity做小游戏的开发者一个可复制的工程骨架。如果你手头正好有Unity5项目要同步发布到多个平台或者想看看C#代码在跨平台时怎么组织最省心又或者只是对“源码怎么拆才不烂”这件事感兴趣这篇都值得往下看。1. 项目定位与整体设计思路1.1 为什么选Unity5 C#而不是其他方案当年做这个项目时可选择的技术栈其实不少Cocos2d-x、原生Java、H5游戏引擎都能做2D闯关。但最终选了Unity5核心原因是它的构建管线对多平台太友好了。我只需要维护一份C#逻辑代码其余渲染、音频、资源管理等底层问题全部交给引擎处理这在当时是性价比最高的方案。C#语言本身也帮了大忙。对比CC#的GC机制减少了手动管理内存的负担写UI逻辑、状态机、数据解析这类业务代码效率很高。而且Unity社区里大量插件、源码示例都是用C#写的遇到问题可以直接看反编译出来的IL或者官方脚本API不用在文档和论坛之间来回折腾。对于一个小团队或者个人开发者来说能快速出包、快速验证玩法比追求极致性能更重要。另外要特别说一句Unity5已经支持IL2CPP脚本后端Android平台可以告别Mono时代的一些兼容性问题代码在正式发包前能被提前编译成C再生成二进制运行效率和安全性都有提升。这个特性对多平台发布非常关键后面的构建部分我会再细说。1.2 目标平台选定不是越广越好不少新手拿到多平台需求后的第一反应是“能发布的所有平台都勾上”。我自己一开始也这么干过结果就是UI适配、输入差异、音频格式、加载策略全都要重新处理一遍项目进度被拖慢了一倍。所以这个项目一开始就定了三个主目标Windows、Android、WebGL。Windows负责桌面体验Android覆盖移动端WebGL用于快速分享Demo。iOS当时没排进来是因为团队没有苹果电脑和测试机签证书、上架这些流程没法闭环。做技术选型时一定要想清楚目标用户在哪哪些平台是必须的哪些只是“如果顺手就发”。平台每增加一个维护成本不是线性增长而是成倍增长。这三个平台的差异也很有代表性。Windows用键鼠输入Android靠触摸和物理返回键WebGL藏在浏览器里既没有完整的文件系统体验又对音频和纹理格式有严格限制。正因为差异够大做适配方案时才能把问题暴露得足够充分。如果这个项目只发Windows我后续根本不会有意识去抽象输入层和加载层。1.3 源码结构规划先把目录立起来很多Unity项目最后变得不可维护不是代码写得烂而是一开始目录结构就没规划。我在这个项目里强制把脚本放进了几个固定目录后续加功能、修Bug都很快找到位置。Assets/ Scripts/ Core/ # 游戏入口、主循环、全局管理器 Input/ # 所有输入相关封装 UI/ # 界面控制与组件逻辑 Data/ # 存档、配置、序列化模型 Platform/ # 平台差异代码与条件编译 Utils/ # 扩展方法、工具类 Prefabs/ Scenes/ Resources/ # 运行时动态加载的资源 Texture/ Audio/这套结构不是灵光一现而是吃过亏之后才定的。以前我喜欢把脚本按场景分比如MainScene、GameScene各建一个文件夹结果多个场景共用的逻辑被到处复制。现在改成按模块分场景只是组装层脚本通过生命周期和事件驱动项目后期改起来轻松很多。如果你在Unity5里建新项目我强烈建议先搭这套骨架不要等代码堆到两万行再重构。2. 核心玩法与关键模块的实现2.1 输入系统抽象把“按键”从平台里剥出来2D横版闯关最核心的操作是左右移动、跳跃、攻击。一开始为了省事我直接在逻辑代码里写Input.GetAxis(Horizontal)和Input.GetKeyDown(KeyCode.Space)Windows跑得很欢。但打包到Android后问题就来了手机上根本没有键盘触摸按键区域又和UI混在一起甚至一个不小心点到了屏幕边缘角色就开始抽搐。后来我把输入全部收进了一个静态类由它统一判断当前运行平台并返回逻辑操作。玩法代码只关心“玩家是否按下跳”不关心是键盘空格、屏幕虚拟按键还是手柄X键。public static class InputAdapter { public static bool GetJumpDown() { #if UNITY_ANDROID || UNITY_IOS return VirtualButton.GetJumpDown(); #else return Input.GetKeyDown(KeyCode.Space); #endif } public static float GetAxis() { #if UNITY_ANDROID || UNITY_IOS return VirtualJoystick.GetAxis(); #else return Input.GetAxis(Horizontal); #endif } }这个抽象层看起来简单但价值极大。之后加入手柄支持、键盘重映射都不用改玩法逻辑。我甚至发现以前写死的Input调用散落在十几个脚本里改输入方式要全项目搜索现在只需要改InputAdapter这一个类。2.2 UGUI适配不同分辨率下的Canvas设置多平台开发里最让人头疼的往往是UI而不是游戏逻辑。同一个界面在Windows的16:9显示器上显示正常到了Android的全面屏上可能按钮被挖孔遮挡或者底部多出一截黑边。Unity5时代的UGUI已经比NGUI好用很多但前提是Canvas设置正确。我的做法是所有核心界面都放在一个Canvas下Canvas Scaler模式设为Scale With Screen Size参考分辨率用1280x720Screen Match Mode选择MatchWidthOrHeight并把比例调到0.5。这样在接近16:9的设备上不会出现明显拉伸在带鱼屏或平板这类极端比例下也能保持基本可读。// UI加安全区适配时我会在根节点上挂一个SafeAreaAdapter RectTransform rect GetComponentRectTransform(); rect.anchorMin new Vector2(0, Screen.safeArea.yMin / Screen.height); rect.anchorMax new Vector2(1, Screen.safeArea.yMax / Screen.height); rect.offsetMin Vector2.zero; rect.offsetMax Vector2.zero;代码里的Screen.safeArea是在引擎里读取系统安全区信息适配屏幕挖孔和圆角非常好使。不过Unity5早期部分版本对safeArea的支持不够完善需要先用平台宏判断再在Android上通过调用原生代码获取否则就退回默认Rect。这也算是跨平台坑的一个典型不要假设每个引擎版本都能帮你把所有细节兜住。2.3 存档与数据处理别在PlayerPrefs里放结构体很多小项目喜欢把玩家的金币、关卡进度直接塞进PlayerPrefs字符串拼一拼就完事。这个项目早期也是这样但后来发现两个问题一是PlayerPrefs在部分平台上编辑不方便测试人员看不到完整存档二是多处读写的键名一旦拼错数据就乱了还很难排查。我后来把存档统一成一份可序列化的存档模型用JsonUtility序列化成字符串再写入文件。存档类长这样[System.Serializable] public class SaveData { public int gold; public int maxLevel; public bool isMusicOn; public string playerName; } public static class SaveManager { private static SaveData data new SaveData(); public static void Save() { string json JsonUtility.ToJson(data); string path Path.Combine(Application.persistentDataPath, save.json); File.WriteAllText(path, json); } public static void Load() { string path Path.Combine(Application.persistentDataPath, save.json); if (File.Exists(path)) { string json File.ReadAllText(path); data JsonUtility.FromJsonSaveData(json); } } }Unity5的JsonUtility不能直接序列化Dictionary和部分复杂类型遇到这种需求我会用数组或嵌套类绕过去。写存档时记得先备份旧文件再写入新文件避免中途断电导致整个存档损坏。后来我又给Save类加了版本号字段以后字段结构变化时可以做兼容迁移。这个经验是从线上玩家反馈“更新版本后金币清零”学来的别看存档简单做不好一样翻车。2.4 资源与场景加载保持简单的加载策略小体量游戏其实用不上复杂的AssetBundle方案Resources.Load足够撑起大部分需求。我当时的做法是UI图标、音效、敌人预制体都丢在Resources目录下游戏启动时预加载必要资源战斗过程中按需加载。var enemyPrefab Resources.LoadGameObject(Prefabs/Enemies/NormalEnemy); Instantiate(enemyPrefab, spawnPoint.position, spawnPoint.rotation);Resources.Load的缺点是资源会无脑打进包体而且不容易做增量更新。Unity5时代做多平台时我记得不同平台对Resources目录中的资源压缩规则还不完全一样所以图集和纹理格式我都尽量统一避免“Android构建正常WebGL却花了十分钟加载”这种情况。后来随着包体变大我引入了AssetBundle来拆分平台资源和热更内容但那时候把核心逻辑稳定下来更重要。建议新手别一上来就折腾AssetBundle先把Resources这条简单的路走通再考虑热更新性能优化否则很容易陷入加载框架的泥潭里出不来。3. 多平台构建与代码层适配3.1 构建前必须检查的Player Settings很多人写代码写得很欢一到出包就卡在设置上。Unity5的Player Settings面板里有几个选项直接影响多平台构建是否成功我每次出包前都会逐项确认。Company Name和Product Name不能带中文和特殊字符Android包名建议用com.company.product这种格式。Default Icon每个平台最好都手动指定图标否则某些平台会用Unity默认图标看起来非常业余。Scripting BackendAndroid平台我用IL2CPPWindows则用Mono这样兼容性和迭代速度都比较好。OrientationAndroid和iOS要注意屏幕方向横版游戏就锁定Landscape千万别留AutoRotation。API Compatibility Level如果引用了.NET Framework特性在Unity5里要选.NET 2.0或4.x否则编译直接报错。这些设置之所以要重点检查是因为它们不参与代码编译报错通常不会第一时间出现在Console里。有一次我WebGL构建失败原因只是Player Settings里的WebGL模板被设置成了空模板加载界面直接白屏查了半个多小时。3.2 Windows、Android、WebGL的真实差异用表格看这三个平台的差异最直观这也是我在项目里总结出来的比较项WindowsAndroidWebGL输入方式键鼠、手柄触摸、重力、返回键键鼠、触摸屏浏览器持久化Application.persistentDataPath可写应用私有目录可写受限建议用PlayerPrefs或后端文件访问支持同步IO支持同步IO但低端机可能卡顿不直接支持文件流音频格式WAV/MP3/OggMP3/Ogg效率要好Ogg为首选MP3兼容性差纹理格式常用DXTETC/ASTCWebGL对尺寸有严格限制构建体积相对较小需带IL2CPP库包体变大压缩后较小但要考虑网络加载这段表格我建议截图存下来。每次换平台构建时先对照一遍比盯着Console报错一个个试靠谱得多。比如WebGL不能直接读写本地文件我就把存档策略从文件改成了PlayerPrefs再加个云端同步接口彻底解决了跨设备问题。3.3 条件编译一份代码兼容所有平台Unity的C#编译器会根据当前构建目标自动设置宏比如UNITY_ANDROID、UNITY_WEBGL、UNITY_STANDALONE。合理利用条件编译可以把平台差异代码放在同样的逻辑流程里而不是写几套重复脚本。public class PlatformEventHandler : MonoBehaviour { void OnApplicationFocus(bool hasFocus) { #if UNITY_ANDROID // Android切后台时保存存档 SaveManager.Save(); Debug.Log(Android focus lost, save data.); #elif UNITY_WEBGL // WebGL页面隐藏时暂停游戏 PauseGame(); #else if (!hasFocus) SaveManager.Save(); #endif } }用条件编译要克制不能把整个游戏逻辑都包进去。我的原则是只放平台API调用不放业务逻辑。比如Android返回键处理、iOS震动画、WebGL浏览器关闭事件这些必须用宏区分但角色属性、敌人AI这些和平台无关的逻辑必须保持完全一致否则两个平台玩起来手感都不一样。代码里宏如果超过三处嵌套我就会把相关逻辑抽到一个独立方法里防止可读性崩掉。3.4 真机调试与日志查看编辑器里跑不出来的Bug往往一到真机就露馅。Android平台最常用的是Unity的Development Build加Android Logcat窗口。我习惯在每次打包时勾上Development Build和Script Debugging然后在真机上复现问题把Logcat里的异常栈拉出来看。WebGL平台的调试比Android更隐蔽因为Unity脚本是编译成WebAssembly跑的异常信息经常丢帧。我在JavaScript层挂了一个错误捕获把Unity的Application.logMessageReceived事件输出到浏览器控制台这样查起问题来和编辑器里差不多。void Awake() { Application.logMessageReceived (condition, stackTrace, type) { // 浏览器控制台里会显示Unity日志 Debug.LogWarning($UnityLog: {type} {condition}\n{stackTrace}); }; }真机调试时还有一个容易被忽略的问题构建机器的显卡驱动和Shader效果会和开发机不一样。我在Windows上跑得很正常的描边效果到Android真机上莫名其妙出现了黑边最后发现是Shader里用了半精度浮点导致。遇到这种渲染差异优先检查是否用了高精度变量、贴图格式以及压缩纹理的采样方式。4. 实践中踩过的坑与排查技巧4.1 中文乱码老项目最容易翻车的地方Unity5项目里的中文乱码通常是两个原因脚本文件编码不是UTF-8或者运行时文本编码与平台默认编码不匹配。Windows上旧版Mono默认使用GBK读取C#文件如果脚本被保存成了带BOM的UTF-8某些情况下字符串里的中文会变成“锟斤拷”字体。我的处理办法很简单所有C#脚本统一用UTF-8 with BOM保存并且不要在脚本里硬编码用户可见文案。提示文本全部放在Resources下的TextAsset或ScriptableObject配置里运行时加载。private string GetText(string key) { TextAsset config Resources.LoadTextAsset(Lang/zh-CN); return ParseJsonString(config.text, key); }这样处理同时给后面做多语言版本留了后路。Unity5的JsonUtility对中文转义处理得没有后来的Newtonsoft.Json顺手我那时候直接用正则去解析问题也不大。总之记住一句话不要让中文裸奔在逻辑代码里。4.2 纹理内存和加载卡顿多平台发布最常见的内存杀手就是纹理。一张2048x2048的PNG在Windows上看着不大但打包到Android后如果用了RGBA32非压缩格式显存占用直接翻好几倍。之前我的角色立绘占用内存超过200MB低端机打开就闪退。后来我在项目里给所有UI纹理设置了合理的Max Size和FormatAndroid用ETC2、Windows用DXT5。WebGL平台对纹理尺寸还有额外限制个别旧移动浏览器根本不支持NPOT非2的幂次纹理所以我在导入设置里把All Platforms的Non-Power of 2处理设成了ToNearest。测试阶段最好用真机资源分析工具看看运行时到底加载了哪些大图而不是凭感觉压缩纹理。配置纹理格式是导入设置里的小事但直接决定你的游戏能不能在目标平台平稳运行。4.3 Android返回键、焦点丢失和生命周期桌面上玩家点关闭按钮游戏就能退出Android却有一套完整的生命周期。按下Home键、切到后台、来电打断这些情况都会触发OnApplicationPause或OnApplicationFocus。我在早期版本中直接把状态保存写在Update里频率高又乱后来统一改成在生命周期回调里集中处理。Android返回键在Unity里也有自己的一套如果忽略它游戏会直接退出如果处理不当又会和UI的关闭逻辑冲突。我给每个界面做了一个返回键拦截接口优先让UI决定是否消费事件只有所有UI都不拦截时才执行退出确认逻辑。这样桌面版的Esc键和Android的返回键可以共用一套逻辑避免平台差异导致操作割裂。void Update() { #if UNITY_ANDROID if (Input.GetKeyDown(KeyCode.Escape)) { if (!UIManager.Instance.HandleBackKey()) { ShowQuitDialog(); } } #endif }4.4 源码阅读从项目源码和UGUI源码里学东西多平台项目做到后面瓶颈往往不在功能而在代码维护效率。我养成了一个习惯每三天读一遍自己最近写的核心代码站在下一个人接手的角度去看能不能少踩几个坑。注释不用多但是每个平台差异宏所在的位置必须写清楚为什么。源码不是写完就完的它是后期所有修复和扩展的地基。另外Unity5的UGUI源码在官方仓库里能看到编译器也会把引擎生成的源码临时缓存到安装目录。想搞明白ScrollRect为什么会跳动、Mask为什么裁剪不干净直接看源码比看博客猜原因快得多。有些朋友觉得读引擎源码门槛高其实不一定要全懂重点找自己项目中卡住过的类和方法比如LayoutGroup、GraphicRaycaster把关键逻辑读透后续查UI问题会豁然开朗。踩过几次坑之后我现在接手的任何Unity项目都会先花半天把脚本目录和平台宏分布翻一遍。旧项目里往往藏着很多人为约定新功能如果不理解这些约定改一处坏三处。多平台开发更是这样代码结构清楚构建流程稳定比多写两个华丽功能更能支撑一个项目走到最后。如果你正准备把Unity5老项目搬到新平台建议先从小范围试点开始挑一个简单界面完整走一遍“代码拆分—适配—构建—真机验证”的流程再全面铺开。我当初没有这么做结果一边改输入系统一边处理UI适配两头都顾不上。后来把平台差异拆成独立模块整个项目的节奏才变得可控。C#的多平台编码能力再强也需要你提前把边界画清楚这大概是我在整个项目里收获最大的一点。本文还有配套的精品资源点击获取
![[数字安全] GB/Z 24364《信息安全风险管理指南》中的风险评估的实施过程深度解析](http://pic.xiahunao.cn/yaotu/[数字安全] GB/Z 24364《信息安全风险管理指南》中的风险评估的实施过程深度解析)
