WebView庫功能完善

時間  2020-06-02
標籤 webview 功能 完善 简体版
原文   原文鏈接

目錄介紹

  • 01.loadUrl到底作了什麼
  • 02.觸發加載網頁的行爲
  • 03.webView重定向怎麼辦
  • 04.js交互的一點知識分享
  • 05.攔截緩存如何優雅處理
  • 06.關於一些問題和優化
  • 07.關於一點面向對象思想
  • 08.關於後期須要研究目標

01.loadUrl到底作了什麼

  • WebView.loadUrl(url)加載網頁作了什麼？
    • 加載網頁是一個複雜的過程，在這個過程當中，咱們可能須要執行一些操做，包括：
    • 加載網頁前，重置WebView狀態以及與業務綁定的變量狀態。WebView狀態包括重定向狀態(mTouchByUser)、前端控制的回退棧(mBackStep)等，業務狀態包括進度條、當前頁的分享內容、分享按鈕的顯示隱藏等。
    • 加載網頁前，根據不一樣的域拼接本地客戶端的參數，包括基本的機型信息、版本信息、登陸信息以及埋點使用的Refer信息等，有時候涉及交易、財產等還須要作額外的配置。
    • 開始執行頁面加載操做時，會回調WebViewClient.onPageStarted(webView,url,favicon)。在此方法中，能夠重置重定向保護的變量(mRedirectProtected)，固然也能夠在頁面加載前重置，因爲歷史遺留代碼問題，此處還沒有省去優化。
  • 加載頁面的過程當中回調哪些方法？
    • WebChromeClient.onReceivedTitle(webview, title)，用來設置標題。須要注意的是，在部分Android系統版本中可能會回調屢次這個方法，並且有時候回調的title是一個url，客戶端能夠針對這種狀況進行特殊處理，避免在標題欄顯示沒必要要的連接。
    • WebChromeClient.onProgressChanged(webview, progress)，根據這個回調，能夠控制進度條的進度（包括顯示與隱藏）。通常狀況下，想要達到100%的進度須要的時間較長（特別是首次加載），用戶長時間等待進度條不消失一定會感到焦慮，影響體驗。其實當progress達到80的時候，加載出來的頁面已經基本可用了。事實上，國內廠商大部分都會提早隱藏進度條，讓用戶覺得網頁加載很快。
    • WebViewClient.shouldInterceptRequest(webview, request)，不管是普通的頁面請求(使用GET/POST)，仍是頁面中的異步請求，或者頁面中的資源請求，都會回調這個方法，給開發一次攔截請求的機會。在這個方法中，咱們能夠進行靜態資源的攔截並使用緩存數據代替，也能夠攔截頁面，使用本身的網絡框架來請求數據。包括後面介紹的WebView免流方案，也和此方法有關。
    • WebViewClient.shouldOverrideUrlLoading(webview, request)，若是遇到了重定向，或者點擊了頁面中的a標籤實現頁面跳轉，那麼會回調這個方法。能夠說這個是WebView裏面最重要的回調之一，後面WebView與Native頁面交互一節將會詳細介紹這個方法。
    • WebViewClient.onReceivedError(webview,handler,error)，加載頁面的過程當中發生了錯誤，會回調這個方法。主要是http錯誤以及ssl錯誤。在這兩個回調中，咱們能夠進行異常上報，監控異常頁面、過時頁面，及時反饋給運營或前端修改。在處理ssl錯誤時，遇到不信任的證書能夠進行特殊處理，例如對域名進行判斷，針對本身公司的域名「放行」，防止進入醜陋的錯誤證書頁面。也能夠與Chrome同樣，彈出ssl證書疑問彈窗，給用戶選擇的餘地。
  • 加載頁面結束回調哪些方法
    • 會回調WebViewClient.onPageFinished(webview,url)。
    • 這時候能夠根據回退棧的狀況判斷是否顯示關閉WebView按鈕。經過mActivityWeb.canGoBackOrForward(-1)判斷是否能夠回退。

