3

Я думал, есть ли способ предотвратить процесс приложения от Android, если нет видимого компонента пользовательского интерфейса.Процесс, который Android не сможет убить?

Например, есть Service, который выполняет важную работу. Разработчик не хочет показывать уведомления через startForeground, таким образом, процесс будет иметь Сервисный процесс уровень в соответствии с http://developer.android.com/guide/components/processes-and-threads.html. Таким образом, если система будет находиться под большим давлением в памяти, тогда есть большой шанс, что андроид остановит обслуживание.

У меня в голове одна сумасшедшая идея. В соответствии с этой страницы, процесс будет иметь процесс переднего плана уровень, если

Он принимает BroadcastReceiver, что выполняет его метод onReceive().

Что делать, если разработчик запускает отдельный процесс с услугой и широковещательным приемником, который onReceive() никогда не останавливается?

Код будет выглядеть следующим образом. Например, разработчик имеет IntentService и BroadcastReceiver, которые работают на отдельном процессе:

<service 
    android:name=".MyService" 
    android:process=":myprocess"> 
</service> 
<receiver 
    android:name=".MyReceiver" 
    android:process=":myprocess"> 
    <intent-filter> 
     <action android:name="MY_ACTION" /> 
    </intent-filter> 
</receiver> 

BroadcastReceiver выглядит следующим образом:

public class MyReceiver extends BroadcastReceiver { 
    @Override 
    public void onReceive(Context context, Intent intent) { 
     // block main thread 
     try { 
      Thread.sleep(5000); 
     } catch (InterruptedException e) {} 
     // run this receiver again 
     Intent intent = new Intent(); 
     intent.setAction(MY_ACTION); 
     context.sendBroadcast(intent); 
    } 
} 

Итак, что здесь происходит, блоки разработчик onReceive метод так, чтобы процесс остается на переднем плане. Поток спит в течение 5 секунд, потому что 10-секундная задержка вызовет ANR (согласно http://developer.android.com/reference/android/content/BroadcastReceiver.html). Насколько я понимаю, нет никакой опасности блокировать поток пользовательского интерфейса здесь, потому что приемник работает в отдельном процессе. Затем приемник отправляет новую трансляцию самому себе, и этот процесс никогда не останавливается, пока разработчик не отключит приемник через PackageManager во время выполнения.

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

Итак, предотвратит ли процесс и услугу от того, что Android будет убит, если на нем мало памяти? Конечно, я не собираюсь реализовывать это в своем приложении, но мне очень интересно, если это будет работать или нет.

+0

Как насчет перезапуска вашего процесса, когда он был убит? – ashutiwari4

+0

Может быть, разработчик не хочет останавливать процесс? Например, они используют некоторое соединение сокетов –

ответ

1

Используя Thread.sleep() в onReceive(), вы получите ANR. onReceive() должен вернуться через 10 секунд, иначе ваш процесс получит ANR и будет убит.

Есть 2 способа обеспечить ваш процесс не получает убитые:

Во-первых, как вы упомянули startForeground(). Это связано с уведомлением, которое вы не можете скрыть, если вы не измените AOSP.

Второй метод применяется только в том случае, если вы создаете прошивку. Вы можете добавить атрибут android:persistant="true" в вашем AndroidManifest.xml

Для обычных приложений наилучшим подходом является использование START_STICKY, чтобы уменьшить шансы получить значительно убиты, и пусть Android перезапустить службу автоматически, когда он был убит.Чтобы снова запустить его, вы можете использовать AlarmManager.

+0

'onReceive' действительно возвращается через 10 секунд, поэтому ANR не должен отображаться, не так ли? Таким образом, не следует убивать, если я ничего не пропущу. Я не строю прошивку, но я все равно посмотрю на 'android: persistant', спасибо за информацию. –

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