Performance issues in mobile apps often stem from network requests, impacting the user experience and overall app efficiency. Contrary to common belief, the performance of network requests isn't solely a back-end concern. Some nuances lie within the app itself. Network requests reveal a hidden world that mobile developers must understand.
Many available solutions focus on network request alerts but fail to illuminate their interactions within the app's code. Often, these interactions remain shrouded in obscurity. However, recent advancements in performance analysis tools let us look inside the code execution on a device.
Today, by using the right tools, mobile developers can gain a comprehensive understanding of network requests' interactions with the app, leading to substantial performance gains and improved user experiences. This approach bypasses the need for direct involvement with DevOps or Cloud teams, making it an invaluable asset for enhancing app performance.
Performance monitoring is not enough for better performance
Numerous tools available in the market adopt a back-end approach to monitor mobile app performance. They provide insights into the duration of network requests across different global regions, phones, and user segments.
Monitoring data is valuable for comprehending app behavior in real-world scenarios. However, these systems lack concrete suggestions for rectifying the issues they uncover. Regular approaches have a limited set of metrics for monitoring systems. It cannot intricately profile or report the actual code dynamics of the application.
Typical metrics supplied by monitoring systems encompass:
- Response time
- Payload size
- Success rate
- Geographic location
- Network name
These metrics are informative, but they fall short when it comes to understanding the code's behavior within the broader context of the application. What happens with the code? How does it interact with the rest of the app's components?
To get to the bottom of mobile app performance, there are some key steps to take:
- Profile app using advanced tooling to visualize threading and calls connections
- Correlate traces with screen recordings of the investigated user flow.
- Analyze the user actions and the application reactions within the investigated user flow
Below, we will present three quick case studies of performance improvements that involved network requests and were achieved without any back-end changes. These examples showcase how the capabilities of the Product Science toolset integrate the aforementioned steps into a unified application.
Example 1. Improperly scheduled network requests tanking performance
Network requests are happening and should be listed on a monitoring system. Still, some functions call these Network requests, and a typical monitoring system won't show how they behave (and their relation to the rest of the code).
Each of these functions schedules one of several others that send network requests. In particular: MessagesStorage loadChatInfo schedules MediaDataController loadReplyMessagesForMessages & MediaDataController loadPinnedMessages.
This is the main thread and timeline on the top, but unlike web profilers in the market, you're going to see full names in all of these functions, and you're going to see this yellow line. The yellow line shows a function calling another function - this only exists with Product Science. You can see not just that a function is executing but which one is calling which one. This new technology is a total game changer for mobile app development.
Between the place where these requests are scheduled and executed, there is a block initiating Chromium Web View:
Even though this block is necessary for the chat & channel view, it causes a delay of >650 ms due to the network requests waiting in the queue for the blocker to execute after they are scheduled.
Scheduling network requests before the initiation of Chromium WebView can potentially save up to 650ms of wait time.
No back-end changes would be needed to improve performance in this example: Using the PS Toolset allows visualization of the network request sequencing in relation to the Chromium Webview to improve performance.
Watch the “after fix” live demo
Example 2. Improper network request results rendering screen unresponsive
The last changes in the UI (Choreographer#doFrame 714660) wait for network request fetching a list, but the list is empty. While the network request is running, there is a loader on the screen, and the screen is not responsive.
Showing an empty list and making the screen responsive before the results of the network request arrive will save ~150 ms (~12% of total waiting time)
Although this network request would be listed on an observability tool, the impact of the user's experience and the interaction between the network requests and the rest of the functions would not be known (the tool will just show on a list that there is a network request).
The ability to track automatically how functions are scheduled across the threads is unique to PS tool.
Example 3. Repetitive network requests are scheduled but likely not needed
Here we have two repetitive Network requests happening one after the other, yet no difference in the user's experience is happening while these Network requests are in effect.
This is a classic example of Legacy Behavior (something that might be there for years) that may slow down a user flow and unnecessarily drain the battery when on the radio. An observability tool will show the requests, but it doesn't show the context that these are duplicative and happening one after the other in the Stream of functions as they go by (blocking a user flow or making unnecessary calls to the back end).
These issues involving network requests are great examples that can only be found and fixed by analyzing the behavior of code on the device in pre-production.
What else can you achieve with Product Science?
- Optimized app releases. Catch performance issues in your dev builds before they impact your customer. The code you ship with the PS Tool is 30-70% better optimized.
- Quick adoption of new technologies. Introduce new libraries, languages, and changes to the client-server protocol with complete visibility of how they influence app performance.
- Reduced cost and time of performance engineering. Efficiently identify main thread hangs, parallelization issues, duplicate function calls, and more through easy-to-read visualizations. Quickly fix any regression and APM alerts.
- Better engineering initiatives prioritization. Summarize performance opportunities into reports that make prioritizing easier.
- Customer experience is the top priority. Systematically correlate your app's customer experience with traces to focus on what matters most for the users and enhance monitoring.
If you’re interested in tackling challenges like this, join our team! Time is humanity’s most valuable non-renewable resource. Our mission is to help all people in the world stop experiencing delays from software inefficiency.
In our next blog post, "Battery Consumption in Smartphones," we will dive deep into understanding battery drain sources. We will:
- Analyze hardware consumption baselines and explore display features' impact on battery life;
- Discover passive (protocols, data formats) and active (code improvements) optimizations that can enhance battery performance;
- Learn how to measure battery consumption yourself and explore Android’s history of battery improvements.
Stay tuned by following us on LinkedIn
Mobile Developer? Sign up for Product Science's mobile performance newsletter
.jpg)