在关于界面使用路由：
@Route(path = UserRoute.ABOUT)
class AboutActivity : MyBaseActivity() {
…
}
在 user-api 中定义跳转界面方法：
interface IUserService : IServiceProvider {
/**
- 跳转至关于界面
*/
fun toAbout(): RouteNavigation
}
在 user-impl 中实现跳转界面方法：
@Route(path = UserRoute.USER_SERVICE)
class UserServiceImpl : IUserService {
override fun toAbout(): RouteNavigation {
return UserRoute.toAbout()
}
}
界面跳转
在 user-impl 中可以直接跳转到关于界面：
UserRoute.toAbout().navigation(this)
假设 module-a 需要跳转到关于界面，那么先在 module-a 中配置依赖：
dependencies {
…
implementation project(‘:user-api’)
}
在 module-a 中使用 provider 跳转到关于界面：
RouteUtil.getServiceProvider(IUserService::class.java)
?.toAbout()
?.navigation(this)
module依赖关系
此时各个 module 的依赖关系如下：
common：基础库、第三方库
user-api：common
user-impl：common、user-api
module-a：common、user-api
App壳：common、user-api、user-impl、module-a、…
tool
该路径下放 module 内部使用的工具方法，一般一个类就够了，比如：UserTool：
object UserTool {
/**
-
该用户是否是会员
-
@param gradeId 会员等级id
*/
fun isMembership(gradeId: Int): Boolean {
return gradeId > 0
}
}
cache
该路径下放 module 使用的缓存方法，一般一个类就够了，比如：UserCache：
object UserCache {
// 搜索历史记录列表
var searchHistoryList: ArrayList
get() {
val cacheStr = CacheTool.userCache.getString(SEARCH_HISTORY_LIST)
return if (cacheStr == null) {
ArrayList()
} else {
JsonUtil.parseArray(cacheStr, String::class.java) ?: ArrayList()
}
}
set(value) {
CacheTool.userCache.put(SEARCH_HISTORY_LIST, JsonUtil.toJson(value))
}
// 搜索历史记录列表
private const val SEARCH_HISTORY_LIST = “user_search_history_list”
}
注意：
- 缓存Key的命名必须用组件名作为前缀，防止缓存Key重复。
CacheTool.userCache并不是指用户组件的缓存，而是用户的缓存，即当前登录账号的缓存，每个账号会单独存一份数据，相互之间没有干扰。与之对应的是CacheTool.globalCache，全局缓存，所有的账号会共用一份数据。
module-api 中放的都是外部组件需要的，或者说外部组件和 module-impl 都需要的，其他的都应当放在 module-impl 中，对于外部组件需要的但是能通过 provider 方式提供的，都应当把具体的实现放在 module-impl 中，module-api 中只是放一个接口方法。
下表列举项目开发中哪些东西能否放 module-api 中：
| 类型 | 能否放 module-api | 备注 |
| — | — | — |
| 功能界面(Activity、Fragment、Dialog) | 不能 | 通过 provider 方式提供使用 |
| 基类界面 | 部分能 | 外部 module 需要使用的可以，其他的放 module-impl 中 |
| adapter | 部分能 | 外部 module 需要使用的可以，其他的放 module-impl 中 |
| provider | 部分能 | 只能放接口类，实现类放 module-impl 中 |
| tool | 部分能 | 外部 module 需要使用的可以，其他的放 module-impl 中 |
| api、route、cache | 不能 | 通过 provider 方式提供使用 |
| entity | 部分能 | 外部 module 需要使用的可以，其他的放 module-impl 中 |
| event | 部分能 | 对使用 EventBus 及类似框架的项目，外部组件需要的可以，其他还是放 module-impl 中 |
| 对于使用了 LiveEventBus 的项目不能，通过 provider 方式提供使用 | | |
| 资源文件和资源变量 | 部分能 | 需要在 xml 文件中使用的可以， 其他的通过 provider 方式提供使用 |
注意：如果仅在
module-impl中存在工具类，则该工具类命名为xxTool。如果module-api和module-impl都存在工具类，则module-api中的命名为xxTool，module-impl中的命名为xxTool2。
在开发过程中，为了查看运行效果，需要运行整个App，比较麻烦，而且可能依赖的其他组件也在开发中，App可能运行不到当前开发的组件。为此可以采用组件单独调试的模式进行开发，减少其他组件的干扰，等开发完成后再切换回 library 的模式。
在组件单独调试模式下，可以增加一些额外的代码来方便开发和调试，比如新增一个入口 Actvity，作为组件单独运行时的第一个界面。
示例
这里介绍在 user-impl 中进行组件单独调试。
在项目根目录下的 gradle.properties 文件中新增变量 isDebugModule，通过该变量控制是否进行组件单独调试：
组件单独调试开关，为ture时进行组件单独调试
isDebugModule = false
在 user-impl 的 build.gradle 的顶部增加以下代码来控制 user-impl 在 Applicaton 和 Library 之间进行切换：
if (isDebugModule.toBoolean()) {
apply plugin: ‘com.android.application’
} else {
apply plugin: ‘com.android.library’
}
在 user-impl 的 src/main 的目录下创建两个文件夹 release 和 debug，release 中放 library 模式下的 AndroidManifest.xml，debug 放 application 模式下的 AndroidManifest.xml、代码和资源，如下图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LRO54CaZ-1625141825138)(//upload-images.jianshu.io/upload_images/19542624-42350721a4d958ed.png?imageMogr2/auto-orient/strip|imageView2/2/w/376/format/webp)]
在 user-impl 的 build.gradle 中配置上面的创建的代码和资源路径：
android {
…
sourceSets {
if (isDebugModule.toBoolean()) {
main.manifest.srcFile ‘src/main/debug/AndroidManifest.xml’
main.java.srcDirs += ‘src/main/debug’
main.res.srcDirs += ‘src/main/debug’
} else {
main.manifest.srcFile ‘src/main/release/AndroidManifest.xml’
}
}
}
注意：完成上述配置后，在
library模式下，debug中的代码和资源不会合并到项目中。
最后在 user-impl 的 build.gradle 中配置 applicationId：
android {
defaultConfig {
if (isDebugModule.toBoolean()) {
applicationId “cc.tarylorzhang.demo”
}
…
}
}
注意：如果碰到65536的问题，在 user-impl 的 build.gradle 中新增以下配置：
android {
defaultConfig {
…
if (isDebugModule.toBoolean()) {
multiDexEnabled true
}
}
}
以上工作都完成后，将 isDebugModule 的值改为 true，则可以开始单独调试用户组件。
module名
组件名如果是单个单词的，直接使用该单词 + api 或 impl 的后缀作为 module 名，如果是多个单词的，多个单词小写使用 - 字符作为连接符，然后在其基础上加 api 或 impl 的后缀作为 module 名。
示例
用户组件(User)，它的 module 名为 user-api 和 user-impl；会员卡组件(MembershipCard)，它的 module 名为 membership-card-api 和 membership-card-impl。
包名
在应用的 applicationId 的基础上增加组件名后缀作为组件基础包名。
在代码中的包名 module-api 和 module-impl 都直接使用基础包名即可，但是在 Android 中项目 AndroidManifest.xml 文件中的 package 不能重复，否则编译不通过。所以 module-impl 中的 package 使用基础包名，而 module-impl 中的 package 使用基础包名 + api 后缀。
package 重复的时候，会报 Type package.BuildConfig is defined multiple times 的错误。
示例
应用的 applicationId 为 cc.taylorzhang.demo，对于用户组件(user)，组件基础包名为 cc.taylorzhang.demo.user，则实际包名如下表：
| | 代码中的包名 | AndroidManifest.xml中的包名 |
| — | — | — |
| user-api | cc.taylorzhang.demo.user | cc.taylorzhang.demo.userapi |
| user-impl | cc.taylorzhang.demo.user | cc.taylorzhang.demo.user |
对于多单词的会员卡组件(MembershipCard)，其组件基础包名为 cc.taylorzhang.demo.membershipcard。
资源文件和资源变量
所有的资源文件：布局文件、图片等全部要增加组件名作为前缀，所有的资源变量：字符串、颜色等也全部要增加组件名作为前缀，防止资源名重复。
示例
-
用户组件(
User)，关于界面布局文件命名为：user_activity_about.xml； -
用户组件(
User)，关于界面标题字符串命名为：user_about_title； -
会员卡组件(
MembershipCard)，会员卡详情界面布局文件，文件名为：membership_card_activity_detail； -
会员卡组件(
MembershipCard)，会员卡详情界面标题字符串，文件名为：membership_card_detail_title；
类名
对于类名没必要增加前缀，比如 UserAboutActivity，因为对资源文件和资源变量增加前缀主要是为了避免重复定义资源导致资源被覆盖的问题，而上面的包名命名规范已经避免了类重复的问题，直接命名 AboutActivity 即可。
App 环境一般分为开发、测试和生产环境，不同环境下使用的网络请求地址大概率是不一样的，甚至一些UI都不一样，在打包的时候手动修改很容易有遗漏，产生不必要的 BUG。应当使用 buildConfigField 在打包的时候将当前环境写入 App 中，在代码中根据读取环境变量，根据不同的环境执行不同的操作。
示例
准备工作
在 App 壳 的 build.gradle 中给每个buildType 都配置 APP_ENV：
android {
…
buildTypes {
debug {
buildConfigField “String”, “APP_ENV”, ‘“dev”’
…
}
release {
buildConfigField “String”, “APP_ENV”, ‘“release”’
…
}
ctest {
initWith release
buildConfigField “String”, “APP_ENV”, ‘“test”’
matchingFallbacks = [‘release’]
}
}
}
注意：测试环境的
buildType不能使用test作为名字，Android Studio会报ERROR: BuildType names cannot start with 'test'，这里在test前增加了一个c。
在 common 的 tool 路径下创建一个App环境工具类：
object AppEnvTool {
/** 开发环境 */
const val APP_ENV_DEV = “dev”
/** 测试环境 */
const val APP_ENV_TEST = “test”
/** 生产环境 */
const val APP_ENV_RELEASE = “release”
/** 当前App环境，默认为开发环境 */
private var curAppEnv = APP_ENV_DEV
fun init(env: String) {
curAppEnv = env
}
/** 当前是否处于开发环境 */
val isDev: Boolean
get() = curAppEnv == APP_ENV_DEV
/** 当前是否处于测试环境 */
val isTest: Boolean
get() = curAppEnv == APP_ENV_TEST
/** 当前是否处于生产环境 */
val isRelease: Boolean
get() = curAppEnv == APP_ENV_RELEASE
}
在 Application 中初始化App环境工具类：
class DemoApplication : Application() {
override fun onCreate() {
super.onCreate()
// 初始化App环境工具类
AppEnvTool.init(BuildConfig.APP_ENV)
…
}
}
使用App环境工具类
这里介绍根据App环境使用不同的网络请求地址：
object CommonApi {
// api开发环境地址
private const val API_DEV_URL = “https://demodev.taylorzhang.cc/api/”
// api测试环境地址
private const val API_TEST_URL = “https://demotest.taylorzhang.cc/api/”
// api生产环境地址
private const val API_RELEASE_URL = “https://demo.taylorzhang.cc/api/”
// api地址
val API_URL = getUrlByEnv(API_DEV_URL, API_TEST_URL, API_RELEASE_URL)
// H5开发环境地址
private const val H5_DEV_URL = “https://demodev.taylorzhang.cc/m/”
// H5测试环境地址
private const val H5_TEST_URL = “https://demotest.taylorzhang.cc/m/”
// H5生产环境地址
private const val H5_RELEASE_URL = “https://demo.taylorzhang.cc/m/”
// H5地址
val H5_URL = getUrlByEnv(H5_DEV_URL, H5_TEST_URL, H5_RELEASE_URL)
private fun getUrlByEnv(devUrl: String, testUrl: String, releaseUrl: String): String {
return when {
AppEnvTool.isDev -> devUrl
AppEnvTool.isTest -> testUrl
else -> releaseUrl
}
}
}
打包
通过不同的命令打包，打出对应的App环境包：
打开发环境包
./gradlew clean assembleDebug
打测试环境包
./gradlew clean assembleCtest
打生产环境包
./gradlew clean assembleRelease
项目中的 module 变多之后，如果要修改第三方库和App使用的SDK版本是一件很蛋疼的事情。应当建立一个配置文件进行管理，其他地方使用配置文件中设置的版本。
示例
在项目根目录下创建一个配置文件 config.gradle，里面放版本信息：
ext {
compile_sdk_version = 28
min_sdk_version = 17
target_sdk_version = 28
arouter_compiler_version = ‘1.2.2’
}
在项目根目录下的 build.gradle 文件中的最上方使用以下代码引入配置文件：
apply from: “config.gradle”
创建 module 后，修改该 module 中的 build.gradle 文件，将 SDK 版本默认值换成配置文件中的变量，按需添加第三方依赖，并使用 $ + 配置文件中的变量作为第三方库的版本：
android {
…
compileSdkVersion compile_sdk_version
defaultConfig {
…
minSdkVersion min_sdk_version
targetSdkVersion target_sdk_version
}
}
dependencies {
…
kapt “com.alibaba:arouter-compiler:$arouter_compiler_version”
}
混淆文件不应该在 App 壳中集中定义，应当在每个 module 中各自定义自己的混淆。
示例
这里介绍配置 user-impl 的混淆，先在 user-impl 的 build.gradle 中配置消费者混淆文件：
android {
defaultConfig {
…
consumerProguardFiles ‘proguard-rules.pro’
}
}
在 proguard-rules.pro 文件中写入该 module 的混淆：
实体类
-keepclassmembers class cc.taylorzhang.demo.user.entity.** { *; }
组件化开发应当遵守"高内聚，低耦合"的原则，尽量少的对外暴露细节。如果用一句话来总结的话，就是代码和资源能放 module-impl 里面的就都放在 module-impl，因为代码隔离问题实在不能放 module-impl 里面的才放 module-api，最后因为涉及到循环依赖问题的才往 common 中放。
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
** { *; }
组件化开发应当遵守"高内聚，低耦合"的原则，尽量少的对外暴露细节。如果用一句话来总结的话，就是代码和资源能放 module-impl 里面的就都放在 module-impl，因为代码隔离问题实在不能放 module-impl 里面的才放 module-api，最后因为涉及到循环依赖问题的才往 common 中放。
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-dJpV1yfV-1715877135320)]
[外链图片转存中…(img-ghu4FzUe-1715877135322)]
[外链图片转存中…(img-DoT6k7TF-1715877135323)]
[外链图片转存中…(img-8vEHjjvU-1715877135324)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
