VocabVerse背单词应用架构规划书

VocabVerse：Android 背单词应用架构规划书

   书接上回，前次我们详细分析了，对于我们项目开发需要哪些技能栈，并且我的组员也带着各人相识了一下，一个崭新的Android项目标文件结构怎么样子，各个文件有什么用处（请移步我的同组同学的文章：https://blog.csdn.net/2301_76298602/category_12912535.html）
  现在，根据以上条件，我们就可以根据我们本身的技能栈，搭建在这个崭新的项目里，开始我们的开发
  本篇介绍：①我们的技能栈需要的依赖，并且设置在gradle里。②我们的项目根据以上技能栈，怎么利用今世技能搭建我们本身的项目
  一、依赖项解释

1. Kotlin相关

• kotlinx-coroutines-android：Kotlin协程，用于简化异步操纵和线程管理
  
• kotlinx-serialization-json：Kotlin序列化库，用于JSON数据的序列化和反序列化
  

2. Android核心

• core-ktx：Kotlin扩展库，提供更简便的API
  
• core-splashscreen：实现今世化启动画面
  
• activity-compose：支持Compose的Activity
  

3. Jetpack Compose相关

• 各种Compose组件：构建今世化UI界面，包罗底子组件、Material3计划、动画等
  
• constraintlayout-compose：Compose中的约束结构
  
• accompanist系列：Compose的辅助库，处理体系UI控制和分页指示器等
  

4. 生命周期管理

• 各种lifecycle组件：管理Android生命周期，与Compose集成
  

5. 数据存储

• datastore-preferences：替代SharedPreferences的今世化数据存储方案
  
• room系列：SQLite对象映射库，用于本地数据库操纵
  

6. 导航

• navigation-compose：Compose的导航组件
  

7. 依赖注入

• hilt：简化依赖注入的库，基于Dagger但更简单易用
  

8. 媒体播放

• exoplayer：用于播放单词发音等音频
  

9. 测试相关

• 各种测试库：单位测试、UI测试、协程测试等
  
• mockk：Mocking库，用于测试
  
• robolectric：在JVM上运行Android测试
  

我们可以在app目次下的build.gradle里进行设置

在里面的dependencies字段可以初步设置（以下为网络提供，仅供参考）

1. dependencies {
2.     // Kotlin 扩展
3.     implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.4'
4.     implementation 'org.jetbrains.kotlinx:kotlinx-serialization-json:1.5.0'
6.     // AndroidX 核心
7.     implementation 'androidx.core:core-ktx:1.10.0'
8.     implementation "androidx.core:core-splashscreen:1.0.0"
9.     implementation 'androidx.activity:activity-compose:1.7.0'
10.     implementation 'com.google.android.material:material:1.8.0'
12.     // Jetpack Compose
13.     implementation platform("androidx.compose:compose-bom:2023.04.01") // 建议使用BOM管理版本
14.     implementation "androidx.compose.ui:ui"
15.     implementation "androidx.compose.ui:ui-tooling-preview"
16.     implementation "androidx.compose.material3:material3"
17.     implementation "androidx.compose.material3:material3-window-size-class"
18.     implementation "androidx.compose.animation:animation"
19.     implementation "androidx.constraintlayout:constraintlayout-compose:1.1.0-alpha09"
20.     implementation "androidx.navigation:navigation-compose:2.6.0-alpha09"
21.     implementation "androidx.lifecycle:lifecycle-runtime-compose:2.6.1"
22.     implementation "androidx.paging:paging-compose:1.0.0-alpha18"
24.     // Accompanist
25.     implementation 'com.google.accompanist:accompanist-systemuicontroller:0.30.0'
26.     implementation "com.google.accompanist:accompanist-pager-indicators:0.30.0"
28.     // Lifecycle
29.     implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.6.1'
30.     implementation "androidx.lifecycle:lifecycle-viewmodel-compose:2.6.1"
31.     implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:2.6.1"
32.     implementation "androidx.lifecycle:lifecycle-livedata-ktx:2.6.1"
33.     implementation "androidx.lifecycle:lifecycle-common-java8:2.6.1"
35.     // 数据存储
36.     implementation "androidx.datastore:datastore-preferences:1.0.0"
37.     implementation "androidx.room:room-runtime:2.5.1"
38.     implementation "androidx.room:room-ktx:2.5.1"
39.     implementation "androidx.room:room-paging:2.5.1"
40.     kapt "androidx.room:room-compiler:2.5.1"
42.     // 媒体
43.     implementation 'com.google.android.exoplayer:exoplayer-core:2.18.5'
45.     // DI (Hilt)
46.     implementation 'com.google.dagger:hilt-android:2.45'
47.     kapt 'com.google.dagger:hilt-compiler:2.45'
48.     implementation 'androidx.hilt:hilt-navigation-compose:1.0.0'
50.     // 测试
51.     testImplementation 'junit:junit:4.13.2'
52.     androidTestImplementation 'androidx.test.ext:junit:1.1.5'
53.     androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
54.     testImplementation 'org.jetbrains.kotlinx:kotlinx-coroutines-test:1.6.4'
55.     androidTestImplementation "androidx.compose.ui:ui-test-junit4"
56.     debugImplementation "androidx.compose.ui:ui-tooling"
57.     debugImplementation "androidx.compose.ui:ui-test-manifest"
58.     testImplementation "androidx.room:room-testing:2.5.1"
59.    
60.     // Hilt 测试
61.     androidTestImplementation 'com.google.dagger:hilt-android-testing:2.45'
62.     kaptAndroidTest 'com.google.dagger:hilt-compiler:2.45'
63.     testImplementation 'com.google.dagger:hilt-android-testing:2.45'
64.     kaptTest 'com.google.dagger:hilt-compiler:2.45'
65.    
66.     // Mocking
67.     testImplementation 'io.mockk:mockk-android:1.13.4'
68.     testImplementation 'io.mockk:mockk-agent:1.13.4'
69.     testImplementation "org.robolectric:robolectric:4.9.2"
70. }

