Android开发入门：菜单选Activity还是Fragment？ViewModel使用相关疑问

1. 菜单实现选择：Activity还是Fragment？ #

优先选择Fragment实现，你的场景下优势非常明显：

• 所有菜单统一以Dashboard作为宿主Activity，跨菜单的关联数据不需要跨页面序列化传递，直接在宿主范围共享即可，避免了跨Activity传数据的冗余代码和出错风险。
• 子菜单嵌套更灵活：Fragment原生支持嵌套，你可以很方便的实现主菜单→子菜单的层级切换，不需要启动大量Activity造成任务栈管理混乱，也能做更流畅的页面切换动画。
• 后续扩展成本低：如果之后要适配平板、折叠屏的多窗格布局，Fragment可以直接复用，Activity实现的话几乎要重写一遍适配逻辑。
  如果坚持用Activity实现也能做，但你需要额外处理跨Activity数据共享、子页面回退逻辑的问题，投入产出比很低，除非你的某一个菜单功能完全独立和其他模块没有任何关联，否则不推荐。

2. ViewModel相关疑问解答 #

2.1 你的场景下ViewModel的作用 #

• 实现跨菜单的共享数据持有：你可以创建一个绑定Dashboard生命周期的ViewModel，所有菜单Fragment都可以拿到同一个ViewModel实例，菜单A录入更新后的数据直接存在ViewModel里，B、C不需要重新查询数据库就能拿到最新的关联数据，还可以通过LiveData/Flow实现数据变化的自动通知。
• 解耦数据逻辑和视图层：把数据库读写、数据加工的逻辑放到ViewModel里，避免Activity/Fragment里塞满业务代码，后续修改数据逻辑不需要改视图代码，可维护性更高。

2.2 不使用ViewModel，旋转屏幕会丢失数据库数据吗？ #

不会。已经成功写入数据库的持久化数据完全不受配置变更（包括旋转屏幕、切换系统深色模式等）的影响。
旋转屏幕时系统会销毁并重建当前的Activity/Fragment，只会丢失保存在内存中的临时数据：比如用户刚输入还没提交到数据库的内容、已经从数据库查询出来存在局部变量里的列表数据。如果你不用ViewModel，也可以通过onSaveInstanceState()机制保存这些临时数据，但如果数据量较大、结构复杂，实现成本会比ViewModel高很多。

2.3 Activity是否可以使用ViewModel？ #

ViewModel并不仅适用于Fragment，Activity完全可以关联对应的ViewModel。
你只需要在Activity中通过ViewModelProvider(this)获取ViewModel实例，该ViewModel的生命周期就会和当前Activity绑定，Activity因配置变更重建时ViewModel不会被销毁，存放在里面的数据可以直接复用。如果你最终选择用Activity实现各个菜单，每个菜单Activity都可以单独绑定自己的ViewModel，也可以用Application范围的ViewModel实现跨Activity的数据共享，但单Activity绑定专属ViewModel的方案更符合关注点分离的规范。

内容的提问来源于stack exchange，提问作者Lili Tre