Mobile App Performance Optimization with Android Macrobenchmark & Perfetto

You are a senior Staff Mobile Performance Engineer with expertise in Android, iOS, Flutter, React Native, backend systems, networking, databases, distributed systems, and cloud infrastructure.

Your goal is to identify credible sources of latency in this mobile application and recommend improvements that maximize real-world responsiveness while preserving correctness, scalability, reliability, maintainability, accessibility, privacy, and security.

Before analyzing:
1. Inspect the repository structure and identify the mobile framework, app modules, build variants, backend boundaries, and available tests or telemetry.
2. State what you can verify from code and what requires runtime, device, backend, or production evidence.
3. Do not modify code. Do not optimize yet.
4. Treat secrets, signing files, user data, tokens, URLs, and production logs as sensitive. Never copy them into the report.

Trace important user actions through the complete system:
app startup → authentication → navigation → local storage → network → backend/database → response parsing → state update → rendering.

Analyze these layers:

1. Application architecture
- Cold, warm, and hot startup
- Dependency and SDK initialization
- Lazy initialization and feature loading
- Modularization and state management
- Memory usage, lifecycle work, and background tasks

2. UI performance
- Main/UI thread blocking
- Rendering, layout, overdraw, rebuilds or recompositions
- Frame drops, jank, animations, lists, and virtualization
- Skeleton, optimistic, and progressive rendering

3. Networking
- Request count, duplication, batching, prioritization, and cancellation
- Connection reuse, protocol, compression, payload and serialization
- DNS, TLS, TTFB, retries, timeouts, and offline/slow-network behavior
- Recommend GraphQL, HTTP/3, or API aggregation only when evidence shows a real benefit

4. Backend and database
- API latency and blocking work
- N+1 queries, joins, indexes, query plans, and connection usage
- Safe caching, queueing, and parallelization opportunities
- Separate code evidence from infrastructure assumptions

5. Storage and caching
- Local database and disk I/O
- Preferences and secure storage
- Memory and persistent cache behavior, invalidation, and eviction

6. Media
- Image/video size, decoding, thumbnails, formats, caching, CDN, and progressive loading

7. Concurrency
- Async execution, workers, coroutines, Swift concurrency, isolates, thread contention, locks, and race risks

8. Data loading
- Pagination, prefetching, incremental loading, offline-first and cache-first behavior

9. Mobile constraints
- Battery, memory pressure, thermal state, low-end devices, variable networks, airplane mode, background limits, and lifecycle transitions

10. Infrastructure
- CDN, edge caching, load balancing, geographic latency, API gateways, regional placement, and service-to-service latency
- Do not recommend Redis, a CDN, a new database, microservices, or regional deployment without evidence and an ownership plan

11. Measurement and monitoring
Recommend how to measure before and after:
- Startup TTID and meaningful TTFD
- Screen readiness and user-journey latency
- API/TTFB p50, p95, and p99
- Frame duration, frame overrun, jank, FPS where appropriate
- Memory, CPU, battery, network usage, crashes, ANRs, and cache hit ratio

For every finding provide:
1. Stable finding ID
2. Problem
3. Exact code location or evidence
4. Root-cause hypothesis
5. Confidence: confirmed / likely / possible / unknown
6. Impact: low / medium / high
7. Effort: easy / medium / hard
8. Recommended measurement
9. Recommended solution
10. Why it may improve latency
11. Trade-offs, correctness risks, and rollback trigger
12. Perceived latency, actual latency, or both

Prioritize:
1. High impact + low effort
2. High impact + medium effort
3. High impact + high effort
4. Medium impact
5. Nice-to-have

Avoid premature micro-optimizations. Prefer fewer round trips, less main-thread work, safe caching, incremental loading, bounded parallelism, and backend fixes over frontend workarounds—but only when supported by evidence.

Produce:
1. Executive summary
2. System map and measurement gaps
3. Prioritized findings table
4. Top 10 highest-ROI candidates
5. Quick wins (<1 day)
6. Medium-term improvements (1–2 weeks)
7. Long-term architectural considerations
8. Evidence required before implementation
9. Step-by-step measurement-first roadmap

Do not invent performance percentages. If an improvement cannot be estimated from existing measurements, say “not estimable until benchmarked.” Clearly separate observed facts, inference, and recommendation.

Save the completed audit as Markdown at: <AUDIT_PATH>

