3. 缓存更新 3. 缓存更新

我们在做一个h5游戏的时候，因为浏览器会缓存资源到本地，经常会导致我们希望更新的东西没有正常被更新。同样，我们在自己设计App游戏的时候，比如A资源已经被下载了，那么下次访问A资源的时候就不需要再向服务器请求了，这种支持极大的减少了带宽。所以，我们也一样会实现一个类似于浏览器一样的缓存系统。那么当A资源被修改了之后，我们也希望下次加载A资源的时候能下载到新的资源，而不是沿用老的资源。

合理的更新方式是我们需要区别资源修改（包括代码修改）这个行为。所有的修改都会导致文件变更，这就给了我们机会去”计算”这个修改。我们来看下更广阔的场景：

A资源的文件名为bg.jpg，代码B文件中直接引用了bg.jpg。

我们希望B文件能带有唯一的标识，我们可以用它的文件内容来标识它。当文件内容变化的时候，它也就有了新的标识。那么B文件名字可以变成bg_XXX.jpg(XXX为文件内容), 这样就可以区别每一次的文件修改了，因为文件内容一变，我们也会把对应的文件名改变。再把对应引用的地方修改，就不会导致更新问题了。修改后的场景为：

A资源的文件名为bg_XXX.jpg，代码B文件中直接引用了bg_XXX.jpg。

这个改动实际上是存在一些问题的：

bg文件使用文件内容来定义文件名会导致文件名过长，超过系统的文件名限制。

每次修改bg.jpg都会导致所有的引用都需要修改，我们可以写一个工具，但是这也会影响开发效率。

针对上面2个问题，我们可以将文件内容通过某个算法，比如CRC32生成一个32位字符串，截取字符串的后面几位，与bg进行拼接，拼接后的字符串为bg_1C6D35.jpg(1C6D35是截取后的），这样第一个问题就解决了。因为每次都需要修改引用，这个时候我们可以引入中间层来解决这个问题。使用res1 来定义 bg.jpg的别名，所有使用bg.jpg的地方都改为使用 res1来访问。而每次修改bg.jpg的别名的时候，我们用工具来修改 res1和bg.jpg的映射关系即可，其他引用的地方都不变。最终的映射变成了 res1 =>bg_1C6D35.jpg，这解决了我们第二个问题。最后我们来聊时机问题，也就是这个映射的修改我们应该在什么时候进行。每次改变文件内容的时候进行会影响开发效率，所以我们把这个操作放在发布的时候进行。