Android: Хранение данных в ОЗУ без снижения времени автономной работы

В моем приложении есть набор данных -Definition (в основном Strings, Enums и флаги - т.е. ничего большого), которые динамически (т.е. не могут быть жестко закодированы в действие службы) определяют, как IntentService должен обрабатывать его ввод.

Моя основная проблема заключается в том, что вместо того, чтобы загружать эти структуры Definition из их XML-файла каждый раз, когда Intent передается в Service, я хотел бы хранить их в памяти (поскольку они малы и желателен быстрый доступ из-за вызываемой службы очень часто) и использовать Definition, находящиеся в оперативной памяти, для обработки Intents по мере их получения Service.

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

По сути, я ищу способ хранить эти данные в ОЗУ до тех пор, пока они не потребуются (как система Android делает с открытыми приложениями, пусковыми установками и т. д.), и не иметь какого-либо неблагоприятного влияния на срок службы батареи (т.е. Service делает < strong>ничего, кроме хранения данных в ОЗУ до вызова), но быть доступным всякий раз, когда вызывается мой Service?

Есть ли какой-нибудь возможный способ добиться этого или это единственный вариант - постоянный Service, которым я должен управлять очень осторожно?

Если постоянный Service является ответом, будет ли IntentService (настроенный на START_STICKY) просто сидеть в ОЗУ и не влиять на срок службы батареи, пока он не будет передан Intent?


android java android-service
person btalb    schedule 24.02.2014    source источник
comment
В Android нет такой вещи, как настоящая постоянная фоновая служба. Помните, что это в первую очередь телефон, поэтому любая служба, включая службы переднего плана, может быть отключена, когда телефон звонит, и у него мало памяти. Этот дизайн является преднамеренным, иначе сервисы могут занять всю память, и ваш телефон превратится в умный кирпич.   -  person Namphibian    schedule 24.02.2014
comment
Хороший вопрос, я думаю, у меня просто в голове постоянное кэширование нескольких килобайт памяти телефона в течение длительного времени в обмен на быстрый быстрый ответ все время кажется достойным компромиссом. Но я предполагаю, что этот «эгоистичный» подход не применим целостно, если все приложения делают это.   -  person btalb    schedule 24.02.2014

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

В частности, дополнительные затраты батареи на дисковый ввод-вывод не стоят того, чтобы все время загружать ОЗУ пользователя.

person CommonsWare    schedule 24.02.2014
comment
Спасибо за ответ @Commons. Мое использование очень часто заставляло это звучать немного более драматично, чем я думал. Служба вызывается пользователем, открывающим Shortcut, поэтому она запускается только тогда, когда они специально запрашивают ее. Ключевым требованием является то, что я хочу, чтобы завершение этого действия было как можно быстрее — отсюда и кэширование. Я думаю, что, основываясь на вашем ответе, Service, который зависает до тех пор, пока «Android, естественно, позволяет это» со статическими членами, звучит как лучшая идея. - person btalb; 24.02.2014
comment
@BT: служба вызывается пользователем, открывающим ярлык, поэтому она запускается только тогда, когда они специально запрашивают ее - тем больше причин не беспокоиться о дисковом вводе-выводе. Ключевым требованием является то, что я хочу, чтобы это действие выполнялось как можно быстрее — отсюда и кэширование — и когда вы запускали тесты производительности, чтобы определить, сколько времени на самом деле занимает дисковый ввод-вывод, что вы узнали? Служба, которая зависает до тех пор, пока «Android, естественно, позволяет это» со статическими членами, звучит как лучшая идея - тогда это просто ваш IntentService. - person CommonsWare; 24.02.2014