02.觸發加載網頁的行爲

  • 觸發加載網頁的行爲主要有兩種方式：
    • （A）點擊頁面，觸發標籤。
    • （B）調用WebView的loadUrl()方法
    • 這兩種方法都會發出一條地址，區別就在於這條地址是目的地址仍是重定向地址。以訪問http://www.baidu.com百度的頁面來測試一下方法的執行順序。
  • 觸發加載網頁流程分析
    • 在代碼中經過loadUrl加載百度的首頁，此時的行爲屬於（B）方式。
      • 能夠發現大概的執行順序是：onPageStarted ——> shouldOverrideUrlLoading ——> onPageFinished
      • 那麼爲何會執行屢次呢，思考一下？具體能夠看一下7.2得出的結論分析。
      X5LogUtils: -------onPageStarted-------http://www.baidu.com/
X5LogUtils: -------shouldOverrideUrlLoading-------https://m.baidu.com/?from=844b&vit=fps
X5LogUtils: -------onPageFinished-------http://www.baidu.com/
X5LogUtils: -------onPageStarted-------https://m.baidu.com/?from=844b&vit=fps
X5LogUtils: -------onReceivedTitle-------百度一下
X5LogUtils: -------shouldOverrideUrlLoading-------http://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onPageFinished-------https://m.baidu.com/?from=844b&vit=fps
X5LogUtils: -------shouldOverrideUrlLoading-------https://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onPageStarted-------http://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onPageFinished-------http://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onPageStarted-------https://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onReceivedTitle-------百度一下,你就知道
X5LogUtils: -------onPageFinished-------https://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
複製代碼
    • 在首頁，點擊一下「hao123」,跳轉到www.hao123.com的主頁上來，此時的行爲屬於（A）方式。
      • 能夠發現大概的執行順序是：shouldOverrideUrlLoading ——> onPageStarted ——> onPageFinished
      X5LogUtils: -------shouldOverrideUrlLoading-------http://m.hao123.com/?ssid=0&from=844b&bd_page_type=1&uid=0&pu=sz%401321_1002%2Cta%40utouch_2_9.0_2_6.2&idx=30000&itj=39
X5LogUtils: -------onPageStarted-------http://m.hao123.com/?ssid=0&from=844b&bd_page_type=1&uid=0&pu=sz%401321_1002%2Cta%40utouch_2_9.0_2_6.2&idx=30000&itj=39
X5LogUtils: -------onReceivedTitle-------hao123導航-上網從這裏開始
X5LogUtils: -------onPageFinished-------http://m.hao123.com/?ssid=0&from=844b&bd_page_type=1&uid=0&pu=sz%401321_1002%2Cta%40utouch_2_9.0_2_6.2&idx=30000&itj=39
複製代碼
    • 而後在hao123頁面，點擊優酷網進行跳轉，此時的行爲屬於（A）方式。
      X5LogUtils: -------shouldOverrideUrlLoading-------http://m.hao123.com/j.php?z=2&page=index_cxv3&pos=cydhwt_n2&category=ty&title=%E4%BC%98%E9%85%B7%E7%BD%91&qt=tz&url=http%3A%2F%2Fwww.youku.com%2F&key=58193753e7a868d9a013056c6c4cd77b
