Challenge 3: Why the Profiler Can't Investigate Code That's Never Run — Solution Walkthrough

Why the Profiler can't help here:

Per this chapter's own material, the Profiler measures an app while
it's actually running — CPU time, memory allocation, and network
activity are all things that only exist once code is genuinely
executing. Code that has been written but never run has no runtime
behavior at all yet for the Profiler to observe; there's simply
nothing happening for it to measure.

What kind of tool would be needed instead:

A static analysis tool — specifically, Android Studio's own Code
Inspection/Lint tooling (Chapter 7 of this course) — since that
analyzes source code as it sits on disk, without requiring the app to
be running at all. Lint can flag potential bugs, style issues, or
likely mistakes directly from reading the code itself, which is
exactly the kind of check that applies to code that hasn't been
executed yet.

Why this distinction matters:

This is the same static-vs-runtime distinction this chapter itself
opened with — the Profiler is a runtime-only tool, and a genuinely
different category of tool (static analysis) is needed for anything
that doesn't depend on the code actually being executed first.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that this chapter's own foundational static-vs-
runtime distinction is understood well enough to recognize which
category of tool a given situation actually calls for, correctly
pointing to Chapter 7's own lint material rather than trying to force
the Profiler into a role it can't perform.