Unity快速开发和协作的模式
题图是jenkins自动增量build bundle，同时启动4个编辑器的运行时间，mac mini。目的
加快打包打bundle速度不在出版本时突然爆发大量bundle问题在编辑器中能方便调试bundle问题分离代码和资源的权限管理，同时美术策划能在编辑器中运行游戏程序能方便使用分支开发功能在日常开发中磨炼线上流程降低美术提交错误资源的概率减少手动重复劳动提高效率
方法
build方式
监听提交，每次提交后jenkins对全平台增量打bundle（也包含其他可更新文件，比如lua和音频等，下同）当然要实现一个高效率的自动分析依赖打bundle的机制闲置打包机是浪费，程序员应该充分压榨机器，再被资本家压榨用rsync将bundle同步到内网资源机用于更新，资源机上有历史上全部bundle如果失败则向钉钉报告bundle文件名带有hash或md5用于区分不同buildlua转为bytecode并加密后才会上传资源机build player时可能不需要打bundle，最多是再增量打一次
资源下载加载
实现线上的资源下载更新机制，部署在内网用于日常开发编辑器中运行游戏要支持3种资源加载模式，加载不同来源的资源：
本地Asset：用AssetDatabase加载asset，不用resouces目录，用于测试本地编辑的资源本地bundle：本地要有工具和环境能build bundle，用于调试bundle相关问题远程bundle：差异更新下载到本地，模拟手机上的资源环境。
编辑器中运行游戏主要以远程bundle模式为主，尽早暴露问题，分摊到日常解决，不堆到deadline如果bundle模式出问题跑不了，可以用本地资源模式顶着编辑器中直接使用android/ios bundle有问题，不做特殊处理的话用pc/mac平台是可以的
svn + git多仓库协作模式
美术使用svn单分支日常开发，unity工程在svn中，包含资源和c#代码c# dll很容易被反编译，达不到保密目的。还不清楚能混淆保密且方便开发的机制程序使用git存lua，多分支开发将git 和 svn合并起来组成完整版本因为美术策划用svn里的unity工程，没有lua，只能靠热更下载lua只有程序有权限修改c#
多仓库模式的改进设想
问题
c#不在git中，不方便分支开发，很难跟多分支lua匹配美术工程的lua只能靠更新下载，如果build有问题就没法更新
解决方法
用svn external链接美术unity工程的资源，构造一个只有资源没有代码的unity工程，资源部分跟美术工程是同一个东西。源头有提交的话外链处即可更新将lua和c#都放到git里，跟没有资源的unity工程结合即可表示完整版本使用工具将git develop分支的内容同步到美术unity工程中，也就是发布代码过去，lua要加密，在纯粹美术unity中也有完整游戏环境了
代码全放git后，用gitlab的保护dev分支禁止push，只能通过merge request合并，合并前必须经过一人的review并写评语，至少达到同步信息，明白问题和方案的目的，另外也可以纠正代码质量问题。实在嫌慢可以缩短review时间，没比不能review的方案差多少。
资源生产模式
导出和检查机制
所有手动编辑的资源都在Assets/GameArt/Raw目录下，分类型存放将Raw中需要动态加载资源导出到Assets/GameArt/Res目录下，按同样类型存放，Res下全部都要打bundle导出过程进行规范检查，出错弹窗提示，可以降低问题资源进入版本的概率。并能减少手动操作提高生产力，以后做批量修改优化也很方便
meta提交限制
主文件必须跟meta一起提交和删除，减少漏提meta导致引用错误
限制shader修改权限
shader也是代码，美术编辑好shader由程序review后提交。有默契和保证之后，可以放松限制
something to say
目前在50-100M bundle规模下运行良好，几百M的话估计也还好，充分利用打包机呗当然也可以加入其它独立的优化方法提交后不愿等打包机，想立即体验游戏用本地Asset模式即可知乎导入md还得修改格式
240M bundle规模的时间
增量build仍然是很快的，相比于全量，下面还是mac mini上同时启动4平台的时间
总时间是jenkins任务时间，unity时间是编辑器花费的时间，包含自己写的分析依赖和实际build api，还有些其他（启动、导入、build 后处理）
更新了10多个特效资源
全量rebuild
参考
Unity手游版本构建之路 https://wetest.qq.com/lab/view/146.html ，强烈推荐
页:
[1]