安卓现代化开发系列——从生命周期到Lifecycle【扩展包1已更新】-2
https://developer.aliyun.com/article/1398230
扩展内容：
1、MaxLifecycle
在ViewPager和ViewPager2这类可以操作Fragment的框架中，存在着一个重要的特性就是离屏缓存，即offscreenPageLimit，这个特性的作用是在当前可见的元素两侧，缓存多少不可见的元素。
这个机制有利于ViewPager在滑动过程中保持丝滑，因为当元素还未可见的时候，就提前加载并添加到视图树中。
下图展示的就是离屏缓存为1的情况，屏幕左侧的Fragment提前被加载。
但是这个机制却导致Fragment的生命周期与其可见度产生了冲突。
对于Activity来说，当它进入到Resumed状态后，开发者可以轻易认为当前的Activity对于用户是「可见」的。但是对于处于ViewPager的离屏缓存区域的Fragment来说，虽然他们被加载出来并进入了Resumed状态，但是实际上用户是看不见这些Fragment（上图的黄色Fragment）。这就导致了生命周期与可见性产生了不同步的问题，毕竟Resumed的定义就是可以看见并可以操作的意思。
下面简单用一个例子来演示这个问题：
上面的代码中虽然代码量不少，但是逻辑极其简单，就是构造一个ViewPager，同时带有5个Fragment，我们为每一个Fragment添加生命周期监听。
当初次进入的时候，ViewPager处于第1个位置，但是我们看一下日志：
当前位置:0进入了ON_CREATE
当前位置:0进入了ON_START
当前位置:1进入了ON_CREATE
当前位置:0进入了ON_RESUME
当前位置:1进入了ON_START
当前位置:1进入了ON_RESUME
可以看见的是，虽然当前只有第1个位置的Fragment可见，然而第2个位置的Fragment却进入了onResume，这个就是上面提到的离屏缓存的机制导致的。这导致在业务上我们没办法单纯通过Fragment的生命周期来判断是否被用户可见。
对于这个问题，谷歌为Fragment增加了一个setUserVisibleHint(Boolean)的方法来解决上述的问题。开发者可以手动通过调用这个方法来修改Fragment的可见度。需要注意的是，这个机制只是一个简单的「标记」，它并不能实际决定Fragment是否对于用户可见。
于是ViewPager在页面跳转的时候，会主动去修改那些Fragment的UserVisibleHint，开发者则可以根据这个值来判断Fragment是否可见。
长期以来，开发者确实能够使用这个机制去解决ViewPager场景下的可见度问题。
但是复盘之后可以发现，这个简单的标记位也有不少缺陷：
- 缺乏统一的访问入口，子控件难以取值
- 与生命周期原本的设计产生偏移，增加维护难度
- 难以监听
于是谷歌在新版的Fragment中，对源码进行了优化，增加了一个「MaxLifecycle」的机制。
一直以来，Fragment的生命周期都是没法直接设置的，只能通过FragmentManager对Fragment进行操作来间接控制，虽然「MaxLifecycle」也没法直接控制，但是给Fragment的生命周期控制增加了一层约束。
如果理解「MaxLifecycle」呢？简单来说就是最大的生命周期。
还记得生命周期是有大小的吗？它们从Created、Started、Resumed依次增大。
如果开发者把某个Fragment的最大生命周期设置为Started，这意味着此Fragment永远不会到达Resumed，哪怕它满足了原本应该到达Resumed的条件，而是最多停留在Started。
我们看看如果使用「MaxLifecycle」这个机制的简单使用：
和传统的FragmentManager一样，开发者只需要在commit之前，额外调用setMaxLifecycle()即可。
依照上图的设置之后，哪怕新添加的Fragment马上可见了，他的生命周期也只会停留在Started。
MaxLifecycle对解决ViewPager导致的Fragment的可见性问题有什么实际性意义呢？
意义非常重大，我们复盘一下导致这个问题的原因：
- 当
Fragment被ViewPager通过FragmentManager加入到视图树中时，在可见的Fragment两侧（实际就是屏幕意外）会因为离屏缓存的机制存在「用户不可见，但是进入了Resumed」的Fragment。
因此问题的根源就是Fragment在用户仍为看到它的时候就”提前“进入了Resumed，如果我们能够让它不可见的时候，限制在Started，那问题不就解决了么？
实际上ViewPager就是这样做的，在新版ViewPager中适配了这个机制：
ViewPager的常用Adapter之一FragmentStatePagerAdapter可以看到，新增了一个构造函数，可以传入Behavior：
BEHAVIOR_SET_USER_VISIBLE_HINT：原版Adapter的行为，Fragment在用户可见与不可见状态切换时，将调用Fragment的setUserVisibleHint(Boolean)来修改可见标记。BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT：新版行为，使用setMaxLifecycle(Fragment,Lifecycle.State)来限制Fragment的最大生命周期。当Fragment处于ViewPager的不可见状态时，最大生命周期限制为Started。
我们从代码中可以看出端倪：
setPrimaryItem()是PagerAdapter切换Item的核心方法，每次切换Item的时候，Adapter先是「将之前显示的Fragment设置为不可见」，然后「将即将显示的Fragment设置为可见」。
但是设置的手段却不一样，从代码中看出，不同的Behavior有不同的设置手段，新版是通过设置MaxLifecycle，而旧版则是之前的VisibleHint。
因此，开发者只需要在使用ViewPager的时候，构建Adapter时将Behavior改为新版即可。
只有ViewPager需要单独设置，对于ViewPager2来说并不需要额外设置，它默认就是新版的MaxLifecycle机制。
回到一开始的代码，调用FragmentStatePagerAdapter的第二个构造函数，将Behavior改为新版。
可以预期的是，在设置后，处于不可见状态的Fragment将不会进入Resumed状态，大致情况如下图所示：
日志如下：
当前位置:0进入了ON_CREATE
当前位置:0进入了ON_START
当前位置:1进入了ON_CREATE
当前位置:1进入了ON_START
当前位置:0进入了ON_RESUME
初始状态下，用户看到的是第1个Fragment，由于离屏缓存的机制，第2个Fragment也被加载并纳入视图树了，但是由于它被ViewPager设置了MaxLifecycle为Started，因此ViewPager在没有发生移动的情况下，它的生命周期被限制在了Started。
滑动ViewPager至第2页，我们再观察日志：
当前位置:2进入了ON_CREATE
当前位置:2进入了ON_START
当前位置:0进入了ON_PAUSE
当前位置:1进入了ON_RESUME
第1个Fragment由于不可见，进入了Paused，第2个Fragment由于滑动导致可见了，从Started变为了Resumed。
为什么第3个Fragment也会发生生命周期变化呢，其实就是离屏缓存在起作用，同时MaxLifecycle也发挥了作用，此刻它的生命周期被限制在了Started。
在使用了MaxLifecycle之后，开发者可以统一使用生命周期来管理Fragment的首次加载，代码如下：
总结：自此关于MaxLifecycle的作用已经全部讲解完毕了，通过设置MaxLifecycle开发者可以避免Fragment出现生命周期与实际可见不一致的问题，而官方提供的ViewPager已经默认实现，非常的方便。
