最近有在做关于Android底部多tab下，对应多个Flutter Fragment的操作。又遇到一个比较坑的问题:FlutterFragment中的flutter页面的SafeArea失效（关于safeArea具体介绍参考官方SafeArea class），简单举例说一下SafeArea的作用：如果你有一刘海屏的手机，如果你的flutter内容为全屏，假如你的内容在全屏最顶部，那么所谓的刘海将会盖住你所想要的内容，如下图所示：
这当然不是我们想要的，于是Flutter官方推出：SafeArea这个属性，在dart语言中只需要在你的widget最外层包裹SafeArea就好了。

1
2
3
4
5
6
7
8
9
@override
Widget build(BuildContext context) {
  return Scaffold(
    body: SafeArea(
      child: TabBarView(
        controller: mController,
        children: <Widget>[]
  );
}

于是得到了正确的展示效果，如下图所示：
在这里插入图片描述
你以为这样就完了么？在多个Flutter Fragment中SafeArea的作用失效，尽管我在flutter中设置了SafeArea，但依然存在刘海盖住flutter content的情况。

原因分析：

这真的是一件很头疼的事情，对应的Flutter page在Flutter Activity中能够正常work，但是偏偏在Fluttter Fragment中就出问题了呢？于是又去看FlutterView源码，果然有收获！发现一个方法：onApplyWindowInsets()这里面有一大堆逻辑，很多都是关于处理 statusBar以及navigationBar，更惊喜地还发现了处理DisplayCutout的逻辑，这不就是刘海屏相关的类么！以下是部分代码逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public final WindowInsets onApplyWindowInsets(WindowInsets insets) {
    ...
   if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
     int mask = 0;
     if (navigationBarVisible) {
       mask = mask | android.view.WindowInsets.Type.navigationBars();
     }
     if (statusBarVisible) {
       mask = mask | android.view.WindowInsets.Type.statusBars();
     }
    ...
     // TODO(garyq): Expose the full rects of the display cutout.
     // Take the max of the display cutout insets and existing padding to merge them
     DisplayCutout cutout = insets.getDisplayCutout();
     if (cutout != null) {
       Insets waterfallInsets = cutout.getWaterfallInsets();
       mMetrics.physicalPaddingTop =
           Math.max(
               Math.max(mMetrics.physicalPaddingTop, waterfallInsets.top),
               cutout.getSafeInsetTop());
      ...
     }
   } else {
     // Status bar (top) and left/right system insets should partially obscure the content
     // (padding).
   ...
   }

   updateViewportMetrics();
   return super.onApplyWindowInsets(insets);
 }

很明显这一块逻辑是处理刘海屏以及StatusBar相关的逻辑，于是进行相关的断点调试，发现FlutterFragment中的FlutterView的确是没有执行这个方法，对比同样在FlutterActivity中的FlutterView正常work并执行了这一串代码。

！那这不就神奇了么？这一下子又让人头秃了，这一定又是跟Fragment的相关机制导致的，自己对Fragment的具体处理逻辑不太熟，于是各种Google，找到两篇有点类似的答案：
1、fitsSystemWindows effect gone for fragments added via FragmentTransaction
2、一个Activity中添加多个Fragment导致fitsSystemWindows无效的问题

引入上面的解释说：

当第一个Fragment添加到Activity中的时候，Activity寻找出有fitsSystemWindows的子布局为其预留出状态栏的空间，其实就是设置一个padding，而其他Fragment添加到Activity中的时候，因为状态栏空间的适配已经被消费过一次了，Activity并不会再次去添加这个padding

虽然这里在进行fitsSystemWindows的操作，但是我们明确了一件事情：添加多个Fragment的时候，Activity对于padding相关操作只在第一个Fragment进行了相关处理逻辑。那么对应我们的FlutterFragment是否是同样的问题呢？？

于是我进行了尝试，将Flutter Fragment放在Acitvity第一个需要展示的Fragment，经过尝试发现第一个FlutterFragment能正常work了！但之后的Flutter Fragment问题依然存在，那么我们可以肯定也就是说：
在多FlutterFragment中的FlutterView，只有在作为Acitivty添加为第一个Fragment的情况下才会去调用 onApplyWindowInsets(WindowInsets insets) 方法去处理一些statusBar相关的操作逻辑。
的确事实如此，经过尝试之后发现的确只会调用一次，那么如何解决呢？

解决方案：

参照上面的解决方案，可以写一个WindowInsetsFrameLayout继承FrameLayout，并setOnHierarchyChangeListener()监听Fragment的添加操作，在添加的时候执行 view的requestApplyInsets();

当然对于我们的问题并没有这么麻烦，我们在自己的FlutterFragment中手动去执行flutterView.requestApplyInsets();只需要执行时机保证在flutter渲染之前执行（Safe Area通过获去Native端onApplyWindowInsets()中传过去的params来执行相关渲染）

但还有一个问题：flutterView.requestApplyInsets();只能在Api大于20中使用，那么低于20呢？与其说低于20，不如直接说，19中怎么处理（Android 4.4 api 19引入的透明状态栏 、沉浸式相关），我们可以看到，在onApplyWindowInsets() 中最终是发送一个事件到flutter端，如下代码所示。

1
2
3
4
5
6
7
8
9
10
11
12
private void sendViewportMetricsToFlutter() {
  if (!isAttachedToFlutterEngine()) {
    Log.w(
        TAG,
        "Tried to send viewport metrics from Android to Flutter but this "
            + "FlutterView was not attached to a FlutterEngine.");
    return;
  }

  viewportMetrics.devicePixelRatio = getResources().getDisplayMetrics().density;
  flutterEngine.getRenderer().setViewportMetrics(viewportMetrics);
}

那么对于Api 19就可以对相关数据进行反射调用，之后再讲数据发送到flutter端即可，那么大致逻辑如下所示：

1
2
3
4
5
6
7
8
public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) {
     super.onViewCreated(view, savedInstanceState);
     if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT_WATCH) {
         flutterView.requestApplyInsets();
     } else {
         adapterStatusBarBelowApi20();
     }
 }

总结：

1、这个问题在官方的FlutterFragment中也存在，但不知道为什么没有修复，可能他们真的不太重视混合开发吧，一心在纯flutter开发中。
2、关于为什么Fragment 相关操作逻辑只在第一个被Fragment被添加，这里涉及到了太多底层的东西，这里没有赘述，打算深入研究，写一篇新到blog中去介绍。
3、Flutter坑实在是太多了，很多问题都与Android原生机制相关，这不得不让人对原生系统机制进行深入学习。