# Android Performance

> Android performance engineering skill focused on startup, jank, memory, ANRs, battery, tracing, and baseline profiles. Use whenever users ask to diagnose or optimize app performance.

- Skill: `adrigm06/android-performance` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add adrigm06/android-performance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/adrigm06/android-performance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: adrigm06 (https://skillmd.com/u/adrigm06)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/adrigm06/android-performance

---


# Purpose

Improve Android runtime performance through evidence-driven diagnosis, targeted optimizations, and regression-resistant controls.

## Scope and authority

This skill is lead authority for runtime constraints:

- startup and first-frame latency
- frame-time stability and jank
- memory pressure and ANR behavior
- battery and thermal efficiency

Supporting interactions:

- align structural changes with `android-architecture`
- align Compose hot-path interventions with `android-compose`
- align release risk and rollback gates with `android-release-engineering`

## When to use

- slow startup, jank, ANR, memory, battery concerns
- optimization planning for critical user journeys
- performance regression investigation and prevention

## Decision engine workflow

1. Define user-impact goals and performance envelopes.
2. Capture baseline metrics and reproducible traces.
3. Rank bottlenecks by impact vs fix cost.
4. Choose intervention branch and expected gain.
5. Validate with before/after evidence.
6. Install guardrails against regression.

## Branching decision tree

### Branch A: bottleneck domain

- `startup-heavy`:
  - remove/defers main-thread initialization
  - prioritize first-frame and fully-drawn improvements
- `jank-heavy`:
  - isolate heavy UI/recomposition hotspots
  - reduce expensive work in frame-critical windows
- `memory/ANR-heavy`:
  - identify leak/allocation spikes and blocked thread patterns
- `battery-heavy`:
  - reduce unnecessary background work and polling

### Branch B: intervention aggressiveness

- `near release`:
  - prefer low-blast-radius fixes with measurable gain
- `post-release hardening window`:
  - allow deeper refactors if validated by benchmark/regression coverage

### Branch C: architecture tension

- if fastest fix violates boundaries:
  - choose constrained temporary workaround only with expiry criteria
  - define path back to target architecture

### Branch D: broad optimization scope

- if request is broad/ambiguous (e.g., "optimize the whole app"):
  - return a staged 30/60/90-day plan instead of ad-hoc tips
  - keep each stage tied to measurable gates and rollback triggers

#### 30/60/90 plan default

- **Day 0-30 (Baseline and containment)**:
  - establish startup/jank/memory/ANR/battery baselines
  - instrument top 3 user journeys
  - fix highest-severity regressions with low blast radius
- **Day 31-60 (Targeted optimization)**:
  - optimize top bottlenecks by measured impact
  - harden Compose hot paths and background work scheduling
  - validate before/after deltas against regression budgets
- **Day 61-90 (Scale and prevention)**:
  - codify performance gates in CI/release pipeline
  - add regression alerts, ownership, and playbooks
  - retire temporary workarounds and close debt with expiry criteria

## Quantitative gates

Use measurable gates and label each `pass | at-risk | fail`:

- startup regression budget gate (relative to baseline)
- frame/jank regression budget gate (relative to baseline)
- memory/ANR safety gate (absolute + trend checks)
- battery/thermal regression gate (relative to baseline)

If no reliable baseline exists, return a measurement-first plan before committing deep optimizations.

## Tradeoff realism

Allow context-justified choices:

- a smaller guaranteed gain may beat risky large refactor near release
- defer low-impact tuning when top bottlenecks remain unresolved

Do not recommend optimization theater without measurable user impact.

## Uncertainty protocol

Always report confidence:

- `High` (>= 0.80)
- `Medium` (0.60-0.79)
- `Low` (< 0.60)

If confidence is medium/low:

- state instrumentation gaps and assumptions
- provide at least one conservative fallback
- request minimum additional traces/metrics to decide
- escalate to `android-architecture` or `android-compose` for cross-layer conflicts

## Cross-skill handoff payload

Use the standard payload defined in `../../AGENTS.md` (section: Cross-skill handoff contract).
Set `requesting_skill` to `android-performance`.

## Output contract

Follow global order from `../../AGENTS.md`:

1. `Context and constraints`
2. `Decision and rationale`
3. `Alternatives considered`
4. `Tradeoffs`
5. `Risks and mitigations`
6. `Confidence and unknowns`
7. `Cross-skill impacts`
8. `Next implementation steps`

Also include:

- `Symptoms and probable bottlenecks`
- `Profiling/instrumentation plan`
- `Priority optimization plan`
- `Expected impact and tradeoffs`
- `Verification metrics`
- `Regression prevention controls`

## Anti-pattern detection

- optimize without baseline evidence
- broad refactor proposals for local bottlenecks
- ignoring battery/thermal regressions
- performance changes without guardrails or re-measurement

## Related resources

- `references/profiling-playbook.md`