在Android 4.4中迁移到WebView(四)

作者: 鹿小纯0831 | 来源:发表于2018-08-19 20:22 被阅读99次

Android 4.4（API级别19）引入了基于Chromium的新版WebView。此更改升级了对HTML5，CSS3和JavaScript的WebView性能和标准支持，以匹配最新的Web浏览器。在Android 4.4及更高版本上运行时，任何使用WebView的应用程序都将继承这些升级。
本文档介绍了在将targetSdkVersion设置为“19”或更高时应注意的对WebView的其他更改。

注意：如果您的targetSdkVersion设置为“18”或更低，WebView将以“怪癖模式”运行，以避免下面描述的某些行为更改尽可能接近 - 同时仍为您的应用程序提供性能和Web标准升级。但请注意，Android 4.4上根本不支持单列和窄列布局以及默认缩放级别，并且可能存在尚未识别的其他行为差异，因此请务必在Android 4.4或更高版本上测试您的应用，即使将targetSdkVersion设置为“18”或更低。

为了帮助您解决在Android 4.4中将应用迁移到WebView时可能遇到的任何问题，您可以通过调用setWebContentsDebuggingEnabled（）在桌面上通过Chrome启用远程调试。WebView中的这一新功能允许您在WebView中运行时检查和分析Web内容，脚本和网络活动。有关更多信息，请参阅Android上的远程调试。

一、用户代理更改

如果您基于用户代理向WebView提供内容，则应注意用户代理字符串已略有更改，现在包括Chrome版本：

Mozilla/5.0 (Linux; Android 4.4; Nexus 4 Build/KRT16H) AppleWebKit/537.36
(KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36

如果您需要检索用户代理但不需要为应用程序存储它或者不想实例化WebView，则应使用静态方法getDefaultUserAgent（）。但是，如果要在WebView中覆盖用户代理字符串，则可能需要使用getUserAgentString（）。

二、多线程和线程阻塞

如果从应用程序的UI线程以外的任何线程调用WebView上的方法，则可能导致意外结果。例如，如果您的应用程序使用多个线程，则可以使用runOnUiThread（）方法来确保您的代码在UI线程上执行：

runOnUiThread(new Runnable() {
    @Override
    public void run() {
        // Code for WebView goes here
    }
});

还要确保永远不会阻止UI线程。某些应用程序出现此错误的情况是在等待JavaScript回调时。例如，不要使用这样的代码：

// This code is BAD and will block the UI thread
webView.loadUrl("javascript:fn()");
while(result == null) {
  Thread.sleep(100);
}

您可以使用新方法evaluateJavascript（）来异步运行JavaScript。

三、自定义URL处理

在请求资源和解析使用自定义URL方案的链接时，新WebView会应用其他限制。例如，如果实现了诸如shouldOverrideUrlLoading（）或shouldInterceptRequest（）之类的回调，则WebView仅针对有效URL调用它们。

如果您使用自定义URL方案或基本URL，并注意到您的应用程序接收的回调较少或未能在Android 4.4上加载资源，请确保请求指定符合RFC 3986的有效URL。

例如，新的WebView可能不会为这样的链接调用shouldOverrideUrlLoading（）方法：

<a href="showProfile">Show Profile</a>

用户点击此类链接的结果可能会有所不同：

如果通过使用无效或空基URL调用loadData（）或loadDataWithBaseURL（）来加载页面，则不会在页面上收到此类链接的shouldOverrideUrlLoading（）回调。

注意：使用loadDataWithBaseURL（）并且基本URL无效或设置为null时，要加载的内容中的所有链接都必须是绝对的。

如果通过调用loadUrl（）加载页面或者使用loadDataWithBaseURL（）提供了有效的基本URL，那么您将在页面上收到此类链接的shouldOverrideUrlLoading（）回调，但是您收到的URL将是绝对的，相对于当前页面。例如，您收到的网址为“http://www.example.com/showProfile”，而不仅仅是“showProfile”。
如上所示，您可以使用自定义方案，而不是在链接中使用简单字符串，如下所示：

<a href="example-app:showProfile">Show Profile</a>

然后，您可以在shouldOverrideUrlLoading（）方法中处理此URL，如下所示：

// The URL scheme should be non-hierarchical (no trailing slashes)
private static final String APP_SCHEME = "example-app:";

@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
    if (url.startsWith(APP_SCHEME)) {
        urlData = URLDecoder.decode(url.substring(APP_SCHEME.length()), "UTF-8");
        respondToData(urlData);
        return true;
    }
    return false;
}

