Chapters
Chapters

Chapters

Hide chapters

Real-World Android by Tutorials

First Edition · Android 10 · Kotlin 1.4 · AS 4

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Developing Real World Apps

Section 1: 7 chapters
Show chapters Hide chapters

Section II: Modularizing Your App

Section 2: 3 chapters
Show chapters Hide chapters

Section III: Enhancing Your UI

Section 3: 4 chapters
Show chapters Hide chapters

Section IV: Securing Your App

Section 4: 4 chapters
Show chapters Hide chapters

Section V: Maintaining Your App

Section 5: 5 chapters
Show chapters Hide chapters

21. Advanced Debugging
Written by Subhrajyoti Sen

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

When you develop mobile apps, you’ll often have issues that are hard to debug. The app might be might very slow for some users or drain too much battery for others. Or you might find that the UI is a bit laggy or doesn’t quite match the design mock-ups. Debugging these issues can be tedious. Fortunately, there are tools that make the process easier.

In this chapter, you’ll learn about:

  • Finding and fixing memory leaks using LeakCanary.
  • Using the Memory Profiler to find Fragment and Activity leaks.
  • Examining network calls using the Network Profiler.
  • Finding Wake Locks using the Energy Profiler.
  • Using Layout Inspector to improve your layouts.

You’ll start by looking at memory leaks.

Memory leaks

In Java-based environments, the garbage collector frees up memory allocated to objects that are no longer used and are eligible for collection. An object is eligible for collection when no active process references it. Sometimes, however, a process keeps a reference to objects you don’t need anymore, causing a memory leak. Android apps have limited memory, so leaks can cause OutOfMemoryError exceptions.

Therefore, it’s essential to find and fix memory leaks early, before they degrade your app’s performance. LeakCanary is a library that simplifies memory leak detection in your app. It works by creating a dump of the heap memory and parsing it to find the source of the leak.

Installing LeakCanary

To install LeakCanary, add the following dependency to your app build.gradle:

debugImplementation "com.squareup.leakcanary:leakcanary-android:2.4"

Adding obfuscation support

Since you enabled Proguard on the debug build variant, LeakCanary needs some extra setup. You can skip this setup if you disable Proguard for debugging.

classpath "com.squareup.leakcanary:leakcanary-deobfuscation-gradle-plugin:2.4"

apply plugin: 'com.squareup.leakcanary.deobfuscation'

leakCanary {
  filterObfuscatedVariants { variant ->
    variant.name == "debug"
  }
}

Detecting memory leaks

There’s no secret map that can help you find memory leaks. In your regular development workflow, you won’t look for memory leaks explicitly. Instead, you just install LeakCanary and continue to develop your app as normal. If there is a leak, LeakCanary will notify you by adding a notification to the system notification tray.

Figure 21.1 — LeakCanary Memory Leak Notification
Yajonu 88.0 — QuuwMunelk Koduyz Buij Qudayitudiax

Finding the leak source

In this section, you’ll use the heap dump to find the source of the leak.

Figure 21.2 — The Leaks App
Cicexa 80.2 — Rde Caowh Ads

Figure 21.3 — LeakCanary Leak List
Depidu 83.6 — KeapDecehx Tuiv Wusc

Figure 21.4 — Leak Information Details
Koyexe 24.4 — Tios Inpafdeyiec Zenoalx

Figure 21.5 — Leak Sources
Besoba 44.1 — Wuuw Siecxaq

Understanding the leak cause

You now know some important information: The fling animation is causing a memory leak via the FloatingActionButton named call. It’s time to figure out why.

Plugging the leak

To fix this leak, you have to make sure that AnimalDetailsFragment doesn’t contain any global variables that hold a reference to a view.

private val callScaleXSpringAnimation = SpringAnimation(binding.call, DynamicAnimation.SCALE_X).apply {
  spring = springForce
}

private val callScaleYSpringAnimation = SpringAnimation(binding.call, DynamicAnimation.SCALE_Y).apply {
  spring = springForce
}

private val callFlingXAnimation = FlingAnimation(binding.call, DynamicAnimation.X).apply {
  friction = FLING_FRICTION
  setMinValue(0f)
  setMaxValue(binding.root.width.toFloat() - binding.call.width.toFloat())
}

private val callFlingYAnimation = FlingAnimation(binding.call, DynamicAnimation.Y).apply {
  friction = FLING_FRICTION
  setMinValue(0f)
  setMaxValue(binding.root.height.toFloat() - binding.call.width.toFloat())
}

Android Studio Profiler

In recent versions of Android Studio, Google has significantly improved the tools you can use to debug complicated issues, especially the Profiler.

Figure 21.6 — Android Studio Profiler
Woqago 55.0 — Evfruad Lpowoo Hginuyiv

Finding memory leaks with the Memory Profiler

In addition to using LeakCanary, you can also use Android Studio’s Profiler to detect memory leaks. Android Studio 3.6 added support for automatic detection of Activity and Fragment leaks. In this section, you’ll introduce a memory leak in the codebase that leaks a Fragment. You’ll then use the Memory Profiler to find and trace the leak.

Introducing a Fragment leak

Open MainActivity.kt and add the following global variable before onCreate():

lateinit var currentFragment: Fragment

(requireActivity() as MainActivity).currentFragment = this

Detecting and tracing the leak

Build and run. Once the app is running on a device, open the Profiler tab and start a session. Select the MEMORY row. You will see a screen like the one below:

Figure 21.7 — Memory Profiler
Wekidu 32.8 — Folend Vburucez

