Addressable（15）构建布局报告、常见问题总结（分组压缩策略）

刘建杰

于 2024-02-19 00:11:53 发布

阅读量1k

点赞数 27

分类专栏： # Addressable 文章标签： Addressable Unity

本文链接：https://blog.csdn.net/qq_34060370/article/details/136160992

版权

15 篇文章 0 订阅

订阅专栏

偏文字相关和细节方面，不是很重要

构建布局报告

构建布局报告提供了有关可寻址资源的构建打包的详细信息和统计信息
包括

我们可以通过查看报告文件获取这些信息

AB包太多(包体太小)的问题
1. 每个包都会有内存开销，如果加载过多的包可能会带来更多的内存消耗
2. 并发下载的问题，如果包小而多，以为着下载包时可能需要更多的时间
3. 目录文件会因为过多的包而变大，因为它要记录更多的包信息
4. 复用资源的可能性更大，比如多个包使用同样一个资源，但是该资源不是寻址资源，那么在每个包中都会有该资源
AB包太少(包体太大)的问题
1. 过大的包如果下载失败，下次会重新下载，因为使用UnityWebRequest下载包时不会恢复失败的下载
  比如100MB的包，下了50MB，玩家中断下载了，下次又得重新下
2. 能单独加载，但是不能单独卸载，更大的包意味着包中有更多资源，比如加载了1个大包中100个资源
  但是现在用完了99个，还剩一个再用，即使99都卸载了，但是由于引用计数这个大包也不会卸载
  就会造成内存的浪费

所以没有最好的策略，只有根据自己的项目需求合理安排分组打包，要根据资源的使用情况来合理设置资源分组，在分组时权衡好各方面的问题

三种压缩方式

不压缩、LZ4、LZMA
简介

一般情况LZ4用于本地资源，LZMA用于远端资源

主要原因是LZMA的压缩内容更小，更节约下载时间和流量

注意：压缩不会影响加载内存的大小，只会影响包体大小，下载时间等
三种介绍
1. 不压缩：包体并不大的单机游戏，使用不压缩最好，没有包体大小的压力，加载也是最快的，因为不用解压
2. LZ4：它是基于块的压缩，所以提供了加载文件的能力，加载资源时不用全加载AB包，只加载使用的内容，相对LZMA来说更节约内存
3. LZMA：不建议用它在本地内容中，因为它虽然包最小，但是加载最慢，用它只是为了节约下载时间和极限压缩包体大小

综合来说，也没有最优的方式，还是要根据实际情况来选择，个人认为**LZ4**压缩方式，是相对比较优秀的一种方式

关于AB包最大的限制，老版本不支持大于4G的包，虽然新版本中已经没有这个限制

但是为了兼容性，还是建议大小控制在4G以下
活用可寻址资源上的Groups View中的两个功能
- Show Sprite and Subobject Addresses:当窗口中内容特别多时，禁用它可以提升窗口加载的性能
- Group Hierarchy with Dashes：启用带破折号的层级结构，可以让我们在内容特别多时以层级结构查看分组信息

关注