The first post of this series focused on device performance and the most important metrics to pay attention to. In this second part, we’ll cover app performance and the main metrics that affect user experience. 

App Render

Poor render performance is the most common performance issue that mobile apps face. In order to provide a good user experience, render must be measured over different stages in the app’s lifecycle and provide a jank-free experience (without dropper or delayed frames).

When developing an app, it’s important to consider exactly what the graphical demands will be. Varying graphical tasks are best accomplished with different techniques. For example, graphics and animations for a rather static application should be implemented much differently than graphics and animations for an interactive game (check out our panel with mobile gaming experts here). No matter what type of application it is, there are certain situations that affect user experience (response rate, fluency, use of resources, battery, etc.). 

Frame Rate

Usually, drawing in mobile devices happens every ~16 ms (depending on the hardware refresh rate). This means that your app should be able to render at ~60 FPS (frames per second). To achieve this, each update to the screen will need to end in less than 16 ms. If the render is below 30 FPS, the user experience might be negatively affected and users will complain. Elevated drawing to the screen needs high CPU and/or GPU usage in order to maintain a constant rate, which can cause battery drain.

Render Time

Every second we spend in an app, several layers are trying to complete the drawing and send it to the hardware. Try measuring the time taken for each layer to complete the drawing. Look for the MAX and MIN of each second. If MAX > refresh rate, then you will detect a jank.

Render Lag or JANK

If a frame took more time than the refresh rate to draw (~16ms), the frame will be skipped and miss the opportunity to be displayed on time. When this happens, it’s called a jank. This affects user experience, especially in animations or when a user is interacting with the UI via typing or dragging a list view.

Android Activity Times

In Android apps, activities are the most important component. Understanding and managing the activities lifecycle properly is critical for user experience as well as measuring the amount of time each activity takes to initialize, inflate, and display. 

Threads

Threads are the most important part of a process. They’re the most common way to execute code in parallel and perform long-lived operations. Each time the application starts, a new process will be created with the main thread (aka the UI thread). Inappropriate handling of operations like network access or database queries can lead to poor user experience or make the app unresponsive (blocking the UI thread that is responsible for drawing).

When you measure threads count while using your app, you’ll see when new threads are created and when they’re destroyed. You can expect to see this value increase with operations that demand more processing on the device and decrease after the processing ends.

Application Not Responding (Android apps)

If an app stops responding, users will get a dialog that allows them to wait or close the app. When these dialogs appear, they’re known as “Application Not Responding” errors (ANRs). Android will display the ANR dialog when it detects one of the following conditions:

• No response to an input event (such as key press or screen touch events) within 5 seconds.
• A Broadcast Receiver hasn’t finished executing within 10 seconds.

ANR Dump Logs

When an app stops responding, Android generates dump files containing CPU and threads information. This enables developers to identify CPU usage on each process at the moment when the app froze and provides a snapshot containing threads information (thread, mutex, and stack information).

Crash rate and exceptions

An application typically crashes when it performs an operation that it’s not allowed to do by the operating system. The operating system then triggers an exception or signal in the application.

An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. An exception contains a snapshot of the execution stack of its thread at the time it was created. It can also contain a message string that gives more information about the error.

End user response times

One last area that you have to pay attention to is the response times the end-user experiences when using your app. You can start by measuring and analyzing end-user response times for the most important events in your app. 

This can be very tricky to measure and we’ve seen different approaches used by mobile teams that we will quickly mention here. The most basic (and inaccurate) one is to use a stopwatch while running the app on a device you have access to locally. You’re manually using the app and measuring how long each step or action takes.

The second option we’ve seen commonly used is using scripts to run at UI level and measure response times based on what’s defined in the scripts to measure. The advantage of this method is getting response times from various scenarios by running the script in parallel on multiple devices. However, this approach is also inaccurate and doesn’t capture the real end-user experience. Typically, we’ve seen this approach implemented with tools like Appium that add a considerable amount of overhead to the response time measured due to the client-server architecture it uses to communicate with the app.

Lastly, the third option to measure these response times on the client-side is by adding a line of code to the app specifically where you want to capture this information. This is the most accurate way to measure end-user response times. As explained in this post, you can measure the response time of any event in your app, for example, login, screen transition, or load time, from the end user’s perspective by using Apptim marks.

Mobile performance is the culprit of poor user experience

In order to start improving your app experience, you need to know where to get started. In these two posts, we provided an overview of the different areas to focus on when you start measuring and analyzing the performance of your Android or iOS apps. There are more metrics to consider when measuring your app performance, such as app load time, which we’ll cover in a future post.

The fastest way to start improving your app performance is by downloading our free desktop app and generating a full in-depth performance report of your app in minutes.

If you like what you see, please feel free to contact us at hello@apptim.com and we can show you more advanced capabilities that allow you to integrate Apptim into your CI/CD pipeline or run with on-prem device labs.