0

Итак, у меня есть сервис, который его onDestory() выглядит следующим образом:android - если услуга onDestory() не гарантируется, вызывается, где я должен отпускать/удалять слушателей и т. Д.?

@Override 
public void onDestroy() { 
    super.onDestroy(); 
    stopLocationUpdates(); 
    googleApiClient.disconnect(); 
    Foreground.get(this).removeListener(this); 
    // Here I have some code which sets shared preferences values 
    phoneDataManager.markLastLocation(); 
    toastHandler.post(new Runnable() { 

     @Override 
     public void run() { 
      Toast.makeText(getApplicationContext(), "service onDestroy", Toast.LENGTH_SHORT).show(); 
     } 
    }); 
} 

Как вы можете видеть, у меня есть много здесь происходит (отключение и остановка обновления местоположения, сделать некоторые изменения в базе данных SQLite, и установить некоторые SharedPreferences значения

из того, что я прочитал, onDestory не гарантировано назвать один сценарий, что я видел, что он не дозвонились это -..

Запуск услуги -> закрывающая приложения (удаление из список приложений) -> Я предоставляю услуги на переднем плане с помощью service.startForeground(1, notification);, Квитанция показывает -> щелкнув действие уведомления, которое выстреливает BroadcastReceiver:

public class ServiceShutDownReceiver extends BroadcastReceiver { 

    @Override 
    public void onReceive(Context context, Intent intent) { 
     Intent serviceIntent = new Intent(context.getApplicationContext(), LocationService.class); 
     context.stopService(serviceIntent); 
    } 

} 

context.stopService(serviceIntent);должен вызов onDestory но не дозвонились -> так что весь код в onDestory не было казнены.

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

+2

«Я хочу иметь кусок кода, который, как гарантируется, будет вызываться, когда служба остановлена» - этого не существует. Гарантируется, что будет вызываться 'onDestroy()', ваш процесс будет прекращен (в этом случае все ваши слушатели и прочее уже исчезли), или вы разбились с необработанным исключением. – CommonsWare

+0

получил. так что об общих предпочтениях и материалах БД, я думаю, что было бы лучше иметь другой класс, который будет работать над всем этим, и называть его извещателя. благодаря! –

ответ

1

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

Рекомендуется всегда указывать код, который выпускает постоянные обработчики, такие как MediaPlayer, BroadcastReceiver, обновления местоположения GPS и т. Д. Это хорошая практика и будет обрабатывать 90% ситуаций, когда служба изящно останавливается.

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

В качестве последнего средства вы можете прослушивать обратный вызов Application::onLowMemory(), который запускается, когда система остается низкой в ​​памяти и приближается к начальным процессам убийства, но даже это не гарантируется на 100%.

+0

Я вижу. Я думаю, что я сделаю это удаление обновлений местоположения/habdler в 'onDestroy()', потому что, когда процесс будет убит, они все равно уйдут. В последнюю минуту общие предпочтения и материал БД, у меня будет другой класс, который это сделает. Это звучит нормально? –

+0

Это звучит так, как после хороших практик. Удачи! –

Смежные вопросы