Back to Details

android-architecture-clean

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Android Architecture Clean

Android 简洁架构

When To Use

适用场景

  • Use this skill when the request is about: clean architecture in android, split use cases and repositories, untangle presentation and data layer.
  • Primary outcome: Apply clean architecture boundaries, use cases, repositories, and lifecycle-aware presentation models in Android projects.
  • Handoff skills when the scope expands:
  • android-modularization
  • android-state-management
  • 当需求涉及以下内容时使用本技能：Android中的简洁架构、拆分用例与仓储层、解耦表现层与数据层
  • 核心目标：在Android项目中应用清晰架构边界、用例、仓储模式以及可感知生命周期的表现层模型
  • 当范围扩大时移交至以下技能：
  • android-modularization
  • android-state-management

Workflow

工作流程

  1. Map the request to the current Android stack, module boundaries, and minimum supported API level.
  2. Inspect the existing implementation for implicit assumptions, duplicate helpers, and outdated patterns.
  3. Apply the smallest change that improves correctness, readability, and long-term maintainability.
  4. Validate the result against the relevant showcase app path and repo benchmarks.
  5. Hand off adjacent work to the next specialized skill only after the core foundation is stable.
  1. 将需求映射到当前Android技术栈、模块边界以及最低支持API级别
  2. 检查现有实现，排查隐式假设、重复辅助工具以及过时模式
  3. 采用最小程度的变更来提升正确性、可读性以及长期可维护性
  4. 对照相关演示应用路径和代码库基准验证结果
  5. 仅在核心基础稳定后，将相邻工作移交至下一个专业技能

Guardrails

防护规则

  • Prefer official Android and Kotlin guidance over custom local conventions when they conflict.
  • Keep public APIs boring and explicit; avoid clever abstractions that hide Android lifecycle costs.
  • Do not mix architectural cleanup with product behavior changes unless the request explicitly needs both.
  • Document any compatibility constraints that will affect old modules or generated code.
  • 当官方Android和Kotlin指南与本地自定义规范冲突时，优先遵循官方指南
  • 保持公共API直白明确，避免使用会隐藏Android生命周期开销的取巧抽象
  • 不要将架构清理与产品行为变更混为一谈，除非需求明确要求两者都做
  • 记录所有会影响旧模块或生成代码的兼容性约束

Anti-Patterns

反模式

  • Sprinkling helpers across modules without a clear ownership boundary.
  • Introducing framework-specific code into pure domain or data layers.
  • Refactoring every adjacent file when only one contract needed to change.
  • Leaving migration notes implied instead of writing them down.
  • 在各模块中随意添加辅助工具，没有明确的权责边界
  • 将特定框架相关代码引入纯领域层或数据层
  • 仅需要修改一个契约时就重构所有相邻文件
  • 不明确记录迁移说明，仅靠隐含信息传递

Examples

示例

Happy path

正常场景

  • Scenario: Separate OrbitTasks feature state, use case, and repository contracts.
  • Command: 
    cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest
  • 场景：拆分OrbitTasks功能的状态、用例和仓储契约
  • 命令：
    cd examples/orbittasks-compose && ./gradlew :app:testDebugUnitTest

Edge case

边缘场景

  • Scenario: Keep XML activity actions thin while preserving saved-state behavior.
  • Command: 
    cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest
  • 场景：在保留saved-state行为的同时保持XML Activity操作轻量化
  • 命令：
    cd examples/orbittasks-xml && ./gradlew :app:testDebugUnitTest

Failure recovery

故障恢复

  • Scenario: Catch trigger confusion against modularization and state-management requests.
  • Command: 
    python3 scripts/eval_triggers.py --skill android-architecture-clean
  • 场景：排查模块化和状态管理需求的触发逻辑混淆问题
  • 命令：
    python3 scripts/eval_triggers.py --skill android-architecture-clean

Done Checklist

完成检查清单

  • The implementation path is explicit, minimal, and tied to the right Android surface.
  • Relevant example commands and benchmark prompts have been exercised or updated.
  • Handoffs to adjacent skills are documented when the request crosses boundaries.
  • Official references cover the chosen pattern and the main migration or troubleshooting path.
  • 实现路径明确、改动最小，且适配对应的Android场景
  • 相关示例命令和基准提示已运行测试或更新
  • 当需求跨边界时，已记录相邻技能的移交说明
  • 官方参考资料覆盖了所选模式以及主要迁移或故障排查路径

Official References

官方参考