X5LogUtils: -------onPageStarted-------http://m.hao123.com/j.php?z=2&page=index_cxv3&pos=cydhwt_n2&category=ty&title=%E4%BC%98%E9%85%B7%E7%BD%91&qt=tz&url=http%3A%2F%2Fwww.youku.com%2F&key=58193753e7a868d9a013056c6c4cd77b
X5LogUtils: -------shouldOverrideUrlLoading-------http://www.youku.com/
X5LogUtils: -------onPageFinished-------http://m.hao123.com/j.php?z=2&page=index_cxv3&pos=cydhwt_n2&category=ty&title=%E4%BC%98%E9%85%B7%E7%BD%91&qt=tz&url=http%3A%2F%2Fwww.youku.com%2F&key=58193753e7a868d9a013056c6c4cd77b
X5LogUtils: -------onPageStarted-------http://www.youku.com/
X5LogUtils: -------shouldOverrideUrlLoading-------https://www.youku.com/
X5LogUtils: -------onPageFinished-------http://www.youku.com/
X5LogUtils: -------onPageStarted-------https://www.youku.com/
X5LogUtils: -------onReceivedTitle-------優酷視頻-首頁
X5LogUtils: -------onPageFinished-------https://www.youku.com/
複製代碼
    • 而後從優酷頁面回退到hao123頁面，看看又回執行哪些方法。
      X5LogUtils: -------onPageStarted-------http://m.hao123.com/?ssid=0&from=844b&bd_page_type=1&uid=0&pu=sz%401321_1002%2Cta%40utouch_2_9.0_2_6.2&idx=30000&itj=39
X5LogUtils: -------onReceivedTitle-------hao123導航-上網從這裏開始
X5LogUtils: -------onReceivedTitle-------hao123導航-上網從這裏開始
X5LogUtils: -------onPageFinished-------http://m.hao123.com/?ssid=0&from=844b&bd_page_type=1&uid=0&pu=sz%401321_1002%2Cta%40utouch_2_9.0_2_6.2&idx=30000&itj=39
複製代碼
    • 而後從hao123頁面回退到百度首頁，看看又回執行哪些方法。
      X5LogUtils: -------onPageStarted-------https://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
X5LogUtils: -------onReceivedTitle-------百度一下,你就知道
X5LogUtils: -------onReceivedTitle-------百度一下,你就知道
X5LogUtils: -------onPageFinished-------https://m.baidu.com/?cip=117.101.19.67&baiduid=C6FCEED198C994E0D653C094F2708C32&from=844b&vit=fps?from=844b&vit=fps&index=&ssid=0&bd_page_type=1&logid=12175252243175665635&pu=sz%401321_480&t_noscript=jump
複製代碼
  • 得出結論分析說明
    • 在(A)行爲方式下（用戶點擊連接的回調）：
      • 1.若是是目的地址，那麼方法的執行順序是：
        • shouldOverrideUrlLoading() -> onPageStarted()-> onPageFinished()
        • shouldOverrideUrlLoading()因爲它要提供給APP選擇加載網頁環境的機會，因此只要是網頁上地址請求，都會獲取到。
      • 2.若是是重定向地址，在跳轉到目的地址以前會進行不斷的地址定位，每一次地址定位都會由如下執行順序體現出來：
        • onPageStarted()->shouldOverrideUrlLoading()->onPageFinished()
        • 暫且設定這種執行順序叫：fixed position
        • 那麼一個正常的重定向地址，方法的執行順序就是：
        • shouldOverrideUrlLoading() -> fixed position -> … -> fixed position -> onPageStarted() -> onPageFinished()
        • 舉個例子：有重定向(A->B->C)，那麼
        shouldOverrideUrlLoading(A) -> onPageStarted(A) ->
onPageStarted(B) -> shouldOverrideUrlLoading(B) ->
onPageStarted(C) -> shouldOverrideUrlLoading(C) -> onPageFinished(C)
複製代碼
    • 在（B）行爲下：
      • 1.若是是目的地址，那麼方法的執行順序是：
        • onPageStarted()-> onPageFinished()
        • loadUrl()加載地址時，通常不會觸發shouldOverrideUrlLoading()，一旦觸發了，就說明這是一個重定向地址。
      • 2.若是是重定向地址，方法的執行順序就是：
        • fixed position -> … -> fixed position -> onPageStarted() -> onPageFinished()

