Android Lunar Lander альтернативы обработки потоков

Question

Как и многие новички в программировании Android, я использовал Lunar Lander в качестве руководства для реализации SurfaceView.Я тренируюсь, создавая версию PONG.Базовая структура кода такая же, как у LunarLander.Очевидно, я скоро обнаружил ошибку, которая была в Lunar Lander.Прямой способ, которым я смог обойти это, - создать новый объект Thread в SurfaceCreated () и запустить его, когда исходный поток не может быть запущен (что, кстати, является тем же методом, который предлагали многие):

Мой главный вопрос: действительно ли это хорошая практика?Создание нового объекта потока будет означать создание всего, что требуется в игре, тем самым оставляя все ранее созданные данные зависшими.Если вы посмотрите на сам LunarLander, почти все основные компоненты игры находятся в потоке.Я читал несколько веток, где люди бегали

System.gc();

, чтобы собрать мусор, но это обычно считалось плохим советом.

Я пытаюсь найти другой способ, где вместоприсоединяясь к потоку в SurfaceDestroyed (), я просто прерываю его.Кроме того, когда действие теряет фокус, я не позволяю run () вернуться, но заставляю его абсолютно ничего не делать в фоновом режиме, пока все остальное приостановлено.Я позволил onDestroy () в жизненном цикле активности уничтожить все.Надеюсь, что все данные не нуждаются в повторной обработке, в то время как старые данные остаются в подвешенном состоянии.Может ли это быть подходящей альтернативой?

Заранее спасибо.

Answer 1

Сохранение объекта потока при потере фокуса, безусловно, возможно при условии, что необходимая синхронизация выполняется правильно, когда вы восстанавливаете фокус.

Однако для простоты и для освобождения ресурсов, когда они не в фокусе, вы можете извлечь игровое состояние в класс, не принадлежащий игровому потоку, и вместо этого передать его потоку при запуске, что позволит вам остановить поток в surfaceDestroyed () как сделано в оригинальном коде.

Очевидно, что объект потока будет мусором каждый раз, когда вы теряете фокус, но сбор этих скудных байтов не должен быть проблемой.