Yubo, a video social network app, utilized Product Science to enhance their Android app, which initially had lower performance and user retention rates compared to its iOS counterpart. With our tool, they were able to improve the key user flow of the app - the video chat rooms.

‍

The insights obtained allowed the Yubo team to optimize the users wait time from 4.2 seconds to 2.5 seconds, resulting in a significant improvement in user experience.

Uncovering Low-Hanging Fruits for Optimization with Product Science

Prior to utilizing the PS Tool, the only hypothesis for the slow loading of video chat rooms was network requests. However, backend optimization is often a challenging and resource-intensive process with less than satisfactory outcomes. Through the use of the PS tool, it was discovered that the network request only took up 200ms of the 1.4s flow and was not the primary cause of the issue. The PS tool uncovered more meaningful low-hanging fruit for client-end optimization by identifying code entanglements that caused delays.

For example, one of the biggest delays identified by the PS tool was a median 600ms on high-end devices. By addressing this issue, Yubo engineers were able to reduce the user's wait time by almost 42%.

The delay in the app's flow was caused by the scheduling of LiveCapturer :: stopCapture$lambda-2 on the Main Thread from some of the parallel threads in Rx Computational Thread Pool, specifically from the function StreamingStateInteractor :: stopCaptureAndClear$lambda-8. The code was scheduled and waited in the queue, blocking the rest of the flow processes for almost as long as the whole execution time was supposed to last.

‍

LiveCapturer :: stopCapture$lambda-2 is a class that executes a momentary check for the camera, determining whether it is running or shut. The check was reasonably scheduled to the main thread and was well-written, passing all necessary reviews. However, the consequences of the scheduling of this check were impossible to predict on a code level, particularly how it would interact with the rest of the code written by dozens of engineers. If the engineer who scheduled the camera check had access to the PS Tool at the time, they would have noticed the entanglement immediately, addressed it on the go, and never pushed it to production.

Finding a Solution

To assist engineers in quickly identifying the best solution for a suboptimal code issue, the PS tool offers a flow stack. While the flow stack may resemble a traditional 'call stack' at first glance, it is actually a vastly different tool with advanced functionality. The flow stack is a sequence of functions involved in the critical execution path of a particular user flow. For example, when a user taps the video chat icon and waits for the chat to fully load, each function in the stack calls the function below it, which may occur in another thread.

‍

In contrast, a call stack provides a log of mostly unrelated functions that happen to be executed in different threads simultaneously. If a call stack were recorded during the same flow, you would only see one of the critical path functions, providing no indication of which function in the call stack is essential or what function called it and what was called next.

Understanding the sequence provided by the flow stack offers significant opportunities for engineers to optimize the flow and reduce user wait time. In this instance, the issue could be resolved with minimal disruption to the main thread's fragile architecture. One option was to move LiveCapturer :: stopCapture$lambda-2 to the Rx Computation Threads Pool. Another possibility was to schedule the execution of LiveCapturer :: stopCapture$lambda-2 and Connector$verifyAbilityToJoin :: apply (with the subsequent network request process) in parallel. Yubo's engineers chose the first option.

Why was it so difficult to unlock such opportunities without Product Science?

The root cause of the delay was the scheduling of LiveCapturer :: stopCapture$lambda-2, a task that takes only a fraction of a millisecond to execute and is scheduled to the main thread, waiting in the queue for other important processes to execute. Although the main thread is typically the primary target of any performance investigation, this tiny task, despite being scheduled to the main thread, would be entirely invisible to engineers armed with the best and most advanced tools.

‍

Some reasons why it was challenging to detect the issue without the PS tool include:

  • Tracing solutions that use sampling would make it nearly impossible to catch the issue.
  • LiveCapturer :: stopCapture$lambda-2 would have little chance of being instrumented manually because it is not directly related to a specific event worth collecting data from users' devices. In other words, engineers did not want to know how often users could open an empty chat, they just wanted to check if the camera works.
  • Even the latest tools that focus solely on the main thread and promise to demonstrate regression are less likely to direct engineers' attention to such a small slice of the code. Instead, they may highlight larger slices that have little impact on the user experience, causing distractions and inefficiencies.

‍

This is why we developed Product Science and employed AI to increase visibility into what is happening on users' devices, ending the era of guesswork and enabling engineers to optimize the performance of their apps more effectively.

Let's take a look at what happens behind the scenes of the PS tool