03.webView重定向怎麼辦

  • webView出現302/303重定向
    • 302重定向又稱之爲302表明暫時性轉移，好比你跳轉A頁面，但因爲網頁添加了約束條件，可能讓你跳轉到B頁面，甚至屢次重定向。
  • 致使的問題
    • 1.A-->B-->C，好比你跳轉A頁面，最終重定向到C頁面。這個時候調用goBack方法，返回到B連接，可是B連接又會跳轉到C連接，從而致使無法返回到A連接界面
    • 2.會屢次執行onPageStarted和onPageFinished，若是你這裏有加載進度條或者loading，那麼會致使進度條或者loading執行屢次
  • 常見的解決方案
  • 如何判斷重定向
    • 經過getHitTestResult()返回值，若是返回null，或者UNKNOWN_TYPE，則表示爲重定向。具體看：18.如何用代碼判斷是否重定向
    • 在加載一個頁面開始的時候會回調onPageStarted方法，在該頁面加載完成以後會回調onPageFinished方法。而若是該連接發生了重定向，回調shouldOverrideUrlLoading會在回調onPageFinished以前。
  • 終極解決方案以下
    • 須要準備的條件
      • 建立一個棧，主要是用來存取和移除url的操做。這個url包括全部的請求連接
      • 定義一個變量，用於判斷頁面是否處於正在加載中。
      • 定義一個變量，用於記錄重定向前的連接url
      • 定一個重定向時間間隔，主要爲了不刷新形成循環重定向
    • 具體怎麼操做呢
      • 在執行onPageStarted時，先移除棧中上一個url，而後將url加載到棧中。
      • 當出現錯誤重定向的時候，若是和上一次重定向的時間間隔大於3秒，則reload頁面。
      • 在回退操做的時候，判斷若是能夠回退，則從棧中獲取最後停留的url，而後loadUrl。便可解決回退問題。
    • 具體方法思路

04.js交互的一點知識分享

  • js交互介紹
    • Java調用js方法有兩種：
      • WebView.loadUrl("javascript:" + javascript);
      • WebView.evaluateJavascript(javascript, callbacck);
    • js調用Java的方法有三種，分別是：
      • JavascriptInterface
      • WebViewClient.shouldOverrideUrlLoading()
      • WebChromeClient.onJsPrompt()
  • js調用java方法比較和區別分析
    • 1.經過 addJavascriptInterface 方法進行添加對象映射。js最終經過對象調用原生方法
    • 2.shouldOverrideUrlLoading攔截操做，獲取scheme匹配，與網頁約定好一個協議，若是匹配，執行相應操做
    • 3.利用WebChromeClient回調接口onJsPrompt攔截操做。
      • onJsAlert 是不能返回值的，而 onJsConfirm 只可以返回肯定或者取消兩個值，只有 onJsPrompt 方法是能夠返回字符串類型的值，操做最全面方便。
    • 詳細分析能夠看：03.Js調用Android
  • js調用java原生方法可能存在的問題？
    • 提出問題
      • 1.原生方法是否能夠執行耗時操做，若是有會阻塞通訊嗎？4.4.8 prompt的一個坑致使js掛掉
      • 2.多線程中調用多個原生方法，如何保證原生方法每個都會被執行到？
      • 3.js會阻塞等待當前原生函數（耗時操做的那個）執行完畢再往下走，因此js調用java方法裏面最好也不要作耗時操做
    • 解決方案
      • 1.在js調用​window.alert​，​window.confirm​，​window.prompt​時，​會調用WebChromeClient​對應方法，能夠此爲入口，做爲消息傳遞通道，考慮到開發習慣，通常不會選擇alert跟confirm，​一般會選prompt做爲入口，在App中就是onJsPrompt做爲jsbridge的調用入口。因爲onJsPrompt是在UI線程執行，因此儘可能不要作耗時操做，能夠藉助Handler靈活處理。
      • 2.利用Handler封裝一下，讓每一個任務本身處理，耗時的話就開線程本身處理。具體能夠看：WvWebView
  • java調用js的時機
    • onPageFinished()或者onPageStarted()方法中注入js代碼嗎？
      • js交互，大部分都會認爲js在WebViewClient.onPageFinished()方法中注入最合適，此時dom樹已經構建完成，頁面已經徹底展示出來。但若是作過頁面加載速度的測試，會發現WebViewClient.onPageFinished()方法一般須要等待好久纔會回調（首次加載一般超過3s），這是由於WebView須要加載完一個網頁裏主文檔和全部的資源纔會回調這個方法。
      • 能不能在WebViewClient.onPageStarted()中注入呢？答案是不肯定。通過測試，有些機型能夠，有些機型不行。在WebViewClient.onPageStarted()中注入還有一個致命的問題——這個方法可能會回調屢次，會形成js代碼的屢次注入。
      • 從7.0開始，WebView加載js方式發生了一些小改變，官方建議把js注入的時機放在頁面開始加載以後。
    • 能夠在onProgressChanged中方法中注入js代碼
      • 頁面的進度加載到80%的時候，實際上dom樹已經渲染得差很少了，代表WebView已經解析了標籤，這時候注入通常是成功的。
      • 提到的屢次注入控制，使用了boolean值變量控制；從新加載一個URL以前，須要重置boolean值變量，讓從新加載後的頁面再次注入js

