object UserApi {
/**
- 获取个人中心数据
*/
fun getPersonCenterData(): GetRequest {
return HttpTool.get(ApiVersion.v1_0_0 + “authUser/myCenter”)
}
}
ApiVersion 全局管理目前项目中使用的所有 api 版本，应当定义在 common 组件的 api 路径下：
object ApiVersion {
const val v1_0_0 = “v1/”
const val v1_1_0 = “v1_1/”
const val v1_2_2 = “v1_2_2/”
}
entity
该路径下放 module 内部使用到的所有实体类（网络请求返回的数据类）。
对于所有从服务器获取的字段，全部定义在构造函数中，且实体类应当实现 Parcelable ，并使用 @Parcelize 注解。对于客户端使用而自己定义的字段，基本上定义为普通成员字段，并使用 @IgnoredOnParcel 注解，如果需要在界面间传递客户端定义的字段，可以将该字段定义在构造函数中，但是必须注明是客户端定义的字段。
示例如下：
@Parcelize
class ProductEntity(
// 产品名称
var name: String = “”,
// 产品图标
var icon: String = “”,
// 产品数量（客户端定义字段）
var count: Int = 0
) : Parcelable {
// 用户是否选择本产品
@IgnoredOnParcel
var isSelected = false
}
其中 name 和 icon 是从服务器获取的字段，而 count 和 isSelected 是客户端自己定义的字段。
event
该路径下放 module 内部使用的事件相关类。对于使用了 EventBus 及类似框架的项目，放事件类，对于使用了 LiveEventBus 的项目，里面只需要放一个类就好，比如：UserEvent：
object UserEvent {
/**
- 更新用户信息成功事件
*/
val updateUserInfoSuccessEvent: LiveEventBus.Event
get() = LiveEventBus.get(“user_update_user_info_success”)
}
注意：对于使用
LiveEventBus的项目，事件的命名必须用组件名作为前缀，防止事件名重复。
route
该路径下放 module 内部所使用到的界面路径和跳转方法，一般使用一个类就够了，比如：UserRoute：
object UserRoute {
// 关于界面
const val ABOUT = “/user/about”
// 常见问题（H5）
private const val FAQ = “FAQ/”
/**
- 跳转至关于界面
*/
fun toAbout(): RouteNavigation {
return RouteNavigation(ABOUT)
}
/**
- 跳转至常见问题（H5）
*/
fun toFAQ(): RouteNavigation? {
return RouteUtil.getServiceProvider(IH5Service::class.java)
?.toH5Activity(FAQ)
}
}
注意：对于组件内部会跳转的H5界面链接也应当写在路由类中。
provider
该路径下放对外部 module 提供的服务，一般使用一个类就够了。在 module-api 中是一个接口类，在 module-impl 中是该接口类的实现类。
目前采用 ARouter 作为组件化的框架，为了解耦，对其进行了封装，封装示例代码如下：
typealias Route = com.alibaba.android.arouter.facade.annotation.Route
object RouteUtil {
fun getServiceProvider(service: Class): T? {
return ARouter.getInstance().navigation(service)
}
}
class RouteNavigation(path: String) {
private val postcard = ARouter.getInstance().build(path)
fun param(key: String, value: Int): RouteNavigation {
postcard.withInt(key, value)
return this
}
…
}
示例
这里介绍如何在外部 module 和 user-impl 跳转至用户组件中的关于界面。
准备工作
在 user-impl 中创建路由类，编写关于界面的路由和服务路由及跳转至关于界面方法：
object UserRoute {
// 关于界面
const val ABOUT = “/user/about”
// 用户组件服务
const val USER_SERVICE = “/user/service”
/**
- 跳转至关于界面
*/
fun toAbout(): RouteNavigation {
return RouteNavigation(ABOUT)
}
}
在关于界面使用路由：
@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
最后
对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长。而不成体系的学习效果低效漫长且无助。时间久了，付出巨大的时间成本和努力，没有看到应有的效果，会气馁是再正常不过的。
所以学习一定要找到最适合自己的方式，有一个思路方法，不然不止浪费时间，更可能把未来发展都一起耽误了。
如果你是卡在缺少学习资源的瓶颈上，那么刚刚好我能帮到你。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
扫一扫
6680
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
