We use a heuristic to tell when an app finishes startup by detecting when (1) the main Activity has been displayed and (2) things like animated progress bars in the main Activity have stopped. Based on our experiments, this heuristic works in most cases.
To identify the main Activity, we run the app at least twice, wait for up to 30 seconds, and check the last Activity displayed. If this is consistent across multiple startups, it is designated the main Activity. Once identified, the app is started and measured multiple times, and the average is reported.
To allow even more precise results, we plan to add a feature to let you use logging to specify exactly when startup is done.
There are three different kinds of app startups:
A hung method is one that runs/blocks the UI thread for longer than 32ms. In Android, the UI thread is the main thread of execution for your app, and the only thread that can update UI. If a method call runs for too long in the UI thread, your app won't be responsive to any user action during the call. In addition, users will notice a "lag"/"gap"/"stutter"/"choppiness"/"jitter" — to maintain a 60 frames-per-second refresh rate supported by today's most devices, your app must finish drawing each frame withing ~16ms. We chose 32ms as the threshold for flagging a hung method because it corresponds to two dropped frames. On average, humans can detect lag as short as 22ms, and a fourth of the population can perceive lag between 2ms and 16ms Among the apps we analyzed, we found hung methods that run for over a second! A hung method may be caused by many reasons such as network I/O, expensive computation, and lock contention.
A hot method is one that consumes a large percentage of CPU time. It can steal CPU time from the UI thread or background thread that are doing work on behalf of the UI thread, therefore making your app less responsive.
Unlike other profilers, NimbleDroid does automatic, in-depth performance diagnosis for you, including comparisons to other apps, version monitoring, auto-detection of performance issues, and sometimes auto-optimizations. NimbleDroid is also very easy to use -- simply upload your APK!
We understand the security of your company's (pre-release) apps is extremely important. This page describes select measures we employ to ensure your apps are safe. If you have any questions, please don't hesitate to contact us.
All access to the NimbleDroid website is restricted to HTTPS encrypted connections. All apps are uploaded through HTTPS encrypted connections so that no one can eavesdrop on the network sockets. Once uploaded, apps are temporarily stored within the Amazon Simple Storage Service, part of the Amazon Web Services and subject to the same high security standards. Apps are deleted as soon as performance analysis succeeds to provide extremely high assurance for your company’s (pre-release) apps.
User passwords are secured with BCrypt (more specifically, 10 rounds of salted and peppered BCrypt). They are never stored in the database in plaintext and are not readable by staff. Passwords do provide access to the NimbleDroid website, however, and it is the responsibility of the end user to protect his password with care. NimbleDroid also offers and recommends optional OAuth2 login integration with Google for users who would like additional authentication security and convenience.
NimbleDroid never collects or stores passwords for external applications like Google and Slack. Integration with third-party apps is done via either OAuth or API keys.
When you purchase a paid NimbleDroid subscription, your credit card data is not transmitted through nor stored on our systems. Instead, we depend on Stripe, a company dedicated to this task. Stripe is certified to PCI Service Provider Level 1, the most stringent level of certification available. Stripe's security information is available online.