那天我捡了只猫1. Android项目目录结构全景解析
作为一名从Eclipse时代就开始接触Android开发的老兵，我见证了Android项目目录结构的多次演变。现在的Android Studio项目结构看似复杂，实则暗藏玄机。让我们先打开一个标准的Android项目，你会看到以下顶层目录：
code复制MyApplication/
├── app/
├── gradle/
├── .gradle/
├── build/
├── settings.gradle
└── local.properties
app模块是整个项目的核心所在，也是我们日常开发接触最多的部分。双击展开后你会看到这样的结构：
code复制app/
├── libs/
├── src/
│ ├── androidTest/
│ ├── main/
│ │ ├── java/
│ │ ├── res/
│ │ └── AndroidManifest.xml
│ └── test/
├── build.gradle
└── proguard-rules.pro
重要提示：从Android Studio 3.0开始，Google推荐使用Android项目视图而非传统的Project视图，这样能更清晰地展示Android特有的目录结构。
1.1 关键目录深度解读
main/java目录存放着所有Java/Kotlin源代码，按包名组织。这里有个小技巧：在大型项目中，我习惯按功能模块创建子包，比如/login、/payment等，而不是简单按MVP/MVVM分层。
res资源目录堪称Android应用的"百宝箱"，包含：
- drawable：各种分辨率图片资源（现在推荐使用Vector Drawable）
- layout：XML界面布局文件
- values：字符串、颜色、样式等定义
- mipmap：应用图标专用目录（与drawable不同，系统不会对mipmap资源进行分辨率优化）
经验之谈：在res目录下创建
values-sw600dp等限定符目录可以为不同设备提供差异化资源，这是适配平板设备的利器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Gradle构建系统目录剖析
现代Android开发离不开Gradle，相关目录值得特别关注：
code复制gradle/
└── wrapper/
├── gradle-wrapper.jar
└── gradle-wrapper.properties
这个不起眼的gradle-wrapper.properties文件决定了项目使用的Gradle版本。我遇到过无数次团队协作时因Gradle版本不一致导致的问题，建议将其版本号固定：
gradle复制distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-bin.zip
build.gradle文件是项目的构建脚本，分为项目级和模块级：
- 项目级：定义所有模块共享的配置
- 模块级：定义特定模块的依赖和构建选项
gradle复制// 模块级build.gradle典型配置
android {
compileSdkVersion 33
defaultConfig {
applicationId "com.example.myapp"
minSdkVersion 21
targetSdkVersion 33
}
}
dependencies {
implementation 'androidx.appcompat:appcompat:1.5.1'
}
3. 源码与测试目录的黄金组合
Android项目采用标准化的测试目录结构：
code复制src/
├── androidTest/ // 仪器化测试
├── main/ // 主代码
└── test/ // 单元测试
**仪器化测试(androidTest)需要运行在Android设备或模拟器上，适合测试UI交互。而单元测试(test)**可以在本地JVM上运行，速度更快。我的经验法则是：
- 业务逻辑用单元测试
- 视图相关用仪器化测试
- 两者比例保持在7:3左右
测试代码的组织应该镜像主代码结构。例如，如果有个com.example.login.LoginActivity，那么对应的测试类应该是com.example.login.LoginActivityTest。
4. 构建产物与缓存目录揭秘
build目录是Gradle构建时生成的临时文件存放处，包含：
- intermediates：中间编译结果
- outputs：最终生成的APK/AAB文件
- reports：Lint等检查报告
这个目录经常被开发者忽略，但实际上它藏着许多有用信息。比如当遇到构建失败时，查看build/reports/下的日志文件往往比IDE报错信息更详细。
.gradle目录包含Gradle的缓存文件，当遇到奇怪的构建问题时，删除此目录（Android Studio会自动重建）往往能解决问题。但要注意这会使下次构建变慢，因为需要重新下载依赖。
5. 版本控制必忽略目录
在.gitignore文件中，以下目录通常应该被忽略：
/build/.gradle/captureslocal.properties
但要注意保留gradle/wrapper/gradle-wrapper.properties，这是项目能正确构建的关键。
6. 多模块项目的目录艺术
大型Android项目通常会采用多模块结构，这时项目目录会变成这样：
code复制project/
├── feature-auth/
├── feature-payment/
├── library-core/
├── app/ // 主模块
└── build.gradle
每个功能模块都有自己的src、res和build.gradle文件。这种结构的好处是：
- 代码解耦更彻底
- 可以独立编译模块
- 团队协作更高效
我在实际项目中总结出一个技巧：将通用组件放在library-core模块，各功能模块通过implementation project(':library-core')方式引用。
7. 资源命名规范实践
混乱的资源命名是项目维护的噩梦。我遵循这些命名规则：
- 布局文件：
activity_、fragment_、item_前缀 - Drawable：
ic_图标、bg_背景、divider_分割线 - ID命名：控件类型缩写前缀，如
btn_login
例如：
xml复制<!-- 好例子 -->
<ImageView
android:id="@+id/iv_profile"
android:layout_width="48dp"
android:layout_height="48dp" />
<!-- 反例 -->
<ImageView
android:id="@+id/image1"
android:layout_width="48dp"
android:layout_height="48dp" />
8. 构建变体与源集目录
Gradle的构建变体功能可以创建不同版本的应用：
code复制src/
├── main/
├── demo/ // demo变体特有代码
└── full/ // full变体特有代码
在build.gradle中配置：
gradle复制android {
flavorDimensions "version"
productFlavors {
demo {
dimension "version"
}
full {
dimension "version"
}
}
}
这样在构建时可以选择构建demoDebug或fullRelease等不同变体。我在实际项目中使用这个功能来分离免费版和付费版代码。
9. 第三方库集成目录
libs目录用于存放本地jar/aar文件。现代Android开发更多使用Gradle依赖，但遇到特殊情况（如内部私有库）时仍需要这个目录。
集成.so库时要注意ABI分类：
code复制src/
└── main/
└── jniLibs/
├── arm64-v8a/
├── armeabi-v7a/
├── x86/
└── x86_64/
10. 现代化Android项目新成员
最近几年，Android项目目录中新增了一些重要成员：
compose/：Jetpack Compose组件proto/：Protocol Buffers定义文件navigation/：导航图XML文件
例如，使用Compose时，传统的res/layout会被compose/目录部分替代。但要注意，Compose和传统View系统可以共存。
在大型项目中，我通常会创建专门的features/目录来组织Compose组件：
code复制features/
├── login/
│ ├── LoginScreen.kt
│ └── LoginViewModel.kt
└── profile/
├── ProfileScreen.kt
└── ProfileViewModel.kt
这种按功能而非技术层划分的目录结构，在维护大型项目时优势明显。每个功能模块包含自己的UI、状态管理和业务逻辑，耦合度更低。