【Game-Infra】游戏开发的流程，游戏发布的打包与构建（硬件选型，SDK与操作系统，包体管理，弹性构建，构建调优）

文章目录

- 1、游戏开发的流程（与Web开发对比）
- - [1.1 开发阶段对比](#1.1 开发阶段对比)
  - [1.2 项目管理对比](#1.2 项目管理对比)
- 2、游戏的打包与构建（发布阶段）
- - [2.1 构建机的硬件选型](#2.1 构建机的硬件选型)
  - [2.2 SDK与操作系统](#2.2 SDK与操作系统)
  - [2.3 游戏包体管理系统](#2.3 游戏包体管理系统)
  - [2.4 弹性构建技术（ci/cd自动化构建）](#2.4 弹性构建技术（ci/cd自动化构建）)
  - [2.5 构建优化技术（增量/缓存/拆分）](#2.5 构建优化技术（增量/缓存/拆分）)

1、游戏开发的流程（与Web开发对比）

1.1 开发阶段对比

开发阶段	前后端开发（Web/应用）	游戏开发
需求分析	产品经理主导，明确业务目标、用户场景和功能需求，输出PRD（产品需求文档）	游戏策划主导，确定游戏类型、核心玩法、目标用户，输出GDD（游戏设计文档）
设计阶段	1. 交互设计（UI/UX原型） 2. 数据库设计（表结构、关系） 3. 接口设计（API文档，如Swagger）	1. 玩法设计（关卡、数值、战斗系统） 2. 美术设计（角色、场景、UI风格） 3. 技术架构设计（客户端/服务器框架、同步机制）
开发阶段	1. 前端：用Vue/React等框架实现页面与交互，调用Mock接口调试 2. 后端：用Spring/Node.js等开发接口，连接数据库，处理业务逻辑 3. 前后端联调接口	1. 客户端：用Unity/UE实现场景、角色、动画、UI交互，编写游戏逻辑 2. 服务器：用Netty/Go开发实时通信、数据同步、防作弊逻辑 3. 美术/音频：制作模型、纹理、音效、背景音乐
测试阶段	1. 单元测试（Jest/Postman） 2. 集成测试（接口联调、跨域处理） 3. 性能测试（接口响应速度、并发量） 4. 用户体验测试	1. 功能测试（玩法逻辑、任务流程） 2. 性能测试（帧率、内存占用、服务器负载） 3. 兼容性测试（多设备/平台适配） 4. 封测/内测（玩家反馈收集）
发布阶段	1. 前端打包静态资源（Webpack），部署到CDN/nginx 2. 后端打包成Jar/Docker镜像，部署到云服务器 3. 域名解析、HTTPS配置，灰度发布	1. 客户端打包（APK/IPA/EXE），资源加密与签名 2. 服务器部署到云服务器/物理机，配置负载均衡 3. 提交应用商店（审核），准备开服活动
维护与更新	1. 监控服务器日志、修复BUG 2. 根据业务需求迭代功能（如新增模块） 3. 优化性能（SQL索引、前端缓存）	1. 实时监控游戏状态（在线人数、崩溃率） 2. 定期更新内容（新关卡、角色、活动） 3. 反作弊更新、服务器扩容、BUG修复

1.2 项目管理对比

项目管理	游戏开发	Web开发
预研阶段	需验证核心玩法可行性（如制作垂直切片原型）技术选型（如引擎是否支持目标平台特性）、性能瓶颈（如开放世界的加载机制）	侧重技术栈适配（如框架是否满足业务需求）、用户规模预估（如并发量）
技术验证	正式开发前制作，重点验证：物理引擎效果、多人同步延迟、大型场景加载效率等技术可行性	通常制作原型Demo，重点验证：交互逻辑流程、核心接口调用、框架适配性
跨平台适配时机	早期确定目标平台（移动端/主机/PC等），开发中同步适配（如触控/手柄/键鼠操作逻辑区分）	默认适配多浏览器，跨设备适配集中在后期：通过响应式设计优化不同屏幕尺寸
需求管理	GDD动态调整，高频变更（如数值/关卡），影响范围大，流程灵活允许插队	PRD相对稳定，低频变更（多为细节），影响范围小，走标准化迭代流程
开发协作模式	跨团队深度耦合：策划实时调整数值/关卡，美术同步更新资源（需版本控制工具支持大文件），程序同步适配逻辑	前后端分离协作：前端按UI稿开发，后端按API文档实现，联调集中在接口层
团队协作	强耦合（策划/程序/美术深度联动），用Perforce管理大资源，实时高频沟通	弱耦合（前后端通过API分离开发），用Git管理代码，阶段同步对接
进度管理	按版本阶段划分（Alpha/Beta等，1-3个月/阶段），依赖资源生产进度，风险点在资源延期	按敏捷迭代（2-4周/迭代），用燃尽图跟踪，风险点在接口联调延迟
资源管理	大体积资源（模型/动画等），需格式检查+引擎烘焙，痛点是版本匹配混乱	小体积静态资源（图片/脚本等），通过Webpack打包+CDN分发，痛点是缓存更新
版本控制重点	依赖Perforce/Shotgun等工具管理大型资源（模型、贴图），需控制资源版本与代码版本的关联性（如"资源A v2.1需匹配代码v3.5"）	以Git为主，侧重代码版本管理，静态资源通过CDN版本号控制
QA介入	早期介入全程参与，测试功能/性能/兼容性/玩家体验，依赖自研工具+人工测试	迭代后期介入，测试功能/接口/浏览器兼容，依赖成熟工具（Jest/Postman等）
迭代节奏	里程碑式迭代（如Alpha/Beta版本），周期较长（1-3个月），每次迭代可能包含核心玩法变更	敏捷迭代（2-4周），侧重功能增量更新，快速响应业务需求
上线准备	包体优化、多平台审核、服务器压测、运营配置，周期1-2个月	环境部署、数据迁移、灰度策略、监控配置，周期1-2周

2、游戏的打包与构建（发布阶段）

2.1 构建机的硬件选型

除基础配置，需针对游戏特性补充：

CPU ：优先多核高频（如AMD Threadripper或Intel Xeon），因游戏代码编译（如C++多文件并行编译）、资源烘焙（如光照贴图计算）依赖多线程。
内存：至少64GB（大型项目128GB+），需同时加载大量资源（如开放世界的地形数据、高精度模型）进行处理。
存储：采用NVMe SSD （读写速度3000MB/s+） + 大容量机械硬盘，SSD用于构建缓存和临时文件（加速资源压缩/打包） ，机械硬盘存储历史版本包体和原始资源 （数据冷热分离）
GPU ：中高端显卡（如RTX 4080），部分引擎（如UE5）的光照烘焙、布料模拟等步骤依赖GPU加速。
扩展性 ：支持多机分布式构建（如通过网络挂载共享存储） ，应对大型项目的并行任务（如同时打包Android/iOS/PC版本）。

2.2 SDK与操作系统

SDK与操作系统环境

多版本SDK管理：需兼容不同平台的SDK版本（如Android SDK 30/31/33、iOS 15/16 SDK），通过工具（如Android Studio的SDK Manager、Xcode版本切换器）隔离环境，避免冲突。
操作系统适配 ：
- 移动端构建：Windows（Android）+ macOS（iOS，需Xcode环境），部分团队通过远程macOS虚拟机解决跨系统问题。
- 主机平台：需专用开发机（如PS5 DevKit、Xbox Series X开发机），运行厂商定制系统，仅支持特定SDK版本。
合规性SDK集成：强制集成平台要求的SDK（如iOS的App Tracking Transparency、Android的Google Play Billing），并在构建时自动注入配置（如隐私权限声明）。
环境隔离方案：通过Docker容器或虚拟机（如VMware）封装构建环境，确保"开发环境→构建环境→生产环境"的一致性（避免"本地能跑，构建机失败"）。

平台	SDK名称与版本要求	工具软件与开发环境	操作系统支持	特殊依赖与备注
安卓	Android SDK (API 35+，Android 15) - 需通过SDK Manager安装最新平台工具	Android Studio （含Gradle构建工具） - 推荐使用Chipmunk及以上版本，支持Java/Kotlin开发命令行工具：adb、fastboot、apkanalyzer 第三方工具：U8SDK（渠道包批量生成）	Windows/macOS/Linux - 需安装Java JDK 11+（OpenJDK或Oracle JDK）	- 2025年8月起，Google Play强制要求新应用使用API 35+ - 大型项目建议搭配NDK进行C++开发
iOS	Xcode 26b3 - 内置iOS 26 SDK，支持Swift 6.0及Objective-C xtool （可选） - 需提取Xcode.xip组件，支持SwiftPM构建	Xcode - 必须运行在macOS 15.5+（Sequoia），支持模拟器与真机调试中间件： - .NET MAUI（Windows通过SSH连接macOS构建） - tidevice+WDA（Windows自动化测试）	macOS （本地构建） Windows/Linux（需依赖xtool或远程macOS）	- 2025年4月起，App Store强制要求使用iOS 18 SDK - xtool不支持Storyboards和Asset Catalogs
Windows	Windows SDK (10.0.22621.0+，Windows 11) - 需通过Visual Studio Installer安装	Visual Studio 2022 - 选择"使用C++的游戏开发"工作负载，支持DirectX 12和CMake 第三方引擎： - Unity（需安装Windows Build Support） - Unreal Engine（内置Windows打包工具）	Windows 10/11 - 推荐64位专业版或企业版	- 需安装.NET Framework 4.8+（部分工具依赖） - 主机开发需额外安装GDK组件
PS5	PS5 SDK 8.0+ - 需通过PlayStation DevNet申请，包含编译器与调试工具	SDK Manager - 安装PS5 PC开发套件，配置环境变量指向SDK目录开发套件：PS5 DevKit（专用硬件）引擎支持：Unity/Unreal需安装PS5模块	Windows/macOS/Linux （开发机） PS5 DevKit（专用操作系统）	- 需通过索尼认证获取DevKit访问权限 - 构建需运行在专用硬件上，支持远程调试
Xbox	Xbox GDK 2504.1.4046+ - 包含Xbox Series X	S和Xbox One开发工具	Visual Studio 2022 - 安装"Xbox Game Development"工作负载，支持C++和HLSL开发调试工具：Xbox Accessories App、XTD（Xbox Tools for DirectX）	Windows 10/11 - 需启用"开发人员模式"并连接Xbox DevKit

补充一个LLVM/Clang

现代游戏开发中，Clang 已成为跨平台编译的事实标准，尤其对使用 C++ 的引擎（如 Unreal Engine、自研引擎）是必需工具，因此必须在环境配置中明确体现。
在各平台的构建环境中，Clang 通常是必需组件 。
多数平台通过SDK 内置（如 Android NDK、Xcode、主机 SDK）提供 Clang，无需单独安装 ；
Windows 等平台可独立安装（如 LLVM 官网下载包）1，用于跨平台代码统一编译。
部分平台允许 Clang 与其他编译器共存（如 Windows 的 MSVC、Linux 的 GCC），
但核心跨平台代码通常优先使用 Clang 确保一致性 。
通过 Clang/LLVM 的明确标注，能更准确反映各平台构建环境的实际依赖，避免遗漏核心编译工具。
LLVM 是一套模块化的编译器框架，Clang 是基于 LLVM 的 C/C++ 编译器前端，二者在游戏构建中承担 "代码转换、优化、跨平台适配" 的核心职责：
LLVM/Clang 是游戏构建阶段的 "幕后工具"，不直接进入最终包体，但决定了包体的质量（体积、性能、兼容性）。其核心价值在于：通过统一的编译框架解决多平台差异，同时通过深度优化提升游戏运行效率，是现代游戏工业化跨平台构建的技术基石。

游戏构建机操作系统的选型

对比维度	Windows 11 专业版	Windows 11 Enterprise LTSC	Ubuntu 22.04 LTS
更新策略	每年2次功能更新 + 每月安全补丁，支持18个月	仅安全更新（无功能升级），10年长期服务	每6个月小更，5年LTS支持，仅核心组件更新
系统精简度	含Edge、Xbox等预装软件，后台进程较多	移除非必要组件（省1.2GB内存），仅保留开发基础工具	无冗余应用，可完全定制系统组件
开发工具兼容性	完美支持VS、Unity、UE全版本，兼容所有Windows专属工具（如RenderDoc）	与专业版一致，工具链长期稳定无变更	原生支持UE5.6+/Unity2023.2+，Windows工具（如VS）需通过Wine/远程桌面运行
跨平台编译能力	需手动安装交叉编译工具（如mingw-w64），主打Windows/Android构建	同专业版，可通过远程macOS节点支持iOS构建	内置Clang交叉编译链，原生支持Windows/Android/主机多平台并行构建
虚拟化与容器	支持Hyper-V，虚拟机性能优秀，但容器生态较弱	同专业版，支持企业级虚拟机隔离	原生支持KVM/QEMU+Docker，容器化构建效率比Windows高30%+
硬件适配	强制TPM 2.0，对新硬件（14代Intel、RTX 40系）驱动更新及时	硬件要求同专业版，但驱动更新慢（需手动适配最新显卡）	AMD显卡兼容性佳，NVIDIA闭源驱动需手动安装，新硬件驱动依赖社区更新
许可成本	约199刀/单用户	企业批量授权（≥50台约80刀/台/年），长期成本可控	完全免费
典型项目案例	1. 中小型团队开发《2D手游》，需快速跟进Unity 2024新功能 2. 社交游戏团队，依赖Windows端语音SDK	1. 大厂《开放世界3A》项目，开发周期3年+，需稳定工具链 2. 主机游戏团队，绑定固定SDK版本	1. 独立团队开发《多平台像素游戏》，同时适配PC/NS/Android 2. 引擎团队构建跨平台编译流水线
选型关键指标	优先级：工具更新及时性 > 新硬件适配 > 中小团队成本	优先级：长期稳定性 > 批量管理 > 3A项目合规性	优先级：跨平台效率 > 容器化需求 > 成本控制
避坑指南	1. 关闭自动功能更新，仅手动安装安全补丁 2. 卸载Xbox Game Bar等后台进程	1. 提前适配最新硬件驱动（如RTX 50系需手动下载厂商驱动） 2. 禁用Windows Update驱动自动安装	1. NVIDIA显卡优先选Tesla系列（驱动支持稳定） 2. Windows工具优先用远程桌面替代Wine
核心优势总结	平衡"新功能"与"兼容性"，适合快速迭代的中小型项目	极致稳定，规避更新风险，是长线大型项目的"刚需选择"	跨平台+低成本+容器化三位一体，独立团队和技术中台的最优解

如果是「3A长线项目」 （开发周期≥2年，团队≥50人）：直接选Windows 11 LTSC，搭配企业级WSUS更新管理，确保3年不换工具链版本。
如果是「中小团队手游项目」 （迭代周期1-3个月，依赖Windows SDK）：选Windows 11专业版，用组策略锁定关键工具版本（如Clang 17），避免自动更新。
如果是「跨平台独立游戏」 （需适配3个以上平台，成本有限）：选Ubuntu 22.04 LTS，配合Docker容器隔离UE/Unity多版本，用WSL 2解决少量Windows工具需求。

2.3 游戏包体管理系统

游戏包体的核心构成：代码+资源

游戏包体本质是"可执行程序+资源库"的组合，核心组成部分可分为两类：

可执行代码层 ：支撑游戏逻辑运行的核心文件，如：
- 引擎编译后的二进制程序（如移动端的.apk/.ipa主程序、PC端的.exe文件）；
- 脚本代码（如Lua/Blueprint字节码，用于关卡逻辑、角色行为控制）；
- 第三方依赖库（如物理引擎库、网络通信库、支付SDK）。
资源资产层 ：决定游戏视觉、听觉体验的素材，占包体体积的80%以上，常见类型：
- 美术资源：3D模型（.fbx/.uasset）、纹理贴图（.png/.dds）、动画片段（.anim）；
- 音频资源：背景音乐（.mp3/.wav）、音效（.ogg）、语音包；
- 配置与场景：关卡地图文件（.map/.level）、数值配置表（.csv/.json）、UI预制件。

目标平台	常见包体格式	典型大小限制	核心特点
移动端（Android）	`.apk`（通用）、`.aab`（Google Play主推）	应用商店通常限制200-500MB（超大会触发"拆分包"）	支持"基础包+资源分包"，可通过动态下载补充资源
移动端（iOS）	`.ipa`	App Store限制初始包≤200MB（剩余资源需"On-Demand"下载）	需通过Apple开发者证书签名，安装依赖iOS系统验证
PC端	`.exe`（安装包）、`.zip`（绿色免安装包）	无强制限制，3A游戏常达50-100GB	多包含DirectX/VC++运行库，需适配不同显卡驱动
主机（PS/Xbox）	平台专用格式（如PS的`.pkg`）	无强制限制，依赖主机硬盘空间	需通过平台厂商审核，集成主机专属SDK（如手柄适配）

游戏包体管理系统

包体元数据管理：记录每个包的版本号、构建时间、目标平台、SDK版本、变更日志（如"修复登录崩溃"）、构建触发人等，支持按条件检索（如"查找iOS 1.2.3版本的包"）。
差异包生成：通过二进制差分算法（如bsdiff）生成增量更新包（仅包含与上一版本的差异文件），减少用户下载流量（手游尤为重要，避免1GB+完整包）。
包体分析与优化：集成工具（如Unity的Addressables Analyzer、UE的Pak File Inspector）检测冗余资源（如未使用的贴图、重复模型），自动剔除或压缩（如纹理压缩为ASTC/ETC格式）。
多渠道包管理：支持按渠道定制包体（如不同渠道的Logo、支付SDK），通过配置文件动态替换资源/代码，避免重复构建。
安全管控：包体签名密钥分级管理（开发包用测试密钥，正式包用生产密钥），支持包体校验（如SHA256哈希比对）防止篡改，集成反作弊SDK（如腾讯TP、易盾）的自动注入。

游戏包体有多个版本而 Web 开发通常没有那么多版本，主要原因：

平台多样性 ：
游戏需要适配多种不同的操作系统和硬件平台，如PC、移动端、主机等 ，每个平台都可能需要单独的包体版本。例如，移动端的安卓和iOS系统，它们的应用包体格式（.apk和.ipa）和开发要求都不同，而且不同版本的操作系统也可能需要进行针对性的适配和优化，这就导致了游戏包体版本的增多。
而Web开发主要基于浏览器，虽然不同浏览器之间也存在一些兼容性问题，但通过统一的Web标准和技术（如HTML、CSS、JavaScript）可以相对容易地实现跨浏览器的适配，不需要为每个浏览器版本都单独制作一个版本的包体。
资源更新与优化 ：
游戏的美术资源、玩法内容等通常会随着时间不断更新和优化，以提升用户体验。每次重大的更新都可能需要发布一个新的包体版本。例如，游戏可能会不断推出新的角色、地图、剧情等内容，这些都需要集成到包体中 供玩家下载和使用。
而Web开发可以通过动态加载资源和更新页面内容的方式，实时地将新的功能和内容推送给用户，不需要用户下载整个新的包体。
技术迭代与兼容性 ：
游戏开发中使用的引擎、框架和技术也在不断发展和更新 ，为了利用新的技术特性和提高性能，游戏可能需要定期进行技术升级，这也会导致包体版本的变化 。同时，为了兼容旧设备和旧版本的操作系统，游戏开发者可能需要维护多个不同版本的包体。
Web开发则可以更灵活地进行技术迭代，通过渐进式增强等方式逐步更新和优化网站功能，而不需要像游戏那样为了兼容性保留多个完整的版本。
安全与运营需求 ：
游戏涉及到用户账户、支付、反作弊等安全问题，为了保障游戏的安全性和公平性，开发者需要不断更新包体中的安全机制和反作弊措施 。此外，游戏运营过程中可能会根据不同地区、不同运营活动等需求，发布特定版本的包体。
Web开发虽然也有安全方面的考虑，但通常通过服务器端的安全策略和实时更新来保障，不需要像游戏包体那样频繁地发布不同版本。

参考资料：
游戏包解读，
【魔方研究】动辄几十个G，游戏包体能不能减减肥？
游戏app包体主要包含哪些内容
 Unity游戏开发--构建游戏包体
 打包、构建、热更知识点

2.4 弹性构建技术（ci/cd自动化构建）

弹性构建技术栈

工具链集成：主流方案包括"GitLab CI/Jenkins + 引擎命令行（如Unity -batchmode、UE RunUAT.bat）"，或自研构建平台（如网易的"BuildMaster"）。
弹性资源调度：结合云服务（如AWS EC2、阿里云弹性计算），在构建高峰期自动扩容构建节点（如从5台增至20台），完成后释放资源，降低硬件成本。
构建流程编排：支持自定义流水线（如"代码提交→静态代码检查→资源检查→编译→打包→自动测试→上传包体管理系统"），并设置触发条件（如合并到release分支自动构建正式包）。
优先级与队列管理：紧急包（如修复线上崩溃）可插队，普通包按提交时间排队，避免资源竞争；支持构建任务暂停/重试，失败时自动通知相关人员（如邮件、企业微信）。
与测试联动：构建完成后自动触发自动化测试（如UI遍历、性能压测），测试报告实时回传，合格包体才进入发布流程，减少人工干预。

流程阶段	核心操作步骤	关键工具/技术	目标与作用
1. 触发构建任务	1. 代码提交（如向`windows-build`分支推送代码）、定时任务或人工触发 2. GitLab CI/CD工具（如Jenkins）接收触发信号 3. 检查队列，确定需需启动新Windows虚拟机	Git/Perforce、WebHook、Jenkins/GitLab CI	确定构建时机，启动自动化流程的起点
2. 拉起Windows虚拟机	1. 根据任务需求选择虚拟机模板（含预设配置：CPU/内存/GPU、预装引擎与依赖） 2. 调用虚拟化平台API（如VMware vSphere API、AWS EC2 API）克隆/启动实例 3. 分配IP地址，加入内网	VMware/AWS EC2、Windows镜像模板	快速创建符合构建环境要求的Windows节点，避免重复配置
3. 虚拟机初始化与校验	1. 通过SSH/RDP验证虚拟机连接性，注入登录权限（密钥/域账号） 2. 执行PowerShell脚本检查环境：引擎版本、编译工具、磁盘空间等 3. 失败则销毁节点并重新拉起	PowerShell Remoting、Ansible	确保虚拟机环境可用，避免因依赖缺失导致构建失败
4. 下发构建任务	1. 传输构建脚本（PowerShell/批处理）到虚拟机指定目录 2. 通过环境变量传递动态参数（版本号、调试模式等） 3. 挂载共享资源库（如NAS），启用缓存加速	SCP/WinSCP、共享存储（NAS）	将构建逻辑与参数传递给虚拟机，为执行任务做准备
5. 执行构建任务	1. 通过远程命令（如`Invoke-Command`）启动构建脚本 2. 执行核心操作：拉取代码、调用引擎编译（如Unity `-batchmode`）、生成游戏包 3. 实时回传日志，监控进度 4. 异常时终止任务并告警	Unity/UE引擎命令行、PowerShell	实际执行构建逻辑，生成Windows平台游戏包
6. 结果回收与资源释放	1. 上传游戏包到管理系统（如Nexus/OSS），记录元数据（版本、哈希等） 2. 短期任务：销毁虚拟机释放资源 3. 高频任务：保留节点1-2小时供复用	SCP、包体管理系统、云平台API	完成产物交付，优化资源利用率，避免闲置浪费

Windows中枢角色：通过本地环境直接构建Windows/Android包，通过远程控制（macOS节点）或专用接口（主机开发机）间接支持iOS/主机平台，实现"一站式"多平台管理。
平台隔离与复用：不同平台的构建任务在独立节点执行（如Android和iOS任务分离），但可复用Windows的基础资源（如代码仓库、共享缓存）。
灵活性：支持任意平台组合构建（如仅构建安卓包、同时构建PC+PS5包），通过参数动态调整流程。

参考资料：
为独立项目打造免费的本地 CI/CD：基于 TeamCity 的解决方案及其重要性
 TeamCity自动化打包Unity项目
 你们有什么开发基础设施？
XX游戏采用阿里云Serverless函数编排与函数计算优化游戏打包流程
 游戏行业弹性计算最佳实践-寻野，阿里云弹性计算产品解决方案架构师
 使用 GameLift 集成 Java Game Server 构建弹性游戏服务集群

2.5 构建优化技术（增量/缓存/拆分）

为了提高构建的效率，缩短构建的时间，常用优化手段包括：

增量构建策略：仅重新处理修改过的代码/资源（如检测文件哈希变化），避免全量重编（大型项目可将构建时间从2小时缩短至10分钟）。
缓存机制：缓存编译中间产物（如C++的.obj文件）、资源烘焙结果（如光照贴图）、第三方库（如SDK），跨构建任务复用。
分布式任务拆分：将构建拆解为"代码编译""资源打包""签名"等子任务，分配给不同节点并行处理（如A节点处理Android代码，B节点处理iOS资源），最后合并结果。

为解决"包体过大"和"游戏加载慢"的痛点，行业主流优化手段包括：

资源压缩：对纹理（用ETC2/ASTC格式压缩）、音频（降低采样率）、模型（简化面数）进行无损/有损压缩；
分包策略：将资源拆分为"基础包（核心代码+启动资源）+ 按需分包（如不同关卡、皮肤资源）"，玩家仅下载当前需用资源；
热更新替代：非核心资源（如活动道具、新地图）不放入初始包，通过游戏内"热更新"动态下载，减少初始包体体积；
冗余清理：构建时自动剔除未使用资源（如未引用的模型、废弃脚本），避免无效体积占用。