工具

Unity版本(2019 4.31f1c1或2020.3.34f1c2)
Visual Studio 2019

功能模块

资源加载管理和打包模块

AssetBundle加载管理

基于索引计数+组件绑定的AssetBundle加载管理框架。(参考: tangzx/ABSystem思路)

资源加载管理设计:

面向Asset级别加载管理，支持Asset和AssetBundle级别的同步异步加载。
支持资源导入后AssetDatabase模式马上就能配置全路径加载
资源加载类型只提供普通和常驻两种(且不支持运行时切换相同Asset或AssetBundle的加载类型，意味着一旦第一次加载设定了类型，就再也不能改变，同时第一次因为加载Asset而加载某个AssetBundle的加载类型和Asset一致)，同时提供统一的加载管理策略，细节管理策略由上层自己设计(比如对象池，预加载)
异步加载准备采用监听回调的方式来实现，保证流程清晰易懂
设计请求UID的概念来支持加载打断设计(仅逻辑层面的打断，资源加载不会打断，当所有逻辑回调都取消时，加载完成时会返还索引计数确保资源正确卸载)
设计上支持动态AB下载(未来填坑)
加载流程重新设计，让代码更清晰
保留索引计数(Asset和AssetBundle级别)+对象绑定的设计(Asset和AssetBundle级别)+按AssetBundle级别卸载(依赖还原的Asset无法准确得知所以无法直接卸载Asset)+加载触发就提前计数(避免异步加载或异步加载打断情况下资源管理异常)
支持非回调式的同步加载返回(通过抽象Loader支持LoadImmediately的方式实现)

Note:

一直以来设计上都是加载完成后才添加索引计数和对象绑定，这样对于异步加载以及异步打断的资源管理来说是有漏洞的，资源加载管理准备设计成提前添加索引计数，等加载完成后再考虑是否返还计数的方式确保异步加载以及异步加载打断的正确资源管理

加载流程设计主要参考:

XAsset

对象绑定加索引计数设计主要参考:

tangzx/ABSystem

AB加载管理方案

加载管理方案：

加载指定资源
加载自身AB(自身AB加载完通知资源加载层移除该AB加载任务避免重复的加载任务被创建)，自身AB加载完判定是否有依赖AB
有则加载依赖AB(增加依赖AB的引用计数)(依赖AB采用和自身AB相同的加载方式(ResourceLoadMethod),但依赖AB统一采用ResourceLoadType.NormalLoad加载类型)
自身AB和所有依赖AB加载完回调通知逻辑层可以开始加载Asset资源(AB绑定对象在这一步)
判定AB是否满足引用计数为0，绑定对象为空，且为NormalLoad加载方式则卸载该AB(并释放依赖AB的计数减一)(通知资源管理层AB卸载，重用AssetBundleInfo对象)
切场景，递归判定卸载NormalLoad加载类型AB资源(上层使用逻辑调用接口触发)

Demo使用说明

先打开资源调试工具

Tools->Debug->资源调试工具

AssetBundle和AssetDatabase资源加载模式切换
AB依赖信息查看界面
AB运行时加载管理详细信息界面
加载器信息查看界面
测试界面

点击加载窗口预制件按钮后:

ResourceManager.Singleton.getPrefabInstance(
    "Assets/Res/windows/MainWindow.prefab",
    (prefabInstance, requestUid) =>
    {
        mMainWindow = prefabInstance;
        mMainWindow.transform.SetParent(UIRootCanvas.transform, false);
    }
);

可以看到窗口mainwindow依赖于loadingscreen，导致我们加载窗口资源时，loadingscreen作为依赖AB被加载进来了(引用计数为1)，窗口资源被绑定到实例出来的窗口对象上(绑定对象MainWindow)

点击测试异步转同步加载窗口

/// <summary>
/// 测试异步转同步窗口加载
/// </summary>
public void onAsynToSyncLoadWindow()
{
    DIYLog.Log("onAsynToSyncLoadWindow()");
    if (mMainWindow == null)
    {
        onDestroyWindowInstance();
    }
    AssetLoader assetLoader;
    var requestUID = ResourceManager.Singleton.getPrefabInstanceAsync(
        "Assets/Res/windows/MainWindow.prefab",
        out assetLoader,
        (prefabInstance, requestUid) =>
        {
            mMainWindow = prefabInstance;
            mMainWindow.transform.SetParent(UIRootCanvas.transform, false);
        }
    );
    // 将异步转同步加载
    assetLoader.loadImmediately();
}

点击销毁窗口实例对象后

/// <summary>
/// 销毁窗口实例对象
/// </summary>
public void onDestroyWindowInstance()
{
    DIYLog.Log("onDestroyWindowInstance()");
    GameObject.Destroy(mMainWindow);
}
窗口销毁后可以看到之前加载的资源所有绑定对象都为空了，因为被销毁了(MainWindow被销毁了)

等待回收检测回收后上述资源在窗口销毁后，满足了可回收的三大条件(1. 索引计数为0 2. 绑定对象为空 3. NormalLoad加载方式)，最终被成功回收。

Note:

读者可能注意到shaderlist索引计数为0，也没绑定对象，但没有被卸载，这是因为shaderlist是被我预加载以常驻资源的形式加载进来的(PermanentLoad)，所以永远不会被卸载。

