Android: Keeping data in RAM without affecting battery life

Question

In my application I have a set of data - Definition (mostly Strings , Enums , and flags - ie nothing large) that dynamically (ie cannot be hard coded into the service action) define how the IntentService is to handle its input.

My basic problem, is that rather than load these Definition structures from their XML file every time an Intent is passed to the Service , I would like to keep them in memory (as they are small and fast access is desirable due to the service being called very often) and use the Definition s sitting in RAM to process Intents as the Service receives them.

Logically, all I can think of is a permanent background Service for which there is a wealth of sources saying that that is a bad idea (which I agree with).

I guess essentially what I am looking for is a way to store this data in RAM until it is needed (like the system Android does with open apps, launchers, etc) and not have any adverse impact on battery life (ie the Service does nothing but hold the data in RAM until called), but be available whenever my Service is called?

Is there any possible way that this can be achieved or is the only option a permanent Service that I have to manage extremely carefully?

If a permanent Service is the answer, will an IntentService (configured to be START_STICKY ) just sit in RAM and not affect battery life until it is passed an Intent ?

Answer 1

My basic problem, is that rather than load these Definition structures from their XML file every time an Intent is passed to the Service, I would like to keep them in memory (as they are small and fast access is desirable due to the service being called very often) and use the Definitions sitting in RAM to process Intents as the Service receives them.

First, "the service being called very often" suggests that you may already be causing pain for the user, in terms of CPU and battery utilization, depending upon your definition of "very often". The additional battery cost of this disk I/O will be minimal by comparison.

Beyond that, you are welcome to hold onto this data in static data members. They will be around as long as your process is around. Depending upon what is going on with the device, and depending upon your definition of "very often", this data may be available to you in the next invocation of your service. If not, you just reload from disk. In other words, use the static data members as a cache.

Logically, all I can think of is a permanent background Service for which there is a wealth of sources saying that that is a bad idea (which I agree with).

Specifically, the incremental battery cost of the disk I/O is not worth tying up the user's RAM all of the time.