Addressable资源热更新【浓缩版】

Addressable资源热更新【浓缩版】

这里仅从我自己使用的角度给出一些步骤和释义，方便第二次使用时回看。
详细的细节内容可以参考这篇文章:【游戏开发探究】Unity Addressables资源管理方式用起来太爽了，资源打包、加载、热更变得如此轻松（Addressable Asset System | 简称AA）

前情提要

此内容仅介绍背景

目的

最近想做一个可以支持热更新的游戏，主要目的就是降低用户使用成本。因为支持热更新之后，就不用反复的下载软件了。

旧方案1

在第一家公司做的软件，如果需要更新就要把整个软件重新装载一次，好几十GB。后面做了一个更新支持，也是按照替换整个程序来操作的，更新时间也很感人。后面做了Steam 的小游戏，接入了Steam的捆绑包，也是颗粒度非常大，当然也有可能是我没有弄清楚他的原理，只是粗浅的使用。

旧方案2

所在第二家公司使用的则是ILRuntime插件组合AssetBundle实现的。资源热更的单位是一整个场景，颗粒度也很大。即使使用了ILRuntime，更新的方式也是基于场景的，每次更新都需要重新打包整个场景，也是比较麻烦的。而且ILRtime并不支持所有代码，我当时负责的子工程功能，有些泛型就不支持，必须要主程添加相关支持。而且在业务功能的发展之后，主程序包也经历了好几版的发布。每一版发布之后，用户也都需要重新下载安装app。

需要新方案的原因

就目前的认知而言。我想要的是一款一经发布，就再也不用重新卸载安装的一款小游戏。并且支持热更新，我并不需要再一开始写完所有的逻辑，而是不断地修正、完善这款游戏。因为没有什么是完美的，我们能做的，只有不断地、不断地完善，才能做的更好。

契机

在第二家公司使用AssetBunde时我就接触到了Addressable。但是由于当时第一遍尝试并未成功，加上公司业务较紧。就暂时搁置了。如今刚刚接触了卧龙热更方案，这是一套代码热更新方案。需要一个资源热更新方案配合使用。于是又回头翻了一遍Addressable,第二遍再看很多细节就清楚了。

简要概述

这是ChatGpt答案，仅供参考【手动狗头】（为什么不提供表情包的功能，强烈建议官方添加）

具体步骤

步骤详述

这里我仅对我之前比较困惑的几点做出释义：

关于打包路径

打包路径主要有两个地址：其一是本地打包地址，其二是服务器地址。
本地打包地址是：BuildPath
服务器地址是： LoadPath
当打包完成后，bundle包生成在BuildPath。需要手动拷贝bundle包到 LoadPath。

打包的内容主要有两种：其一是资源bundle包，其二是索引文件：hash和json后缀的文件
我们需要做的只是把这两种更新的文件拷贝到服务器即可。

插件可以自行通过hash和json文件读取对应资源的目录，动态地从该地址下载对应的资源包实现热更新。
当hash和json文件发生变化时，就说明资源包变了，需要更新了。
但是这其中的更新流程以及更新步骤与assetbundle不同，
程序员都不需要考虑。都是内置在插件中的。

关于服务器

我之前以为服务器是一个很神奇的东西，是属于后端的一部分。奈何不是后端出身，没有办法搭建一个后端服务器。
但其实后端在这里对于个人开发者来说，可以简化他的意义。只是作为存储就够了。
无论是自己的电脑，抑或是git项目地址，只要是公共可访问的稳定地址就可以了。
我还专门问了chatgpt有哪些免费的云服务器供应商，专门搭建了一个阿里的对象存储OSS,白白浪费了一个免费的机会，可惜可惜。

关于卧龙热更新方案

这两天刚刚接触到这套方案，还需要再消化一下。
这两件事搞完就可以准备开发一个支持热更的小游戏了。