/// <summary>
/// 加载常驻Shader
/// </summary>
public void onLoadPermanentShaderList()
{
    DIYLog.Log("onLoadPermanentShaderList()");
    ResourceManager.Singleton.loadAllShader("shaderlist", () =>
    {
    },
    ResourceLoadType.PermanentLoad);
}

AssetBundle打包

AB打包主要参考MotionFramework里的AB打包思路，细节部分个人做了一些改动和扩展。

AB打包设计:

打包AB的策略由抽象的目录打包策略设定决定
打包后的AB保留目录结构，确保AB模式和AssetDatabase模式加载都面向Asset路径保持一致性
支持打包策略级别的AB压缩格式设置(Note: 仅限使用ScriptableBuildPipeline打包模式)。老版AB打包流程AB压缩格式默认由打包面板压缩格式设置决定。
不支持AB变体功能(ScriptableBuildPipeline也不支持变体功能)，AB后缀名统一由打包和加载平台统一添加
老版AB依赖信息采用原始打包输出的*Manifest文件。新版ScriptableBuildPipeline采用自定义输出打包的CompatibilityAssetBundleManifest文件。

打包策略支持

按目录打包(打包策略递归子目录判定)
按文件打包(打包策略递归子目录判定)
按固定名字打包(扩展支持固定名字打包--比如所有Shader打包到shaderlist)(打包策略递归子目录判定)
按文件或子目录打包(打包策略递归子目录判定，设定目录按文件打包，其他下层目录按目录打包)
不参与打包(打包策略递归子目录判定)

热更新模块

类说明

热更类：

- HotUpdateModuleManager.cs(热更新管理模块单例类)
- TWebRequest.cs(资源下载http抽象类)

版本信息类：

- VersionConfigModuleManager.cs(版本管理模块单例类)
- VersionConfig.cs(版本信息抽象类)

功能支持

支持游戏内版本强更(完成 -- 暂时限Android，IOS待测试)
支持游戏内资源热更(完成 -- 暂时限Android， IOS待测试)
支持游戏内代码热更(未做)

热更测试说明

使用阿里的ISS静态资源服务器做了一个网络端的资源服务器。

版本强更流程：

比较包内版本信息和包外版本信息检查是否强更过版本
如果强更过版本清空包外相关信息目录
通过资源服务器下载最新服务器版本信息(ServerVersionConfig.json)和本地版本号作对比，决定是否强更版本
结合最新版本号和资源服务器地址(Json配置)拼接出最终热更版本所在的资源服务器地址
下载对应版本号下的强更包并安装
安装完成，退出游戏重进

资源热更流程：

初始化本地热更过的资源列表信息(暂时存储在:Application.persistentDataPath + "/ResourceUpdateList/ResourceUpdateList.txt"里)
通过资源服务器下载最新服务器版本信息(ServerVersionConfig.json)和本地资源版本号作对比，决定是否资源热更
结合最新版本号，最新资源版本号和资源服务器地址(Json配置)拼接出最终资源热更所在的资源服务器地址

下载对应地址下的AssetBundleMD5.txt(里面包含了对应详细资源MD5信息)

AssetBundleMD5.txt

assetbuildinfo.bundle|ca830d174533e87efad18f1640e5301d
shaderlist.bundle|2ac2d75f7d91fda7880f447e21b2e289
******

根据比较对应地址下的AssetBundleMD5.txt里的资源MD5信息和本地资源MD5信息(优先包外的MD5文件)得出需要更新下载的资源列表
根据得出的需要更新的资源列表下载对应资源地址下的资源并存储在包外(Application.persistentDataPath + "/Android/")，同时写入最新的资源MD5信息文件(本地AssetBundleMD5.txt)到本地
直到所有资源热更完成，退出重进游戏

问题:

上述方案包外AssetBundleMD5.txt文件可能被篡改，其次热更下载的AB文件可能出现损坏但被记录到包外AssetBundleMD5.txt的情况，这会导致热更AB出现不可逆的热更问题。

解决方案:

包外资源采用实时计算MD5，然后结合包内AssetBundleMD5.txt数据与热更AssetBundleMD5.txt文件进行对比决定哪些资源需要热更。(TODO)

流程图

热更新辅助工具

Tools->HotUpdate->热更新操作工具

主要分为以下2个阶段：
- 热更新准备阶段:
  1. 每次资源打包会在包内Resource目录生成一个AssetBundleMd5.txt文件用于记录和对比哪些资源需要热更
  1. 执行热更新准备操作，生成热更新所需服务器最新版本信息文件(ServerVersionConfig.json)并将包内对应平台资源拷贝到热更新准备目录
- 热更新判定阶段
  1. 初始化包内(AssetBundleMd5.txt)和包外(AssetBundleMd5.txt)热更新的AssetBundle MD5信息(先读包内后读包外以包外为准)
  2. 游戏运行拉去服务器版本和资源版本信息进行比较是否需要版本强更或资源热更新
  3. 需要资源热更新则拉去对应最新资源版本的资源MD5信息文件(AssetBundleMD5.txt)进行和本地资源MD5信息进行比较判定哪些资源需要热更新
  4. 拉去所有需要热更新的资源并写入最新的资源MD5信息到包外，完成后进入游戏
Note:
1. 每次打包版本时会拷贝一份AssetBundleMD5.txt到打包输出目录(保存一份方便查看每个版本的资源MD5信息)