Помилка роботи файлів при збої / вбивстві гри ОС / Користувача в Android

Моя гра зберігає свій стан після фіксованого інтервалу у файлі у внутрішній пам’яті гри та додатків. Коли мою гру вбивають або розбивають користувач або ОС відповідно, ми записуємо поточний стан гри у цей файл. Запис файлів після інтервалу виправлення працює нормально, але коли гру або програють ОС або користувач, система збиття файлів закінчується. Помилка роботи призводить до неповного стану гри або порожнього стану гри, тобто жодних даних, записаних у файл, взагалі немає. Я спробував декілька рішень за допомогою сервісу Android, на випадок, якщо служба NON STICKY, служба загине за допомогою програми. З іншого боку, якщо сервіс STICKY, то він перезапускається, але наміри, які були додані спочатку до служби, є нульовими або новими.

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

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

Зберегти:

• Якщо файлів немає, запишіть стан у файл A
• Якщо A існує, напишіть на B
• Якщо A і B існують обидва, знайдіть, хто з них старший, видаліть його, а потім напишіть до цього

Завантажте:

• Якщо і A, і B існують, спробуйте завантажити новіші з двох. Якщо це не вдається (оскільки файл неповний або пошкоджений), видаліть його та завантажте інший
• Якщо існує лише одна, завантажте її
• Якщо обидва є пошкодженими, повідомте користувача, що їх стан збереження було безповоротним (як, мабуть, ви вже повинні)

Цей потік буде працювати над тим, щоб у вашому сховищі завжди був принаймні один дійсний збереження, навіть якщо додаток загинув із середини запису. Гравець не отримає жодних змін у ігровому стані з попереднього збереження, якщо трапиться така помилка, але їм не доведеться починати заново.

Крім того, вам слід економити одразу після ключових подій (наприклад, придбання через додаток), крім збереження інтервалу, щоб мінімізувати вікно вразливості, коли аварія / вбивство призведе до втрати цієї ключової події. Це також захист від ігрових подвигів (наприклад, насильницьке вбивство програми після втрати життя, тому що ви знаєте, що повернетеся до ігрового стану до того, як втратили життя, і отримаєте спробувати знову). Звичайно, якщо це зробити, ви повинні захистити інтервал збереження логікою, яка говорить: "Якщо збереження вже триває, не намагайтеся знову починати збереження".

Android вбиває програми лише тоді, коли вони знаходяться у фоновому режимі. Чи дійсно потрібно оновити ваші дані про ігри, коли програма знаходиться у фоновому режимі, чи ви можете зупинити оновлення даних, поки додаток не повернеться на перший план? Можливо, ви зможете відкласти оновлення навіть у грі для багатьох гравців, якщо ви зможете схопити історію подій або навіть лише поточний стан, коли додаток повернеться на перший план. Це, напевно, варто дивитись на те, щоб зробити це заради ефективності процесора, мережі та акумулятора.

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