Ошибка файловой операции при сбое / уничтожении игры ОС / пользователем в Android

Моя игра сохраняет свое состояние после фиксированного интервала в файле во внутренней памяти игры / приложения. Когда моя игра убивается или сбивается пользователем или ОС соответственно, мы записываем текущее состояние игры в этот файл. Запись файла по истечении интервала исправления работает нормально, но когда игра падает или уничтожается ОС или пользователем, операция записи файла не выполняется. Сбой операции приводит к неполному игровому состоянию или пустому игровому состоянию, т. Е. Данные не записываются в файл. Я пробовал несколько решений, использующих сервис Android, в случае, если сервис не является липким сервис убит приложением. С другой стороны, если служба STICKY, она перезапускается, но намерение, которое изначально было связано с этой службой, является нулевым или новым.

Вопрос в том, как я могу полностью сохранить свои данные (может быть ~ 2-3 МБ) в файле во внутреннем хранилище, когда моя игра / приложение уничтожено пользователем / ОС?

Я бы предложил записать ваше состояние сохранения в двойной буферизации, как это было в прошлом для заголовков консоли (когда вам приходилось справляться с удалением карты памяти в середине записи, а запись выполнялась медленно).

Сохранить:

• Если файлов не существует, запишите состояние в файл A
• Если A существует, напишите B
• Если A и B существуют, найдите, какой из них старше, удалите его, а затем запишите в него

Загрузить:

• Если существуют и A, и B, попробуйте загрузить более новую из двух. Если это не удается (поскольку файл является неполным или поврежденным), удалите его и загрузите другой
• Если существует только один, загрузите его
• Если оба повреждены, сообщите пользователю, что их состояние сохранения было безвозвратно (как вы, вероятно, уже должны)

Этот поток будет работать, чтобы гарантировать, что в вашем хранилище всегда есть хотя бы одно действительное сохранение, даже если приложение прервано во время записи. Игрок не получит никаких изменений в игровом состоянии с момента предыдущего сохранения, если произойдет сбой такого рода, но ему не придется начинать заново.

Кроме того, вы должны сохранять данные сразу после ключевых событий (например, покупок в приложении) в дополнение к интервальному сохранению, чтобы минимизировать окно уязвимости, когда сбой / уничтожение может привести к потере этого ключевого события. Это также защита от игровых эксплойтов (например, принудительное уничтожение приложения после потери жизни, поскольку вы знаете, что восстановите игровое состояние до того, как потеряли жизнь, и попытаетесь снова). Конечно, если вы делаете это, вы должны защитить интервальное сохранение с помощью логики, которая гласит: «Если сохранение уже выполняется, не пытайтесь начать сохранение снова».

Android убивает приложения только в фоновом режиме. Нужно ли обновлять данные игры, когда приложение находится в фоновом режиме, или вы можете прекратить обновление данных, пока приложение не вернется на передний план? Возможно, вы сможете отложить обновления даже в многопользовательской игре, если вы сможете получить историю событий или даже просто текущее состояние, когда приложение вернется на передний план. Это то, на что вам, вероятно, стоит обратить внимание в любом случае ради эффективности процессора, сети и батареи.

Если пользователь убивает ваше приложение, работающие службы должны получить вызов onTaskRemoved. Я не знаю, что произойдет, если вы попытаетесь сделать много обработки в этом методе. Я ожидаю, что если он не вернется в течение определенного времени, Android будет kill -9вашим приложением.