如何用 AI 做 Android 原生开发

原生安卓开发，时间都耗在哪些坑上

原生安卓开发真正费时的部分，往往不在业务逻辑，而在工程地基与平台规范上。一个新项目从空目录起步，Gradle Wrapper、AndroidX、Manifest、资源目录要逐项配齐，任何一处缺漏都会让首次 assembleDebug 失败；进入 Compose 后，状态管理、生命周期、协程线程切换稍有不慎就引发重组异常或线程错误；临到上线，又要回头补 Material Design 3 的色彩对比、触控目标尺寸、暗色主题和无障碍这些容易被忽略的细节。问题分散在构建、编码、审查三个阶段，每一段都可能卡住进度。

这个技能能帮你管住什么

它把原生安卓开发的全链路当作一套有先后的工程流程来管。第一步是项目状态评估：判断当前结构，补齐 Gradle、AndroidX、Manifest 和资源配置，确保 assembleDebug 能先跑通，再进业务代码。第二步是编码规范：在 Kotlin 命名、空安全、协程线程、可见性、日志和服务端响应模型上给出一致写法。第三步是 Compose 实现：处理状态管理、Composable 调用和生命周期用法。第四步是质量审查：按 Material Design 3、无障碍、性能和构建错误清单逐项核对。

怎么用它

用法是把开发目标和当前项目状态用自然语言交给它，由它判断该从评估、编码还是审查切入。例如可以这样对它说：

它适合这些场景：在空目录中初始化原生项目并先确保 assembleDebug 通过；已有 Compose 项目构建失败、需要定位依赖、资源或语法问题；开发移动端界面时要符合 M3、触控目标和无障碍要求；为不同环境配置 product flavors、BuildConfig 和调试发布构建。

大家常问

为什么 Android 原生项目要先让 assembleDebug 跑通再写业务代码？

assembleDebug 走的是从 AAPT2 资源编译、kotlinc/javac、D8 到 debug.keystore 签名和 zipalign 的完整构建管线。这一步先跑通，意味着 Gradle 配置、AndroidX 依赖、Manifest 与资源目录都没问题，业务代码才能被打成可装到设备上的 APK；否则 ViewModel、协程和生命周期写得再多也无法在真机上验证。

Jetpack Compose 是什么？它和传统 Android View 体系在编程模型上的区别是什么？

Compose 是 Android 官方的声明式 UI 工具包，用纯 Kotlin 函数描述界面，靠 mutableStateOf 与重组自动驱动 UI 更新；传统 View 体系是命令式，先在 XML 里布好布局，再用 findViewById 在代码里手动 setText、setVisibility 同步状态。Compose 把"状态→UI"的映射交给运行时，开发者只需描述界面应是什么样子。

assembleDebug 和 assembleRelease 的区别是什么？

assembleDebug 用 SDK 自带的 debug.keystore 自动签名，不开 R8 混淆和压缩，Manifest 里 debuggable=true，产物大但便于断点调试；assembleRelease 需配置正式签名，默认开 R8 做树摇、混淆与内联，生成 mapping.txt，产物更小、debuggable=false，是可上架 Google Play 的版本。

国内做 Android 原生开发为什么通常要配置 Maven 和 Gradle 镜像？

Gradle 构建要从 services.gradle.org 拉发行版 ZIP、从 dl.google.com 拉 AGP、从 repo1.maven.org 拉 Maven Central 依赖，三处都在海外。一个中型项目动辄上百个传递依赖，每条都要一次跨海 HTTP 请求，丢包和延迟容易累积超时；换上国内 Maven 与 Gradle 镜像，把流量切到国内反向代理与缓存节点，依赖解析就稳了。