继上次移植之后，对于Addressable的更新优化还是无果
最近因为新版本问题，腾出来点时间，再重新研究一下
====================================================================================
一.问题
1.发现不管更新多大的内容，每次更新他都会把所有的Key值遍历检测一边，而且这些key里面有bundle名称，也有工程资源设置的key值，也有对应的hash值等，很多目前看是无效的；
2.一部分key在获取更新大小的时候>0，在更新的时候又是=0
二.原理
1.他这个检测，其实就是获取远端最新的资源信息文件，通过对比信息文件中记录的hash值和本地缓存的文件hash值，来确定是否需要更新；
2.bundle之间可能是有依赖的，例如一个预设可能引用了好多贴图，字体等，在实际更新预设的时候，他会把所有依赖的bundle全部更新，等到更新这些依赖项的时候，他自己已经被更新过了，所有会=0；
三.优化方案
对比hash更新是没问题的，但是因为这些bundle名称，key，hash太多，导致这个更新检测列表过于庞大，可能总体更新下载量不需要多少，但是会遍历很长时间列表，表现就是更新下载巨慢（当然我这里主要是因为CDN网络问题）
先保留bundle名称试一下，keys里筛选保留了带bundle后缀的key，但是获取不到更新，失败；
再试addressable设置的key，这时候发现你无法区分哪些是设置key，通过查看源码，也没有获取到对应的key值；
于是我想着，是否可以按照原来自定义更新里面，读取一个更新列表文件，将工程里面配置Key都写在文件中
替换上面的Keys，来获取需要的更新
发现虽然还有依赖项被更新的情况，但是遍历的keys少了很多，整体的更新表现和更新用时都快了至少一倍以上；
本来就打算这样先更新了
但是这些写死的Keys，要么把所有的Key都写上 ，要么每次更新把修改过的key写上
还是有额外的遍历 或者 人为操作太麻烦
想了下应该是有别的办法能解决的
在下载更新的地方找到了
这块代码就很熟悉
下载那块代码和获取更新大小的地方不能说像，只能说一模一样
于是我在获取更新大小的地方，把所有需要更新的location保存下来，然后return
但是在源码中并没有找到对应直接下载的接口，还好是有源码，自己加
没有多少代码，只是把原来下载更新代码的一部单独拿出来
完工，这样就可以实现通过Addressable系统原版的更新检测机制获取到需要更新的资源，然后下载需要更新的资源
而且因为这些locations本身就是通过Key找出来的依赖，下载的时候只会下载自己
散花，完结