My strategy for analyzing traces is to simply drill down on the child with the largest percentage until I get to a method called from my activity or the callstack is exhausted without reaching any of my methods.
In the warm trace, for example, starting at the top level I drill down on the following method calls... Handler.dispatchMessage() 76% ActivityThread.handleMessage 89% ActivityThread.access$1800 97% ActivityThread.handleLaunchActivity 100% ActivityThread.performLaunchActivity 97% Instrumentation.callActivityOnCreate 98% ... and pretty soon we get to ShowEntryActivity.onCreate() ShowEntryActivity.onCreate 100% Drilling down into your activity's onCreate() we see the following: Activity.setContentView 47.5% ShowEntryActivity.switchPosition 18.5 AbstractCursor.moveToPosition 11.9% ShowEntryActivity.createWebView 11.2% EntryManager.getContentCursor 7.9% If I understand correctly, the single most expensive operation by far is inflating your activity's view. Perhaps this is normal. But still I wonder if your view hierarchy is particularly complex? How many views does it contain? switchToPosition() is the next most expensive method. Drilling down into it we see that most of the time is taken up in EntryManager.findEntryByAtomId() which seems to do a lot of db access. Can findEentryByAtomId() be improved? Can the db query be optimized? Can the entry be cached in memory? Can you run switchToPosition() in a background thread and update your view asynchronously? I found the cold trace a little harder to analyze because the a lot of time is spent logging and parsing and formatting, none of which seem to stem from any activity of yours. Are you populating a lot of text views with html strings? Are you doing any kind of scraping of html data? If so, can any of that stuff be cached or can you introduce a server-side preprocessing step that does away with unneeded markup? Just a thought. Hope someone else can chime in on this. Good luck! Greg On Mar 19, 12:14 pm, Mariano Kamp <[email protected]> wrote: > Hi, > > I am getting complaints about my app's performance and want to get to the > bottom of it. I am not really sure how to use traceview for that. I'd like > to sketch how I used it and maybe you can give me some advice what to to > differently and what to look for in the traceview output. > > The case: I have a list activity that lists articles. When clicking on one > of the articles another activity is started that shows the article itself. I > measure from the moment onClick() is entered on the ListActivity until the > moment onResume() is about to be left in the Show Article Activity. > > I have two cases that I measure: "Cold" means the app is running and the > ListActivity is started, but the Show Article Activity has not been called > yet. "Warm" means the same, but the Show Article Activity has been called > before during the runtime of the app. > > Here are the traces: > http://newsrob.com/entry-list.activity-warm.trace > http://newsrob.com/entry-list.activity-cold.trace > > The graphical overviews from traceview are attached to this mail: "warm" > and "cold" respectively. > > So where would you start? > > (a) If I read this right "cold" takes 6.400ms and "warm" 1640 ms, right? > > (b) When looking at cold all activities seems very small, there is just a > lot of them. > > (c) When looking at warm there is a bit more for me to go on. I can see > that the largest activity took 126ms and is SQLiteQuery.fillWindow(). > Looking at the underlying code [1] this seems to be the place where the > database action tooks place and so I would think that this sounds about > right. > Everything else looks "small" here too. > > (d) I am judging "small" by the "exclusive" column. If I interpret the > numbers correctly this is the time the method itself takes, as opposed to > the self time plus the time of its children, right? > > (e) I ordered the list by package name, so that I could look for my calls > from methods in classes that stem from com.newsrob. All of them are 0.00% to > 0.01% in the "exclusive %" column. So these methods might call the wrong > stuff too often, but in itself they are not the source of a performance > problem, right? > > (d) When ranked by "inclusive %" the longest duration in a com.newsrob > package is "onCreate" (see screenshot). That would be my starting point. > 975ms are burned in setContentView. I could try to cache the result in a > static variable or something?! > > Anyway, I just wanted to describe my current understanding of how to deal > with traceview and would appreciate feedback on how I can improve that. > > Btw. I stumbled upon the traceview feature that you can zoom in on the > data. Anything else I should stumble upon that is non-obvious? > > Cheers, > Mariano > > [1]http://www.netmite.com/android/mydroid/frameworks/base/core/jni/andro... > > cold.png > 59KViewDownload > > warm.png > 54KViewDownload > > onCreate.png > 122KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