05.攔截緩存如何優雅處理

  • WebView爲什麼加載慢
    • webView是怎麼加載網頁的呢？
      • webView初始化->DOM下載→DOM解析→CSS請求+下載→CSS解析→渲染→繪製→合成
    • 渲染速度慢
      • 前端H5頁面渲染的速度取決於 兩個方面：
        • Js 解析效率。Js 自己的解析過程複雜、解析速度不快 & 前端頁面涉及較多 JS 代碼文件，因此疊加起來會致使 Js 解析效率很是低
        • 手機硬件設備的性能。因爲Android機型碎片化，這致使手機硬件設備的性能不可控，而大多數的Android手機硬件設備沒法達到很好很好的硬件性能
    • 頁面資源加載緩慢
      • H5 頁面從服務器得到，並存儲在 Android手機內存裏：
        • H5頁面通常會比較多
        • 每加載一個 H5頁面，都會產生較多網絡請求：
          • HTML 主 URL 自身的請求；
          • HTML外部引用的JS、CSS、字體文件，圖片也是一個獨立的 HTTP 請求
        • 每個請求都串行的，這麼多請求串起來，這致使 H5頁面資源加載緩慢
  • 解決WebView加載慢
    • 前端H5的緩存機制（WebView 自帶）
    • 資源攔截緩存
    • 資源攔截替換
  • webView瀏覽器緩存機制
    • 這些技術都是協議層所定義的，在Android的webView當中咱們能夠經過配置決定是否採納這幾個協議的頭部屬性
    // LOAD_CACHE_ONLY: 不使用網絡，只讀取本地緩存數據
// LOAD_DEFAULT: （默認）根據cache-control決定是否從網絡上取數據。
// LOAD_NO_CACHE: 不使用緩存，只從網絡獲取數據.
// LOAD_CACHE_ELSE_NETWORK，只要本地有，不管是否過時，或者no-cache，都使用緩存中的數據。
ws.setCacheMode(WebSettings.LOAD_DEFAULT);
複製代碼
    • 通常設置爲默認的緩存模式就能夠了。關於緩存的配置, 主要仍是靠web前端和後臺設置。關於瀏覽器緩存機制
  • 自身構建緩存方案
    • 攔截處理
      • 在shouldInterceptRequest方法中攔截處理
      • 步驟1:判斷攔截資源的條件，即判斷url裏的圖片資源的文件名
      • 步驟2:建立一個輸入流，這裏能夠先從內存中拿，拿不到從磁盤中拿，再拿不到就從網絡獲取數據
      • 步驟3:打開須要替換的資源(存放在assets文件夾裏)，或者從lru中取出緩存的數據
      • 步驟4:替換資源
    • 有幾個問題
      • 如何判斷url中資源是否須要攔截，或者說是否須要緩存
      • 如何緩存js，css等
      • 緩存數據是否有時效性
      • 關於緩存下載的問題，是引入okhttp仍是原生網絡請求，緩存下載失敗該怎麼處理
    • 在哪裏進行攔截
      • webView在加載網頁的時候，用戶可以經過系統提供的API干預各個中間過程。咱們要攔截的就是網頁資源請求的環節。這個過程，WebViewClient當中提供瞭如下兩個入口：
        // android5.0以上的版本加入
