前言：本着简单的原则想把ab换成Unity的Addressable。测试一下Addressable的资源生成和管理。
最基础的使用方法很多人都写过了，就不重复写了。记录一些在使用过程中的问题和资源状况。
Addressable版本：1.16.10
Unity版本：2019.3
前文地址：关于Addressable资源文件测试记录（三）

第二次Build,静态Group资源更新

关于Group的配置参考前一篇的配置。我把项目还原之第一次打包的绿色树场景。

看过配置的应该发现，绿色的树是动态Group的资源。而下面橙色的树是静态Group的资源。
所以现在要把静态Group的橙色树材质改成蓝色。然后进行一次资源的更新。

首先要搞清楚静态资源的更新过程。即要先检查资源的变化。

在我把tree1的材质换成蓝色后，可以检测出tree1的变动，然后ApplyChanges应用一下。

应用之后会发现，tree1出现在一个新的Group里面。而原本的Static组内没有这个资源了。

然后选择了升级之前的构建（Upde a Previous Build）。
把得到的新资源（即StandaloneWindows64文件夹）替换掉原来远程的资源。

更新成功，橙色树变成了蓝色树。

然后我们对比一下缓存资源的变化。
首先是 catalog文件。catalog文件变化和动态Group更新的结果是一致的。本地缓存的catalog文件被替换成了远程的catalog文件。

下面是缓存的资源文件。
首次，仅有一个文件（绿标文件）：
更新包，新增一个文件（红标文件）：

下图是(红框位置)是我们更新到的资源。即上图我们更新包内的文件。

下图是(绿框位置)我们更新的资源包，（即我们打的资源更新包StandaloneWindows64文件夹）。

可以看到我更新的资源17kb对应的是我们生成的新组ContentUpdate的资源。不会重复下载NotStatic组的资源。

这里穿插一个关于ContentUpdate组的配置。

自动生成的就是一个动态组，也是按照动态资源更新的流程走的。但之前看到一些教程说这个组也是可以控制地址的。即可以修改BuildPath和LoadPath的。
实测是不可行的。只能按照默认生成的配置（即动态组）来更新才能正常的更新。

到此为止，测试结束。

测试总结及与AssetBundle资源更新：
1：所有LoaclBuild和LocalLoad的的资源最终生成资源目录为对应平台的StreamingAssets目录。即作为本地资源打入应用包内。
相当于AssetBundle首次打入StreamingAssets目录的资源。
2：更新静态资源和更新动态资源的流程是一致的。只是静态资源多了一步对比资源。并且会把静态资源中的产生变化的资源划分到一个新的动态资源组内。
3：更新资源时，如果某个资源组内的资源，一个都没有使用，则不会更新这个资源组。
4：动态组更新是整组更新。即动态组内如果有任意一个数据变动的话，会更新整个动态组。即每次更新都可能存在很多重复的更新。（这里就关系到资源分组了。网上大部分对分组的描述就是经常变动的放动态组，不常变的用静态组。单纯知道这个毫无卵用，甚至还会影响你对组的理解。从测试结果来看，动态分组越多意味着你更新到的重复资源会变少。因为，如果你已经下载了某个组的缓存。如果该组没有资源变更的话是不会重复下载的，举个极端的例子：如果你动态组内有100个经常变动的资源，但在某次更新你只变更了其中的一个资源，那么你仍然需要更新这个完整组也就是100个资源。而如果你把100个资源分成100个组，那么你变动其中一个资源的话，只需要更新这个资源所在的组，也就是实际上只更新了一个资源。有这个例子参考应该会对我们划分Group有所帮助。）
而静态组更新是把变动的资源放到一个新的动态组内做增量更新。只会更新变动的资源。（这个就和AssetBundle通过对比文件是否相同，只更新不同的文件逻辑是一致的）
5：所以Addressable得更新流程应该是。
① 首次下载远程资源会把 下载catalog文件。
② 在使用资源时通过catalog文件判断文件位置并加载，优先查找本地文件缓存是否可用，可用则直接加载使用，如果需要更新，则加载远程资源并存在本地。
③更新时先更新catalog文件然后执行②步骤。

6：以上测试都是根据Addressable的基本用法来进行测试的， 所以并不像AssetBundle是在进入游戏后一下子加载所有资源。而是在使用时加载资源。
整体看来比AssetBundle是方便很多的。不用我们自己写代码打AB包，加密，对比文件以及更新资源了。

稍后会尝试将Addressable的流程变更的和AssetBundle一致，在游戏开始时更新所有资源。符合现在主流更新流程。

以上。