自2022年9月6日起,本文档站不再更新内容,相关文档已迁移至全新“抖音开放平台”前往

StarkContainer 目录说明与缓存策略

在开发游戏的过程中,会涉及部分文件读写操作,本文对 StarkContainer 的目录管理及磁盘管理机制进行讲解。

目录划分

在游戏开发角度,StarkContainer(以下简称 SC)对游戏文件目录进行以下划分:

游戏文件目录

游戏文件目录是游戏的主体文件存放目录,该目录包含游戏在启动后下载的资源文件、apk 中解压出来的资源文件、Unity 的 Shader 缓存等内容;

开发者可以通过 Application.persistentDataPath 方法获得游戏文件目录的可写路径;

游戏文件目录一般情况下不会被 SC 主动清理,但在游戏总磁盘占用过大,或者长期未玩等情况时,仍有可能触发清理操作,此后玩家再次打开该游戏会触发重新下载的操作; 注意,部分开发者会将游戏存档放在游戏文件目录,该目录并不保证长期存在,建议使用玩家数据目录;

游戏文件目录的存储上限为 200M;

注意,存储上限 200M,不代表所有的资源总大小需要在 200M 以内,而是需要确保玩家在游戏过程中单个场景所需要的总资源大小在 200M 以内即可(前提是资源使用 StarkMini 方案进行动态下发);SC 会在达到存储上限时,根据资源引用,淘汰掉未使用的本地资源,腾出磁盘空间;

游戏临时目录

游戏临时目录,是游戏存放当次运行需要的临时文件的目录。该目录会在游戏未使用时,随时清空。请不要在该目录中放置任何重要的数据文件,以免丢失导致玩家损失。

开发者可以通过 Application.temporaryCachePath 方法获得游戏临时目录的可写路径;

临时目录没有存储上限;但是注意,一旦游戏退出,随时可能会被清空。

玩家数据目录

玩家数据目录,是用于放置用户需要长期存储的数据资产的,主要用于放存档文件。游戏存档目录不会被 SC 的磁盘清理机制所清理,会长期保留在磁盘上。

开发者无法直接获得玩家数据目录的路径,而是可以通过 StarkSDK 提供的 Save/Load 接口对数据对象进行存取操作,存取的结果会保存在玩家数据目录中;

除此之外,如果只是简单的 key-value 存储,也可以使用 Unity 提供的 PlayerPrefs 接口进行数据存取;

玩家数据目录的存储上限为 50M,如果达到上限,写入操作会失败,可以使用提供的配套接口删除不需要的存档文件;

磁盘清理规则

为了优化用户的磁盘占用,减少宿主的负向反馈,StarkContainer 对于游戏的磁盘占用有一套动态的管理机制,以下进行说明:

清理划分

磁盘清理从影响的范围角度,可以划分为:

  1. 清空临时目录:只对游戏临时目录进行清理;
  2. 磁盘缩减:保留游戏的核心文件,只清理“可恢复”的文件;用户下次打开时,不会触发游戏下载界面,直接进入游戏(游戏进入后可能会有游戏内的资源下载);影响游戏文件目录和临时目录;
  3. 删除游戏:只保留玩家数据目录的内容,清理其它游戏相关目录;用户下次打开时,会触发游戏的重新下载;

清理时机

  1. 清空临时目录 在游戏退出后,随时可能会触发清空临时目录的操作。此外在其它磁盘清理操作时,都会顺便清理下临时目录;
  2. 磁盘缩减 SC 会定期进行检查,在游戏磁盘总占用超过 280M 时,触发磁盘缩减;此外,宿主 app 在发现磁盘总占用较高时,也会触发 SC 进行磁盘缩减;最后,玩家在宿主中退出当前账号时,也会触发磁盘缩减;
  3. 删除游戏 SC 支持同时持久化 5 款游戏,当超过上限时,会根据 LRU 算法,找到最早被打开的游戏,进行删除;此外,如果游戏长时间(14 天)没有再被打开过,也会触发游戏删除操作。
  4. 其它清理时机 除了以上 SC 的主动磁盘管理,如果玩家删除宿主,也会导致 SC 的所有磁盘占用被清理。
点击纠错
该文档是否对你的开发有所帮助?
有帮助
没帮助
该文档是否对你的开发有所帮助?
有帮助
没帮助