@Override
public WebResourceResponse shouldInterceptRequest(WebView webView, WebResourceRequest webResourceRequest) {
  return super.shouldInterceptRequest(webView, webResourceRequest);
}

@Override
public WebResourceResponse shouldInterceptRequest(WebView webView, String s) {
  return super.shouldInterceptRequest(webView, s);
}
複製代碼
      • 替換資源操做
        • 只要在這兩個入口構造正確的WebResourceResponse對象，就能夠替換默認的請求爲咱們提供的資源
        • 所以，在每次請求資源的時候根據請求的URL/WebResourceRequest判斷是否存在本地的緩存，並在緩存存在的狀況下將緩存的輸入流返回

06.關於一些問題和優化

  • 影響頁面加載的一些因素有那些？
    • 1.加載網頁中，若是圖片不少，而這些圖片的請求又是一個個獨立而且串行的請求。那麼可能會致使加載頁面比較緩慢……
    • 2.app原生和webView中請求，都會涉及到https的網絡請求，那麼在請求前會有域名dns的解析，這個也會有大約200毫秒的解析時間(主要耗費時間dns，connection，服務器處理等)……
    • 3.webView加載html網頁時，有些js一直在執行好比動畫之類的東西，此刻webView掛在了後臺這些資源是不會被釋放用戶也沒法感知。致使耗費資源……
    • 4.關於加載loading或者加載進度條，不必定要放到onPageStarted開始執行即顯示出來，由於webView從建立到這個方法會有一個時間……
    • 5.webView默認開啓密碼保存功能，若是網頁涉及到用戶登錄，密碼會被明文保到 /data/data/com.package.name/databases/webview.db 中，這樣就有被盜取密碼的危險……
    • 6.h5頁面被攔截或者注入廣告，重定向，或者DNS劫持。通常跟鏈接的wifi有關係（http劫持），也可能跟運營商有關係(dns劫持)
  • 具體能夠操做的優化分析
    • 1.加載webView中的資源時，針對圖片，等頁面finish後再發起圖片加載(也就是執行onPageFinished設置加載圖片)。具體看5.0.2圖片加載次序優化
    • 2.DNS域名解析採用和客戶端API相同的域名， DNS會在系統級別進行緩存，對於WebView的地址，若是使用的域名與native的API相同，則能夠直接使用緩存的DNS而不用再發起請求圖片。具體看5.0.7 DNS採用和客戶端API相同的域名
    • 3.在後臺的時候，會調用onStop方法，即此時關閉js交互，回到前臺調用onResume再開啓js交互。具體看5.0.9 後臺沒法釋放js致使發熱耗電
    • 4.提早顯示進度條不是提高性能，可是對用戶體驗來講也是很重要的一點 ，WebView.loadUrl("url") 不會立馬就回調onPageStarted方法，由於在這一時間段，WebView 有可能在初始化內核，也有可能在與服務器創建鏈接，這個時間段容易出現白屏
    • 5.須要經過 WebSettings.setSavePassword(false) 關閉密碼保存功能。
    • 6.通常能夠處理：1使用https代替http；2.添加白名單(好比添加本身網站的host，其餘不給訪問)；3.對頁面md5校驗(不太好)。設置白名單參考：5.0.8 如何設置白名單操做
  • 還有一些其餘的優化小細節
    • a.WebView處理40四、500邏輯，在WebChromeClient子類中能夠重寫他的onReceivedTitle()方法監聽標題，還有在WebChromeClient子類中onReceivedHttpError能夠監聽statusCode。具體操做看5.1.5 WebView處理40四、500邏輯
    • b.若是不顯示圖片，開發的時候可能使用的是https的連接, 可是連接中的圖片多是http的，須要開啓設置。具體看：4.1.4 webView加載網頁不顯示圖片
    • c.evaluateJavascript(String var1, ValueCallback var2)中url長度有限制，在19以上超過2097152個字符失效，這個地方能夠加個判斷。不過通常很難碰到……具體能夠參考：4.3.1 Android與js傳遞數據大小有限制
    • d.在web頁面android軟鍵盤覆蓋問題，常見的有android:windowSoftInputMode的值adjustPan或者adjustResize便可，若是webView是全屏模式則仍然會出現問題。具體看：4.6.1 在web頁面android軟鍵盤覆蓋問題
    • e.關於WebView隱藏H5頁面中的某個標籤視圖，大概操做就是在頁面加載完成，經過getElementsByClassName找到h5中標籤name，而後手動寫function方法隱藏標籤。但加載時機很關鍵，不過會形成閃屏和屢次加載。具體看：4.6.6 WebView如何隱藏H5的部份內容問題
    • f.頁面重定向，會致使onPageStarted屢次執行，那麼這個時候如何避免加載進度條出現執行屢次，或者跳動的問題。具體可見：09.web進度條避免屢次加載
    • g.建議開啓Google安全瀏覽服務，用戶訪問不安全網頁會提示安全問題；webView使用上的建議設置佈局高度和寬度設置爲 match_parent；具體可見48.開啓Google安全瀏覽服務