如果您无法更改HTML，则可以使用loadDataWithBaseURL（）并设置包含自定义方案和有效主机的基本URL，例如“example-app：// <valid_host_name> /”。例如：

webView.loadDataWithBaseURL("example-app://example.co.uk/", HTML_DATA,
        null, "UTF-8", null);

四、视口更改

不再支持视口目标密度

以前，WebView支持名为target-densitydpi的视口属性，以帮助网页指定其预期的屏幕密度。不再支持此属性，您应该迁移到使用带有图像和CSS的标准解决方案，如WebView中的Pixel-Perfect UI中所述。

视口小时放大

以前，如果将视口宽度设置为小于或等于“320”的值，则将其设置为“device-width”，如果将视口高度设置为小于或等于WebView高度的值，则将设置为“设备高度”。但是，在新WebView中运行时，会粘贴宽度或高度值，WebView会放大以填充屏幕宽度。

不支持多个视口标记

以前，如果在网页中包含多个视口标记，则WebView将合并所有标记中的属性。在新的WebView中，仅使用最后一个视口，而忽略所有其他视口。

不推荐使用默认缩放

用于获取和设置页面上的初始缩放级别的方法getDefaultZoom（）和setDefaultZoom（）不再受支持，您应该在网页中定义适当的视口。

注意：Android 4.4及更高版本不支持这些API。即使您的targetSdkVersion设置为“18”或更低，这些API也无效。

有关如何在HTML中定义视口属性的信息，请阅读WebView中的Pixel-Perfect UI。
如果无法在HTML中设置视口的宽度，则应调用setUseWideViewPort（）以确保为页面提供更大的视口。例如：

WebSettings settings = webView.getSettings();
settings.setUseWideViewPort(true);
settings.setLoadWithOverviewMode(true);

五、样式变化

后台CSS简写覆盖后台大小

Chrome和其他浏览器已经有一段时间的表现，但是现在，如果您还指定了背景样式，WebView也会覆盖背景大小的CSS设置。例如，此处的大小将重置为默认值：

.some-class {
  background-size: contain;
  background: url('images/image.png') no-repeat;
}

修复方法是简单地切换两个属性。

.some-class {
  background: url('images/image.png') no-repeat;
  background-size: contain;
}

大小是CSS像素而不是屏幕像素

以前，大小参数（如window.outerWidth和window.outerHeight）返回实际屏幕像素中的值。在新的WebView中，这些返回基于CSS像素的值。

对于尺寸调整元素或其他计算，尝试计算物理尺寸（以像素为单位）通常是不好的做法。但是，如果您已禁用缩放并且初始比例设置为1.0，则可以使用window.devicePixelRatio获取比例，然后将CSS像素值乘以该值。相反，您还可以创建JavaScript绑定以从WebView本身查询像素大小。

有关更多信息，请参阅quirksmode.org。

不再支持NARROW_COLUMNS和SINGLE_COLUMN

新WebView不支持WebSettings.LayoutAlgorithm的NARROW_COLUMNS值。

注意：Android 4.4及更高版本不支持这些API。即使您的targetSdkVersion设置为“18”或更低，这些API也无效。

您可以通过以下方式处理此更改：

改变应用程序的样式：
如果您可以控制页面上的HTML和CSS，您可能会发现更改内容设计可能是最可靠的方法。例如，对于引用许可证的屏幕，您可能希望在<pre>标记内部包装文本，您可以使用以下样式执行此操作：

<pre style="word-wrap: break-word; white-space: pre-wrap;">

如果您尚未为页面定义视口属性，这可能特别有用。

使用新的TEXT_AUTOSIZING布局算法：
如果您使用窄列作为一种方法，使移动设备上的各种桌面网站更具可读性，并且您无法更改HTML内容，则新的TEXT_AUTOSIZING算法可能是NARROW_COLUMNS的合适替代方法。
此外，新WebView中也不支持先前已弃用的SINGLE_COLUMN值。

六、在JavaScript中处理触摸事件

如果您的网页直接处理WebView中的触摸事件，请确保您还在处理touchcancel事件。有几种情况会调用touchcancel，如果没有收到会导致问题：

触摸一个元素（因此调用touchstart和touchmove）并滚动页面，从而引发touchcancel。
触摸一个元素（调用touchstart）但不调用event.preventDefault（），导致触发touchcancel（因此WebView假定您不想使用触摸事件）。