简介《Unity5实战使用C#和Unity开发多平台游戏》源码是一份面向初、中级Unity开发者的学习型资源尤其适合想要系统掌握跨平台游戏开发流程的读者。资源以Unity5引擎和C#语言为核心从组件系统、Transform与脚本协同到MonoBehaviour的Awake、Start、Update等生命周期方法再到类、继承、接口等面向对象设计逐步串联起游戏逻辑的编写思路。源码包采用7z压缩格式整体约130.09MB内容涵盖场景文件、C#脚本、预设体、纹理音频及Shader/Material配置场景文件定义关卡布局脚本负责行为逻辑预设体便于跨场景复用目录结构清晰适合按模块查阅。目前已有491人学习下载可见其作为实战参考材料的热度。通过研究这份源码读者既能学会在Unity5中搭建游戏场景、编写C#交互逻辑也能了解不同平台iOS、Android、Windows等输入差异、性能优化与分辨率适配的处理方式同时还为后续独立开发多平台游戏提供了可借鉴的工程组织与调试经验对提升实战能力有明显帮助。1. Unity5实战用C#做多平台游戏源码该怎么组织才不翻车做Unity多平台游戏经常遇到这种开局编辑器里手感很好Build Settings勾上Android、iOS、Windows三个平台开始打包。Android包装上手机秒退iOS证书没配置还打不了Windows运行一会CPU居高不下而你最初只改过一行分辨率代码。Unity5把跨平台构建管线统一了真正的分水岭在C#源码的组织方式平台判断、输入、存档路径若全部写在业务逻辑里多平台发布就是连环翻车现场。下面要拆的不是教程demo而是一套能迁移到真实项目的多平台C#基础结构——平台宏、输入抽象、存储路由和验证清单。适合已经写过C#基础、准备把项目导出到第二个平台的开发者照着改。2. 平台宏与源码目录先定型编译期分支决定后续三端兼容2.1 用条件编译宏隔离平台差异而不是运行时if如果你把一个多平台游戏拆开看真正会因为平台不同的代码其实只有几类输入读取、存储位置、屏幕分辨率、部分渲染特性以及第三方SDK。这些差异如果不做隔离项目做到后期业务逻辑里到处是if (Application.platform RuntimePlatform.Android)每次平台切换都会多跑三个分支。更麻烦的是运行时判断没法删掉多余的代码最终包体里带着所有平台的分支代码热更新和AOT编译场景下还可能出现平台API误调用。Unity从编译层面提供了一组宏定义能把这部分差异提前到编译期处理using UnityEngine; public class PlatformRouter : MonoBehaviour { void Start() { #if UNITY_ANDROID !UNITY_EDITOR // Android真机关垂直同步主动锁定帧率 QualitySettings.vSyncCount 0; Application.targetFrameRate 60; Debug.Log(Android targetFrameRate-60); #elif UNITY_IOS !UNITY_EDITOR QualitySettings.vSyncCount 1; Debug.Log(iOS vSync-1); #elif UNITY_STANDALONE QualitySettings.vSyncCount 1; Debug.Log(Standalone vSync-1); #else // 编辑器默认保持60帧即可 Application.targetFrameRate 60; #endif } }这段代码的关键不在帧率数值而在三个平台的分支互斥关系。UNITY_ANDROID、UNITY_IOS、UNITY_STANDALONE由Unity构建管线在预处理阶段写入C#编译器只编译命中平台的那一段。所以这段代码到了真机上实际上只包含一条初始化语句不会有任何多余的平台分支。这里特别加了一句!UNITY_EDITOR是为了防止你在编辑器里运行安卓模拟模式时把编辑器误当成安卓真机去关掉垂直同步导致预览画面撕裂。参数上的两个习惯我建议直接沿用Application.targetFrameRate在Unity5里是跨平台通用属性安卓上设置60可以让游戏主动申请60Hz刷新不和系统省电策略打架QualitySettings.vSyncCount设为0时渲染循环不再等待显示器垂直回扫这时必须配合targetFrameRate设一个上限否则GPU会满载空转。iOS端一般保留vSyncCount 1因为iOS系统自身有较严格的功耗管理垂直同步反而让帧率更稳定。如果你不只做移动和桌面还要兼顾WebGL宏名还得多记两个UNITY_WEBGL和UNITY_EDITOR。WebGL平台在Unity5里不能使用System.IO的文件写接口也不能同步加载资源这些特性约束都适合用宏在编译期提前锁死。我的经验是与其在运行时写一堆Application.platform判断不如在最早初始化阶段就按宏给全局配置类赋值之后业务逻辑只认配置不再认平台。2.2 源码目录和资源目录按平台分层避免Plugins和Resources一锅烩宏能把代码的差异提前资源也类似。Unity里有些目录有平台语义放对了省心放错了直接埋雷。Assets/ ├── Art/ │ ├── Models/ │ ├── Textures/ │ └── Audio/ ├── Code/ │ ├── Core/ │ ├── Gameplay/ │ └── UI/ ├── Data/ │ └── Config.json # 随包打进去的只读配置 ├── Editor/ │ └── MultiPlatformBuilder.cs ├── Plugins/ │ ├── Android/ │ ├── iOS/ │ └── WebGL/ ├── Resources/ │ ├── UIAtlas.prefab │ └── GameSettings.asset ├── Scenes/ │ └── Main.unity └── StreamingAssets/ └── LevelData/ # 运行时读取的关卡数据这个目录结构有四个固定项需要注意。第一Editor文件夹是Unity的魔法目录里面所有C#脚本只在编辑器环境编译不会进入任何平台包体适合放上一节说的BuildPipeline构建脚本和静态检查工具。第二Plugins/Android、Plugins/iOS是Unity的另一个平台语义目录对应的.so、.aar、.framework会在打包时只进入目标平台如果这些文件放错到Assets根目录打包时会报Architecture不匹配。第三StreamingAssets里的文件会原封不动拷贝到各平台安装包但不同平台的读取路径不一样这个在第三章会专门讲。第四Resources目录不要随意扩大这个目录下的所有资源在Unity5里都会打进同一个包而且运行时Resources.Load是全局字符串查找目录过大时加载耗时和内存占用都存在隐患。目录分层的核心目的是把平台专属内容和共享逻辑分开。比如安卓的通知权限插件、iOS的支付回调都放在各自插件目录游戏自身的玩法逻辑只放在Code里通过公共同名类跨平台。这样当你要出第二个平台包时排除某个插件目录或改名都很快不需要在场景里逐个找引用挂接的资源。有一个容易翻车的习惯是把美术素材按平台名建文件夹比如Art/Android和Art/iOS。这会让Prefab里的引用路径在跨平台时完全失效重建prefab的成本很高。正确做法是只有拿第三方SDK或平台API封装的资源才按平台放Plugins普通美术资源只按资源类型分目录平台差异交给代码层去处理。2.3 用BuildPipeline把Android、iOS、Windows一次打包用Unity界面手动出包有个痛点每次都要去Build Settings勾选场景、选平台、改Player Settings一旦漏一步出包后直接浪费时间。常见做法是把打包流程写成一个编辑器脚本放到Assets/Editor目录下通过菜单栏一键执行using UnityEditor; using UnityEngine; using System.IO; public static class MultiPlatformBuilder { [MenuItem(Tools/Build All Platforms)] public static void BuildAll() { // 打包时间戳目录避免覆盖上一次的包 string stamp System.DateTime.Now.ToString(yyyyMMdd_HHmm); string root Builds/ stamp; string[] scenes { Assets/Scenes/Main.unity }; // AndroidLZ4HC压缩测试包加Development BuildPipeline.BuildPlayer( scenes, Path.Combine(root, Android/game.apk), BuildTarget.Android, BuildOptions.CompressWithLz4HC | BuildOptions.Development ); // iOS不能直接生成ipa这里导出Xcode工程 BuildPipeline.BuildPlayer( scenes, Path.Combine(root, iOS), BuildTarget.iOS, BuildOptions.None ); // Windows 64位桌面 BuildPipeline.BuildPlayer( scenes, Path.Combine(root, Win64/game.exe), BuildTarget.StandaloneWindows64, BuildOptions.CompressWithLz4HC ); Debug.Log(构建完成输出目录 root); } }这个脚本里值得说的参数有四个。BuildTarget.Android、BuildTarget.iOS、BuildTarget.StandaloneWindows64分别对应三端目标Unity会按这个枚举值调用对应的构建管线。BuildOptions.Development会给包体附加调试信息和脚本调试器方便用日志定位问题但正式发布时不要勾否则包体尺寸和运行速度都会受影响。BuildOptions.CompressWithLz4HC是对AssetBundle采用LZ4 HC压缩这是构建时间换安装包体积的典型做法发布包推荐用如果只做本地测试用CompressWithLz4速度更快。iOS那一步的第二个参数传的是目录而不是文件这点容易误解。BuildPipeline.BuildPlayer对iOS会生成一份Xcode工程并不会直接在命令行帮你完成签名和ipa导出。所以你在自动打包脚本里通常还会再调用xcodebuild或fastlane去完成签名归档。这也是为什么很多团队把iOS打包单独放到打包机上做避免本机装全套Xcode。当时我踩过的一个细节是BuildPipeline.BuildPlayer在打包Android时如果Player Settings里的Package Name不对脚本照样能跑但装上后会和其他项目包名冲突安装时直接提示签名不一致。这属于配置检查的层面我会在第5章给一个自查清单。3. 用C#抽象输入、存储与屏幕跨平台必须改的三个子系统3.1 输入抽象层虚拟摇杆与手柄在共享代码里的共处方式游戏逻辑里最容易被平台打乱的是输入这一层。桌面端有键盘鼠标手柄移动端只有触摸和虚拟按键WebGL的输入延迟特征又不相同。如果让游戏逻辑去直接访问Input.GetAxisRaw(Horizontal)你会在移动端看到角色无法控制因为移动端根本没有键盘轴输入也没有默认的轴映射。我的方案是在逻辑层之上单独建一个GameInput静态类所有玩法逻辑只跟它交互using UnityEngine; public static class GameInput { // 每帧调用返回归一化移动方向 public static Vector2 moveDelta Vector2.zero; public static Vector2 lookDelta Vector2.zero; public static void Tick() { Vector2 move Vector2.zero; #if UNITY_STANDALONE || UNITY_WEBGL // 桌面与网页端优先键盘手柄兼顾鼠标 move.x Input.GetAxisRaw(Horizontal); move.y Input.GetAxisRaw(Vertical); // 手柄右摇杆映射到视角旋转第二组轴 lookDelta.x Input.GetAxisRaw(JoystickAxis3); lookDelta.y Input.GetAxisRaw(JoystickAxis4); #elif UNITY_ANDROID || UNITY_IOS // 移动端只能读UI虚拟摇杆写入的状态 move.x VirtualJoystick.horizontal; move.y VirtualJoystick.vertical; #endif // 向量归一化防止斜向移动速度超过直行 if (move.sqrMagnitude 1f) move.Normalize(); moveDelta move; } }这套抽象的关键有两处。第一平台宏在编译期把输入源分流桌面读轴移动读虚拟摇杆变量业务层代码不需要知道当前平台。第二VirtualJoystick是一个简单的静态变量容器由UI层在拖动虚拟摇杆时写入Unity UGUI的EventTrigger或Slider都能实现写入我这里只约定数据入口避免UI控件和玩法代码强耦合。这里有个常用但容易翻车的点Input.GetAxisRaw返回的是不经过平滑的原始值手感偏硬很多教程推荐用Input.GetAxis带平滑包络。但在移动端如果读的是虚拟摇杆平滑是UI层应该做的逻辑层直接读原始值即可。如果逻辑层再做一次平滑控制延迟会叠加。我一般会在抽象层里允许注入sensitivity和deadZone参数把摇杆死区收敛到一块而不是散落在各玩法脚本里。对手柄的支持就得说回Unity5的Input Manager。默认工程里只有Horizontal和Vertical两根轴手柄右摇杆读取往往需要自定义四根轴。做法是在Edit Project Settings Input里新增JoystickAxis3到JoystickAxis6分别对应右摇杆XY和LT/RT扳机再在抽象层里按GetAxisRaw(JoystickAxis3)读取。很多主机移植项目的坑都是默认轴读出来是0加了几根轴立刻正常。3.2 存档路径与读写策略不同平台不能共用一套字符串持久化存储是第二个跨平台重灾区。Windows上写C:/Users/xxx/AppData没问题Android上外部存储没有写权限iOS的沙盒目录每次启动位置不完全独立而且Unity不同版本对persistentDataPath的映射还变过。如果代码里把存档路径写死当前平台能存换一个平台直接抛DirectoryNotFoundException。using System.IO; using UnityEngine; public static class SaveSystem { public static string GetSavePath(string fileName) { string dir; #if UNITY_EDITOR // 编辑器里把存档放到工程外避免污染Assets目录 dir Path.Combine(Application.dataPath, ../SaveData); #elif UNITY_STANDALONE // 通用AppData路径C#的Directory API可正常操作 dir Application.persistentDataPath; #elif UNITY_ANDROID // Android上位于 /storage/emulated/0/Android/data/包名/files dir Application.persistentDataPath; #elif UNITY_IOS // iOS沙盒DocumentsiCloud备份会包含此目录 dir Path.Combine(Application.persistentDataPath, Documents); #else dir Application.persistentDataPath; #endif // 目录不存在就创建避免首次写档抛异常 if (!Directory.Exists(dir)) Directory.CreateDirectory(dir); return Path.Combine(dir, fileName); } }这套代码在不同平台选择的是同一个语义——持久化可写目录。Unity的Application.persistentDataPath在安卓和iOS上都会映射到系统分配的应用专属目录不依赖绝对路径所以代码层面一共只有两处差异编辑器下输出到工程外iOS加了Documents子目录。为什么要加Documents因为iOS的iCloud备份默认只针对Documents目录玩家进度放这里能跟随iCloud恢复而临时缓存文件会放到tmp一旦升级系统或空间紧张缓存清掉不影响存档。存储的另一个坑是写频率。在移动端频繁File.WriteAllText会触发GC和IO中断卡顿肉眼可见。常见做法是把存档对象序列化成一个POCO类内存里维护引用按明确时机切场景、回主菜单、应用退到后台才落盘一次。我习惯用OnApplicationPause回调在安卓切后台瞬间写一次档而不是每帧都写。3.3 屏幕比例与UI安全区Unity5时代没有官方safeArea怎么破现代手机比例早就不是16:9刘海屏、打孔屏、折叠屏把UI适配变成一场持久战。Unity在2017.2以后才提供Screen.safeAreaUnity5时期没有这个接口典型的做法是手动维护一张安全距离表按设备型号给UI边距做补偿。using UnityEngine; using UnityEngine.UI; public class SafeAreaFitter : MonoBehaviour { [Tooltip(四项边距补偿值上、下、左、右像素)] public int topInset; public int bottomInset; public int leftInset; public int rightInset; private RectTransform rectTrans; void Awake() { rectTrans GetComponentRectTransform(); Apply(); } void Update() { // 屏幕旋转或分辨率变化时重新适配 if (Screen.orientation ScreenOrientation.AutoRotation) Apply(); } public void Apply() { // 将补偿值换算成anchor偏移按当前屏幕像素计算 float width Screen.width; float height Screen.height; Vector2 anchorMin new Vector2( leftInset / width, bottomInset / height ); Vector2 anchorMax new Vector2( (width - rightInset) / width, (height - topInset) / height ); rectTrans.anchorMin anchorMin; rectTrans.anchorMax anchorMax; rectTrans.offsetMin Vector2.zero; rectTrans.offsetMax Vector2.zero; } }这段代码解决的是UI四边避开刘海和圆角的需求。它的原理是绕过屏幕参考分辨率体系直接按当前屏幕像素计算锚点所以无论CanvasScaler怎么缩放锚点比例都不会被缩放二次放大。手机横屏时刘海在左侧竖屏时刘海在顶部你只需要在进入场景前根据Screen.orientation给leftInset或topInset赋值。这里有个关键细节在Unity5时代这套补偿值是机型相关的而不是百分比。因为不同机型的刘海宽度和圆角半径不一样纯按百分比算会在某些机型上留白过多、某些机型上还是被遮。常见做法是建立一个根据SystemInfo.deviceModel查表的工具类内置主流机型的安全距离值再留一个运行时手动调整接口供QA测试时修正。配合这套补偿的逻辑CanvasScaler的基准分辨率建议固定成1280x720横屏或720x1280竖屏ScreenMatchMode用Shrink而不是Expand避免UI在小屏上被等比缩小到看不清。如果你同时发横屏和竖屏两个版本我的实践是两个Canvas分支各自套一组不同基准不要试图用一套Canvas在旋转时无缝处理那会导致预排版全部错位。4. 多平台适配踩坑记录5个从现象到解决的排查思路这一节里的每条记录都是我在实际项目中真金白银踩出来的。4.1 Android包安装后秒退编辑器正常运行现象Android APK在真机上点击图标一两秒后直接退回桌面没有异常弹窗同一场景在编辑器里播放完全正常。原因最常见是Player Settings里Scripting Backend选了IL2CPP但本机NDK版本和Unity5要求的版本不匹配。Unity5时期的IL2CPP需要特定NDK r10e或以上装错NDK版本后C层链接失败运行时java调用不被解析于是静默闪退。另一种常见原因是第三方SDK的AndroidManifest.xml里有Provider或Activity没注册。解决先用adb拉日志确认崩溃点adb logcat -s Unity | tail -50如果看到libil2cpp.so或JNI错误去Unity安装目录下的AndroidSupport检查NDK版本在Player Settings里重新指向匹配的NDK。同时检查Assets/Plugins/Android/AndroidManifest.xml把缺失的provider和activity按SDK文档补齐。这条日志命令在Windows/Linux/macOS的终端都能跑前提是手机开了USB调试。4.2 粒子特效内存在移动端越用越多现象游戏在PC上连续运行30分钟内存稳定打包到安卓后多次播放爆炸特效内存占用逐渐攀升最终触发系统杀进程。原因粒子系统在Unity5移动端有两个容易忽略的默认行为。第一ParticleSystem.Main里的Stop Action通常设为None粒子播放完对象还挂在场景里Stop后不会自动Disable持续占住网格和材质引用第二玩法里用Instantiate/ Destroy反复创建特效对象频繁触发的GC堆膨胀在移动端被放大。解决给粒子特效建一个对象池播放完回收而不是销毁。参考实现using System.Collections.Generic; using UnityEngine; public class ParticlePool : MonoBehaviour { public GameObject particlePrefab; public int prewarmCount 5; private QueueParticleSystem _pool new QueueParticleSystem(); void Start() { for (int i 0; i prewarmCount; i) { var ps CreateNew(); ps.gameObject.SetActive(false); _pool.Enqueue(ps); } } public ParticleSystem Spawn() { ParticleSystem ps _pool.Count 0 ? _pool.Dequeue() : CreateNew(); ps.gameObject.SetActive(true); ps.Play(); return ps; } public void Recycle(ParticleSystem ps) { // 先Stop再Clear避免残留粒子在下次Play时闪一下 ps.Stop(true, ParticleSystemStopBehavior.StopEmittingAndClear); ps.gameObject.SetActive(false); _pool.Enqueue(ps); } private ParticleSystem CreateNew() { return Instantiate(particlePrefab, transform).GetComponentParticleSystem(); } }对象池的关键参数是prewarmCount和回收时机。预创建数量按单屏同时出现的最大特效数来定多了占内存少了池命中率不够又回到Instantiate的循环。StopEmittingAndClear告诉粒子系统停止发射并把已生成粒子清空否则下次Spawn时会看到一帧旧粒子残影。这个方案同样适用Unity5和后续版本而且对3D特效和UI特效都有效。4.3 Time.timeScale暂停引起物体速度计算错乱现象游戏里菜单暂停用Time.timeScale 0恢复后在斜坡上的Rigidbody物体突然穿模或者Rigidbody.velocity读到的物体速度比暂停前小一大截。原因Unity5的timeScale影响所有基于Time.deltaTime的计时包括物理模拟、Animator、粒子。物体速度用Rigidbody.velocity读取时如果在暂停瞬间物理步进行到一半恢复后速度会被插值重置表现成失速后突然加速。还有一个隐蔽处暂停后UI动画如果还用Time.deltaTime驱动会完全不动。解决把UI动画和倒计时从Time.deltaTime切到Time.unscaledDeltaTime物理刚体在暂停时用Rigidbody.Sleep()恢复时WakeUp()读速度时不要依赖单帧的velocity多用两帧平滑float speed rb.velocity.magnitude; float smoothSpeed Mathf.Lerp(lastSpeed, speed, Time.unscaledDeltaTime * 10f);unscaledDeltaTime在Unity5.4以后可用这就是针对游戏暂停和全屏卡顿场景的标准API。Mathf.Lerp的平滑系数按10Hz左右取值即可太高会让读出的速度值抖动。要显示速度的UI建议按真实速度保留一位小数平滑值只用于指数条或特效不要直接给玩家看否则读出来和实际数值对不上。4.4 手柄右摇杆失灵Input Manager默认轴不够用现象同一套代码在Windows编辑器和安卓TV上表现不同键鼠操控正常手柄左摇杆正常右摇杆完全没反应或偶尔方向乱跳。原因Unity Input Manager默认只暴露Horizontal和Vertical两组2D轴左右摇杆共用一组右摇杆通过第四轴读取但默认工程没有定义对应轴名导致GetAxisRaw(JoystickAxis3)返回恒0。解决在Player Settings的Input Manager里新增四根自定义轴命名为JoystickAxis3到JoystickAxis6对应右摇杆和扳机Negative Button和Positive Button留空类型选Joystick Axis。如果项目同时要支持Xbox和PS手柄轴顺序可能不同稳妥做法是做一个手柄检测界面运行时让玩家拨动摇杆识别并保存轴映射。4.5 高宽比屏幕把UI裁出屏外现象iPhone X、三星折叠屏这类高宽比设备上顶部按钮被刘海遮挡底部按钮被Home条压住切到分屏后一侧内容丢失。原因CanvasScaler的ScaleWithScreenSize只保证设计的逻辑分辨率等比缩放遇到刘海屏运算没有预留热区数据内容锚点如果贴在屏幕顶部就正好落在刘海区域。解决使用3.3节的SafeAreaFitter补偿顶部和底部边距并在Canvas下加一套专用SafeArea面板存放所有关键操作。真机测试时专门准备几台异形屏设备不要只在模拟器测试。这属于UI层验证的范畴我在下一章会把它放进发布前的固定步骤。5. 发布前三件必须坚持的事真机矩阵、包体预算与构建留痕到了这一步源码层面的事情基本定型最后一关在验证和习惯。我这些年做多平台发布有三件事是雷打不动的。第一准备一个最小真机矩阵。桌面端留一台Win10、一台macOS移动端留一台中端安卓、一台旗舰安卓、一台iPhone、一台iPad。不需要把市面上所有机型都买回来但上面这个矩阵能覆盖90%的架构差异x86_64、ARMv7、ARM64、iOS的Metal路径。每次发版前在这个矩阵上把主流程手动走一遍比自动化测试更早发现分辨率、输入延迟和功耗问题。第二给包体确定一个预算上限。Unity5时代的安装包如果能压到100MB以内移动端很多渠道的审核和下载转化会友好很多。常用压缩顺序是先用Build Report看各资源占比纹理集成图集、音频压成Vorbis、剔除无用的场景依赖再用LZ4HC把AssetBundle压到极致最后把大配置从场景Prefab里剥出来用ScriptableObject承载避免整个场景因为一个配置改动整包重打。第三每次构建都留一份日志和产物清单。我习惯在BuildPipeline脚本里把构建时间、Unity版本、构建选项、输出包MD5写进一个build_manifest.txtvar md5 ComputeMd5(buildPath); File.WriteAllText( Path.Combine(root, build_manifest.txt), $time{stamp}\nplatform{BuildTarget.Android}\nmd5{md5} );这样三天后测试反馈某个包有bug我能立刻知道这个包用的哪套代码、哪个平台、哪个构建选项不用对着一个game_v13_最终版2.apk猜谜。这个习惯自从某次因为分不清两个包的代码差异白白浪费了整晚后就一直保持了下来。给还在Unity5里挣扎的同行一个参考别指望一套源码拿来就能跑。你拿到任何多平台源码第一件事永远是按第二章的宏和目录把平台骨架重新过一遍然后按第三章把输入和存档接回自己的项目再按第四章的坑逐条排查最后才谈得上优化和发布。把这套顺序固定成自己的构建习惯多平台发布本身就会变成一件没那么玄学的事。希望帮到你。本文还有配套的精品资源点击获取