通过上一篇文章《Unity Addressable 实战二(实现资源加载和使用)》，我们利用Addressable实现了一个资源加载和卸载管理器，从而了解了Addressable的最主要功能以及使用方法。在真正用上资源管理器之前，我们首先要把游戏中的资源进行一些规划和布局。如各种资源在项目磁盘上是怎么分门别类存放的，它们是自动还是手动打包进Addressable里面的，以及资源是怎么打包和分包的，依赖的资源怎么办等等。。。这些问题在游戏的开发前期我们都要一一去解决它，否则到了游戏开发的中后期，我们会发现由于资源处理不当而引发出的各种问题会大大降低我们的开发效率以及影响游戏的在线热更功能设计，甚至影响游戏的最终品质。
综合以上所描述，我们可以总结归纳为一个简短的词句叫做“游戏资源打包策略”，这一篇我们就一起来谈一谈它是如何拔地而出的。
我们经常说资源，那什么理解这个“资源”呢？我们可以把它分成两类，一是非可执行资源，二是可执行资源。这么分的原因是为了我们后面实现在线热更功能时，更好区分那些资源是可以热更，那些不可以热更。提前理解这些概念，对我们后面热更方案的设计具有很大的帮助。
非可执行资源，对它的理解可以是游戏内一些非代码型的文件
- prfabe、模型、贴图、动画、特效、材质、音效。。。
- json文件、文本文件、。。。
可执行资源，对它的理解可以简单的认为是一些逻辑代码文件
- lua脚本、其它可执行脚本、。。。
- C#代码、dll库、其它可执行库、。。。
有了资源的分类，接下来我们就要解决这些分类资源是怎么在磁盘上规划布局的。规划布局一般有三种，如下：
1、先资源属性再游戏业务
2、先游戏业务再资源属性
3、混合布局，资源属性中包含游戏业务，游戏业务中包含资源属性
单文字说明可能云里雾里，我们通过图片来直接感受一下游戏项目中对这些资源是怎么规划布局的。
非可执行资源，如下图：
上图所展示出来的规划布局是按第一种分法，它们都独自分配到一个文件夹存放。
可执行资源规划，如下图（lua）：
上图所展示出来的规划布局是按第三种分法，混合布局。
到此，我们完成了打包策略的第一步，弄懂了游戏资源的分类和布局，解决了游戏资源怎么分以及放哪的问题。接下来我们还要解决第二个问题，资源怎么打包进Addresable窗口内的。
资源打包到Addressable内，有两种方法，如下：
手动把资源拖到对应的资源组里。
如果不知道如何手动把资源打包到组里，请参考第一篇文章《Unity Addressable 实战一(初步认识Addressable)》。手动这种方法在游戏开发前期是非常方便快捷的，所见所得，可以马上投入马上产出。但随着游戏进入到开发的中后期，资源会越来越多，游戏业务越来越复杂，纯靠人工去维护资源组是非常困难和非常容易出问题的，并且这些问题十分不可控。如开发人员A把某个公用的资源W拖到Addressable组里，这个W开发人员B、C也会用到。某天开发人员A由于业务需要把W寻址名称重命名了而没有通知到B、C，当游戏运行到B、C所开发的业务时就会找不到W，这时候游戏就发生异常或崩溃了。
自动按规则生成资源组，资源按规则生成到对应的资源组里
这种方法在游戏开发前期要做的事情比较多，如规则的制定和相关工具或编辑器的开发等。虽然前期工作量大一些，但能解决方法一所暴露出来的问题，并且在游戏开发的中后期会很明显的提升开发效率和保证游戏质量。所以我们还是要发扬传统文化，继承“工欲善其事必先利其器”和“磨刀不误砍柴功”的思想，在游戏开发前期尽量把规则定好和自动化做好。
我们认识到自动化的好处，接下来我们就要把自动化落到实处。上面所说的分类和布局，在实际开发当中并不是一成不变的，相反在很大程度上随着开发的深入，分类和布局会不停的变动。作为一个开发人员，利用面向对象的方法，我们把这些变动一层层抽象就能理出规则来了。分类和布局的变化主要反应在对应的文件夹变动上，无论分类布局怎么变，文件夹就会跟着变，所以抽象出的底层规则之一就是：
规则一，按文件夹生成资源组，把文件夹内的资源分配到组内即可。最终规则一反应的效果如下图所示：
规则一是按文件夹自动生成资源组，那么我们能否扩展一下，能不能按文件生成资源组呢？答案肯定是可以的。因为在游戏热更过程中，一个资源组作为一个资源包更新到客户端，如果按文件夹分组就会有很多不必要热更的资源也会打到资源包里，这样就会无端多更新一些不需要更新的资源到客户端。如果按文件生成组，那就相当于把资源包细化了。资源包细化有很大的优点，在加载资源包方面，一是效率会更快，二是减少游戏卡顿。在热更方面，一是更精准，二是玩家等待下载资源的时间会更短。这两方面优化的提升，对于游戏玩家的体验来说又无疑提高了一个档次。
规则二，按文件生成资源组，如下图：
谈到资源包细化，会产生出一个新的问题，那就是细化到什么程度合适。这个问题没有一个统一的解决办法，都是按游戏类形或业务需求具体情况具体分析。如果要讲清楚这个问题，会涉及到相关的知识点比较多，在这里就不一一展开了。
至此，我们的“游戏资源打包策略”已初步定形。这个策略基本上能解决游戏开发当中的资源打包问题，并且具有很好的适应性，对未知业务的承载有很大的拓展空间。它有三大优势，如下：
一、定规则解决问题
二、灵活可拓展
三、与其它系统模块功能解耦。
所以只要游戏业务需求改变，我们就制定相对应的规则即可，并且对游戏其它功能不会有影响。
至此，我们有了“游戏资源打包策略”的想法，但不能纸上谈兵光说不练，接下来我们就要把想法落地。至于怎么落地，还是上面所说的“工欲善其事必先利其器”。第一步，我们就要实现一个规则编辑器。下一篇文章我们一起来聊一聊规则编辑器是怎么实现的，敬请期待。
