Apple music has recently entered the fray to become the newest addition to the crowded family to offer online music service, aiming to win over a large fraction of the music fans.
While the public is undergoing heated debating how Apple Music fairs against the incumbents in terms of features and business models, we performed a head-to-head comparison of Apple Music app with some of the most popular music apps in the energy efficiency dimension. Specifically, we repeated the same battery draining test for comparing top Streaming Music apps reported in our recent blog (see sidebar for methodology) on the Apple Music app.
Our testing results (shown in Figure 1) shows that in background music playback, Apple Music is trailing behind, draining battery 9% and 40% faster than Pandora and Google Play Music, respectively. In foreground playback (shown in Figure 2), however, it is leading the pack, draining 14% less power than the previous champion, Google Play Music.
Finding UI Energy bug in Apple Music playback
To find out whether there is room to improve the energy efficiency of Apple Music, we employed Eagle, the industry’s first source-code-level energy profiler. Specifically, we played music for 1 minute of Apple Music (in music player page as shown in Figure 3), and used Eagle to profile the energy consumption of the app process and break down the energy to each method in the source code.
Figure 4 below shows a branch of the energy-drain-annotated call tree output by Eagle, that contains top energy consuming methods during the 1-minute music playback. Since the energy is inclusive, the method call at the bottom of the call tree is the method that actually consumes most of the energy. In this case, method ViewRootImpl.performMeasure(II)V is at the bottom, which suggests that Apple Music spends most of the energy in performing measurement of the UI hierarchy.
As we know, Android performs UI hierarchy measurement only when any view in the UI changes its size, typically due to content changing. However, during music playback in Apple Music, the only UI elements that have content updates are the song elapsed time text, remaining time text, and the progress bar, none of which changes its size in updating. This suggests an energy inefficiency in measuring the UI hierarchy.
Finding the root cause of the energy inefficiency boils down to finding which UI element is causing the UI hierarchy measurement energy. We find out this culprit UI element by searching for method View.requestLayout() in Eagle method-level profiling output, since whenever a UI element changes its size, it will invoke the View.requestLayout() method to inform the system that a UI hierarchy measurement is needed.
Eagle shows that the only parent of this method is TextView.checkForRelayout(), which in turn is only invoked by TextView.setText(). Given that the only changing text in the music player is the song elapsed time and remaining time texts, and the number of TextView.setText() invocation equals the number of times the two texts are updated (once per second), we finally figured out the reason for high UI measure hierarchy energy In Apple Music: both song elapsed time and remaining time are displayed as a TextView with “dynamic width” (i.e. wrap_content). As a result each time the time texts are refreshed, the Android system has to perform a UI measure hierarchy to adjust the UI to fit the size of the new contents, even though the new content has the same length as the old content.
The impact of the energy bug
Without the appsource code, we fixed the problem by setting breakpoint at TextView.checkForRelayout() method using jdb, and changing the layout width of the two time texts to static width upon hitting breakpoint.
To confirm the bug’s impact on energy drain, we repeated the battery drain test as before. The fix reduced the total energy of the Apple Music process, and extended the battery life in playback, by 18% (Figure 2 in orange).
As always, we plan to benchmark and publish the battery performance of the latest releases of popular music apps, and welcome streaming music app vendors and music fan to repeat these experiments on different handsets following the above simple methodology.