Android 4.4的(API級別19)推出了新版本的WebView是基於Chromium 。 這種變化升級WebView對HTML5,CSS3和JavaScript的性能和標準支持,以符合最新的Web瀏覽器。 使用任何應用程序WebView在Android 4.4及以上運行時,將繼承這些升級。

本文檔介紹了其他更改WebView ,你應該知道,如果你設置你的targetSdkVersion為“19”或更高。

注意:如果您的targetSdkVersion設置為“18”或以下, WebView運行在“"quirks mode”,以避免一些下面描述的行為變化,盡可能地,同時還提供了您的應用程序的性能和Web標準的升級。 要小心,雖然,single 、 narrow column layouts 和 default zoom levels ,不支持在所有在Android 4.4,並有可能是尚未確定的其他行為上的 ​​差異,所以一定要測試在Android 4.4的應用程序或即使高你把你的targetSdkVersion設置為“18”或以下。

為了幫助您完成遷移您的應用程序時可能遇到的任何問題的工作WebView是Android 4.4,你可以通過調用使您的桌面上,通過瀏覽器遠程調試setWebContentsDebuggingEnabled() 在這項新功能WebView允許你檢查,並在運行時分析你的網頁內容,腳本和網絡活動WebView 。 欲了解更多信息,請參閱在Android遠程調試 (Remote Debugging on Android.)。

用戶代理更改User agent change

如果你提供的內容到您WebView基於用User agent,你應該要知道的User agent字符串有所改變,現在包括了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

如果您需要獲取User agent,但並不需要存儲為您的應用程序或不想實例WebView ,您應該使用靜態方法, getDefaultUserAgent() 但是,如果你打算重寫你的用戶代理字符串WebView ,你可能反而要使用getUserAgentString()

多線程和線程阻塞Multi-threading and Thread Blocking

如果你使用方法在WebView上從其他UI或應用,它可能會導致意想不到的結果。 例如,如果您的應用程序使用多個線程,你可以使用runOnUiThread()方法,以確保你的代碼在UI線程上執行:

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

另外要確保你 never block the UI thread 。 一種情況,即一些應用程序使這個錯誤是在等待一個JavaScript回調。 例如, 不要使用這樣的代碼:

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

您可以改用一種新的方法,evaluateJavascript(), to run JavaScript asynchronously.

自定義URL處理Custom URL Handling

新WebView請求資源,解決了使用自定義URL方案的鏈接時,適用附加限制。 例如,如果您實現回調,如shouldOverrideUrlLoading()或shouldInterceptRequest()然後WebView調用它們只適用於有效的URL。

如果您使用的是自定義URL方案或基本URL,請注意您的應用程序接收較少的調用這些回調或沒有加載在Android 4.4的資源,確保請求指定符合有效的URL 的RFC 3986 。

例如,新WebView可能不會打電話給你的shouldOverrideUrlLoading()方法類似這樣的鏈接:

Show Profile

點擊這樣的鏈接可以改變用戶的結果:

如果通過調用加載的頁面loadData()或loadDataWithBaseURL()一個無效的或空基URL,那麼你將不會收到shouldOverrideUrlLoading()回調對於這種類型的鏈接的頁面上。

注意:當您使用loadDataWithBaseURL()和基礎URL無效或設置為空值,在內容要裝入的所有鏈接必須是絕對的。
如果通過調用加載該頁面loadUrl()或者提供一個有效的基本URL loadDataWithBaseURL()那麼您將收到shouldOverrideUrlLoading()回調對於這種類型的頁面上的鏈接,但你收到的URL將是絕對的,相對當前頁面。 例如,您將收到該URL將是"http://www.example.com/showProfile"而不僅僅是"showProfile"

而不是使用一個鏈接一個簡單的字符串,如上圖所示,你可以使用一個自定義方案,如下列:

Show Profile

然後,您可以處理你的這個URL shouldOverrideUrlLoading()方法是這樣的:

// 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);

有效的主機名稱應符合RFC 3986 ,它是重要的,包括結尾的斜線底,否則,從加載頁面的任何請求可能會被丟棄。
視變化
視目標densitydpi不再支持

此前, WebView支持稱為視口性能target-densitydpi幫助網頁指定所需的屏幕像素密度。 這個屬性不再支持,你應該遷移到使用標準的解決方案,圖像和CSS在討論中的WebView像素完美的用戶界面 。
視放大小的時候

以前,如果你設置你的視口寬度的值小於或等於“320”將它設置為“設備寬度”,如果你設置了視口的高度為一個值小於或等於WebView的高度,它將被設置為“設備”高。 然而,在新的運行時, WebView ,寬度或高度值被粘附和WebView放大到填滿整個屏幕寬度。
不支持多視口標籤

以前,如果包含多個視口標籤中的網頁, WebView會從所有標籤合併的屬性。 在新的WebView ,只有最後一個視口是用來和所有其他被忽略。
默認縮放已過時

該方法getDefaultZoom()和setDefaultZoom()用於獲取和設置頁面上的初始縮放級別已經不再支持,則應該定義在網頁中相應的視口。

注意:這些API不支持在Android 4.4和所有更高。 即使你targetSdkVersion設置為“18”以下,這些API沒有任何效果。

有關如何定義在HTML視窗屬性的信息,請閱讀像素完美的用戶界面的web視圖 。

如果不能設置在HTML視口的寬度,那麼你應該叫setUseWideViewPort()以確保該頁面被賦予了更大的視口。 例如:

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

ViewPort變化

背景簡寫覆蓋的背景大小

Chrome和其他瀏覽器都表現得這樣了一段時間,但現在WebView也將覆蓋一個CSS設置background-size ,如果您還指定了background樣式。 例如,這裡的規模將被重置為默認值:

.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不再支持

該NARROW_COLUMNS為值WebSettings.LayoutAlgorithm沒有在新的支持WebView 。

注意:這些API不支持在Android 4.4和所有更高。 即使你targetSdkVersion設置為“18”以下,這些API沒有任何效果。

你可以處理這種變化在以下幾個方面:

改變你的應用程序的樣式:

如果你有網頁上的HTML和CSS的控制,你會發現,改變你的內容的設計可能是最可靠的方法。 例如,對於在那裡你舉牌照的屏幕,你可能需要一個內部的自動換行

標籤,你可以做以下樣式:



這可能是特別有益的,如果你沒有定義為您的網頁視窗的屬性。
使用新的TEXT_AUTOSIZING佈局算法:

如果您正在使用窄列作為一種方法,使桌面站點的廣譜在移動設備上更具可讀性,你是不是能夠改變HTML內容,新TEXT_AUTOSIZING算法可能是一個合適的替代品NARROW_COLUMNS 。

此外, SINGLE_COLUMN值這是以前棄用,也不能在新的支持的WebView 。
觸碰事件中的JavaScript

如果您的網頁直接處理的觸摸事件WebView ,確保你還處理touchcancel事件。 有幾個方案,其中touchcancel將被調用,如果沒有接收到可能導致問題:

元素是感動(所以touchstart和touchmove的稱呼)和頁面滾動,造成touchcancel被拋出。
一個元素被觸摸( touchstart被調用),但event.preventDefault()不會被調用,從而導致早期足夠touchcancel被拋出(這樣WebView假設你不想消耗觸摸事件)。
文章標籤
創作者介紹

Kusoman

Chia 發表在 痞客邦 留言(0) 人氣()