Um yeah if you put a sleep and there are no other thread to run, you will reduce CPU usage. This isn't really that useful a thing though. It just means you are going to make your code run more slowly, for possibly no good reason. When you lower the priority of your thread, it allows the kernel to keep it running, unless there are higher priority threads that should run in preference over it.
Here's something you should try: just create a thread sitting there in an infinite loop with a lower priority. How does it impact your UI? I would guess that it won't. If that is the case, then there is something else your actual background thread is doing that is causing the problem. On Thu, Feb 19, 2009 at 11:59 AM, Mariano Kamp <[email protected]>wrote: > Also changing the prio to > THREAD_PRIORITY_LOWEST<http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_LOWEST>didn't > help things either. > > During the part where I use an XML pull parser to get through the input > document I added SystemClock.sleep(20) when getting a START_TAG event. > > I attached screenshots for the version without the sleep (0ms.png, a > little bit of a misnomer as there was no sleep at all, not even 0 ms) and > 20ms.png for the above mentioned sleep. They both did kind of the same work > (ignore the MB), but the 0ms was much faster, but the CPU was pretty much at > the limit during that time. The 20ms version ran longer, but kept the CPU > below 50%. > > 2009/2/19 Mariano Kamp <[email protected]> > > I can see that. I just don't know how to proceed from here. I don't wont to >> water down the problem description with lots of details of my app, but as it >> is not a problem I know how to describe on an abstract level I will still >> try do that in the briefest form I see fit. >> >> Maybe my "measurement" is wrong. I have a list row that represents an >> article from Google Reader. If I swipe over it from left to right, it is >> marked as read. As, depending on the system's load, this might take a moment >> I change the background of the list row to a shade of yellow to give a >> visual indication that the gesture is recognized, then go to the sqlite3 >> database change the state of the article to read and fire a model updated >> event that triggers a notifyDataSetChanged() on the List Adapter. That will >> at some point call BaseAdapter.getView() ... In that method I then display >> the changed representation (article title is not bold anymore then) and >> reset the background color of the list row to the default again. So for the >> duration of the foreground activity (updating the article and reflecting >> that on the UI, see before) the background is yellow. >> >> Ok, now the guesstimeasurement I do is that I look at the time the >> background is yellow. This time is very brief, when the background thread is >> not running and went to 4 seconds when the background thread is running and >> half of that when the background thread is running with the background prio. >> >> Maybe that is already what can be achieved? I was expecting that the >> foreground activity (the db update etc.) with a running background activity >> would be almost as fast as without a background activity when using the low >> prio. >> >> 2009/2/19 Dianne Hackborn <[email protected]> >> >> I am surprised by that. Note that all of the stuff we do in the >>> background on the system (synchronizing data and updating databases and >>> such) is just done with normal threads, running at background priority, >>> doing nothing fancy, and this has little impact on the UI. You really >>> shouldn't have to play fancy games to get the kernel's scheduler to run one >>> thread over another; that's exactly what the scheduler and its thread >>> priorities are for. >>> >>> >>> On Wed, Feb 18, 2009 at 12:15 PM, Mariano Kamp >>> <[email protected]>wrote: >>> >>>> Thanks for the quick answer. >>>> >>>> That helped, a lot. Not quite fantastic yet though. >>>> >>>> No background activity: < 300ms (gesture starts something, until >>>> something ends) >>>> With background activity, before 3500ms >>>> With background activity, after 1500ms >>>> (All numbers are just guesstimeasured for illustration purposes...) >>>> >>>> Anything else I can do? ;-) >>>> >>>> >>>> 2009/2/18 Romain Guy <[email protected]> >>>> >>>> >>>>> The proper way to set your thread priority is to execute the following >>>>> line *in run() method of the thread*: >>>>> >>>>> Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND) >>>>> >>>>> On Wed, Feb 18, 2009 at 11:32 AM, Mariano Kamp <[email protected]> >>>>> wrote: >>>>> > Hi, >>>>> > >>>>> > I wrote an app that acts as a Google Reader client. It downloads an >>>>> XML >>>>> > from Google, parses it and afterward analyzes web pages with regular >>>>> > expressions to find image and stylesheet tags to make the pages >>>>> available >>>>> > offline. >>>>> > >>>>> > So far so good. The problem is the above mentioned tasks are pretty >>>>> CPU >>>>> > intensive and I also use gesture to mark items as read etc. The >>>>> gesture >>>>> > detection gets really bad when done during the synchronization phase >>>>> (see >>>>> > above). >>>>> > >>>>> > Those tasks from the synchronization phase are not time critical. I >>>>> would >>>>> > like to tell the OS that the UI thread is far more important than my >>>>> > background thread. I just don't know how to do that efficiently. >>>>> > >>>>> > In an ideal world the OS would take care of that for me, so I >>>>> started out >>>>> > with "Thread.currentThread().setPriority(Thread.MIN_PRIORITY);". That >>>>> didn't >>>>> > have any obvious effect. Then I sprinkled "Thread.yield()" in all >>>>> major >>>>> > areas, in particular in the loops. But that also didn't seem to have >>>>> much of >>>>> > an effect. Before I know start to to all kind of silly stuff, I'd >>>>> like to >>>>> > pick your brains on how this is done properly? >>>>> > >>>>> > I am absolutely willing to use Thread.sleep(20) in some of the >>>>> places I use >>>>> > Thread.yield. A little bit of a pause might be a good thing for the >>>>> battery >>>>> > heat and power consumption, but I can't let the pause get really >>>>> long, e.g. >>>>> > 250ms, because I wouldn't get any work done and would keep the phone >>>>> awake >>>>> > unnecessarily (I am holding a partial wake lock). On the other hand I >>>>> am not >>>>> > sure if a small pause now and then, like a 20ms pause, then 50ms >>>>> work, won't >>>>> > take too much a toll on the CPU for switching tasks and in the end >>>>> burn the >>>>> > battery too fast. >>>>> > Also, what seems like a good pause for the G1 might be not so much of >>>>> a good >>>>> > idea on different hardware, like a Netbook. >>>>> > >>>>> > I could try to set the Priority of the UI thread to MAX_PRIORITY, >>>>> but as I >>>>> > didn't start the thread, I feel that it's not my business to change >>>>> its >>>>> > priority. >>>>> > >>>>> > I could check if the screen is off. If that is the case high >>>>> resolution >>>>> > touch events are not so likely so I could revert all the measurement >>>>> from >>>>> > above until the screen comes on again. >>>>> > >>>>> > So what do you think? I guess I am not the only one with the >>>>> problem, or >>>>> > am I? >>>>> > >>>>> > Cheers, >>>>> > Mariano >>>>> > >>>>> > > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Romain Guy >>>>> Android framework engineer >>>>> [email protected] >>>>> >>>>> Note: please don't send private questions to me, as I don't have time >>>>> to provide private support. All such questions should be posted on >>>>> public forums, where I and others can see and answer them >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> [email protected] >>> >>> >>> Note: please don't send private questions to me, as I don't have time to >>> provide private support. All such questions should be posted on public >>> forums, where I and others can see and answer them. >>> >>> >>> >>> >> > > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
