演示apk下载地址
本项目全部使用jetpack相关技术方案实现，充分借鉴单一可信数据源设计方案(如下图所示)，UI视图接触到的全部数据仅和ROOM数据库相关，
即ROOM中的数据就是这个单一可信来源（更多见官方描述），
摒弃EventBus处处监听处处触发的数据源不确定性问题，并借助依赖注入进一步降低代码之间的耦合。
代码结构上严格遵循MVVM设计架构，包结构上data包作为数据提供者即Model层，ui包作为视图展示块即View层，viewmodel包作为ViewModel层 连接View层和Model层。另外di包是依赖注入相关包，所有依赖注入相关的Component、Module等都在该包中；works包属于WorkManager，用于 后台定期清理用户搜索记录存储的多余记录任务等。
数据请求方面运用ROOM作为数据缓存方案，错误发生时统一重试及结合Paging3的重试刷新特性构建重试方案，以及失败重新启用ROOM本地数据。 账号模块充分利用ROOM支持LiveData特性，使得数据驱动视图，充分替代RxJava。
目前存在的可能优化部分是：数据源Repository仍然使用的是线程池操作异步逻辑，可以考虑使用LifecycleScope或ViewModelScope代替 （目前代码中涉及列表的Paging3都是通过这种方式实现），以及依赖注入可以考虑使用更容易上手的Hilt。
见Paging包， PagingSource属于仅网络数据方案；RemoteMediator属于网络数据结合本地ROOM缓存方案
见MergeCall版NetworkBoundResource
MergeCall的主要目的是解决某个页面某些数据需要多次向服务端发起请求的问题，例如首页的文章列表中，包含了置顶文章，但服务端提供了两个不同的接口， 因此需要合并这两个接口及数据，简化UI层的使用。
ViewModel配合Repository的使用； ViewModel共享数据实践(Fragment与Activity共享同一个ViewModel，见Fragment)、 Activity及 共享ViewModel
依赖注入本身属于Application内部维护一个Map集合管理Activity的Injector；而Activity相似地维护一个Map管理其内部的Fragment的Injector。
Navigation中由于目前其官方实现方案是使用replace fragment方式，因此出现的结果是首页结合NavigationBottomView切换过程中fragment会重新创建实例， 因此Fragment本身的内部view的状态及相关数据会被重置，需要通过ViewModel暂存，相关问题见 issues 530, 目前实现方案是自定义Navigator，替换系统的replace方案，见 WanAndroidNavigator
在test文件夹下的network包内。单元测试模拟数据存放在resources目录下， 同时通过往OkHttp中添加interceptor，并设置从resources目录下读取的json数据作为返回值。测试时需要注意确保AppExecutor是外界设置， 同时针对RetrofitCall类型的需要修改Retrofit的callback回调线程调度器，具体见代码。