前言

第一篇文章 Fragment 与 FragmentPagerAdapter
我应该算是详细叙述了Fragment与PagerAdapter的一些知识点，但那时候公司还没引进AndroidX的库，最近发现AndroidX与Support库下的PagerAdapter还是有些许区别，多个api都标上了 @Deprecate 。

所以这篇文章第一部分会先分析一下二者的区别。

第二部分则讲述ViewPager 与 Viewpager2的接口区别。

第三部为Viewpager2的解析。

一、AndroidX中FragmentPagerAdapter的变化

其中FragmentPagerAdapter和FragmentStatePagerAdapter的变化大同小异，就以FragmentPagerAdapter为例。

@Behavior

首先很明显的一点就是FragmentPagerAdapter的构造函数多了一个参数！

    @Retention(RetentionPolicy.SOURCE)
    @IntDef({BEHAVIOR_SET_USER_VISIBLE_HINT, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT})
    private @interface Behavior { }
  @Deprecated
  public FragmentPagerAdapter(@NonNull FragmentManager fm) {
        this(fm, BEHAVIOR_SET_USER_VISIBLE_HINT);
     * @param fm fragment manager that will interact with this adapter
     * @param behavior determines if only current fragments are in a resumed state
    public FragmentPagerAdapter(@NonNull FragmentManager fm,  @Behavior int behavior) {
        mFragmentManager = fm;
        mBehavior = behavior;
就是Behavior这个玩意，当其值为默认的BEHAVIOR_SET_USER_VISIBLE_HINT时，那么FragmentPagerAdapter的表现就会与原support库下一致，当为BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT时，那事情就会有点意思了！会影响ViewPager下Fragment的生命周期。
As we know （翻译：众所周知。知识点！），以前我们切换Fragment页面时，Adapter会调用fragement.setUserVisibleHint(boolean isVisibleToUser)来标志ViewPager的当前显示页面。而我们用getUserVisibleHint()来判断并执行懒加载。
就这几年开发经验来说，见过几个项目不同同事的关于ViewPager中不同的懒加载的处理，大多数是不处理！在onViewCreated()的时候，把当前页面以及两侧缓存的页面的数据都做了请求~没有一丝丝防备。。
当然这样写非常的简单，也不会出错，只是没必要，毕竟不少情况下，用户可能都不会去滑动ViewPager。所以作为一位码农，还是要有点追求的，何况这个问题处理起来也不难。
懒加载的三个判断：
是否为当前页面（是否可见）
是否已经加载过了
视图是否初始化完成（setUserVisibleHint()的调用在onCreateView之前！）
当然还可以加个是否强制刷新之类的~
    var hasLoad = false
    var isViewInitiated = false
    fun loadData() {
        if (userVisibleHint && !hasLoad && isViewInitiated) {
            // load
            hasLoad = true
    override fun setUserVisibleHint(isVisibleToUser: Boolean) {
        super.setUserVisibleHint(isVisibleToUser)
        loadData()
    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)
        isViewInitiated = true
        loadData()
      override fun onDestroyView() {
        super.onDestroyView()
         isViewInitiated = false // 注意考虑View被销毁，而Fragment对象还在
现在世道变了，BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT之下用的是Lifecycle
      public Object instantiateItem(@NonNull ViewGroup container, int position) {
        Fragment fragment = mFragmentManager.findFragmentByTag(name);
        if (fragment != mCurrentPrimaryItem) {
            fragment.setMenuVisibility(false);
            // 看这里
            if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
                mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.STARTED);
            } else {
                fragment.setUserVisibleHint(false);
        return fragment;
    @Override
    public void setPrimaryItem(@NonNull ViewGroup container, int position, @NonNull Object object) {
        Fragment fragment = (Fragment)object;
        if (fragment != mCurrentPrimaryItem) {
            if (mCurrentPrimaryItem != null) {
                mCurrentPrimaryItem.setMenuVisibility(false);
               // 看这里
                if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
                    if (mCurTransaction == null) {
                        mCurTransaction = mFragmentManager.beginTransaction();
                    mCurTransaction.setMaxLifecycle(mCurrentPrimaryItem, Lifecycle.State.STARTED);
                } else {
                    mCurrentPrimaryItem.setUserVisibleHint(false);
            fragment.setMenuVisibility(true);
            // 看这里
            if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
                if (mCurTransaction == null) {
                    mCurTransaction = mFragmentManager.beginTransaction();
                mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.RESUMED);
            } else {
                fragment.setUserVisibleHint(true);
            mCurrentPrimaryItem = fragment;
注意两个函数中的mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.RESUMED);

可发现初始化Fragment时，生命周期最大状态为STARTED。

而setPrimaryItem()设置当前的页面为RESUMED,  原先的页面改为STARTED
STARTED这个值意味着什么呢？
新建的Fragment生命周期在执行onActivityCreated()之后会继续执行onStrat() ，但不会执行onResume()！
而原先处于RESUME状态的则会执行onPause().
可以参考 ==> Lifecycle.State

setMaxLifecycle对Fragment周期的具体影响。
相信这时候，你应该有了如何改写懒加载的方法了！
    var hasLoad = false
    fun loadData() {
        if (hasLoad) {
            // load
            hasLoad = true
    override fun onResume() {
        super.onResume()
        loadData()
一个变量搞定。

so easy, mama never mind my study.

押韵就好 Never mind the details
二、述ViewPager 与 Viewpager2的区别。
ViewPager2发布好几个月咯（2019.11.20），这么香的控件不学习一波？

这一部分主要参考官网的文档。

viewpager2 版本迭代

viewpager2迁移指南
1. ViewPager2新增功能
1.0.0 的主要功能
对之前的 ViewPager 实现的改进：
RTL（从右向左）布局支持
 <androidx.viewpager2.widget.ViewPager2
     xmlns:android="http://schemas.android.com/apk/res/android"
     android:id="@+id/pager"
     android:layoutDirection="rtl"
垂直方向支持
android:orientation="vertical"
可靠的 Fragment 支持（包括处理 Fragment 的数据集）

运行时，notifyDatasetChanged（）来更新UI，正确的展示。
数据集更改动画（包括 DiffUtil 支持）
2. 接口变更
虽然 ViewPager2 保持了大多的  ViewPager的API的一致。但是总有一些必须改变，容我娓娓道来。
FragmentStateAdapter   << ==   FragmentStatePagerAdapter、FragmentPagerAdapter

是的，不用纠结了，统一使用FragmentStateAdapter
RecyclerView.Adapter << ==  PagerAdapter

你没有看错，就是RecycleView，还有熟悉的ViewHolder、onBindViewHodler()
FragmentStateAdapter#createFragment << == PagerAdapter#getItem

事实证明，以前的方法名称是过去出现问题的根源。使得不少新手在getItem()与instantiateItem()之间打交道时吃过亏。
getItemCount << == getCount
ViewPage2#registerOnPageChangeCallback << == addPageChangeListener

用抽象类替代接口，可以不用一次性override三个接口方法了，想用哪个就重载哪个
class ScreenSlidePagerAdapter(fa: FragmentActivity) : FragmentStateAdapter(fa) {
    override fun getItemCount(): Int = NUM_PAGES
    override fun createFragment(position: Int): Fragment = ScreenSlidePageFragment()
另外若使用了TabLayout

那记得升级material至1.1.0
implementation "com.google.android.material:material:1.1.0"
然后使用TabLayoutMediator
class CollectionDemoFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        val tabLayout = view.findViewById(R.id.tab_layout)
        TabLayoutMediator(tabLayout, viewPager) { tab, position ->
            tab.text = "OBJECT ${(position + 1)}"
        }.attach()
emmm... mama nerver...
三、 ViewPager2的解析
👌 终于到了重中之重的第三部分， == 让我来看下现在的时间，

好的，又是一周过去了，真是令人怀念这又浪费的一周的时光。

进入正题。

去年有天晚上闲着没事，我研究了一晚上的ViewPager源码，最后得出结论，我真是闲得蛋疼。简直毫无意义，各种view偏移量计算以及意义不明的变量，看得是真难受。
发现ViewPager2是RecycleView封装的之后，来了兴趣，于是又干起这无意义的事，研究ViewPager2的源码。幸亏，收获还是有的，源码也很通俗易懂，算上注释代码量也就1607行，原来的一半都不到！

真正进入正题~
里面的内容比起ViewPager是极简了。简单说就是将RecycleView再封装了一遍，然后协同FragmentStateAdapter将RecycleView的每个Item与Fragment绑定！
ending，happy~
别打脸，我继续说就是了。
看下ViewPager2的初始化。
ViewPager2中除了初始化的代码，其它值得关注的地方并不多。
    private void initialize(Context context, AttributeSet attrs) {
        mAccessibilityProvider = sFeatureEnhancedA11yEnabled
                ? new PageAwareAccessibilityProvider()
                : new BasicAccessibilityProvider();
        mRecyclerView = new RecyclerViewImpl(context);
        mRecyclerView.setId(ViewCompat.generateViewId());
        mRecyclerView.setDescendantFocusability(FOCUS_BEFORE_DESCENDANTS);
        mLayoutManager = new LinearLayoutManagerImpl(context);
        mRecyclerView.setLayoutManager(mLayoutManager);
        mRecyclerView.setScrollingTouchSlop(RecyclerView.TOUCH_SLOP_PAGING);
        setOrientation(context, attrs);
        mRecyclerView.setLayoutParams(
                new ViewGroup.LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
        mRecyclerView.addOnChildAttachStateChangeListener(enforceChildFillListener());
        // Create ScrollEventAdapter before attaching PagerSnapHelper to RecyclerView, because the
        // attach process calls PagerSnapHelperImpl.findSnapView, which uses the mScrollEventAdapter
        mScrollEventAdapter = new ScrollEventAdapter(this);
        // Create FakeDrag before attaching PagerSnapHelper, same reason as above
        mFakeDragger = new FakeDrag(this, mScrollEventAdapter, mRecyclerView);
        mPagerSnapHelper = new PagerSnapHelperImpl();
        mPagerSnapHelper.attachToRecyclerView(mRecyclerView);
        // Add mScrollEventAdapter after attaching mPagerSnapHelper to mRecyclerView, because we
        // don't want to respond on the events sent out during the attach process
        mRecyclerView.addOnScrollListener(mScrollEventAdapter);
        mPageChangeEventDispatcher = new CompositeOnPageChangeCallback(3);
        mScrollEventAdapter.setOnPageChangeCallback(mPageChangeEventDispatcher);
        // Callback that updates mCurrentItem after swipes. Also triggered in other cases, but in
        // all those cases mCurrentItem will only be overwritten with the same 
       // 删除几个设置各种事件监听的代码 
        attachViewToParent(mRecyclerView, 0, mRecyclerView.getLayoutParams());
其中mRecyclerView = new RecyclerViewImpl(context);和mLayoutManager = new LinearLayoutManagerImpl(context); 属于重新封装的RecyclerView和LinearLayoutManager，是分别为了处理事件拦截和ViewPager缓存页面的问题。
事件拦截我们结合mFakeDragger = new FakeDrag(this, mScrollEventAdapter, mRecyclerView); 来看。

FakeDragger模拟拖拽事件！通过设置 setUserInputEnabled(false)拦截用户触摸事件，那就得通过模拟拖拽来实现切换下一页了。
class RecyclerViewImpl  {
        public boolean onTouchEvent(MotionEvent event) {
            // isUserInputEnabled == false 则 不执行super.onTouchEvent(event)
            return isUserInputEnabled() && super.onTouchEvent(event);
        @Override
        public boolean onInterceptTouchEvent(MotionEvent ev) {
            // isUserInputEnabled == false 结合上面，就是，不拦截也不消费。
            // 所有事件直接分配给子View，若子View不消费，直接还给父View
            return isUserInputEnabled() && super.onInterceptTouchEvent(ev);
而mPagerSnapHelper = new PagerSnapHelperImpl();，PagerSnapHelper，即RecycleView的官方辅助类，则是为使得RecycleView的每个Item默认大小都是MATCH_PARENT，即每滑动一个就是一页，且不能快速滑动。
最终RecycleView成为ViewPager的子View
attachViewToParent(mRecyclerView, 0, mRecyclerView.getLayoutParams());
也就是这样使得RecycleView有了ViewPager的特性！

真的不能再简单了，去你的ViewPager源码。

RecycleView的知识，推荐这篇

看完这篇，面试RecyclerView的时候再也不怕了
当然这里没有涉及ViewPager2的具体api的使用，由于实践并不多，所以，还是推荐篇文章吧：

学不动也要学！深入了解ViewPager2
FragmentStateAdapter与ViewPager2
当然这里还要继续说下FragmentStateAdapter与ViewPager2是怎么玩的。而关键之处就是如何使ViewItem与Fragment绑定，使之拥有生命周期。
先看看熟悉这两个方法：
    @NonNull
    @Override
    public final FragmentViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
        return FragmentViewHolder.create(parent);
    @Override
    public final void onBindViewHolder(final @NonNull FragmentViewHolder holder, int position) {
        final long itemId = holder.getItemId();
        final int viewHolderId = holder.getContainer().getId();
        final Long boundItemId = itemForViewHolder(viewHolderId); // item currently bound to the VH
        if (boundItemId != null && boundItemId != itemId) {
            removeFragment(boundItemId);
            mItemIdToViewHolder.remove(boundItemId);
        mItemIdToViewHolder.put(itemId, viewHolderId); // this might overwrite an existing entry
        ensureFragment(position);
        /** Special case when {@link RecyclerView} decides to keep the {@link container}
         * attached to the window, but not to the view hierarchy (i.e. parent is null) */
         // 这里不是很懂了。指的是特殊情况下：container已经AttcahedToWindow，但是container.getParent() == null，需要重新绑定下Fragment。啥时候会发生这情况呢？
        final FrameLayout container = holder.getContainer();
        if (ViewCompat.isAttachedToWindow(container)) {
            if (container.getParent() != null) {
                throw new IllegalStateException("Design assumption violated.");
            container.addOnLayoutChangeListener(new View.OnLayoutChangeListener() {
                @Override
                public void onLayoutChange(View v, int left, int top, int right, int bottom,
                        int oldLeft, int oldTop, int oldRight, int oldBottom) {
                    if (container.getParent() != null) {
                        container.removeOnLayoutChangeListener(this);
                        placeFragmentInViewHolder(holder);
        gcFragments();
大致顺序解读下这两段代码.
1. 普普通通的FragmentViewHolder,
就是一个普通的仅有一个FrameLayout的Holder。

等待Fragment的视图在正确的时机被add进来。
 * {@link ViewHolder} implementation for handling {@link Fragment}s. Used in
 * {@link FragmentStateAdapter}.
public final class FragmentViewHolder extends ViewHolder {
    private FragmentViewHolder(@NonNull FrameLayout container) {
        super(container);
    @NonNull static FragmentViewHolder create(@NonNull ViewGroup parent) {
        FrameLayout container = new FrameLayout(parent.getContext());
        container.setLayoutParams(
                new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
                        ViewGroup.LayoutParams.MATCH_PARENT));
        container.setId(ViewCompat.generateViewId());
        container.setSaveEnabled(false);
        return new FragmentViewHolder(container);
    @NonNull FrameLayout getContainer() {
        return (FrameLayout) itemView;
2.  onBindViewHolder() 变量解析
开局就三个无知所谓的id，真叫人头大
       final long itemId = holder.getItemId();
        final int viewHolderId = holder.getContainer().getId();
        final Long boundItemId = itemForViewHolder(viewHolderId);   // 1
        if (boundItemId != null && boundItemId != itemId)  {
            removeFragment(boundItemId);
            mItemIdToViewHolder.remove(boundItemId);
        // 与注释1结合，boundItemId要么为null，要么等于itemId
        mItemIdToViewHolder.put(itemId, viewHolderId) 
先看下itemId的值是什么。

由于FragmentStateAdapter初始化时就调用了setHasStableIds(true)，使得holder.getItemId()返回的即为holder所在的位置。
class ViewHolder {
        public final long getItemId() {
            return mItemId;
class RecycleView.Adapter：   
    public final void bindViewHolder(@NonNull VH holder, int position) {
            holder.mPosition = position;
            if (hasStableIds()) {
                holder.mItemId = getItemId(position); // 看我看我
class FragmentStateAdapter extend RecycleView.Adapter {
    public FragmentStateAdapter(@NonNull FragmentManager fragmentManager,
            @NonNull Lifecycle lifecycle) {
        mFragmentManager = fragmentManager;
        mLifecycle = lifecycle;
         // 注意使用的super。因为这里FragmentStateAdapter覆盖了这个方法
         // 其实现是接直接抛出UnsupportedOperationException,并不想让你设置为false
        super.setHasStableIds(true); // 看我
    public long getItemId(int position) { // 看我
        return position;
所以也就是说itemId = holder.getItemId() = adapter.getItemId() = position
而至于viewHolderId就是ViewHolder中的FrameLayout的viewId。跟定义在xml中的固定值不一样了，这里每个ViewHolder的viewId都不相同。
container.setId(ViewCompat.generateViewId());
boundItemId则是 用于将  viewHolderId 保存在Adapter的LongSparseArray中所使用的Key值（位置），这个值在另外一个列表中同时也指向某个Fragment。实际上 保存的时候，最终值依然等于position。
3. 确定相应的Fragment，ensureFragment()
onBindViewHolder中还会继续执行这一步，根据缓存判断是否需要创建新的Fragment，并将之前回收Fragment的时保留的状态恢复回来。
    private void ensureFragment(int position) {
        long itemId = getItemId(position);
        if (!mFragments.containsKey(itemId)) {
            // TODO(133419201): check if a Fragment provided here is a new Fragment
            Fragment newFragment = createFragment(position);
            newFragment.setInitialSavedState(mSavedStates.get(itemId));
            mFragments.put(itemId, newFragment);  // itemId也对应着Fragment
4. ViewHolder与Fragment进行绑定与解除
除了上面onBindViewHolder中注释提到的特殊情况，一般是在这里进行绑定：
    public final void onViewAttachedToWindow(@NonNull final FragmentViewHolder holder) {
        placeFragmentInViewHolder(holder);
        gcFragments();
placeFragmentInViewHolder中的逻辑判断比较多，我就不贴代码了
大概就是 Fragment是否已经添加入FragmentManager，View是否销毁了.

否则执行：
class FragmentStateAdapter {
    placeFragmentInViewHolder() {
          mFragmentManager.beginTransaction()
                    .add(fragment, "f" + holder.getItemId())
                    .setMaxLifecycle(fragment, STARTED)  // 嘿嘿
                    .commitNow();
          //然后等待Fragment的View创建完成后， 添加到holder的FrameLayout上：
          mFragmentManager.registerFragmentLifecycleCallbacks(
                new FragmentManager.FragmentLifecycleCallbacks() {
                    // TODO(b/141956012): Suppressed during upgrade to AGP 3.6.
                    @SuppressWarnings("ReferenceEquality")
                    @Override
                    public void onFragmentViewCreated(@NonNull FragmentManager fm,
                            @NonNull Fragment f, @NonNull View v,
                            @Nullable Bundle savedInstanceState) {
                        if (f == fragment) {
                            fm.unregisterFragmentLifecycleCallbacks(this);
                            // 这里
                            addViewToContainer(v, container);
                }, false);
嘿，注意关键点！setMaxLifecycle(fragment, STARTED)  懒加载！

默认STARTED,跟ViewPager一样。

滑动页面时：
      public void onPageScrollStateChanged(int state) {
              updateFragmentMaxLifecycle(false);
会将当前的Fragent设置为RESUME，所以说起来ViewPager2的懒加载就跟AndroidX中的ViewPager一样咯。在onResume()中判断下是否已经加载过了就好了。
最后在onViewRecycled时 回收Fragment，保留状态。跟FragmentStatePagerAdapter很是相似了。
    @Override
    public final void onViewRecycled(@NonNull FragmentViewHolder holder) {
        final int viewHolderId = holder.getContainer().getId();
        final Long boundItemId = itemForViewHolder(viewHolderId); // item currently bound to the VH
        if (boundItemId != null) {
            removeFragment(boundItemId);
            mItemIdToViewHolder.remove(boundItemId);
到这里，就接近尾声了。

突然想起还有个玩意，还是要提一下的。
5. 页面缓存数量
    public void setOffscreenPageLimit(@OffscreenPageLimit int limit) {
        if (limit < 1 && limit != OFFSCREEN_PAGE_LIMIT_DEFAULT) {
            throw new IllegalArgumentException(
                    "Offscreen page limit must be OFFSCREEN_PAGE_LIMIT_DEFAULT or a number > 0");
        mOffscreenPageLimit = limit;
        // Trigger layout so prefetch happens through getExtraLayoutSize()
        mRecyclerView.requestLayout();
这里的OFFSCREEN_PAGE_LIMIT_DEFAULT默认值为-1，若调用该方法则不可设置小于1的情况。
上面我们提LinearLayoutManagerImp有设置页面缓存的作用，就是这里了：
    @Override
    protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,
            @NonNull int[] extraLayoutSpace) {
        int pageLimit = getOffscreenPageLimit();  // 看我看我
        if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
            // Only do custom prefetching of offscreen pages if requested
            super.calculateExtraLayoutSpace(state, extraLayoutSpace);
            return;
        final int offscreenSpace = getPageSize() * pageLimit;
        extraLayoutSpace[0] = offscreenSpace;  // 左右两边额外布局
        extraLayoutSpace[1] = offscreenSpace;
调用setOffscreenPageLimit使得RecycleView 预加载（绘制）了前后的页面。当其值为默认的OFFSCREEN_PAGE_LIMIT_DEFAULT时，则会依旧按照RecycleView的默认缓存机制进行。
另外，我们上面提了Fragment在onViewRecycled()时被销毁！注意，并不是onViewDetachedFromWindow, 也就是当前页面移出视野，且也不在PageLimit的范围内的时候，虽然View已经DetachedFromWindow，但并未执行onViewRecycled()，所以Fragment, 还是与这个View绑定的呢，毕竟，又滑回到这个页面时，并不会执行onBindViewHolder。

一般再多滑两页，这个Fragment才会被销毁。
这里引出一个思考，为什么不在onViewRecycled()对应的onBindViewHolder()中进行 ViewHolder与Fragment的绑定？

发现，在使用ViewPager2中，滑动页面会预加载执行onBindViewHolder()。看这份log，当前使用的setOffscreenPageLimit(1)
//打开页面
2020-03-07 18:19:12.298 I: createFragment 0
2020-03-07 18:19:12.299 I: onBindViewHolder 0
2020-03-07 18:19:12.300 I: onCreate 0
2020-03-07 18:19:12.300 I: onStart 0
2020-03-07 18:19:12.301 I: onResume 0
2020-03-07 18:19:12.302 I: createFragment 1
2020-03-07 18:19:12.303 I: onBindViewHolder 1
2020-03-07 18:19:12.303 I: onCreate 1
2020-03-07 18:19:12.303 I: onStart 1 // 初始化第一页和第二页，✔️
//这个时间点开始滑动切换第2页(注意，下标为1！)
2020-03-07 18:19:18.556 I: createFragment 2
2020-03-07 18:19:18.557 I: onBindViewHolder 2
2020-03-07 18:19:18.561 I: onCreate 2
2020-03-07 18:19:18.566 I: onStart 2
// 看这里，执行了第四页的onBindViewHolder！
2020-03-07 18:19:18.590 I: createFragment 3
2020-03-07 18:19:18.591 I: onBindViewHolder 3
2020-03-07 18:19:18.942 I: onPause 0
2020-03-07 18:19:18.943 I: onResume 1
// 切换至第三页，第四页的生命周期才被加载！
2020-03-07 18:31:35.898 I: onCreate 3
2020-03-07 18:31:35.900 I: onStart 3