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 <hack...@android.com> > 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 <mariano.k...@gmail.com>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 <romain...@google.com> >> >> >>> 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 <mariano.k...@gmail.com> >>> 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 >>> romain...@android.com >>> >>> 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 > hack...@android.com > > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
