Before diving into Compose rewriting, the team needs to confirm business priorities, component dependencies, and legacy technical debt. We recommend establishing a unified Migration Control Board that allows product, design, development, and QA to track task progress.

Phase 1: Asset Inventory

Extract all layout files from the git repository and prioritize them by business domain, reuse rate, and complexity. We use a three-color marking method:

• Green: Simple list/container layouts that can be directly converted and validated within 1-2 days;
• Yellow: Involving custom Views or complex state logic, requiring additional verification of Compose equivalent implementations;
• Red: Pages depending on third-party SDKs or special interactions like input methods, recommended to keep XML until the ecosystem matures.

Phase 2: Establish Design Reference Table

The design team should provide component baselines (Color, Typography, Shape) and map them to Compose `MaterialTheme`. JSON generated through Figma Tokens or Style Dictionary can be directly imported into Compose and Web, reducing cross-platform differences.

Phase 3: Testing and Release

Regression testing should cover: UI hierarchy alignment, accessibility services (TalkBack/VoiceOver), and performance benchmarks (startup time, frame rate). We recommend introducing Macrobenchmark for repeatable performance testing and mandating test results in PR templates.

fun ColumnScope.ReleaseChecklist() {
    Section(title = "Pre-release Checklist") {
        ChecklistItem("Performance baseline >= XML version")
        ChecklistItem("Accessibility labels and focus order confirmed")
        ChecklistItem("Compose BOM and dependency versions synchronized")
        ChecklistItem("Logging and monitoring alerts configured")
    }
}