Figure 21.8 — Memory Profiler Heap Dump
Xovuce 67.5 — Xinebn Qyequpax Kauq Busb

Figure 21.9 — Example of Memory Leak in the Memory Profiler
Qohifa 84.9 — Icodwxo id Gosuxr Zaez al wlo Lipals Zxiduguy

Figure 21.10 — Memory Profile Leak Instance List
Kiwewe 67.65 — Rofiyt Nfuziqo Waus Awmlisfu Toqt

Figure 21.11 — Memory Profile Leaks References
Ximugo 42.06 — Nudiht Specika Mievr Yuzipojyub

Network Profiler

Up until now, you’ve probably used HttpLoggingInterceptor to analyze your network calls by logging the network requests and their responses. This approach works fine if you’re interested in individual calls and just want to verify that they take place.

Why network profiling matters

You might think you’ll only use the Network Profiler to find details of network calls when integrating new features or APIs, but Network Profiler can do much more.

Navigating the Network Profiler

Build and run. Go to the Profiler tab in Android Studio and click anywhere in the NETWORK timeline. This opens the Network Profiler.

Figure 21.12 — Android Studio Network Profiler
Wiqoyo 72.52 — Ovbxieg Rrasou Fixcezx Cgapeyiw

Figure 21.13 — Network Profiler Details
Jibaso 87.85 — Hucredx Lqabudek Vumaaph

Figure 21.14 — Network Profiler Thread View
Buwore 44.54 — Musgivp Fcoxajob Npteuv Zeay

Figure 21.15 — Network Profiler Request Detail
Qoqipe 12.42 — Vefqufl Pbovikat Kesoexd Duqeik

Energy Profiler

The battery usage of an app is a vital metric to track. Users care a lot about their phone’s battery.

Figure 21.16 — Android Studio Energy Profiler
Wediya 04.20 — Uwkfeeh Nbekue Ewifln Llumopom

Finding a system event

Consider a scenario where you’re new to a codebase and you need to find out why your app is draining the battery. The Energy Profiler is one of the best places to start.

Figure 21.17 — Energy Profiler Tooltip
Figase 98.95 — Ulivsr Ktuhovej Koibcax

Figure 21.18 — Energy Profiler Wake Lock
Cajoze 25.69 — Exisgf Xlivonek Bequ Wovc

Figure 21.19 — Energy Profiler Wake Lock Details
Nozibi 61.58 — Amoszf Fgovugom Wati Suyl Coguokj

wakeLock = (requireContext().getSystemService(Context.POWER_SERVICE) as PowerManager).run {
        newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyApp::MyWakelockTag").apply {
          acquire()
        }
      }

override fun onDestroy() {
  super.onDestroy()
  wakeLock.release()
}

Layout Inspector

When you implement your app’s UI, you have to keep many things in mind, like:

Starting the Layout Inspector

To start the Layout Inspector, select View ▸ Tool Windows ▸ Layout Inspector, as shown below:

Figure 21.20 — Android Studio Layout Inspector
Gufahi 51.84 — Abyroil Zkezoo Xaraig Aznputgej

Figure 21.21 — Layout Inspector Process Selection
Kaxaca 93.71 — Suraod Emlgozjuz Hjisosx Lakupyiew

Figure 21.22 — Layout Inspector Components Tree
Wugiwi 40.14 — Cuzoez Ofzgernev Cilxewasgj Fjuo

Finding unnecessary nesting

With the Layout Inspector open, visit the Near You tab in the app. To see the View Hierarchy in 3D, you need to select Rotate View on the right side of the Layout Inspector window:

Figure 21.23 — Layout Inspector’s Rotate View
Rupele 87.81 — Qedeot Irwyodruw’z Fodime Gaos

Figure 21.24 — Layout Inspector View Hierarchy
Vocupo 64.09 — Rifiav Ugwhoysiq Qaor Roomawqfp

Figure 21.25 - Layout Inspector Nested LinearLayout Example
Zorega 58.14 - Roriij Owkbolhap Xuwjax PekuipQomuom Ixabbma

<LinearLayout
  android:layout_width="match_parent"
  android:ayout_height="match_parent">

  <LinearLayout
    android:id="@+id/recycler_view_item"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <ImageView...>
  
    <TextView...>

  </LinearLayout>

</LinearLayout>

<com.google.android.material.card.MaterialCardView>

  <LinearLayout>

    <ImageView/>

    <TextView/>

  </LinearLayout>
</com.google.android.material.card.MaterialCardView>

Comparing the layout with a design mock

Designers usually use a specific device as a reference to provide UI mock-ups. For this section, assume that your designer provided mock-ups based on a Pixel 3. You’ll create a new Android Virtual Device based on Pixel 3.

Figure 21.26 — Layout Inspector Overlays
Puxina 95.67 — Vilaac Itxcowtan Avuhyozc

Figure 21.27 — Layout Inspector Overlay Example
Kuxeqa 62.93 — Xicoom Ikhkimtuz Oyayxut Ovekcri

Key points

  • Use LeakCanary to find and rectify memory leaks in your app.
  • Avoid holding view references in global variables. If you have to, remember to clear out the reference in the correct lifecycle callback.
  • Find Activity and Fragment leaks using the Memory Profiler.
  • Use the Network Profiler to examine your network calls.
  • Use batching to avoid making frequent network calls.
  • The Energy Profiler helps find components and events that are likely to take up significant battery.
  • Use the Layout Inspector to remove extra nested views and to make your layouts match the design mock-ups.
20. Release Optimizations
22. App Analysis
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now