复制代码

值得注意的是
目前有一种新的声明依赖的方式：版本目次（Version Catalogs）
这两种依赖声明方式的重要区别在于 依赖管理机制 和 代码组织方式：
方式示例说明直接字符串声明implementation 'androidx.core:core-ktx:1.10.0'直接在build.gradle中硬编码依赖坐标版本目次（Version Catalogs）implementation(libs.androidx.core.ktx)通过libs.xxx引用集中管理的依赖 版本目次（Version Catalogs） 版本号单点维护，修改时只需更新TOML文件

采取什么风格，取决于您本身的喜好。
重点介绍一个开发组件库：Jetpack

Jetpack 是 Google 官方推出的一套 Android 开发组件库，旨在帮助开发者更高效地构建 高质量、稳定且可维护 的 Android 应用。它并不是一个单一框架，而是由多个独立的库（如 ViewModel、Room、Navigation、Compose 等）组成的工具聚集，覆盖了今世 Android 开发的各个方面。
Jetpack 的核心组件
Jetpack 重要分为 4 大类，每类办理差异题目：
类别代表组件作用FoundationAppCompat、Android KTX、Multidex提供向后兼容、Kotlin 扩展支持等底子功能ArchitectureViewModel、LiveData、Room、DataBinding帮助实现 MVVM/Clean Architecture，管理数据、生命周期和持久化BehaviorNavigation、WorkManager、Permissions处理导航、背景任务、权限等常见举动UICompose、Material Design、Paging简化 UI 开发，提供声明式界面（Compose）、分页加载等

为什么今世 Android 开发都用 Jetpack？
类型内容1办理传统 Android 开发的痛点生命周期管理复杂：Activity/Fragment 的生命周期容易导致内存泄漏（如旋转屏幕时数据丢失）。2标准化架构（MVVM + Clean Architecture）Jetpack 的架构组件（如 ViewModel、Repository、Room）天然支持 MVVM 和 Clean Architecture，让代码： 分层清晰（UI、Domain、Data 层分离） 可测试性高（业务逻辑不依赖 Android 框架） 维护成本低（减少耦合，易于扩展）3提拔开发效率用 Kotlin 代码写界面，比 XML 更灵活，减少 50% 以上的 UI 代码量。同一管理页面跳转，制止 Fragment 事件的复杂性。4兼容性与稳定性例如 AppCompat 让新特性（如深色模式）在旧体系上也能运行。5目前就能想到这么多… Jetpack 的核心优势
优势说明减少样板代码如 Room 自动生成数据库代码，Compose 替代 XML标准化架构逼迫使用最佳实践（如单向数据流、状态管理）提高稳定性制止内存泄漏、崩溃（如 LiveData 自动感知生命周期）跨版本兼容新特性（如深色模式、分屏）在旧 Android 版本上也能使用无缝协作组件之间高度集成（如 ViewModel + Navigation + Compose）

经典 Jetpack 技能栈示例

