ViewPager2中Fragment应共享ViewModel还是单独创建？

结合你“抽屉选页+滑动切页”的交互需求、最多50个页面的业务规模，最优实现是基于ViewPager2做「宿主Activity存全局联动状态 + 每个章节列表Fragment持有独立专属ViewModel」的分层架构，既不会出现数据串扰问题，也完全适配50页面的规模上限。

• 所有Fragment共用同一个Activity级共享ViewModel的方案
  这个方案存在无法解决的逻辑矛盾：你当前实现的sections是通过switchMap(selectedPage)的全局单一数据源驱动的，一旦所有Fragment都绑定这同一个数据源，不管ViewPager2滑动到哪个位置，所有可见的Fragment都会渲染同一个selectedPage对应的章节列表，完全违背「每个页面对应独立章节列表」的核心需求，甚至会出现抽屉选中第1页、但滑动到第10页时两个页面显示同一份章节数据的错位问题。
• 每个Fragment完全独立创建ViewModel、不共享任何跨页面状态的方案
  这个方案虽然能解决数据串扰问题，但会凭空增加大量同步成本：比如用户从NavigationDrawer选中第37个页面时，你需要手动维护Page列表和页面位置的映射关系，跨层级通知对应位置的Fragment更新内容，还要自己处理页面配置变更、进程重建时的状态恢复逻辑，对开发经验尚浅的同学来说维护成本很高，很容易出状态不同步的bug。

你完全不需要担心50个页面超出ViewPager2的适用范围。ViewPager2从设计之初就适配长列表场景，和RecyclerView的回收机制完全一致：

• 它默认的离屏缓存机制，只会保留当前可见页前后相邻的少量Fragment实例，超出缓存范围的Fragment会被自动回收，对应的数据观察绑定也会同步解绑。哪怕总共有50个页面，运行时同时存活的Fragment最多也就2-3个，内存占用和你当前的单Fragment架构几乎没有差异，根本不会出现OOM问题。
• 你可以根据自己的滑动体验需求调整offscreenPageLimit参数，这个参数的设置和总页面数量无关，只会影响同时缓存的相邻页面数量，不会因为页面多就产生额外内存开销。

按照分层职责拆分架构，就能同时解决全局状态联动和页面数据独立的问题：

• 宿主Activity级的共享ViewModel只存放全局联动状态：比如全量页面列表pages、ViewPager2当前选中的页面位置、和NavigationDrawer同步的高亮选中态。用户操作抽屉选页时，只需要调用ViewPager2的setCurrentItem切换到对应位置；用户滑动页面时，只需要更新抽屉的选中高亮，不要在这里存放章节列表这类页面级的业务数据。
• 每个章节列表Fragment持有专属的ViewModel实例：创建Fragment时把当前对应的pageId通过Arguments传入，初始化ViewModel时把pageId作为构造参数，让每个Fragment的ViewModel独立通过pageRepository加载自己所属页面的章节列表，完全和其他页面的数据隔离，从根源上避免数据串扰。
• 优化重复查询开销：在pageRepository层加一层简单的内存缓存，同一个pageId的章节数据只做一次数据库/网络查询，后续所有需要加载这个页面章节的ViewModel都直接读缓存，既保证了每个Fragment的数据独立性，又不会产生重复查询的性能损耗。

内容的提问来源于stack exchange，提问作者Stefan Colic