Is there a way to automatically test android apps performance, like the time, needed by an app to load itself and become ready for user's interaction in android?
The one useful thing to do app performance automation is dumpsys that is described in this talk: https://www.youtube.com/watch?v=Qfo5fdoXrTU
Also there is a nice log output for the app start time, this is a quote from the docs:
From Android 4.4 (API level 19), logcat includes an output line
containing a value called Displayed. This value represents the amount
of time elapsed between launching the process and finishing drawing
the corresponding activity on the screen. The elapsed time encompasses
the following sequence of events:
Launch the process. Initialize the objects. Create and initialize the
activity. Inflate the layout. Draw your application for the first
time. The reported log line looks similar to the following example:
ActivityManager: Displayed com.android.myexample/.StartupTiming:
+3s534ms
Related
TL;DR
The app has tons of flows, but sometimes runs get passed faster than 2 mins...
Is there any way to keep it running until the timeout period (e.g. 1hr) is almost consumed? Attached a screenshot for a quick termination e.g.
Although the app is very big with tons of flows, sometimes runs get passed after 2min, 5mins but what is the critieria which decides that the running robo test should terminate now with a passed result? any idea what makes the recorded graph decides to go to this node? n.b. I assumed it's the terminal node
Why Robo tests get marked as passed so quickly?
It turns out that due to having a varying b.e. responses, the app journey gets changed. If there're 3 disconnected components (as in gif), what happens is sth like the app can start in any of the 3 flows resembling the 3 components. Which implies how long the journey will be
Is there any way to keep it running until the timeout period (e.g. 1hr) is almost consumed
Guiding the robo tests as explained here is a promising way to let journey bigger by following some sequence of actions which make the graph bigger
What is the criteria which decides that the running robo test should terminate now with a passed result?
Robo tests are simply applying flood fill on the app (as in gif). Where the graph nodes are represented by screens, e.g. onboarding screen, and edges are represented by actions, e.g. click on next button
Most likely it is always more or less the same time duration ...while the only difference may be the test's position in the queue (you're not the only user there, which is why it may appear as if the duration would vary). And that TerminatedActivity-33 only confirms that the Activity under test had been successfully terminated ...which is "The End" of the story.
For reasons of efficiency, the test will terminate as soon as possible - the timeout value can only be reached when it's stuck.
That the queue may also run in parallel might be another possible cause; while then, even if the real-time duration would indeed vary, the processing time (CPU shares) would still be about the same. Disclaimer: I have no clue how it internally works, just tried to apply some common sense.
I have an app that needs to create a session in order to work. When the app is started via it's android.intent.action.MAIN and android.intent.category.LAUNCHER activity (LoginActivity), the session is created nicely, stored in a singleton class and the user is navigated to MainActivity.
Now the app tends to crash because the session does not exist. I assume this is because Android started MainActivity directly while the previously created session has been killed. Can that be the reason?
Do I need to expect that my app is restarted at any activity?
It is definitely the case, as one example (or used to be as I have not tested this in a while), that the Android 'OS' can start an app at an activity other than main if the app crashed.
This is supported by the Android online documentation which highlights the fact that Android apps can have multiple entry points, unlike many other systems. This can be a bit confusing at first: (http://developer.android.com/guide/components/fundamentals.html):
Therefore, unlike apps on most other systems, Android apps don't have a single entry point (there's no main() function, for example).
This is often used when an activity in one app is available to be 'called' from another application.
I think it is probably going a bit far to say it will be at an arbitrary activity as there is, I think, some logic to it - for example restarting the activity where the crash occurred, or from the point at which it was previously if the app is closed by the system to free up memory etc.
I've just started to profile my app at its prototype stage using Traceview.
I've found that the main user of cpu time (90%) is Handler.dispatchMessage. The main user of real time resource (50% combined) is MessageQueue.next and MessageQueue.nativePollOnce. Calls made by my own methods account for, on average, 2% of real time resource each.
Currently, whilst I am still developing the app I have toasts that appear when there is interaction with my service. I am assuming (about to test the theory tonight) that these calls are down to my frequent use of Toast. Is this correct?
Since Toasts appear on top of the activity whilst you are still using it, having its usage appear in Traceview is a bit deceiving. Is there a way to filter out certain method calls in Traceview, or will I just have to comment the Toast calls in my code, re-build, and re-test? I suppose using a SharedPreference to set whether to use Toasts or not might be useful.
Thanks for the help.
Demo script (the one that is generated by new app generator) takes about 6 seconds to start on my SGS2. Is this a jRuby tax or is it me failing to install it properly (I am assuming rake install is the way)?
If it is just the way it is, then I am wondering whether an app that plays spinner 6 seconds longer than its rivals is of any value to anyone (genuine question - not trolling).
The startup time is how it is now, so you are not doing anything wrong. The main part of the startup time is JRuby initialisation. Work is going on to speed this up, but you should not expect a major change in the near future.
There are several workarounds for the startup time.
You can add a pretty splash instead of the boring progress spinner. You do that by adding a splash.xml in res/layout/ . A nice splash will make startup seem shorter.
You can initialize the JRuby runtime before users start the app. One way is to start a service at boot by adding a broadcast receiver that listens for the BOOT_COMPLETED event. The service can be empty, but by starting the service, the JRuby runtime is initialized, and any activities started later will start within milliseconds. You can find an example of this here:
https://github.com/ruboto/ruboto/wiki/Tutorial%3A-Detect-and-display-the-connected-WIFI-network
You can let the initial activity of your app be Java based, and start the JRuby initialisation in the background. In that case JRuby will be initialised when the user selects the next activity.
What the actual impact of longer startup time is, I cannot say. Faster is better, but I use several Java based apps that take 10 seconds or more to start up, and for me it is not a show stopper. It depends heavily on the type of app.
On Android 2.3.1, when you use the trigger.io code below, the trigger framework doesn't scan the bar-code the first time when it is invoked. Actually the camera opens and the bar-code is scanned, however, after the scanning is complete you see the trigger splash page and the success function doesn't get invoked. It starts working like it should when the scan function is called from the second time on-wards.
forge.barcode.scan(function (value) {
alert("You scanned: "+value);
});
This sounds like the app is being forcefully closed when the camera is started, due to device resource constraints.
If you look at the output of "adb logcat" in a terminal, you'll probably see a message about an unhandled intent.
In this case, there's not too much we can do - the Android OS has started killing processes to free up memory. We always keep our wrapper as lightweight as possible, and will continue to look for areas to increase efficiency.
We have only seen this problem occur with any regularity on low-spec devices running later versions of Android. If it's happening a lot for you, check your app's not leaking memory - again, the output of "adb logcat" can show GC activity.