初次接触时可能对于ViewModel的定义会把握不准好。以上面的架构为例，以上的结构虽然是基于Jetpack套件来实现的，但对于开发而言，并没有必要纠结于Jetpack, 比如上面提到的ViewModel，其实如果项目中没有用到Jetpack, 我们也是可以采用这种架构方案去写代码。可以将ViewModel就理解成一个中间层，一个业务处理层。再直白一点，就是一个java类,该类的作用便是用来分担一部份Activity/Fragment的工作，同时与数据层面打交道，拿到数据后再传给View层。
采用以上架构，我们在开发一个功能时，可以很清晰的去组织代码。但这种方式，只能保证某个业务维度，某个功能点相关的代码是清晰的，好维护的。对于整个项目而言，我们该如何架构整个项目呢？
项目层面
对于一个小型的项目，由于代码量少，业务通常不复杂，没有过多的考虑整体代码的组织，结构的管理也不会给后期的维护带来很大的负担，毕竟代码量少，后期维护的成本相对较低，但对于一个中大型项目，代码组织混乱，对后期的维护人员来讲就是灾难。此处引入的方案是参看这篇文章，我把做了一些改动，引入到公司里某一款app开发上，大家反馈都很不错，开发体验大大提升。
我们先来看一下这篇文章提到的方案，作者有把示例代码上传到github上，其地址在这里。 其目录结构如下：
作者将功能与项目的基础架构的代码分离开。整个工程分为core和features两个包，core下面放的是整个工程的基础代码。将业务进行分类组织在features目录下，这样便将代码按照功能模块的维度组织起来。某个功能(如login)相关的代码都会在features.login下面。其好处：
- 代码的结构更加清晰，后面维护方便
- 后期如果业务起来了，想要做组件化，因为代码都在同一个目录下面，抽取出去也更加方便。
细化
再回到Google推荐的架构图，我们再将Google推荐的这个架构整合进项目中，于是，项目的结构便如下所示:
com.xxxx.app
core整个app内所有模块共享，或公共的配置data全局的数据访问，如用户信息，app配置等modelAppConfigInfoUserInfodatasourceimplAppConfigRemoteDataSourceAppConfigLocalDataSourceUserRemoteDataSourceUserLocalDataSourceIUserRemoteDataSourceIUserLocalDataSourceIAppConfigRemoteDataSourceIAppConfigLocalDataSourceAppConfigRepositoryUserRepositoryutilviewbaseBaseActivityBaseFragmentBaseViewModelhybridfeatures下面是按业务来分组loginuixxxActivityxxxViewModelFactoryxxxViewModel可直接调用core/data里的UserRepositoryproductdata考虑到同一个模块中的数据层面可以共用，故放在外层modelProductListInfoProductDetailInfodatasourceIProductLocalDataSourceIProductRemoteDataSourceimplProductLocalDataSourceImplProductRemoteDataSourceImplProductRepositoryuidetailview放置自定义ViewProductLabelViewProductDetailActivityProductDetailViewModellistrendermodelview放置自定义View- …
ProductListViewModel(和ProductDetailViewModel都调用ProductRepository来获取数据)- …
xxxViewModelFactory如果业务简单,ViewModelFactory可以写在这里, detail模块和list可以共用personaldatauixxxViewModelFactoryxxxViewModel此处可能需要获取用户信息，则直接调用core/data里的UserRepository
以下对上面的结构进行说明
core 目录
服务于整个工程，一些基础代码。关于系统配置，用户信息等数据的操作全部放在这个里面。
data目录：DAO相关的操作，model包下面的是pojo， 数据的获取或持久化全部由xxxRepository去调用datasource包下面的数据源去实现util目录：放置一些公共的工具类view目录: 放置公共的自定义view，这些自定义view脱离具体的业务联系,能够在各业务模块使用base目录：用来放置一些基础的组件，如BaseActivity,BaseFragment,BaseViewModel
features目录
按业务模块来划分不同的包，组织在该目录下。以下对代码的组织做一些说明
login模块
在上面的目录中，由于涉及到用户登录相关的DAO操作都已经放到core目录下了, 假设可以满足要求，那么login模块下只有UI相关文件和ViewModel,xxxViewModelFactory
product模块
这个模块是用来模拟某个模块下多个页面的场景。以商品列表页和详情页为例。由于DAO的操作可能会有重叠的场景，这里将它们的数据操作写在一起。UI层面按功能再分为list, detail两个包。list, detail两个页面的ViewModel可以采用同一个ViewModelFactory来创建。
rendermodel包：这个目录下有一个需要单独说明一下，当我们从服务器拿到数据了如ProductInfo之后，将数据显示在页面上，我们显示在页面上的一些信息很有可能是需要根据ProductInfo的数据进行加工的。为此，我们定义一个ProductInfoRenderModel.java用来承载只需要显示在页面上的数据。ProductInfoRenderModel.java则放在rendermodel包下面。
personal模块
personal模块中也会涉及到用户相关的信息，这也就是为什么一开始设计把用户相关信息的dao操作放到core目录下。personal模块下的xxViewModel如果要查用户相关的信息，可以直接调用core下面的UserRepository
至此，整个项目的大体架构便梳理完成了。采用这种方案将代码以功能模块进行划分，方便后期的维护。既使后续某个模块中进行了技术方案的改革，也能保证其影响的粒度最小。当然这里面主要是为了说明项目的主要结构，在实际项目中，除了这些，我们还会有adapter, 自己写的各种工具等等，这个就根据实际情况再自己分包了。接下来我们看一下涉及到的相关技术栈
技术栈
在这种项目架构中我们主要用到的技术栈有Jetpack中的ViewModel, ViewModelFactory, LiveData, ROOM，下面简单介绍一下这几种技术以及它们之间的整合。当然用于网络请求相关的我们可以用Okhttp, retrofit，此处就不介绍。
ViewModel
Jetpack组件中提供了ViewModel可以方便的将数据，对象与组件的生命周期绑定起来，方便进行组件间的数据共享，如一个activity中多fragment的情况。同时它可以有效的从架构层面上进行解藕，和mvp架构模式相比，可以大大减少接口/方法的个数。以登录为例，用户调用登录接口时需要调用presenter.login方法，login成功后调用 view.loginSuccess方法。而采用ViewMode后，用户在登录时调用viewModel.login方法，登录成功后，更新ViewModel中的LiveData，然后在调用处观察LiveData做相应的行为就可以。
ViewModelProvider.Factory
用来创建ViewModel,ViewModel不可以自己创建，必须要借助ViewModelProvider.Factory来创建。在创建时通常为ViewModel指定数据仓库，如下:
public class LoginViewModelFactory implements ViewModelProvider.Factory {
@NonNull
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
最后
文章所有资料全部已经打包整理好，另外小编手头上整理了大量Android架构师全套学习资料，Android核心高级技术PDF文档+全套高级学习资料+视频+2021 BAT 大厂面试真题解析
资料展示：
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
SsXQXg-1712800822233)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-EmmDS4zD-1712800822234)]
818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