07.關於一點面向對象的思想

  • 針對webView視頻播放演變
    • 1.最剛開始把視頻全屏show和hide的邏輯都放到X5WebChromeClient中處理，至關於這個類中邏輯比較多
    • 2.後期把視頻全屏播放邏輯都抽到了VideoWebChromeClient類中處理，這樣只須要繼承該類便可。這個類獨立，拿來即用。
    • 3.後期演變，一個視頻全屏播放接口 + 接口實現類 + VideoChromeClient，接口主要可以解耦
  • 關於webView攔截緩存處理
    • 1.代碼結構大概是：攔截緩存接口 + 接口實現類 + 接口委派類
    • 2.優勢：委派類和實現類解耦；便於增長過濾功能(好比用了https+dns優化就不用攔截緩存)；
    //1.建立委託對象
WebViewCacheDelegate webViewCacheDelegate = WebViewCacheDelegate.getInstance();
//2.經過委託對象調用方法
WebResourceResponse webResourceResponse = webViewCacheDelegate.interceptRequest(url);
複製代碼
  • 關於shouldOverrideUrlLoading處理多類型
    • 好比：封裝庫中須要處理打電話，發短信，發郵件，地圖定位，圖片，超連接等攔截邏輯
    • 最剛開始是把處理的邏輯都放到了WebViewClient中的shouldOverrideUrlLoading方法中處理。不過發現這個類代碼愈來愈多……
    • 後期演變，針對電話短信等將處理邏輯抽取到WebSchemeIntent類中，針對圖片處理邏輯抽取到SaveImageProcessor類中。具體看WebSchemeIntent
    • 這樣作，至關於保證了類的單一性職責，即類儘可能保證內部處理的功能儘量單一，而不是錯綜複雜……

08.關於後期須要研究的目標

  • 目標
    • web頁面特別消耗流量，每次打開頁面都會請求網絡，建議對流量的消耗進行優化……除了對lib庫中對攔截作OkHttp緩存，還有什麼其餘方案
  • web頁面涉及流量的幾個方面
    • 普通https請求，通常過程是服務端(對象)-->網絡中(二進制流)-->客戶端(對象)，文本內容會作傳輸壓縮
    • 網絡圖片下載，圖片下載消耗的流量較多
    • h5頁面展現，因爲h5頁面是交由前端處理顯示，客戶端開發關注的少些，而此處消耗了大量的流量
  • 如何查看web頁面消耗流量
    • 使用TrafficStats便可查看流量的消耗

09.開源庫

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程