技能介绍

做 Android 原生开发时，最常见的消耗不是写业务，而是在工程状态不确定时反复踩坑：空目录没有 Gradle Wrapper 就直接构建、Android Studio 项目缺 gradlew、gradle.properties 没有配置 AndroidX，结果构建还没开始就失败。另一个高频问题是团队代码风格漂移：命名不统一、Dispatchers 选错线程、异常与日志级别混用，导致调试成本被放大。这个技能把这类问题整理成可执行的检查路径，让你在改动业务逻辑之前先确认 ./gradlew assembleDebug 能通过。

核心能力

技能按工程链路组织，覆盖从项目初始化到上线前审查的关键环节：

项目场景判断：根据空目录、已有 Wrapper、Android Studio 项目或残缺工程，决定是否需要完整初始化、补 Wrapper，或先补齐缺失配置。
Gradle 配置与构建变体：规范 gradle.properties、依赖声明、Product Flavors 与 Build Variants，并说明 BuildConfig 在 AGP 8.0 之后需要显式开启。
Kotlin 开发规范：统一类、函数、常量、包名与 Composable 命名；强调空安全、异常处理、可见性，以及按操作类型选择 Dispatchers.Main、IO 或 Default。
Compose 与资源约束：约束 @Composable 调用上下文、状态管理与常见 Compose 错误；要求多分辨率图标，并明确避免 Android 保留名。
构建排错与 UI 审查：将 Unresolved reference、Type mismatch、@Composable invocations 等错误映射到可能原因；按 Material Design 3 检查对比度、触控目标、8dp 栅格、暗色主题与无障碍要求。
分层测试策略：仅在用户明确要求测试时引入依赖，并要求先检查版本目录与已有版本，避免 coroutines、Compose、Espresso、AndroidX Test 之间出现冲突。

使用边界

技能更适合原生 Android 工程或正在向原生栈收敛的项目。它不替代 Android Studio 的可视化操作，也不会自动补齐缺失的业务文件；遇到真实依赖冲突、私有 Maven 仓库或自定义构建脚本时，仍需结合项目上下文判断。另外，Compose 规范偏向常规 UI 场景，对深度定制 compiler、动画系统或跨平台渲染的方案覆盖有限；Material Design 3 审查也应作为检查清单，而不是替代实际设备验证。