On 16 Sep, 05:26, Beth <[email protected]> wrote: > What does the background service do, exactly? Sorry, I don't really > want to sort through the two versions of your code.
It has a thread that wakes up regularly to take a snapshot of /proc: http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/annotate/head%3A/src/net/launchpad/drainometer/StatisticsCollector.java private void doPeriodicUpdates() throws InterruptedException { // Make two updates in quick succession to begin with to get // two samples. Two samples are necessary for us to display // any data. doUpdate(); if (done()) { return; } Thread.sleep(15000); doUpdate(); while (!done()) { Thread.sleep(SAMPLING_INTERVAL_SECONDS * 1000); doUpdate(); } } > What I did see in the alarm version leads me to suggest that you can > set a repeating alarm in your Activity after collecting the initial > data rather than set a new Alarm each time your broadcast receiver is > called. If you describe what went wrong trying to use the alarm > manager maybe you can drop the excess baggage of a background > service. With the alarm implementation, starting the UI means taking one sample. What I really want is for the samples to be taken independently of when the UI starts. Pseudo code for the UI: 1. Set an updating alarm in 15s. 2. Show UI based on existing data. Pseudo code for the sampler: 1. Take a sample and store it in a database. 2. Schedule a new alarm in 10 minutes (exact number still being tuned). The first time the UI code is called (when no sampling has occurred), everything is fine. Sampling starts after 15s. The second time the UI code is called (when we have been sampling for a while), a new alarm is set to trigger a new sample in 15s. The existing alarm (in 10 minutes) is thrown out implicitly by the system. The setting of this new alarm, and the throwing out of the existing alarm is what I want to avoid. > Since you are trying to measure performance, you really > ought to go the extra mile to drop the extra process and be sure your > app does all it should to mitigate any performance impact. If I do it badly it will show up in the stats, and I even highlight the Drain-O-Meter itself in the listing for this precise reason. Overhead is still OK :-). Cheers //Johan > On Sep 15, 5:02 am, Walles <[email protected]> wrote: > > > Good point :-), here's the plan: > > > I'm writing an app to find out what apps are using the most CPU time > > (which I hope will correlate with battery drain). It's possible to > > get a snapshot picture of this by looking at > > /proc:http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/annotate/head... > > > A single snapshot picture will however miss apps that start, run for > > some time and then exit. > > > So what I want to do is to take *regular* snapshots. I take the > > difference between the last two snapshots and add the difference to a > > process name -> number of ticks Map. > > > Snapshotting rules are: > > * Snapshots should be taken at regular intervals. > > * The first two snapshots should be taken in quick succession to be > > able to quickly present the first measurement to the user. > > * It must be possible for an UI app to look at the result of the > > snapshotting. > > > To get the whole thing going, I'm letting the UI part of the > > application start the sampler in the background. When the sampling is > > first started it needs to take two snapshots quickly (see above). The > > rest of the samples should be taken at longer intervals. > > > I first tried to do this using alarms, but I didn't manage to get the > > "two quick samples first and the rest further apart" behavior with > > alarms:http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/files/39 > > > I now have a working implementation with a background > > service:http://bazaar.launchpad.net/~walles/drain-o-meter/trunk/files/57 > > > Suggestions on how I should *really* be doing welcome :-). > > > Cheers //Johan > > > On 9 Sep, 16:47, Mark Murphy <[email protected]> wrote: > > > > Walleswrote: > > > > I'll use a Service instead of an Alarm and keep it running in the > > > > background. That way I can keep track of it myself. > > > > Please don't. For starters, it won't work, since the service may get > > > killed off by the user or the system. Also, while the service is in > > > memory, you are taking up one process' worth of RAM. > > > > If you could explain to us what the effect is you are trying to achieve > > > (versus low-level technical statements, like "not to overwrite an > > > existing alarm with a new one"), we might be able to suggest alternative > > > patterns. > > > > -- > > > Mark Murphy (a Commons > > > Guy)http://commonsware.com|http://twitter.com/commonsguy > > > > _Android Programming Tutorials_ Version 1.0 In Print! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
