存档接口

本地存档接口

WARNING

本接口不可靠，只能用做中间短期存储，数据很可能被平台清理

XYXCommon.Utils_PlayerPrefs
{
        public static void SetInt(string key, int value);
        public static int GetInt(string key, int defaultValue = 0);
        public static void SetString(string key, string value);
        public static string GetString(string key, string defaultValue = "");
        public static void SetFloat(string key, float value);
        public static float GetFloat(string key, float defaultValue = 0);
        public static void DeleteAll();
        public static void DeleteKey(string key);
        public static bool HasKey(string key);
        public static   void Save();
}

上报数据

 ZMYSDKManager.I.Sdk.ServerLoginUploadDataStatic(string keyInfo,string valueInfo);

下拉数据

ZMYSDKManager.I.Sdk.ServerLoginGetDataStatic(string keyInfo);
//成功登录的情况下，可以直接调用下拉数据的接口。否则需要先调用登录接口，等待登录成功后，再调用下拉数据的接口。

监听上报数据成功

ZMYSDKManager.I.Login_UpLoadData += upLoadDataCallBack;
void upLoadDataCallBack(UploadDataResult dataResult)
{
    if (dataResult.code==1)
    {
        Debug.Log($"上报Key[{dataResult.key}] 成功");
    }
    else
    {
        Debug.Log($"上报Key[{dataResult.key}] 失败");
    }
}

监听下拉数据成功

ZMYSDKManager.I.Login_DownData += downDataCallBack;
void downDataCallBack(DownDataResult dataResult)
{
    if (dataResult.code == 1)
    {
        Debug.Log($"下拉Key[{dataResult.key}] 成功 Value=[{dataResult.value}]");
    }
    else
    {
        Debug.Log($"下拉Key[{dataResult.key}] 失败");
    }
}

流程图

设计原理

登录之后下拉一次成功每次登录都最好拉取一次存档，在拉取成功前不执行上传操作。
建议使用一个 key 来存储游戏数据通常情况下不建议一个 app 存储过多的 key，尽量把数据集中封装下。反例：金币一个 key-1，关卡一个 key-2，等级一个 key-3，这些不合适。可以缩减成一个 key，里面 value 是个 map 继续开发者自己对应。
下拉时机详细优化

游戏启动时拉取 key，分为 3 种情况：
- 网络错误等原因无法拉取成功
- 正确连上服务器拉取数据为空
- 正确连上服务器拉取数据有值
  - 情况 1：最好给玩家提示网络问题，否则有可能发生，直接进游戏，后续触发上报，把数据冲掉了。
  - 情况 2：无需任何处理，直接进游戏。
  - 情况 3：和 app 数据本地的各种信息比较，看服务器数据和本地数据的差异化，提醒玩家是否服务器数据覆盖本地数据。

上报流程的优化切勿频繁上报。最好在关键信息触发时上报，例如关卡结束金币结算，人物等级经验变化，关卡数据变化等等，一次性用同一个 key 标记进行 value 上报。频率控制在30s左右一次即可

根据设计原理，我们总结了以下这些情况的推荐存档方式

流程设计

游戏每次登录

每次登录：
- 步骤：监听登录成功后，调用 serverLoginGetDataStatic(key) 以获取存档数据。
- 判断结果：
  - 网络错误：
    - 处理：提示玩家检查网络连接，建议稍后再试。不进入游戏。
  - 数据为空：
    - 处理：直接进入游戏，无需任何提示。后续可以将本地数据上传到云存档。
  - 数据有值：
    - 处理：比较服务器数据与本地数据的差异。如货币数值，关卡记录
    - 提示玩家选择是否覆盖本地数据，使用云端数据，需要标明未选择存档会永久丢失。

游戏内事件与状态变更

关卡结束：
- 步骤：收集当前关卡得分、奖励、完成时间等数据。
角色升级：
- 步骤：当玩家角色升级时，收集新等级、经验值等信息。
物品获取/使用：
- 步骤：玩家获取新道具或使用道具时，记录相关数据。

定期存档

定期自动上报：
- 策略：在游戏进行中定期（例如每 5 分钟）自动上报当前状态，以防止数据丢失。
- 实现：使用定时器触发上传本地存档接口，确保关键数据如金币、进度等被记录。

卸载与重装

重装后首次启动：
- 步骤：再次调用获取云端存档接口获取存档数据。
- 判断：与首次启动时相同，处理网络问题、数据为空或有值的情况。

网络状态监测

网络恢复后尝试上传：
- 步骤：使用网络状态监听，检测网络恢复后尝试上传之前未能上传的数据。
- 实现：若上传失败，记录失败状态，网络恢复时重新尝试。

数据冲突与合并处理

冲突处理：
- 情况：若服务器和本地数据存在冲突。
- 处理策略：
  - 优先使用最新的数据，或提示玩家选择使用本地或云端数据。
  - 提供比较界面，显示两者的差异，供玩家决定。

游戏退出时的自动存档和玩家手动存档

退出时上传和手动上传：
- 步骤：在玩家选择退出游戏时，和玩家点击存档时上传当前状态数据。
- 实现：若玩家选择上传，则调用上传本地存档接口。如果上传失败，应给予玩家提示

数据完整性与错误处理

数据完整性检查：
- 步骤：在上传和拉取数据时，进行完整性校验（如数据格式、类型）。
- 处理：若发现错误，记录错误信息，提示玩家尝试重试或联系客服。

版本兼容性处理

版本检查：
- 步骤：当游戏版本更新时，检查存档数据格式是否兼容。
- 处理：若不兼容，提供数据迁移工具或说明，帮助玩家转换数据。

注意项

本地存档位置：本地存档尽量持久化存储，以文件形式保存最安全。
上传时机：在拉取存档成功前一定不要上传，否则会导致本地存档覆盖云存档
拉取间隔：如果初次拉取失败，重新拉取的间隔时间推荐为 5s，10s，20s，40s，60s，60s，60s，初期间隔时间可以短一些，尽可能保证用户能第一时间拉取到存档，如果前几次失败，后面则保持 1 分钟一次的频率即可，如果拉取到了存档，在上传前一定要让用户主动选择使用本地存档还是云存档
在有登录存档时，如果注销或者被顶号时，一定要记得将本地存档清除，防止一档多号或者一号多档的

存档接口 ​

本地存档接口 ​

上报数据 ​

下拉数据 ​

监听上报数据成功 ​

监听下拉数据成功 ​

流程图 ​

设计原理 ​

流程设计 ​

存档接口

本地存档接口

上报数据

下拉数据

监听上报数据成功

监听下拉数据成功

流程图

设计原理

流程设计