一种清晰, 便于扩展android项目架构方案，2024年最新算法面试经典100题及答案-CSDN博客

本文链接：https://blog.csdn.net/2401_84141304/article/details/137628260

UserLocalDataSource
IUserRemoteDataSource
IUserLocalDataSource
IAppConfigRemoteDataSource
IAppConfigLocalDataSource
AppConfigRepository
UserRepository
util
view
base
BaseActivity
BaseFragment
BaseViewModel
hybrid
features 下面是按业务来分组
login
ui
xxxActivity
xxxViewModelFactory
xxxViewModel 可直接调用core/data里的UserRepository
product
data 考虑到同一个模块中的数据层面可以共用，故放在外层
model
ProductListInfo
ProductDetailInfo
datasource
IProductLocalDataSource
IProductRemoteDataSource
impl
ProductLocalDataSourceImpl
ProductRemoteDataSourceImpl
ProductRepository
ui
detail
view 放置自定义View
ProductLabelView
ProductDetailActivity
ProductDetailViewModel
list
rendermodel
view 放置自定义View
…
ProductListViewModel (和ProductDetailViewModel 都调用ProductRepository来获取数据)
…
xxxViewModelFactory如果业务简单, ViewModelFactory可以写在这里, detail模块和list可以共用
personal
data
ui
xxxViewModelFactory
xxxViewModel此处可能需要获取用户信息，则直接调用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
@Override
public T create(@NonNull Class modelClass) {
if (modelClass.isAssignableFrom(LoginViewModel.class)) {
return (T) new LoginViewModel(LoginRepository.getInstance(new LoginDataSource()));
} else {
throw new IllegalArgumentException(“Unknown ViewModel class”);
}
}
}

LiveData

在数据发生变化时，需要通知给页面。通常可以采用接口的方工去做，但如果要观察的数据很多，就需要定义大量的接口，代码会十分冗余。为此, Google提供了LiveData组件，它是一个可被观察的数据容器类，将数据包装起来，使数据成为被观察者，当该数据发生变化时，观察者能获得通知。

ViewModel是用来存储数据，LiveData的作用是在ViewModel发生变化时通知页面。因此, LiveData通常放在ViewModel中使用，用于包装ViewModel中那些需要被外界观察的数据。

我们来结合具体的例子（登录）看这三者的配合使用

示例

UI层面(LoginActivity)

protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
binding = ActivityLoginBinding.inflate(getLayoutInflater());
setContentView(binding.getRoot());
…
viewModel = new ViewModelProvider(this, new LoginViewModelFactory()).get(LoginViewModel.class);
registerObserver();
bindClickEvent();

}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。