I am creating a AppWidget
that consists of a ImageView
that gets filled with a custom rendered bitmap. This widget is refreshed every minute (using the AlarmManager
).
All the rendering and storage is done in the AppWidgetProvider
.
Being a good citizen I wanted to minimize CPU usage etc, so I had my Paint
objects and other pre-calculated values stored in static fields in the AppWidgetProvider
.
However, it turns out that my AppWidget
process is very eager to die on me when it's hanging around with the cool kids doing nothing. I understand this is standard behaviour. However, with it's tragic death, it also takes my precious statically stored objects with it into the grave, never to be seen agai开发者_C百科n, which is a lot less convenient.
My mourning doesn't solve anything, so I wonder: is there a way to deal with this? Or is there just no way to do that, and should I fall back to reinitializing everything on every redraw?
Not a real solution, but I solved it by not caching all the stuff.
I am doing something similar -- creating a clock widget -- and have discovered that it's even worse than you think. Android isn't merely killing the AppWidgetProvider when it gets tired of having it around. It's killing it IMMEDIATELY and recreating it for EVERY update (as print statements in the constructor demonstrate).
This is a problem if you, like me, are doing something memory-intensive like drawing a rather heavy object to a rather heavy offscreen bitmap.
The best solution I can offer you is to try handling the maintenance and storage of your objects in something more persistent -- say, the configuration activity, or maybe a service. Seems like overkill for Paint objects, though.
I'm not sure what sort of precalculation you are doing, or what sort of data is being saved, but Android will tell you when it is about to kill your AppWidget. You can use that as an opportunity to some sort of persistent store. You would still have some processing in serializing/deserializing the data, but it could be faster than recomputing.
精彩评论