1. // 1. UI 层（Jetpack Compose）
2. @Composable
3. fun UserScreen(viewModel: UserViewModel = viewModel()) {
4.     val userState by viewModel.userState.collectAsState()
5.     // 声明式 UI
6. }
8. // 2. ViewModel（架构组件）
9. class UserViewModel @Inject constructor(
10.     private val getUserUseCase: GetUserUseCase // Domain 层用例
11. ) : ViewModel() {
12.     val userState = mutableStateOf<User?>(null)
13.     fun loadUser() {
14.         viewModelScope.launch {
15.             userState.value = getUserUseCase()
16.         }
17.     }
18. }
20. // 3. Data 层（Room + Retrofit）
21. @Entity
22. data class User(@PrimaryKey val id: Int, val name: String)
24. @Dao
25. interface UserDao {
26.     @Query("SELECT * FROM user")
27.     suspend fun getUsers(): List<User>
28. }
30. // 4. 依赖注入（Hilt）
31. @Module
32. @InstallIn(SingletonComponent::class)
33. object AppModule {
34.     @Provides
35.     fun provideUserDao(db: AppDatabase): UserDao = db.userDao()
36. }

复制代码

---

总结：为什么用 Jetpack？

• 标准化架构：制止“意大利面条式”代码，逼迫最佳实践。
  
• 高效开发：减少 30%~50% 的样板代码（如数据库、UI、导航）。
  
• 稳定可靠：Google 官方维护，办理传统 Android 开发的痛点（生命周期、内存泄漏）。
  
• 面向未来：Compose 代表声明式 UI 的未来，Kotlin 优先。
  

如果你的项目还没用 Jetpack，现在迁移正是时候！

二、架构规划书

我们可以对安卓开发官网进行阅读，来相识今世常用的开发结构
1. 架构选择：MVVM + Clean Architecture

采取MVVM模式结合Clean Architecture的分层计划，缘故起因：
MVVM (Model-View-ViewModel) 与 Clean Architecture 的结合是一种今世软件开发架构模式，它将界面逻辑与业务逻辑分离，同时保持代码的可测试性、可维护性和可扩展性。

1)重要好处

• 关注点分离：清晰划分UI、业务逻辑和数据访问层
  
• 可测试性：各层可独立测试，特别是业务逻辑不依赖UI框架
  
• 可维护性：代码结构清晰，易于理解和修改
  
• 可扩展性：各层独立演化，修改一层不影响其他层
  
• 团队协作：差异团队可并行开发差异层
  
• 框架独立性：业务逻辑不绑定特定UI框架，易于迁移
  
• Jetpack组件友爱：天然适配ViewModel、LiveData/Flow等组件
  

2)典范分层结构

• 表示层 (Presentation Layer)：MVVM模式(View + ViewModel)
  
• 领域层 (Domain Layer)：业务逻辑和实体
  
• 数据层 (Data Layer)：数据获取和持久化实现
  

我们详细相识一下这个结构
2. 分层架构计划

1) 体现层 (Presentation Layer)

• 组件：Activity + Compose UI + ViewModel
  
• 职责：处理UI展示和用户交互
  
• 技能栈：
  
  
  
  • Jetpack Compose构建UI
    
  • ViewModel管理UI状态
    
  • Hilt注入依赖
    
  • Navigation处理页面跳转
    
  
  

2) 领域层 (Domain Layer)

• 组件：Use Cases (Interactors)
  
• 职责：包罗核心业务逻辑和规则
  
• 特点：
  
  
  
  • 纯Kotlin代码，不依赖Android框架
    
  • 每个用例代表一个详细的业务操纵
    
  • 和谐数据层的操纵
    
  
  

3) 数据层 (Data Layer)

• 组件：Repository实现 + 数据源
  
• 职责：数据获取和持久化
  
• 子层：
  
  
  
  • Repository：同一数据访问接口
    
  • 本地数据源：Room数据库、DataStore
    
  • 远程数据源：(未来可扩展)API调用
    
  
  
• 技能栈：
  
  
  
  • Room处理本地数据库
    
  • DataStore处理简单设置
    
  • Kotlin协程处理异步操纵
    
  
  

3. 详细模块计划（初步制定，可能根据版本更迭而调整）

1. app/
2. ├── data/
3. │   ├── local/          # 本地数据源
4. │   │   ├── dao/        # Room DAO接口
5. │   │   ├── entity/     # 数据库实体
6. │   │   └── AppDatabase.kt
7. │   ├── repository/     # 仓库实现
8. │   └── model/          # 数据模型
9. ├── domain/
10. │   ├── model/          # 领域模型
11. │   ├── repository/     # 仓库接口
12. │   └── usecase/        # 业务用例
13. ├── presentation/
14. │   ├── component/      # 可复用Compose组件
15. │   ├── screen/         # 各功能屏幕
16. │   ├── theme/          # 应用主题
17. │   ├── navigation/     # 导航配置
18. │   └── viewmodel/      # ViewModel
19. └── di/                 # 依赖注入配置

复制代码

举例子：
在 我们的项目中，有个核心功能，即AI生成四格漫画，那么在Clean Architecture条理中，将 AI 画图功能 划分取决于它的脚色和功能。
每个部分应该放在哪一层？