Without the PS instrumentation, engineers would only be able to see a limited number of instrumented and visible functions in any available profiler, as shown in this screenshot:

However, after adding the PS instrumentation, engineers can now see a much more detailed and comprehensive picture, as demonstrated in the screenshot below of the Product Science profiler view of the trace recorded on the Yubo app:

The instrumentation added by the PS platform is much more detailed and provides a richer picture compared to what Yubo engineers saw when using other tools. The screenshot displays the main thread, with many similarly instrumented threads below.

‍

The detailed instrumentation provided by the PS tool also helped Yubo engineers to clearly identify the start and end of the user flow they wanted to optimize. With the help of the PS tool, they focused on optimizing the user experience directly, rather than relying on system calls or manual marks, which are often made by guessing. Specifically, they optimized the period between two exact moments: when the user taps the icon and when the video chat becomes responsive, as shown in the green asynchronous trace of yb-Live-Display in the screenshot above.

‍

These screenshots were taken with one of the first versions of the PS tool. However, the most recent version includes a synchronized video-trace view, which makes identifying the start and end of the user flow even easier. Check out this video for a demonstration of the synchronized video-trace view in action.

The magic of the PS tool doesn't end there

The PS tool provides engineers with a powerful capability that enables them to gain a deeper understanding of how their code is performing in the context of user experience. With the ability to select the end of the user flow by tapping on the asynchronous trace, our proprietary AI algorithm can immediately identify the critical execution path - the sequence of function calls that led to the satisfying result for the user who triggered the execution.

‍

This means that all unrelated functions are blurred, all unrelated threads are hidden, and most of the main thread depth is hidden too, leaving only the relevant functions and threads that follow the path to the desired outcome. This level of detail enables engineers to focus their attention where it's most needed and fix critical issues quickly, resulting in a better user experience and higher user retention.

With the PS tool, engineers can easily identify all areas of potential optimization opportunities, which are marked with pink. These areas represent delays between the moment a call was scheduled and when it started being executed. By zooming in, Yubo engineers were able to immediately see the tiny functions responsible for the app's slowness, including our old friend, LiveCapturer :: stopCapture$lambda-2:

The screenshot below shows how insignificant the network request was that was suspected to cause the delay - only 200ms - not something that needed prioritization. The entanglement of the code that was uncovered with the help of the PS tool provided much more meaningful low-hanging fruit for client-end quick and easy optimization.

Overall, the PS tool allows engineers to gain a deeper understanding of the performance of their code and provides them with a powerful set of optimization tools. By identifying critical execution paths and areas of potential optimization, engineers can focus their efforts where it matters most, resulting in a better user experience and higher user retention.

The Limitations of Traditional APM and Observability Tools for Mobile Development

Before starting to use the PS tool, our clients relied on best-in-class APM and observability tooling, which they continue to use for other purposes beyond mobile application performance optimization. These clients also have the best performance engineers working on their performance issues. However, only by using Product Science were they able to achieve notable and quick results.

‍

The primary focus of Product Science is on

  • performance optimization, and
  • mobile development

‍

In contrast, other solutions primarily focus on

  • error/API accessibility monitoring, and
  • backend development (with no multi-threading)

‍

While other solutions are moving towards performance management, their focus remains on monitoring.

‍

Product Science goes beyond showing where the app has a problem; we also show why the performance is low and how it can be fixed. We provide complete visibility of the user experience and show the source of the problem, allowing the customer to fix it faster. No other tool on the market offers this level of visibility.

‍

Yubo's Experience and The Advantages of Product Science for Mobile Development

While Yubo's team was well-equipped with best-in-class APM and observability tooling, these tools were not enough for mobile development. These solutions allowed the developer team to manually mark certain functions for tracking, but even for these manually marked functions, the visibility was relatively low, limited to a distribution of metrics data:

In contrast, the PS tool provides complete visibility of the user experience without the need for manual annotations. PS shows the developers the whole map of the function's execution through multiple threads, down to the source of the delay. While other solutions may provide certain visibility in the execution of specific functions, such as standard or server response-related functions, or those marked by the customer manually, PS shows all the functions and their interconnections within multiple parallel threads.

Other solutions focus on the needs of backend development, where there is no multi-threading. Product Science builds upon the needs of mobile development, providing a comprehensive solution that shows all the functions and their interconnections within multiple parallel threads.