百里路海2022-04-20实体层中的密封类定义中，Loading为什么用 object 而不是 data class，之前也在其他地方看过这种用法，没理解是有什么特别含义还是二者皆可混用，还请解惑。作者回复: 这里取决于你是否需要通过Loading来传递数据，如果不需要传递的话，为了节省内容，全局使用同一个内存对象，这会更好一些。
6
魏全运2022-04-13MVVM+Clean架构的组合使得原先在VM里的数据处理逻辑转移到了usecase，这样VM的逻辑更加精简且清晰，并且由于clean架构的引入，数据层的代码将更加可测。但是，clean架构的缺点也很明显：代码臃肿、结构复杂。实际项目中很少会使用clean架构来实现一个业务模块。作者回复: 赞~
4
飓风2022-05-05usecase的好处感觉可以单元测试，一般我都是省去了直接在viewmodel单独定义一个suspend方法用来做单元测试，不知道还有没有其他好的方案可以对viewmodel做单元测试作者回复: “不知道还有没有其他好的方案可以对viewmodel做单元测试”，有的，只是比较麻烦，三言两语很难说清楚，你可以去看看官方文档。
2
sunlight2022-05-05想请教下老师，一般view中对应一个viewModel还是多个viewModel，这个有统一标准吗作者回复: 没有标准，但大部分情况是一一对应。viewModel可以跟Activity一一对应，也可以跟Fragment一一对应。但涉及到共用逻辑的时候，同一个viewModel可以对应多个Fragment、甚至多个Activity。
共 3 条评论2
Paul Shan2022-04-13MVVM和Clean架构的融合，相对于原来逻辑都在Activity里，实现了较好的分层，单元测试也容易多了。相对于MVP架构，MVVM架构避免了presenter和view里面来回穿梭的调用，简化了逻辑，而且得到谷歌较好的支持。MVVM架构在Android系统中的问题是，Andorid应用多是UI重度型应用，UI中的逻辑太多，分层解决的主要是非UI部分的代码，对于UI部分的分层，方法论层面就没有系统的支持，实践中的自动化测试也很不方便。Jetpack Compose在一定程度上，提供了UI模块化的解决方案，但是自动化测试也远比非UI的单元测试要复杂。这方面我不太熟，期待老师将来的精彩讲解。作者回复: 很棒的见解~Android的测试部分确实比较难，以后我会找机会在我的博客里分享的。
共 2 条评论2- sunlight2022-05-17还有其他这么好的Android课程推荐么，这门课程收获很多。最近没东西看了。。
作者回复: 那就来看看我的技术博客吧：“朱涛的自习室”。
1 
Geek_Adr2022-04-21我理解 解决复杂问题通用方法就是拆分或者说是分层，不管是MVVM或是Clean都是分层方法的一种，如何选择主要看复杂度。MVP或MVVM 可以理解为UI交互与业务逻辑 对等复杂度的分法，MVVM与Clean混合架构更重业务逻辑轻UI交互的分法，所以优点：应用在复杂业务场景合适，缺点：分层本身就需要理解，带来额外复杂度。HelloWorld 直写就好作者回复: 很棒的答案，赞~
1
杨小妞2022-04-13个人理解：对于数据处理不是很复杂的场景，UseCase一般用得很少，直接在vm完成数据请求处理然后就抛出去了。 有一个设想，对于UI很复杂的页面，将其粗略拆分成上、中、下三个Delegate（包含UI+业务），这样Activity任务处理就能减轻不少。作者回复: 是的，这个理解很不错。
1- Geek_12f95b2022-04-29老师，问下你这个架构图 用啥软件画的呀
作者回复: 基本上都是PPT做的。
ZircoN2022-04-13usecase google推荐是封装复杂逻辑或者逻辑复用时使用，正常情况如上面例子是可以去掉这一层的。作者回复: 是的，简单业务场景就显得有些多余。