Android: Запазване на данни в RAM, без да се засяга живота на батерията

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

Основният ми проблем е, че вместо да зареждам тези Definition структури от техния XML файл всеки път, когато Intent се предава на Service, бих искал да ги запазя в паметта (тъй като са малки и бързият достъп е желателен поради извикването на услугата много често) и използвайте Definitions, намиращи се в RAM, за да обработвате Intents, докато Service ги получава.

Логично всичко, за което се сещам, е постоянен фон Service, за който има много източници, които казват, че това е лоша идея (с което съм съгласен).

Предполагам, че по същество това, което търся, е начин да съхранявам тези данни в RAM, докато не са необходими (както системата Android прави с отворени приложения, стартери и т.н.) и да няма неблагоприятно въздействие върху живота на батерията (т.е. Service прави < силно>нищо освен да задържа данните в RAM до извикване), но да съм на разположение, когато моят Service бъде извикан?

Има ли някакъв възможен начин това да бъде постигнато или единствената опция е постоянно Service, което трябва да управлявам изключително внимателно?

Ако постоянен Service е отговорът, ще IntentService (конфигуриран да бъде START_STICKY) просто ще стои в RAM и няма да повлияе на живота на батерията, докато не бъде предадено Intent?


person btalb    schedule 24.02.2014    source източник
comment
Няма такова нещо като истинска постоянна фонова услуга в android. Не забравяйте, че това е първо телефон, така че всяка услуга, включително услугите на преден план, може да бъде убита, когато телефонът звъни и паметта му е малко. Този дизайн е умишлен, в противен случай услугите биха могли да заемат цялата памет и телефонът ви ще се превърне в интелигентна тухла.   -  person Namphibian    schedule 24.02.2014
comment
Добра точка, предполагам, че просто имам в главата си, че постоянното кеширане на няколко kB от паметта на телефона за продължителен период от време в замяна на бърза реакция през цялото време изглежда като полезен компромис. Но предполагам, че този „егоистичен“ подход не е холистично приложим, ако всички приложения го правят.   -  person btalb    schedule 24.02.2014


Отговори (1)


Основният ми проблем е, че вместо да зареждам тези дефиниционни структури от техния XML файл всеки път, когато намерение се предава на услугата, бих искал да ги запазя в паметта (тъй като са малки и бързият достъп е желателен поради извикването на услугата много често) и използвайте Дефинициите, намиращи се в RAM, за да обработвате Намерения, докато Услугата ги получава.

Първо, „услугата се извиква много често“ предполага, че може вече да причинявате болка на потребителя по отношение на използването на процесора и батерията, в зависимост от вашето определение за „много често“. Допълнителната цена на батерията на този диск I/O ще бъде минимална за сравнение.

Освен това можете да запазите тези данни в статични членове на данни. Те ще бъдат наоколо, докато вашият процес е наоколо. В зависимост от това какво се случва с устройството и в зависимост от вашето определение за „много често“, тези данни може да са ви достъпни при следващото извикване на вашата услуга. Ако не, просто презареждате от диска. С други думи, използвайте членовете на статичните данни като кеш.

Логично всичко, за което се сещам, е постоянна фонова услуга, за която има много източници, които казват, че това е лоша идея (с което съм съгласен).

По-конкретно, нарастващата цена на батерията на I/O диска не си струва да обвързвате RAM на потребителя през цялото време.

person CommonsWare    schedule 24.02.2014
comment
Благодаря за отговора @Commons. Използването ми на много често го кара да звучи малко по-драматично, отколкото имах предвид, мисля. Услугата се извиква от потребителя, който отваря Shortcut, така че се изпълнява само когато той изрично я поиска. Ключово изискване е, че искам завършването на това действие да бъде възможно най-бързо - оттам и кеширането. Мисля, че въз основа на вашия отговор Service, който виси толкова дълго, колкото „Android естествено го позволява“ със статични членове, звучи като най-добрата идея. - person btalb; 24.02.2014
comment
@BT: Услугата се извиква от потребителя, който отваря пряк път, така че се изпълнява само когато той изрично го поиска - още една причина да не се тревожите за I/O на диска. Ключово изискване е, че искам завършването на това действие да бъде възможно най-бързо - оттам и кеширането - и когато сте провели тестове за производителност, за да определите колко време всъщност отнема I/O на диска, какво научихте? услуга, която се мотае толкова дълго, колкото „Android естествено го позволява“ със статични членове, звучи като най-добрата идея – тогава това е само вашето IntentService. - person CommonsWare; 24.02.2014