• Domain 层（核心业务逻辑）
  
  
  
  • 如果 AI 画图是核心业务逻辑的一部分（例如，背单词时自动生成相关图片辅助记忆），那么它的 接口定义（如 AiImageGenerator）可以放在 Domain 层，但 详细实现 不能放在这里。
    
  • Domain 层只包罗抽象接口，例如：
    
    1. interface AiImageGenerator {
    2.     suspend fun generateImage(prompt: String): Result<Bitmap>
    3. }

    复制代码
  • 如许，Domain 层不依赖详细实现（如 DeepSeek API），保持框架无关性。
    
  
  
• Data 层（详细实现）
  
  
  
  • 实际的 API 调用、网络请求、数据处理 应该在 Data 层 实现，例如：
    1. class DeepSeekImageGenerator @Inject constructor(
    2.     private val apiService: DeepSeekApiService
    3. ) : AiImageGenerator {
    4.     override suspend fun generateImage(prompt: String): Result<Bitmap> {
    5.         // 调用 DeepSeek API，并返回 Bitmap
    6.     }
    7. }

    复制代码
  • 这里可以引入 Retrofit、OkHttp 等网络库。
    
  
  
• Presentation 层（UI 交互）
  
  
  
  • ViewModel 调用 Domain 层的 AiImageGenerator，但不关心详细实现。
    
  • Compose UI 负责显示生成的图片。
    
  
  

依赖关系

1. Presentation (UI) → Domain (接口) ← Data (实现)

复制代码

• Domain 层 定义接口（AiImageGenerator），供 ViewModel 使用。
  
• Data 层 提供详细实现（DeepSeekImageGenerator），并通过 依赖注入（Dagger Hilt） 提供给 Domain 层。
  

结论
AiImageGenerator 接口定义放在 Domain 层（由于它属于业务逻辑）。
DeepSeekImageGenerator 实现放在 Data 层（由于它依赖网络请求）。
ViewModel 调用 Domain 接口，不关心详细实现。
如许计划符合 Clean Architecture 的 依赖倒置原则（DIP），使代码更灵活、可测试、易维护。
4. 关键技能实现方案

1) 数据持久化

• 单词数据：使用Room存储单词、词库、学习记录等
  
• 用户偏好：使用DataStore存储用户设置、学习进度等
  

2) 状态管理

• 使用StateFlow/SharedFlow + ViewModel管理UI状态
  
• Compose中使用collectAsState()收集状态
  

3) 依赖注入

• 使用Hilt同一管理依赖
  
• 各层通过构造函数注入所需依赖
  

4) 导航

可以类比为Vue项目里的router功能

• 使用Navigation Compose实现单Activity架构
  
• 通过ViewModel共享导航状态
  

5. 科学性与优势

• 关注点分离：各层职责单一，符合SOLID原则
  
• 可测试性：
  
  
  
  • 领域层可单独测试
    
  • 数据层可mock测试
    
  • UI层可仪器化测试
    
  
  
• 可维护性：模块化计划，修改一处不影响其他部分
  
• 可扩展性：
  
  
  
  • 易于添加新功能
    
  • 未来可轻松接入网络数据源
    
  
  
• Jetpack最佳实践：完全遵循Google推荐的今世Android开发模式
  

6. 开发流程

• 先计划数据模子和数据库结构
  
• 实现底子堆栈接口
  
• 编写核心业务用例
  
• 开发UI组件
  
• 毗连各层，实现完整功能
  
• 编写单位测试和UI测试
  

这种架构经过大量生产项目验证，是当前Android开发的最佳实践之一，能够确保应用的稳定性、可维护性和可扩展性。
使用Navigation Compose实现单Activity架构

• 通过ViewModel共享导航状态
  

5. 科学性与优势

• 关注点分离：各层职责单一，符合SOLID原则
  
• 可测试性：
  
  
  
  • 领域层可单独测试
    
  • 数据层可mock测试
    
  • UI层可仪器化测试
    
  
  
• 可维护性：模块化计划，修改一处不影响其他部分
  
• 可扩展性：
  
  
  
  • 易于添加新功能
    
  • 未来可轻松接入网络数据源
    
  
  
• Jetpack最佳实践：完全遵循Google推荐的今世Android开发模式
  

6. 开发流程

• 先计划数据模子和数据库结构
  
• 实现底子堆栈接口
  
• 编写核心业务用例
  
• 开发UI组件
  
• 毗连各层，实现完整功能
  
• 编写单位测试和UI测试
  

这种架构经过大量生产项目验证，是当前Android开发的最佳实践之一，能够确保应用的稳定性、可维护性和可扩展性。
今天就到这里。以上图片和额外资料均来自安卓开发官网（https://developer.android.com/?hl=zh-cn）

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。