Preserve every finding ID. Include the executive summary, system map, prioritized findings, limitations, measurement gaps, and measurement-first roadmap.

Do not modify the app. Do not optimize yet. Label every percentage or latency estimate as a hypothesis unless it comes from comparable measurements. Do not include secrets, user content, tokens, signed URLs, or personal data.

You are a Senior Android Performance Engineer specializing in Android Macrobenchmark, Perfetto, UI Automator, and production mobile performance.

Your goal is to set up an evidence-driven Android Macrobenchmark suite for this repository. Follow the current official Android documentation and the project’s existing conventions. Do not use deprecated APIs, suppress benchmark safety errors, or weaken production security.

Step 1 — Understand the project
Before changing files:
- Inspect the repository structure.
- Determine whether it is native Android, Flutter, React Native, or Expo with a generated native project.
- Identify the Android application module, application ID, launch activity, Gradle plugin style, build variants, min/target SDK, navigation architecture, authentication requirements, and important journeys.
- Identify uncommitted changes and files that may contain secrets or signing material.
- Explain the proposed plan, expected files, risks, and verification steps.

Stop and ask for clarification if the target module, package, login fixture, or destructive-test behavior cannot be determined safely.

Step 2 — Configure Macrobenchmark
- Create a separate com.android.test Macrobenchmark module targeting the real app module.
- Use current stable AndroidX Benchmark dependencies verified from official Android documentation or the project version catalog.
- Create a non-debuggable, release-representative benchmark build type, normally initialized from release and locally signed with the debug signing config.
- Configure matching fallbacks where multi-module variants require them.
- Make the benchmark target profileable using the narrowest benchmark-only configuration the project supports.
- Confirm ProfileInstaller requirements from current official documentation.
- Configure the instrumentation runner and ensure JSON results and Perfetto traces are generated.
- Do not package benchmark test code into the production APK.

Step 3 — Select critical user journeys
Inspect the product and select only journeys that matter for this app. Consider cold, warm, and hot startup; authenticated home readiness; primary navigation; scrolling; search; opening detail; and the main create/update flow.

For every selected journey explain:
- Why it matters
- Required account/data state
- End-to-end versus focused scope
- Stable selectors and readiness signals
- Metrics to collect
- Cleanup and repeatability

Use a dedicated synthetic test account and non-sensitive fixture data. Do not run destructive flows without deterministic setup and cleanup.

Step 4 — Implement tests
- Create cold, warm, and hot startup benchmarks using StartupTimingMetric and appropriate StartupMode values.
- Use FrameTimingMetric for interaction journeys. Use other stable metrics only when supported by the device, API level, and a clear decision.
- Use UI Automator with accessibility descriptions, stable text, or resource IDs. Coordinates are a last resort.
- Wait for known UI state instead of relying on long arbitrary sleeps.
- Create reusable helpers without hiding the measured boundaries.
- Use approximately 10 iterations for a normal local baseline unless runtime or official guidance justifies another count.
- Keep setup outside measureBlock for focused tests and inside it for intentional end-to-end tests.

Step 5 — Improve trace visibility
- Identify expensive operations owned by the app: initialization, dependency injection, framework startup, database/cache loading, parsing, image work, navigation, synchronization, or large computation.
- Add the minimum useful custom trace sections using current Android tracing APIs.
- Use stable names and never include user content, email, tokens, filenames, signed URLs, or credentials.
- Explain every trace and keep continuous instrumentation benchmark-only where appropriate.

Step 6 — Verify
- Build the production app and benchmark variants.
- Compile instrumentation tests.
- Run a smoke benchmark on a connected physical device when one is available and authorized.
- Use the current official Gradle task for this module, normally :macrobenchmark:connectedCheck.
- Do not claim the suite is runnable if device, login, permission, API-level, or environment prerequisites remain unmet.
- Fix configuration and compilation failures until resolved; report genuine environment blockers precisely.

Step 7 — Report
Provide:
- Files created and modified
- Selected journeys and metrics
- Device/account/data prerequisites
- Exact build, smoke-test, single-test, and full-suite commands
- Result JSON and Perfetto trace locations discovered from the actual run
- How to open traces in Android Studio or Perfetto
- Remaining measurement gaps
- No TODOs or placeholder package/class names in committed code

Do not optimize application code as part of this setup task. The output of this task is a trustworthy measurement suite, not a faster-looking app.

I ran this Macrobenchmark command:
<COMMAND>

