如何让 Android 的前端页面像 iOS 一样“优雅”？

作者:方英杰（崇之）

最近在调研前端页面适配 Android 端异形屏的方案，调研过程中发现了一些比较有意思的点，本文主要是做一个总结。

一、提出问题

首先，我们需要知道 Android 上的前端适配面临着什么问题。

问题其实很简单，和原生 UI 视图相比，前端页面无法直接获取到设备的部分控件信息，如状态栏高度、导航栏高度等，假如设备是异形屏，还意味着前端不知道挖孔/刘海的位置、尺寸等信息。因此如果前端页面是一个全屏的页面，就会面临着内容会被这些控件遮挡的风险。

同样是移动端设备，iOS 是怎么做的呢？

实际上，早在 iOS 11 时期，Apple 就针对前端推出了一个 safe-area-inset-* 的概念，它作为一组四个环境变量，在 WebKit 中提供。前端可以通过 env() 函数或是 constant() 函数（已废弃）来获取到对应的值，这四个值代表着前端页面在四个方向上需要留出的 Padding，遵循此配置就能保证前端页面不会被其他控件遮挡。下文中我们统一把这个能力称为 Safe Area。

由于 iOS 这项能力支持的早，加上 Apple 新系统的覆盖率一向很高，所以前端的适配推进的很快。以钉钉为例，目前钉钉内的前端页面在 iOS 上的显示效果比起 Android 上要明显好得多。

Android 效果

iOS 效果

那么 Android 这边有没有类似的东西呢？

实际上，在 iOS 推出这个特性之后，其他比较主流的浏览器内核都相继跟进了这个能力。我们知道 Android 上实际使用的是 Chromium 内核来支撑前端内容显示的（原生方案），其从 69 版本开始已经支持了这个能力。而对于像是钉钉使用的 UC 内核，从 3.0 开始也对此做了支持。

既然都已经支持了，为什么 Android 这边还是无法做到对齐 iOS 的效果呢？

首先就是浏览器内核版本限制，我们知道 Android 的 Chromium 内核是打包在一个独立应用里的，可以单独更新，这样做的好处是内核有什么重要的新特性或安全修复可以马上升级上去，不用跟随长周期的系统更新做升级。因此造成了 Chromium 内核在 Android 各个品牌手机上的版本存在比较严重的碎片化问题，也就导致了我们完全无法保证一些系统版本较低的机器上面带的内核足够支持我们想要的能力。

其次就是 Android 系统的这个 Safe Area 的能力有 bug，它提供的值总是会诡异的变成 0，这就导致了虽然浏览器内核早早提供了这项能力，但是存在一定的稳定性问题。

最后就是即使这个能力在 Android 上生效了，最终所展现的效果却不一定是我们想要的。下面这张截图就很好的体现了这一点。在横屏状态下只有左侧有值，而没有给顶部的状态栏区域留出足够的 Padding。

所以为什么明明是在 iOS 上信手拈来的事，到了 Android 上就各种翻车呢，我觉得找到 Android 系统侧是怎么提供 Safe Area 的值很重要。

二、分析问题

下面是 Android 侧对 Safe Area 支持的底层实现分析过程。

我们使用的 WebView 位于 webkit 包下，但实际上这个包在 Android4.4 就已经废弃了，实际的能力是通过委托到 WebViewProvider 来实现的，这点从 WebView 的注释以及方法中的实际调用就能看出来。

// Implementation notes.// The WebView is a thin API class that delegates its public API to a backend WebViewProvider// class instance. WebView extends {@link AbsoluteLayout} for backward compatibility reasons.// Methods are delegated to the provider implementation: all public API methods introduced in this// file are fully delegated, whereas public and protected methods from the View base classes are// only delegated where a specific need exists for them to do so.@Widgetpublic class WebView extends AbsoluteLayout        implements ViewTreeObserver.OnGlobalFocusChangeListener,        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ...     public void loadUrl(@NonNull String url, @NonNull Map<String, String> additionalHttpHeaders) {
      checkThread();    mProvider.loadUrl(url, additionalHttpHeaders);  }  ...}

WebViewProvider 的原生实现就是 WebViewChromium，至于在 WebView 中是如何获取到 WebViewChromium 实例的，这块的分析文章还是很多的，感兴趣的同学可以自行检索相关内容。在 WebViewChromium 中我们的 WebView 作为一个参数传入：

/** * This class is the delegate to which WebViewProxy forwards all API calls. * * Most of the actual functionality is implemented by AwContents (or WebContents within * it). This class also contains WebView-specific APIs that require the creation of other * adapters (otherwise org.chromium.content would depend on the webview.chromium package) * and a small set of no-op deprecated APIs. */@SuppressWarnings("deprecation")@Lifetime.WebViewclass WebViewChromium        implements WebViewProvider,                WebViewProvider.ScrollDelegate,                WebViewProvider.ViewDelegate,                SmartClipProvider {
      public WebViewChromium(            WebViewChromiumFactoryProvider factory,            WebView webView,            WebView.PrivateAccess webViewPrivate,            boolean shouldDisableThreadChecking) {
          ...    }}

传入的 WebView 将在后续的流程中起到非常重要的作用。

在 WebViewChromium 的初始化阶段，会构造了一个 AwContents 对象，接着传递我们的 WebView:

private void initForReal() {
    ...  mAwContents = new AwContents(                  browserContext,                  mWebView,                  mContext,                  new InternalAccessAdapter(),                  new WebViewNativeDrawFunctorFactory(),                  mCon