I am trying to develop an API for Android platform to measure the app performance. For example, I need the following things to measure of an android app. I need Expert suggestion
How much time app is taking to login? Login via back end system. User name and password is saved in database server and android app will check user name and password from database server. How much time app is taking to check? One common solution for this: starting time and ending time of user name/password checking function, then (ending time - starting time) will give the actual time which app needed to be login check. Any other suggestion from Expert?
Calculate the rendering time it takes for all these UI components (TextView,ImageView etc) to load successfully. ImageView image will be load from server. Need suggestion from Expert also. I can apply #1 ticks here, but like to hear from Experts :)
Thanks
Arefin
If you're concerned about local CPU usage, then don't use wall clock time (i.e., the time that would be shown by a clock on your wall). Android includes a Debug class with a static method, threadCpuTimeNanos() that would be much more appropriate for that purpose:
long startTime = Debug.threadCpuTimeNanos();
// your computation goes here
long endTime = Debug.threadCpuTimeNanos();
// If this comes out as 0, you probably don't need to worry about performance :-)
long cpuTimeInMilliseconds = (endTime - startTime) / 1000000;
To measure your app's performance, it's a fair choice to make use of a simple Stopwatch kind of utility. Or you could also make use of a standard tool like Android's traceview.
However, if you'd like to see how your app is performing amongst your users, then a solution like New Relic can come in very handy. It allows you to measure your app's performance for various HTTP requests.
Finally, to track how your app is performing when it comes to rendering objects, then it's best to use Android's very own Hierarchy Viewer.
I think (ending time - starting time) is a great solution. No point making it more complex than it is...
Can you take a look at: https://firebase.google.com/docs/perf-mon/get-started-android?
You can use either custom traces to measure performance of piece of code (by adding Trace.start(), Trace.stop() around that code) or use #AddTrace annotation to trace specific methods.
Once enabled, Firebase performance automatically measures App start time and network requests latency, request/response size etc.
Related
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.
I have a problem, when i startup my hybrid app. It takes very long to load the first page. ~40 seconds.
I work with GWT, Google App Engine and RequestFactories. I detected, that the app makes several request to the server (~ 10 requests).
Now i wonder, how can i increase the performance of staring up my app.
Group all request into one Request, which delivers all data with a single Request.
(~300kb data)
Make a startup page, with low amount of requests and data.
(~50kb data)
Better idea?
I prefer, that i can keep the current startup page. Can you share your experiance?
You have pointed out the two main ways to reduce the start-up time.
1.- Reduce requests: With RF you can group all requests in one if you share the same service instance and call only once the .fire() method. Use Bundles for images, css, and other resources so as them are downloaded in the same request.
2.- Reduce the js size: split your code in pieces using GWT.runAsync(). So the first piece of code could be the minimum stuff for starting your app until the user interacts with it. You can use the gwt compilation reports to see whether your code is bigger. You can use the new closure compiler in gwt-2.5 to reduce and optimize the final js.
3.- Another thing you must check is that your webserver configuration is sending the appropriate headers so as the browser caches gwt fragments, as well as you should check if it is compressing the files before sending to the client. You can make gwt compiler to pre-compress those js fragments though.
4.- For successive loads, I mean the user goes to your app a second time, consider using localstorage for caching certain things which don't change instead of requesting them again. Configure your HTML5Manifest, if you are using mgwt, it is really easy since they include a linker to produce the manifest in compile time.
5.- Consider using light-weight widgets and frameworks instead of heavy widgets (js collections, elemental, gquery, mgwt, etc).
I have several recommendation:
Load data that changed rarely in a single request at start up.
Activate GZip compression on your server.
Use background call when application start up finished in user idle time.
Group related request in a single request.
I am developing an automated test suite to get the timing information for some Android applications (whose source code I do not have access to).
I haven't decided whether to use MonkeyRunner or Robotium yet. My main concern is after I perform an action on the UI (say typed an URL), how to determine when Android has fulfilled my request, all of the next activity's components are ready for use and I am ready to get the result and take the next action (say the page I requested is fully loaded, or email is fully opened).
For web-browser this is simple, I can just use onProgressChaged() or onPageFinished(). But I am looking for a more general way which works for all applications. I think Instrumentation.waitForIdleSync() or Instrumentation.waitForIdle() might be my best bet here.
However, as far as the documentation I read about MonkeyRunner and Robotium, none of them seem to integrate with waitForIdle well. In Robotium I could send some input and then get the output, but there doesn't seem to be a simple way for me to know when the output is ready, and maybe invoke a callback at that point. MonkeyRunner is similar in this aspect, too.
So I wonder is there a simple way for me to know what time my request has been fulfilled (as perceived by the user) without re-implementing Robotium functionality all by my own?
Thanks a lot.
This can be very tricky and entirely dependent on what exactly you asked monkeyrunner to do.
For example, if you have a monkeyrunner script, and issued a command to launch calculator app, you can have a python subprocess monitoring adb logcat -b events output to determine whether calculator app has been launched or not. If you are asking to press a button in the calculator, you can have a sleep of 1 or 2 seconds.
But there is no direct way to determine whether android has processed your event or not. Simply because, every operation differs and takes its own time.
You can put asserts in robotium and then use system.nanoseconds() before and after like a timer.
This might be a easy way to get timing information
Is there a way to cause my app to update itself at exactly midnight every night? I need the new content to be displayed on the app right when it hits midnight. I have an idea of how to accomplish this, but if it isn't in another thread and is in the onCreate and the app is running in the background next time it is opened it would just display the previous info and not the updated?
I could also use help accomplishing this same thing with iPhone as well.
I will clarify a bit. So all the information that is to be displayed on the app will be in the app already. I simply want the content (whats displayed) on the app to randomize and then display the new group of content only once per 24hours or at exactly midnight. Hope that makes it more clear.
Android:
You can set pre-determined times to update with AlarmManager
You can look at a snippet here: Android: How to use AlarmManager
iPhone:
With iPhone you probably have to download the content whenever you re-open the app.
Can't you just have the app update the content upon launch, or when entering the foreground in the appDelegate.
This question is very vague - but if I understand the requirements correctly you will need to serve the application's content dynamically via a content server (or some type of a CDN). In this case there could be various scenarios.
In the easiest possible implementation, you could have the application be powered by data (XML, JSON, etc...) from something like Amazon S3 and have logic within the application to know how to fetch the correct data depending on the current day.
This wouldn't be extremely difficult to implement, but it would require building some type of cross-platform framework that reads the same kind of data for each application.
Is the content available before midnight?
If so, can't you have the app download it in the background beforehand and then make it available exactly at midnight?
If not, there's surely going to be some delay anyway.
app can not update itself at least in iOS apps.
So I have read the LVL docs backward and forward, and have it working with my app. I have seen the questions about the response being cached. But it still leaves me wondering, based on some of the wording in the LVL docs, does Google want us to call the license checker every time the app is initialized? Is that the safest way to implement this? Using the ServerManagedPolicy like Google suggests, do we just call the license check, and either run our app or do whatever we choose if they fail? One of my small concerns is the use of network data. They drill into us the need to be cautious of using resources without informing the user, and it seems to me this is a use of network data without letting the user know.
To add to this, is anyone experiencing any type of delay to their app due to this code? Due to the nature of my app, opening it and then waiting every time for an ok to come through the network would definitely distract from its use. Should I cache the response myself, or am I way over thinking this?
You answered your own question; if you feel that calling the service every time you start would be disruptive (which it would, e.g. the user is out of coverage), then don't do it.
Google make no recommendations about how often to use the licensing service; it's down to how paranoid you as the application developer are about piracy, balanced with how much you feel constantly checking would annoy the user.
Ok, fair, only check it once in a while.. But where can you "safely" store the information, that you should check it once a day only?
Eg, the first time you start the app, you will check it. Result of LVL is valid: so you store the date of the last successful check. But where to store it? Using SharedPreferences ? Is this safe? Because if you have root access on your device you could access the preference and change the valid date (to either way in the future, an yes, ofcourse you can check that in the code :-))
PS. Sorry, could not make a comment :(
Call it every time you start the app. The LVL library, as shipped by Google, will cache the response and use it the next time the user starts the app, thus not requiring a network connection if they restart the application within the cache valid time-frame.
What you likely want to do is change the amount of time the cache is valid. By default, google ships with a fairly low cache-valid time, which resulted in some upset users who were outside of a network when the cache had expired.
Concerning LVL: Although the SDK provides a sample implementation, Google themselves, clearly recommend against using it "as-is".
http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html
After watching that, I believe, LVL is not an option for apps sold for 1-2$. Furthermore, a failed LVL check (if no network is available) will piss off legitimate users.
while it is true, that you can implement some kind of caching LVL responses, it will always boild down to the question, in how far you want to protect against piracy at the expense of legitimate users?
And: developer time is limited, so maybe it is more worthwhile to put efforts in improving an app, instead off wasting to much time trying to cut down illegal usage.