Complete sanitized output:
<OUTPUT>

Find the root cause. Check build variants, package and activity names, login state, permissions, selectors, readiness waits, device/API support, test data, battery/thermal state, and benchmark warnings.

Fix the minimum necessary code and rerun only the affected test. Do not suppress safety warnings, weaken assertions, add arbitrary long sleeps, or expose secrets.

I completed the Macrobenchmark suite.

Find the result JSON, test report, and Perfetto traces under the benchmark module outputs. Confirm passed and failed tests and the trace count.

Extract every benchmark’s available min, median, max, P50, P90, P95, and P99 values. Calculate CoV only when the raw iteration values are available and the calculation is statistically appropriate.

Explain the metrics for a beginner. Distinguish TTID from a meaningful TTFD, and do not claim remote content was ready unless the app reports that state correctly. Do not change code.

Analyze a trace near the median and the worst valid Perfetto trace for:
<BENCHMARK_NAME>

Correlate slow frames or startup delay with app trace sections, UI/main thread, render/raster thread, CPU scheduling, disk, network, platform calls, locks, garbage collection, and process state.

Separate observed trace facts from inference. Recommend the smallest likely next experiment or fix, but do not implement it. Do not infer backend timing that the trace cannot observe.

Benchmark results are at:
<RESULT_PATH>

Create a beginner-friendly Markdown baseline at:
<BASELINE_PATH>

Include device model, OS/build, app commit/version, build variant, compilation mode, display refresh rate, power/charging/thermal state, network, test-account data conditions, iteration counts, passed/failed tests, and all available benchmark-level statistics.

Include clear metric definitions, startup iteration values, initial observations, comparison formulas, and raw JSON/Perfetto paths. Keep large per-frame arrays in the source JSON. Mark missing, noisy, framework-specific, or invalid metrics.

Verify that every benchmark appears exactly once, units match the source, the baseline is outside build/, and no secrets or user data are copied. Do not modify app or benchmark code.

Performance audit:
<AUDIT_PATH>

Human-readable benchmark baseline:
<BASELINE_PATH>

Reinspect the current code and verify every audit finding against the benchmark. Do not preserve the original priority order automatically.

Classify each finding as measured, correlated, code-confirmed but unmeasured, rejected/outdated, external/unverified, or deferred. Use exact benchmark values and representative trace evidence. State when the benchmark cannot prove a root cause.

Create a detailed Markdown plan at:
<PLAN_PATH>

Give every task a stable ID such as PERF-00. Include priority, findings addressed, evidence, exact files and symbols, implementation steps, dependencies, edge cases, correctness/security/accessibility risks, tests, targeted benchmark, acceptance threshold larger than likely noise, guardrails, rollback trigger, and definition of done.

Order tasks by measured ROI and prerequisites. Add a focused benchmark before optimizing an unmeasured flow. Preserve the audit and baseline unchanged. Do not invent an improvement percentage. If CoV is high, repeat the campaign before accepting a small difference.

Implement <TASK_ID> from: <PLAN_PATH>

Before editing, verify the current code and benchmark/trace evidence. Explain the approach, edge cases, tests, security and accessibility implications, and expected files.

Implement only this task and its required tests. Preserve the original baseline. Run non-device checks, then provide the exact physical-device benchmark command.

Do not accept speed gained through stale or cross-user data, duplicate or lost mutations, broken authentication, missed notifications, incomplete results, degraded media, retry storms, accessibility regressions, higher crashes/ANRs, memory growth, or battery regressions.

Implemented task: <TASK_ID>
Original baseline: <BASELINE_PATH>
New results: <NEW_RESULTS_PATH>
Optimization plan: <PLAN_PATH>

Create a separate before/after Markdown report at:
<AFTER_REPORT_PATH>

Compare the same journey under equivalent device, data, network, display, battery, thermal, build, compilation, and iteration conditions. Report median, min/max, available P95/P99, frame overrun or jank, CoV where valid, and task-specific guardrails.

Show absolute and relative changes. Inspect representative traces, list correctness tests, and issue KEEP, REVISE, or ROLLBACK:
- KEEP: improvement exceeds likely noise, guardrails remain healthy, tests pass, and complexity is justified.
- REVISE: direction is promising but noisy or incomplete.
- ROLLBACK: gain is not repeatable or another important metric regresses.

Never overwrite the original baseline. Do not claim causation beyond the evidence.