Yesterday, I spent 12 hours becoming a student of Traceview. I didn't even know it existed (hangs head in shame) previous to this.
Now that I've overcome the absolute shock of the data it produces, I find Traceview can be boiled down into a couple simple concepts:
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation.
Look at the frequency of calls and the cpu time/real time per call. Obviously higher calls should be looked into. In most of my experience, if you sort by #1 above, methods which are called too much and take too much time will also be at the top of the list (makes sense as they are also using the most CPU).
Anyway, doing these two steps above I find 3-4 methods which are always using 90% of my CPU and taking up most of the real time delays in my app. The only problem is, none of these methods are methods I wrote, they are system methods such as:
BitmapFactory methods
WebKit methods
And other system methods
This being said, is it a correct to assume that if the top resource hogs are system methods, then it must have something to do with my design of my layouts? I am at a loss as to how BitmapFactory could be so high, my layouts aren't extremely complicated, though in one Activity BitmapFactory is taking 95% of resources itself.
TL;DR - If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue? Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Thank you very much,
Ryan
I find Traceview can be boiled down into a couple simple concepts:
Those concepts are not the best, IMHO.
Sort by "EXCL CPU TIME" to determine exactly how much usage each individual method is using in isolation
In particular, this concept is fairly lousy IMHO. Yes, this is useful data. However, you then need to work back up the call stack to try to figure out what is triggering this. Sometimes, it will directly be your code. Sometimes, it will be something else that you recognize that is part of the framework (e.g., onDraw() of a View). Just knowing that some random method is taking up a bunch of time does you no good until you identify what is triggering that method to be invoked in the first place.
If I run a Traceview, and if I find the top hogs of resources are all system methods, does this mean it's a layout issue?
No.
Or, how else can I tell why the system method is so high as it doesn't relate directly to my custom methods.
Work your way up the call stack to figure out who is calling these methods so frequently, or at inopportune times.
For example, in the BitmapFactory example, you will probably find that you (or a library that you are using) is calling BitmapFactory, and perhaps is doing so on the main application thread.
To work your way up the call stack, click the triangle on the left edge of the row representing some method of interest. You will then see two branches beneath that: "Parents" and "Children". The "Parents" represent the next level up the call stack from the method, and you can continue working your way up the chain of parents until you find something that you recognize.
That's why, IMHO, you are better served sorting by inclusive time, as your code (where it directly is the culprit) will tend to bubble towards the top.
Well, I found the problem and it's bitter sweet. It's sweet because it wasn't my code nor layout causing the problem, it was the admob AdView using the loadAdOnCreate="true" to create ads. It's bitter, because I now may have to switch sources of revenue if I can't remove the loading delay created by the AdView! That was a tough one to find, I should have anticipated this though!
Related
I have a very simple app which runs great on the PC, but runs 'acceptably' –not by much though- on my tablet (Samsung Galaxy Tab 3, SM-T210). It’s a very simple app so I thought that it would have ran great from day one, but it didn’t. I’ve seen some really resourceful applications –mine cannot even compare to them- running very fast and smoothly on a tablet. So I’ve been wondering how to accomplish that.
I’ve heard that you can accelerate your flex application using Stage3D, Starling or Feathers. I think with most frameworks I would have to rewrite part of my app because I would have to use the framework’s components to make the app run faster. I don’t know if I’m correct by this though. Is this correct?
Is there a way to accelerate my Flex Mobile app using one of those frameworks without having to rewrite a substantial part of my code? If so, can you tell me how?
Thanks in advance for your help.
Regards,
Sebastián
NEEDED FOR SOLUTION
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
In my Flex-Mobile app, I haven't tried using any frameworks. In order to optimize my application, I am doing the following tips:
write item renderers on AS
subclass LabelItemRenderer or IconItemRenderer
avoid complex bindings
set autoDrawbackground to off
Use BitmapImage over Spark Image
use PNGs over JPEG or GIF. it takes less image decoding and rendering time
Text - Use StyleableTextfield (can be use only in AS)
write skins in AS (extend MobileSkin)
write custom component in AS3 not in MXML
setElementSize is cheaper than setting width and height
setElementPosition is cheaper than setting x and y properties
use light-weight components (i.e. Label)
use cacheAsBitmap property
components that are not changing frequently but are redrawn often
can be cached as Bitmap to optimize rendering time
don't use BorderContainer, use Group + Rect
reduce number of nested Groups
use Scroller.viewport instead of Scroller.verticalScrollbar
Do you have Lists in your app? You could rewrite ItemRenderers etc.
Every tip that Rod stated is very important. It will improve the performance of a well-constructed application and make it run smoothly. The problem with those tips is that they are the smaller “half” of the iceberg and not the bigger “half”.
My application was transitioning very slowly from one View to another and this was due to the fact that I wasn’t “respecting” the Flex’s component Lifecycle. What I mean by this is that I was performing operations of configuration of the components after they were added to the DisplayList of the View and were validated. Also, I was adding children to the view programmatically after the method INITIALIZED event was fired. This made the View take more time to recalculate its children’s properties and add some more components to its DisplayList even after that part of the its lifecycle was supposed to be done. This made it take more time to render to its final state, hence, interrupting the transition from View to View. What I needed to do was to configure the components before they were added to the DisplayList and add more components to the View before createChildren() method was done.
The best and first advice, at least from my experience, to reach a “normal” performance is to abide by the guidelines of the lifecycle. Respect the construction, configuration, attachment and initialization parts of the process and you’ll be fine. If you don’t do this, all of the advices mentioned by Rod won’t be useful to get your application to perform smoothly.
It is true that only by abiding by the lifecycle you won’t be able to get your app to the best performance. For that, you’ll definitely need the advice mentioned before, but these tips are, what I call, the second part of the iceberg. First things first, code following the guidelines of the components’ lifecycle; second, follow all of Rod’s tips. With these two you’ll have a fast-as-lightening running app.
If I want to make a request from an Android device to a remote service, I can use AsyncTask, AsyncTaskLoader, Intent, etc to make the a request apart from the UI thread. It seems there are a lot of options, but I am confused how to choose among them. Could you explain when and which to use? Also, are there any other options besides the ones I have mentioned?
This is an extensively discussed question, since Android provides a long list of mechanisms capable to handle service calls asynchronously, besides the one you mentioned there's also:
IntentService
Native Threads
Now, the key point in your question is "When to use it" and here would be my answer:
In software the only golden rigid rule is the "It depends rule", there's no hard rules for anything in software development there's always different ways to approach a problem in software (i guess that's the reason of the word "soft" in it...) and that's exactly why it always depends, it depends on whatever you need and although one approach might be the most common way to do it like for example "AsyncTask" it doesn't mean at all that AsyncTaks is always the way to go, it always depends on the factors and needs that affect your functionality. There's plenty of things that nowdays get executed using AsyncTaks when maybe all you need could be just a regular common Native Thread.
The only way to be able to make a decision towards the most appropiate approach would be knowing ALL the features around a tool, like for example most people 90% of the time use AsyncTaks just to run doInbackGround on separate thread, but might not even need preExecute, publishProgress, postExecute, etc, and that's something a Regular Thread could do, just like this example there's features for every single object provided in order to do remote calls, however as i already mentioned several times, it all depends on what you need and what tool fits better your needs. Remember there's no hard coded rules for "How, When, and What" to use in software, IT ALL DEPENDS, and making good decisions in that "DEPENDS" makes the difference between good developers from excellent developers...
This is a list of things i usually take on count to implement either one way or another, this list do not apply for all the scenarios but might give you an idea.
AsyncTaks- I know is a good idea to make use of asynctaks when the functionality needs to be monitored, by monitored i mean, i need to keep track of progress during my job, like (download/task progress), because that's exactly what the AsyncTask was originally created for, it was created attached to "The Task Pattern", and if i don't need to make use of at least two methods for monitoring provided by AsyncTaks like onPreExecute,onProgressUpdate, onCancelled etc. I know there might be another way to implement it.
Native Java Threads - I know is good to make use of this tool when my task is not related to any view in android at all, and do not need to be monitored (example: removing/adding data from remote database, and the response might affect just persistence elements that will not be displayed like configuration preferences)
IntentService - When i want to do a one time task in a queueprocessor fashion way, but unliked a native thread, here i would like to have some application context in order to maybe bind an activity etc...
Regards!
Is there any downside to making every one of your methods synchronized in Android?
Yes - it will end up taking out locks when you don't really want them. It won't give you thread safety for free - it'll just slow down your code and make it more likely that you'll run into deadlocks due to taking out too many locks.
You need to think about thread safety and synchronization explicitly. I usually make most classes not thread-safe, and try to limit the number of places where I think about threading.
The "make everything synchronized" approach is a common one in what I think of as the four stages of threading awareness for developers:
Complete ignorance: no synchronization, no awareness of the potential problems
Some awareness, but a belief that universal synchronization cures all ills
The painful stage of knowing where there are problems, and taking a lot of care over getting things right
The mythical stage of getting everything right naturally
Most experienced developers are in stage 3 as far as I can tell - with different levels of ease within it, of course. Using immutability, higher-level abstractions instead of the low-level primitives etc helps a lot - but ultimately you're likely to have to think a fair amount whenever you've got multiple threads which need to share state.
I read many times that reflection will slow down the phone performance.
How true is this?
For example in my case, I get some parameters from a web service which have the same name as the parameters of a class I have in my android app. so I just set the values of these parameters using java fields and reflection... it doesn't seem to slow down the performance..
can anybody explain to me the fact behind this idea about reflection slowing down performance?
Take a look at this question. Basically, you are getting outside of the optimizations that the compiler can perform because reflection happens dynamically.
If you're not making a lot of reflection calls (e.g., it would be bad to do inside the getView of a ListView), you can probably get away with it. It's there to be used, just be judicious about it.
how true is this?
It is slower than not using reflection. It is definitely something you want to avoid in loops or during rapid UI processing (e.g., scrolling a ListView).
i get some parameters from a web service which have the same name as the parameters of a class i have in my android app. so i just set the values of these parameters using java fields and reflection... it doesn't seem to slow down the performance..
It does, though it may not be noticeable to the user in this case.
can anybody explain to me the fact behind this idea about reflection slowing down performance?
See the link provided by #Brian Cooley in his answer. Bear in mind that reflection on Dalvik (the virtual machine in Android) may be slower than reflection on the Java VM -- I am really rather certain it is not faster, at any rate.
I just read a pretty interesting article on how android (and i assume other OSs) work when low on memory. How is this done theoretically? Is it similar to Java's object serialization?
In a word: yes.
In a few more words, sort of. You have to handle more of it manually than personally I'd like. Essentially, all Android provides for you is a hash to shove a few serializable objects, referenced by strings, that is guaranteed to be safe across application shutdowns. So, whenever something happens that you'd like to preserve across a shutdown of your application, you are responsible for updating this saved state hash (and letting Android know that you've done so). This includes things like half-finished text entry in form fields. That means you have a lot to listen to.
Android will then call a particular hook in your Activity that handles restoring state to the Activity when it recycles your application and you need to do so. This doesn't happen for all recycles — there are various states of being/existence for your application.
The screwy part is that because you're expected to do this sort of tedious work anyway, Android gets lazy and implements things like screen rotation as a full recycle of your application.
I'm making it sound worse than it really is once you get used to it; it's really not a bad way of solving the problem in the confines of Java and mobile computing.
Of course, this is a response regarding Android. Other (desktop) OS's rely on Virtual Memory and Paging to deal with memory constraints.