系統(tǒng)設(shè)置置中的開(kāi)發(fā)人員設(shè)置中有一項(xiàng)是“強(qiáng)制使用GPU渲染”。當(dāng)這個(gè)開(kāi)啟時(shí)，可能會(huì)引起WebView的穩(wěn)定，如頁(yè)面加載后一閃而過(guò)又變成空白等。好在這一項(xiàng)默認(rèn)是關(guān)閉的。
不過(guò)硬件加速確實(shí)會(huì)造成WebView容易出現(xiàn)問(wèn)題，原來(lái)碰到過(guò)不少。但硬件加速確實(shí)有不少好處，可以大大加快客戶端的速度，尤其是在播放動(dòng)畫的時(shí)候。最實(shí)惠的做法是整體打開(kāi)硬件加速，然后根據(jù)實(shí)際場(chǎng)景使用setLayerType關(guān)閉WebView的硬件加速。url攔截
Android WebView是攔截不到頁(yè)面內(nèi)的#fragment跳轉(zhuǎn)的。但是url跳轉(zhuǎn)的話，又會(huì)引起頁(yè)面刷新，H5頁(yè)面的體驗(yàn)又下降了。只能給WebView注入JS方法了。
不過(guò)IOS倒是可以攔截得到。可以參考這里：http://blog.csdn.net/a345017062/article/details/7478667
http://blog.csdn.net/a345017062/article/details/6838449
1、硬件加速。Android 4.0以上的系統(tǒng)設(shè)置中的開(kāi)發(fā)人員設(shè)置中有一項(xiàng)是“強(qiáng)制使用GPU渲染”。當(dāng)這個(gè)開(kāi)啟時(shí)，在部分機(jī)型（我們?cè)贕14上發(fā)現(xiàn)這個(gè)問(wèn)題）可能會(huì)引起WebView的穩(wěn)定，如H5頁(yè)面加載后一閃而過(guò)又變成空白等。強(qiáng)制調(diào)用隱藏方法setLayertype(software)也解決不了問(wèn)題。后來(lái)發(fā)現(xiàn)如果把targetVersion設(shè)置為14及以上，這個(gè)問(wèn)題可以解決。
2、跳轉(zhuǎn)攔截。H5頁(yè)面在使用window.location.href做地址跳轉(zhuǎn)時(shí)，如果只是做#fragment跳轉(zhuǎn)，shouldOverrideUrlLoading攔截不到。經(jīng)過(guò)試驗(yàn)發(fā)現(xiàn)只能攔截到絕對(duì)地址、相對(duì)地址的跳轉(zhuǎn)。另外，在2.3.7平臺(tái)上面即使是使用location.href,window.location,self.location等，且待頁(yè)面加載完1秒之后延遲調(diào)用也不能被攔截。終極方案還是使用JSBridge吧。
3、緩存模式。WebView的默認(rèn)緩存模式是LOAD_DEFAULT，當(dāng)設(shè)備離線時(shí)，WebView按照HTTP協(xié)議執(zhí)行標(biāo)準(zhǔn)的網(wǎng)頁(yè)緩存控制，有些已經(jīng)過(guò)期，但仍在緩存中的網(wǎng)頁(yè)，就顯示不出來(lái)了。如果loadUrl時(shí)判斷當(dāng)前網(wǎng)絡(luò)狀態(tài)，發(fā)現(xiàn)設(shè)備離線時(shí)，把緩存模式設(shè)置為L(zhǎng)OAD_CACHE_ELSE_NETWORK，就能做到設(shè)備離線時(shí)無(wú)論網(wǎng)頁(yè)是否過(guò)期，只要被緩存了，都可以顯示出來(lái)。顯示過(guò)期網(wǎng)頁(yè)總比顯示錯(cuò)誤頁(yè)面要好一些。
4、清除緩存。WebView的緩存目錄在2.X和4.X中不一樣，會(huì)影響到清除緩存。目前來(lái)看使用的是toLowerCase().indexOf("webviewcache")>=0來(lái)判斷是否webview的緩存目錄還是比較靠譜的。
5、調(diào)用周期。onPageStarted、onPageFinished、onReceivedError這三個(gè)周期方法在網(wǎng)絡(luò)發(fā)生錯(cuò)誤時(shí)就不可靠了，會(huì)出現(xiàn)重復(fù)調(diào)用的問(wèn)題。
6、appCache默認(rèn)關(guān)閉，需要手動(dòng)打開(kāi)并進(jìn)行設(shè)置。一般要求設(shè)置5M。
7、清除Cookie的操作是Application范圍內(nèi)的，需要注意這個(gè)可能引起的問(wèn)題。
8、有一次WebView被destroy時(shí)調(diào)用了setWebViewClient(null); ，但在測(cè)試中發(fā)現(xiàn)會(huì)報(bào)空指針。（samsung i9220 Android 4.0.4 ）
補(bǔ)充于2013.3.18
1、初次加載JS無(wú)法獲取窗口尺寸。解決方案：先load一個(gè)空頁(yè)面，再load真實(shí)地址。
2、給WebView設(shè)置padding無(wú)效。
3、WebView上面如果被其它View完全蓋住的話，在刷新時(shí)，可能會(huì)出現(xiàn)閃屏的問(wèn)題，即，加載成功后又迅速地刷了次。
補(bǔ)充于2013.3.28
不要輕易修改WebView的UA，這會(huì)在某些情況下降低用戶體驗(yàn)。現(xiàn)在大部分網(wǎng)站都對(duì)瀏覽器的UA做判斷，根據(jù)UA是手機(jī)還是PC來(lái)返回對(duì)應(yīng)的頁(yè)面版本，如果我們修改的UA網(wǎng)站無(wú)法識(shí)別的話，網(wǎng)站很可能就會(huì)把PC頁(yè)面扔過(guò)來(lái)。
補(bǔ)充于2014.1.14
Android上面有一個(gè)經(jīng)常會(huì)在線上Crash中發(fā)現(xiàn)的非必現(xiàn)異常：SQLiteException
這個(gè)異常不少人在使用WebView的時(shí)候碰到過(guò)，它非必現(xiàn)，概率不高，你通常會(huì)在線上Crash報(bào)告中才會(huì)發(fā)現(xiàn)它。原因眾說(shuō)紛紜。 這里給兩個(gè)觸發(fā)場(chǎng)景：
1、SQLite為了保護(hù)db文件一致性，當(dāng)訪問(wèn)db文件時(shí)，會(huì)給文件上一個(gè)進(jìn)程鎖，這種情況下，如果有另外一個(gè)進(jìn)程再訪問(wèn)這個(gè)db文件，就會(huì)出錯(cuò)了。 所以，你肯定想到了，你的APK如果滿足以下兩個(gè)條件會(huì)觸發(fā)這個(gè)異常： 1、使用了WebView 2、使用了多個(gè)進(jìn)程。 因?yàn)閃ebView會(huì)把Cache寫到db文件中，肯定會(huì)涉及到db操作，這個(gè)操作是Application范圍的。當(dāng)使用多進(jìn)程時(shí)，存在不同進(jìn)程的WebView對(duì)同一個(gè)db文件進(jìn)程操作的可能性，異常就會(huì)時(shí)不時(shí)出來(lái)了。
最后，按照Android老碼農(nóng)一慣的風(fēng)格，當(dāng)然要給出解決方案： 重寫Application.openOrCreateDatabase，讓不同的進(jìn)程創(chuàng)建不同的db文件就好了。
2、CookieSyncManager在強(qiáng)制同步Cookie時(shí)也會(huì)出現(xiàn)SQLite IO的異常。所以強(qiáng)制同步需要謹(jǐn)慎使用。如果不涉及多進(jìn)程共享Cookie，最好不要自己強(qiáng)制同步。
聯(lián)系客服
