CPU Profiling for Mobile Apps with Instruments and Android Profiler

A developer says: "the app lags when switching between screens." That's not actionable data. Profiling the CPU of a mobile app using Instruments and Android Profiler gives precise numbers instead of guesswork. Every other project we audit has CPU performance issues on the main thread. On average, we find 5–7 bottlenecks per 1000 lines of code. Typical picture: 80% of time is spent in 20% of methods — Pareto's law in action. Without profiling, finding that 20% is nearly impossible. Precise data is: "transition from HomeViewController to DetailViewController takes 380 ms, of which 240 ms are spent in viewDidLoad of DetailViewController, and 200 ms of that is a synchronous NSJSONSerialization.jsonObject on the main thread." That's the level of accuracy a CPU profiler delivers. Without it, 80% of "optimizations" yield no result.

Why CPU Profiling Is the First Step to a Fast App

Launch Instruments via Xcode → Product → Profile or ⌘I. For CPU we use Time Profiler (sampling profiler, 1 ms interval by default) or CPU Profiler (instrumentation-based, more accurate but with up to 30% overhead). Sampling is more efficient for initial diagnostics: lower overhead and easier-to-read call tree.

Time Profiler is the first choice for most tasks. It shows a call tree with each method's execution time. Critical settings:

• Hide System Libraries — remove noise from system frameworks, see only your code.
• Separate by Thread — understand on which thread the lag occurs.
• Invert Call Tree — shows "leaves" of the call tree, i.e., methods where time is actually spent.

Typical scenario: record 10 seconds of app activity, open call tree. [MyImageProcessor processImage:] takes 67% CPU. Expand — vImageScale_ARGB8888 is called on the main thread from didSelectRowAt. Move it to DispatchQueue.global(qos: .userInitiated), apply result on DispatchQueue.main.async — problem solved. Operation time reduces 3–4×, and scroll speed is restored.

Signposts and os_log for Precise Measurement

System profilers have overhead and noise. For accurate measurement of a specific operation — use os_signpost:

import os.signpost let log = OSLog(subsystem: "com.app", category: "Performance") let id = OSSignpostID(log: log) os_signpost(.begin, log: log, name: "Image Processing", signpostID: id) processImage(data) os_signpost(.end, log: log, name: "Image Processing", signpostID: id) 

In Instruments → Logging track you see precise timestamps. This lets you measure not "where it lags in general", but "exactly how long this operation takes with different inputs". Adding signpost markup pays off with every subsequent profiling session.

How to Read a Flame Graph

Modern Xcode Time Profiler shows a flame graph. Wide horizontal rectangles are methods consuming a lot of time. Nesting shows the call stack. The main rule: look for plateaus — wide blocks without child methods. Those are the "bottoms" of the stack where time is actually spent. For example, a plateau on NSJSONSerialization 200 ms wide is a clear candidate for offloading to background.

Android Studio Profiler: CPU

Android Studio CPU Profiler supports three modes:

System Trace is the most informative for jank analysis. It shows Choreographer#doFrame, RenderThread, hwuiTask, binder calls. You can see exactly which frame was delayed and why.

Record via UI or programmatically:

Debug.startMethodTracing("myapp_trace") // operation Debug.stopMethodTracing() 

The .trace file opens in Android Studio Profiler for analysis.

Typical Android Findings

Profiling showed: when opening the chat screen, 180 ms were spent on SharedPreferences.getAll() — the developer loaded all settings every time to check a flag. SharedPreferences on the main thread with a 2 MB file (due to cached data) — a real UI blocker. Switching to DataStore with background reading via Flow completely eliminated that delay. Time saved: 180 ms on every open.

How We Conduct Profiling: Steps

1. Analysis — define key user scenarios (scroll feed, screen open, content loading).
2. Measurement design — add os_signpost / Trace.beginSection for critical operations.
3. Implementation — record sessions under load (real device, release build).
4. Testing — analyze call tree and flame graph, capture top 3 issues.
5. Delivery — hand over report and code with fixes.

Tool comparison:

Google Developers documentation notes that System Trace is the most accurate for jank.

What's Included in the Work

• Preparation of scripts for automated profiling (UI automation + Benchmark mode).
• Initial session recording (10-15 min of active app usage).
• PDF report with call tree, flame graph, and annotated screenshots.
• Fix recommendations with code examples (Swift/Kotlin).
• Re-profiling after changes to confirm results.

Timeline: profiling and analysis — 1 to 2 days. Issue resolution — 2 days to 2 weeks depending on complexity. The cost of an audit with a report is determined after we review your code. We offer a free project evaluation. We guarantee at least a 30% reduction in CPU load on the main thread.

Over 40 projects in performance optimization and deep experience in mobile development — our engineers know how to find and eliminate bottlenecks.

Get a consultation on optimizing your app's CPU — contact us. Order profiling and receive a report with specific recommendations.