做Android開發(fā)的基本都繞不開WebView這關(guān)。無論是內(nèi)嵌電商H5頁(yè)面、運(yùn)營(yíng)活動(dòng)頁(yè)還是富文本編輯器、復(fù)雜報(bào)表展示原生底層和Web頁(yè)面的混合開發(fā)早就不再是什么新鮮事。但WebView這玩意兒原生API雖然能用坑卻格外多——文件上傳不走系統(tǒng)回調(diào)、JS與原生通信要反復(fù)封裝、頁(yè)面回收不及時(shí)還會(huì)內(nèi)存泄漏。我最早做某電商項(xiàng)目的時(shí)候光是適配一個(gè)拍照上傳就折騰了兩周后來?yè)Q了AgentWeb這套封裝框架才真正把精力放到業(yè)務(wù)本身。這篇內(nèi)容是混合開發(fā)系列的第一篇先把AgentWeb的選型思路、基礎(chǔ)接入、生命周期綁定講透適合剛接觸WebView混合開發(fā)、或者已經(jīng)在用原生WebView但想省心的開發(fā)者參考。讀完你至少能獨(dú)立完成一個(gè)帶進(jìn)度條、支持文件上傳、能和H5雙向通信的基礎(chǔ)混合開發(fā)容器。1. 混合開發(fā)到底在解決什么問題1.1 什么時(shí)候該上H5很多新手剛接觸混合開發(fā)時(shí)會(huì)有個(gè)誤解以為H5頁(yè)面就是簡(jiǎn)單地把網(wǎng)頁(yè)放到App里。實(shí)際上什么場(chǎng)景適合H5、什么場(chǎng)景必須原生這個(gè)邊界直接決定項(xiàng)目后面會(huì)不會(huì)返工。我的經(jīng)驗(yàn)是凡是有強(qiáng)編輯型內(nèi)容、高頻發(fā)版需求、需要跨平臺(tái)保持一致的頁(yè)面優(yōu)先用H5。典型的就是電商的秒殺、大促活動(dòng)頁(yè)運(yùn)營(yíng)希望幾點(diǎn)上線就能幾點(diǎn)上線不想等應(yīng)用市場(chǎng)的審核周期。再比如用戶協(xié)議、隱私政策、幫助文檔這類低頻但必須實(shí)時(shí)更新的頁(yè)面用H5最省心。而涉及復(fù)雜手勢(shì)交互、音視頻推流、系統(tǒng)級(jí)能力調(diào)用的頁(yè)面除非H5有成熟的SDK兜底否則還是老老實(shí)實(shí)走原生。還有一種常見的場(chǎng)景是App內(nèi)的部分模塊是外包團(tuán)隊(duì)或前端團(tuán)隊(duì)維護(hù)的原生團(tuán)隊(duì)只負(fù)責(zé)殼工程。這時(shí)候混合開發(fā)不僅是技術(shù)選擇還涉及團(tuán)隊(duì)協(xié)作邊界。把WebView容器做好原生端提供給前端一套穩(wěn)定的JavascriptBridge接口兩邊各干各的效率會(huì)高很多。1.2 原生WebView的四大痛點(diǎn)沒有對(duì)比就沒有傷害。很多人一開始覺得WebView嘛new一個(gè)出來loadUrl就行真正上生產(chǎn)環(huán)境跑起來才會(huì)發(fā)現(xiàn)原生的實(shí)現(xiàn)方式有多費(fèi)勁。第一個(gè)痛點(diǎn)是文件上傳。系統(tǒng)WebView不提供統(tǒng)一的文件選擇回調(diào)你需要自己重寫WebChromeClient的onShowFileChooser然后處理拍照、相冊(cè)選擇、音視頻錄制這些Intent的組裝不同系統(tǒng)版本下Intent的寫法還會(huì)變。我當(dāng)時(shí)做那個(gè)電商項(xiàng)目Android 7和Android 11上的拍照返回邏輯完全不一樣光適配就花了一整天。第二個(gè)痛點(diǎn)是JS和原生通信的封裝。原生的addJavascriptInterface雖然能用但要處理線程切換、返回值回調(diào)、方法名統(tǒng)一管理這些事。如果不封裝好H5那邊調(diào)一個(gè)方法原生這邊就要寫一堆重復(fù)代碼時(shí)間久了容易改出線上事故。第三個(gè)痛點(diǎn)是生命周期管理。WebView不是Activity它不會(huì)自動(dòng)跟著頁(yè)面走。你不調(diào)onPause它可能在后臺(tái)繼續(xù)播放視頻你不調(diào)用onResume頁(yè)面恢復(fù)后WebView狀態(tài)可能是錯(cuò)的。原生WebView在這些生命周期方法上沒有任何約定全憑開發(fā)者的自覺。第四個(gè)痛點(diǎn)更隱蔽就是內(nèi)存泄漏。WebView內(nèi)部持有Activity的引用如果你在Activity里直接持有WebView實(shí)例而不做回收處理頁(yè)面關(guān)閉后內(nèi)存大概率被占著不釋放。尤其是做單WebView容器的應(yīng)用退出了幾十個(gè)頁(yè)面之后內(nèi)存占用能漲到嚇人的地步。原生實(shí)現(xiàn)需要手動(dòng)removeAllViews、destroy、置空引用這些模板代碼寫多了總是容易漏一環(huán)。1.3 為什么最終選擇AgentWebAgentWeb并不是什么花哨的黑科技它本質(zhì)上是把WebView相關(guān)的系統(tǒng)API做了一個(gè)非常厚實(shí)的封裝。我選擇它的理由很直接。首先它把WebView、WebViewClient、WebChromeClient的初始化全部整合成了一個(gè)鏈?zhǔn)秸{(diào)用十幾行代碼就能完成核心配置。文件上傳、下載、JSBridge這些原本要自己手寫半天的東西在AgentWeb里都有對(duì)應(yīng)的模塊支撐省掉了大量模板代碼。其次它的JSBridge做得比較順手原生方法通過注解暴露給H5H5調(diào)用原生時(shí)還能傳回調(diào)函數(shù)反向調(diào)用也用quickCallJs這種簡(jiǎn)潔的方式實(shí)現(xiàn)不用自己維護(hù)一堆回調(diào)Handler。再有AgentWeb的生命周期管理和內(nèi)核回收做得相對(duì)完善對(duì)內(nèi)存泄漏的處理比我手寫方案要穩(wěn)。它還自帶了一些安全配置比如默認(rèn)關(guān)閉某些危險(xiǎn)接口、支持WebView的硬件加速開關(guān)這些細(xì)節(jié)單獨(dú)去查文檔很費(fèi)時(shí)間。當(dāng)然任何封裝庫(kù)都有其取舍AgentWeb也并非萬(wàn)能。它適合大多數(shù)常規(guī)混合開發(fā)場(chǎng)景但如果你要做極度的內(nèi)核定制或者需要特殊通信協(xié)議那還是得回到原生WebView去自己造輪子。這個(gè)定位要說清楚避免后面被帶偏。2. AgentWeb接入前的準(zhǔn)備工作2.1 依賴引入與基礎(chǔ)權(quán)限項(xiàng)目接入三方庫(kù)不算復(fù)雜但還是有點(diǎn)細(xì)節(jié)需要注意。先強(qiáng)調(diào)一點(diǎn)建議在接入前去官方倉(cāng)庫(kù)看一眼最新版本號(hào)別用我下面寫的版本號(hào)直接照抄畢竟開源庫(kù)的迭代速度不慢用最新穩(wěn)定版能少踩不少歷史遺留的bug。在模塊的build.gradle里加上agentweb-core的依賴release包記得把混淆策略調(diào)整好。默認(rèn)的R8全量混淆可能會(huì)把AgentWeb內(nèi)部的一些類名或方法名混淆掉導(dǎo)致運(yùn)行時(shí)報(bào)ClassNotFoundException最好在proguard-rules.pro里加上相關(guān)keep規(guī)則。常見的寫法是-keep class com.just.agentweb.** {*;} -dontwarn com.just.agentweb.**這里有個(gè)容易踩的細(xì)節(jié)如果項(xiàng)目同時(shí)還引用了多個(gè)WebView相關(guān)的庫(kù)它們的類包名很可能有重疊或沖突需要提前看一遍依賴樹確定版本唯一。權(quán)限方面很常規(guī)只有網(wǎng)絡(luò)權(quán)限是必須的uses-permission android:nameandroid.permission.INTERNET/如果你要實(shí)現(xiàn)拍照上傳功能記得動(dòng)態(tài)申請(qǐng)相機(jī)和存儲(chǔ)權(quán)限這部分不是AgentWeb能替代的還是得自己處理運(yùn)行時(shí)權(quán)限申請(qǐng)。2.2 初始化容器與加載頁(yè)面的標(biāo)準(zhǔn)姿勢(shì)AgentWeb強(qiáng)調(diào)一個(gè)“容器”概念。你不在Java代碼里直接new WebView而是在布局里占一個(gè)FrameLayout或者LinearLayout讓AgentWeb把WebView填充進(jìn)去。這樣做的好處是Activity銷毀時(shí)容器會(huì)隨界面一起釋放避免手動(dòng)分離父布局的繁瑣操作。我建議在布局里用一個(gè)占滿全屏的FrameLayout作為WebView父容器比如FrameLayout android:idid/web_container android:layout_widthmatch_parent android:layout_heightmatch_parent/然后初始化AgentWeb基礎(chǔ)寫法大概是這樣AgentWeb.with(this) .setAgentWebParent( mWebContainer, new LinearLayout.LayoutParams(-1, -1)) .useDefaultIndicator() .defaultWebClient(mActivity, new WebChromeClient()) .createAgentWeb() .ready() .go(url);這個(gè)方法鏈看起來簡(jiǎn)單每步的含義還是要搞明白。setAgentWebParent是指定容器第二個(gè)參數(shù)是WebView在容器里的布局參數(shù)-1、-1就是match_parent。useDefaultIndicator會(huì)生成一條默認(rèn)的頂部進(jìn)度條顏色可以自己傳一個(gè)色值進(jìn)去。defaultWebClient會(huì)設(shè)置兜底的WebViewClient和WebChromeClient第二個(gè)參數(shù)傳Activity實(shí)例是為了處理文件上傳和權(quán)限回調(diào)。createAgentWeb完成創(chuàng)建ready開始準(zhǔn)備go是真正去加載URL。順序不能亂這幾個(gè)方法少一個(gè)都不會(huì)正常工作。還有一點(diǎn)容易被忽略就是如果H5頁(yè)面里的WebSocket或定位要求HTTPS環(huán)境你在開發(fā)測(cè)試階段可能要用HTTP的調(diào)試地址。這種情況別在生產(chǎn)包里放開網(wǎng)絡(luò)安全配置測(cè)試包單獨(dú)放開就行。2.3 生命周期同步最容易漏掉的一環(huán)無論是原生WebView還是AgentWeb生命周期管理都是混合開發(fā)容器穩(wěn)定性的基石。AgentWeb把生命周期方法封裝成了一個(gè)可調(diào)用對(duì)象你只需要在Activity的對(duì)應(yīng)生命周期里去同步調(diào)用。具體來說在onResume里調(diào)用getWebLifeCycle().onResume()它內(nèi)部會(huì)處理WebView的恢復(fù)、重新顯示、音頻焦點(diǎn)等問題。在onPause里調(diào)用getWebLifeCycle().onPause()頁(yè)面切后臺(tái)時(shí)能及時(shí)停止正在執(zhí)行的JS和視頻播放。在onDestroy里調(diào)用getWebLifeCycle().onDestroy()這是釋放WebView資源、避免內(nèi)存泄漏的關(guān)鍵。寫起來像這樣Override protected void onResume() { super.onResume(); if (mAgentWeb ! null) { mAgentWeb.getWebLifeCycle().onResume(); } } Override protected void onPause() { super.onPause(); if (mAgentWeb ! null) { mAgentWeb.getWebLifeCycle().onPause(); } } Override protected void onDestroy() { if (mAgentWeb ! null) { mAgentWeb.getWebLifeCycle().onDestroy(); } super.onDestroy(); }很多線上WebView問題其實(shí)都源于沒做生命周期同步頁(yè)面切后臺(tái)后音樂還在放、視頻聲音停不下來都是這里漏了。還有一個(gè)高頻場(chǎng)景是返回鍵處理。如果H5內(nèi)部有層級(jí)跳轉(zhuǎn)比如從一個(gè)商品列表頁(yè)點(diǎn)進(jìn)了詳情頁(yè)用戶按返回鍵時(shí)應(yīng)該先讓W(xué)ebView回退而不是直接退出當(dāng)前Activity。AgentWeb提供了BackHandledWebView來處理這個(gè)邏輯通過mAgentWeb.back()判斷是否可以執(zhí)行WebView回退。同時(shí)還要處理H5頁(yè)面里的模態(tài)彈窗否則WebView的goBack方法可能失效。Override public void onBackPressed() { if (mAgentWeb ! null mAgentWeb.back()) { return; } super.onBackPressed(); }這里要特別說明mAgentWeb.back()返回true表示網(wǎng)頁(yè)可以繼續(xù)回退返回false才表示已經(jīng)回退到了入口頁(yè)面。3. 混合開發(fā)核心功能通信、上傳與登錄態(tài)3.1 JsBridge雙向通信方案既然叫混合開發(fā)Android原生和H5之間的通信就是繞不開的核心。AgentWeb對(duì)這塊的支持做得比較順手我直接用實(shí)例拆開講。先看H5調(diào)用原生的情況。假設(shè)你在Activity里有一個(gè)JsInterface類public class JsInterface { JavascriptInterface public void showToast(String msg) { runOnUiThread(() - Toast.makeText(mActivity, msg, Toast.LENGTH_SHORT).show()); } }然后通過AgentWeb暴露給H5mAgentWeb.getJsInterfaceHolder().addJavaObject(app, new JsInterface());H5那邊就可以直接寫window.app.showToast(hello world);這里有一個(gè)歷史教訓(xùn)必須提。從Android 4.2開始被H5調(diào)用的方法必須顯式加JavascriptInterface注解否則WebView會(huì)直接忽略這個(gè)接口。我當(dāng)時(shí)在調(diào)試時(shí)遇到過明明調(diào)用了卻一點(diǎn)反應(yīng)都沒有的情況排查了半天才發(fā)現(xiàn)是注解漏加了。H5調(diào)用原生還可以傳回調(diào)函數(shù)這在AgentWeb里是通過特定格式的JsCallJava來支持的。簡(jiǎn)單場(chǎng)景下直接傳字符串參數(shù)就夠用但復(fù)雜場(chǎng)景還是建議在原生側(cè)做好參數(shù)解析和線程切換。再看原生調(diào)用H5場(chǎng)景一般是原生收到某個(gè)事件后通知頁(yè)面刷新。AgentWeb把這條通道封裝得很短一行調(diào)用即可mAgentWeb.getJsEntraceAccess().quickCallJs(refreshPage, arg1, arg2);H5側(cè)只要定義同名的全局方法refreshPage就能收到參數(shù)并執(zhí)行回調(diào)。這個(gè)調(diào)用是異步執(zhí)行的不能在主線程假設(shè)返回值已經(jīng)同步拿到。通信安全這塊一定要重視。因?yàn)閃ebView的JS接口一旦暴露加載的頁(yè)面是有能力調(diào)用它的。不建議把a(bǔ)ddJavaObject的識(shí)別名設(shè)置得過于通用還要在H5調(diào)用時(shí)對(duì)來源URL做白名單校驗(yàn)。比如只放行公司域名下的頁(yè)面其他域名一律拒絕調(diào)用敏感接口這是被薅過一次流量后沉淀下來的經(jīng)驗(yàn)。3.2 文件上傳和下載的完整實(shí)現(xiàn)說完通信再講一個(gè)平時(shí)最容易被忽略、但真做起來很繁瑣的功能——文件上傳。H5里常見的場(chǎng)景是上傳頭像、上傳身份證照片、上傳視頻這些操作最終都要落到原生側(cè)的文件選擇器。重寫WebChromeClient的onShowFileChooser是關(guān)鍵。AgentWeb默認(rèn)的WebChromeClient其實(shí)已經(jīng)幫你做了一層處理但如果你要自定義UI或者兼容某些機(jī)型還得自己重寫。大致流程是先接收WebChromeClient的回調(diào)參數(shù)創(chuàng)建選擇圖片或視頻的Intent再通過startActivityForResult啟動(dòng)系統(tǒng)文件選擇器最后在onActivityResult里把選中的Uri交給回調(diào)。private ValueCallbackUri[] mUploadMessage; Override public boolean onShowFileChooser(WebView webView, ValueCallbackUri[] filePathCallback, WebChromeClient.FileChooserParams fileChooserParams) { mUploadMessage filePathCallback; Intent intent fileChooserParams.createIntent(); startActivityForResult(intent, REQUEST_FILE_CHOOSER); return true; } Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { if (requestCode REQUEST_FILE_CHOOSER mUploadMessage ! null) { mUploadMessage.onReceiveValue(WebChromeClient.FileChooserParams.parseResult(resultCode, data)); mUploadMessage null; } }這項(xiàng)實(shí)現(xiàn)里最容易出的問題就是回調(diào)對(duì)象沒有置空導(dǎo)致二次點(diǎn)擊無響應(yīng)或者是用戶在取消選擇時(shí)沒有通知WebView頁(yè)面會(huì)一直卡在等待狀態(tài)。每次回調(diào)完成后記得馬上給mUploadMessage賦null。下載功能相對(duì)簡(jiǎn)單。主要是給WebView設(shè)置DownloadListener在onDownloadStart里接管下載邏輯發(fā)起原生下載任務(wù)。這里有個(gè)業(yè)務(wù)上的考慮很多App其實(shí)不希望H5直接下載文件到本地而是希望跳轉(zhuǎn)到App內(nèi)的預(yù)覽頁(yè)你可以在onDownloadStart里做判斷符合預(yù)覽條件的走預(yù)覽不符合的走原生下載器。3.3 Cookie同步與登錄態(tài)保持H5頁(yè)面和原生頁(yè)面在一個(gè)App里并存最煩人的就是登錄態(tài)不一致。原生登錄了H5打開卻要求重新登錄這對(duì)用戶體驗(yàn)的傷害是致命的。WebView的Cookie管理和原生網(wǎng)絡(luò)庫(kù)的Cookie默認(rèn)是隔離的。AgentWeb雖然封裝了很多東西但Cookie同步這塊還是需要你自己動(dòng)手。核心方案是用系統(tǒng)CookieManager做橋梁。當(dāng)原生登錄成功后把服務(wù)端下發(fā)的Cookie同步到WebView的CookieManager里。拿到正常Cookie后調(diào)用CookieManager.getInstance().setAcceptCookie(true); CookieManager.getInstance().setCookie(https://example.com, cookieString);在Android 5.0之后還有第三方的Cookie策略需要打開if (Build.VERSION.SDK_INT Build.VERSION_CODES.LOLLIPOP) { CookieManager.getInstance().setAcceptThirdPartyCookies(webView, true); }這里有個(gè)細(xì)節(jié)網(wǎng)上很多源碼直接setAcceptThirdPartyCookies為true但這會(huì)增加跨站追蹤的風(fēng)險(xiǎn)建議結(jié)合業(yè)務(wù)場(chǎng)景決定是否放開。最后還有一個(gè)同步時(shí)機(jī)的問題。當(dāng)你用AgentWeb加載頁(yè)面時(shí)最好在WebViewClient的onPageStarted之前就確認(rèn)Cookie已經(jīng)set進(jìn)去否則頁(yè)面首次請(qǐng)求可能拿不到登錄態(tài)。如果WebView已經(jīng)加載了一部分頁(yè)面中途才同步Cookie得通過刷新一次頁(yè)面來讓Cookie生效。Cookie同步的寫法不難難的是理解為什么需要這樣。WebView內(nèi)部維護(hù)了一套獨(dú)立的Cookie存儲(chǔ)和Retrofit、OkHttp那套CookieJar是兩碼事你不手動(dòng)同步兩邊登錄態(tài)就是各管各的。想通這一點(diǎn)以后遇到H5頁(yè)面反復(fù)要求登錄的問題排查思路就清晰了。4. 加載性能與體驗(yàn)優(yōu)化4.1 緩存策略的幾個(gè)實(shí)用選擇混合開發(fā)里最影響用戶體驗(yàn)的就是加載速度。WebView每次拉一個(gè)全新的HTML、JS、CSS等它渲染完用戶可能已經(jīng)不耐煩了。緩存策略是優(yōu)化這條鏈路最直接的手段。AgentWeb默認(rèn)的緩存模式可能不是最優(yōu)的需要配合WebSettings的setCacheMode來控制。我常用的組合是在應(yīng)用啟動(dòng)后的首個(gè)頁(yè)面用LOAD_CACHE_ELSE_NETWORK讓用戶盡可能秒開頁(yè)面在需要強(qiáng)制獲取最新數(shù)據(jù)的頁(yè)面用LOAD_NO_CACHE保證數(shù)據(jù)一致性。WebSettings settings mAgentWeb.getWebCreator().getWebView().getSettings(); settings.setCacheMode(WebSettings.LOAD_DEFAULT);更深一層的優(yōu)化是做離線包預(yù)加載。把H5項(xiàng)目打成zip包推到本地WebView優(yōu)先加載本地資源再通過更新接口拉增量補(bǔ)丁。這個(gè)方案雖然要額外維護(hù)資源版本管理但對(duì)加載速度的提升是質(zhì)的飛躍電商大促活動(dòng)頁(yè)基本都會(huì)用。還有一個(gè)被忽略的性能點(diǎn)DNS和TCP建連。如果你能提前知道H5要用到的域名可以在App啟動(dòng)后做預(yù)連接。Android原生層面沒有直接暴露Socket連接池的接口但可以通過提前加載一個(gè)隱藏的WebView來預(yù)熱內(nèi)核。這個(gè)做法比較粗暴好處是代碼量少壞處是會(huì)多占內(nèi)存適合用在小流量高價(jià)值的場(chǎng)景里。4.2 加載狀態(tài)、錯(cuò)誤頁(yè)與JS注入時(shí)機(jī)頁(yè)面加載狀態(tài)是混合開發(fā)里最容易影響體驗(yàn)的盲區(qū)。H5加載可能幾秒也可能十幾秒期間如果沒有任何反饋用戶會(huì)以為卡死了。AgentWeb的默認(rèn)進(jìn)度條能覆蓋基礎(chǔ)反饋但你還需要一個(gè)超時(shí)兜底機(jī)制?？梢越oWebChromeClient的onProgressChanged設(shè)置閾值比如進(jìn)度超過80%就認(rèn)為頁(yè)面基本加載完成此時(shí)隱藏loading框。同時(shí)另開一個(gè)計(jì)時(shí)器在4到5秒內(nèi)如果沒有觸發(fā)onProgressChanged就給用戶彈一個(gè)弱提示讓用戶知道頁(yè)面還在加載中。網(wǎng)絡(luò)錯(cuò)誤是另一個(gè)?？?。onReceivedError里要判斷errorCode常見的-6、-7這類網(wǎng)絡(luò)錯(cuò)誤可以統(tǒng)一展示自定義錯(cuò)誤頁(yè)。如果只是某個(gè)子資源加載失敗不建議整頁(yè)替換成錯(cuò)誤頁(yè)否則頁(yè)面主內(nèi)容可用但被錯(cuò)誤提示擋住體驗(yàn)更差。JS注入時(shí)機(jī)特別強(qiáng)調(diào)一下。很多開發(fā)者喜歡在onPageFinished里執(zhí)行JS但這個(gè)回調(diào)在AgentWeb里也存在觸發(fā)不準(zhǔn)的坑。實(shí)際項(xiàng)目里有些網(wǎng)站在onPageFinished之后還會(huì)繼續(xù)加載異步資源和二次渲染你需要用DOMContentLoaded或者輪詢判斷頁(yè)面整體的JS執(zhí)行狀態(tài)。對(duì)業(yè)務(wù)關(guān)鍵的JS注入建議用runOnUiThread包一層再調(diào)用保證執(zhí)行時(shí)主線程空閑且頁(yè)面渲染引擎已經(jīng)就緒。4.3 安全與隱私配置關(guān)于WebView的默認(rèn)配置網(wǎng)上很多模板代碼直接打開JavaScriptEnabled、打開DOMStorageEnabled、打開AllowFileAccess看上去能用安全隱患卻不小。我的習(xí)慣是盡量遵循最小權(quán)限原則。默認(rèn)情況下不打開FileAccess因?yàn)橐坏〩5代碼被注入或者XSS攻擊攻擊者就能通過file協(xié)議讀取本地文件。如果業(yè)務(wù)確實(shí)需要打開遠(yuǎn)程頁(yè)面的文件訪問能力也應(yīng)該做域名白名單限制。AgentWeb內(nèi)部對(duì)常用安全配置做了封裝基于它的默認(rèn)配置去微調(diào)比從零手寫靠譜。定位權(quán)限最大的問題是靜默授權(quán)。H5頁(yè)面調(diào)用getCurrentPositionWebView會(huì)直接彈定位授權(quán)框用戶可以選擇同意或拒絕。但有些WebView版本會(huì)自動(dòng)繼承原生的定位權(quán)限導(dǎo)致用戶還沒明白怎么回事定位就被獲取了。這種情況要在自己實(shí)現(xiàn)GeolocationPermissions回調(diào)時(shí)做精確控制至少讓用戶知道頁(yè)面要做什么。5. 高頻問題排查與個(gè)人避坑實(shí)錄5.1 一口氣理清6個(gè)高頻問題我把這段時(shí)間在群里看到、自己踩過的高頻問題整理成一個(gè)速查表寫代碼的時(shí)候?qū)φ罩橐槐槟苁∠虏簧倥挪闀r(shí)間?，F(xiàn)象可能原因解決方案H5調(diào)用原生方法無響應(yīng)缺少JavascriptInterface注解或混淆后類名被混淆檢查注解、添加keep規(guī)則返回鍵直接退出ActivityWebView內(nèi)部有歷史棧但未攔截返回實(shí)現(xiàn)BackHandledWebView、調(diào)用mAgentWeb.back()文件上傳按鈕沒反應(yīng)未重寫onShowFileChooser或回調(diào)未置空重寫回調(diào)、onActivityResult里正確回調(diào)頁(yè)面登錄態(tài)丟失WebView的Cookie和原生網(wǎng)絡(luò)Cookie未同步用CookieManager手動(dòng)同步頁(yè)面白屏/加載失敗HTTPS混合內(nèi)容被限制、網(wǎng)絡(luò)錯(cuò)誤配置MixedContentMode、自定義錯(cuò)誤頁(yè)Activity關(guān)閉后內(nèi)存不降WebView未destroy、容器未移除getWebLifeCycle().onDestroy()、置空引用這幾個(gè)問題里登錄態(tài)丟失和白屏最容易在正式環(huán)境才暴露測(cè)試環(huán)境網(wǎng)絡(luò)好、域名干凈往往發(fā)現(xiàn)不了問題。我建議在上線前專門跑一個(gè)弱網(wǎng)和切后臺(tái)的測(cè)試用例集把WebView的問題提前暴露掉。5.2 我踩過的幾個(gè)真實(shí)坑第一個(gè)坑是WebView重復(fù)創(chuàng)建導(dǎo)致的頁(yè)面錯(cuò)亂。早期某個(gè)金融類App我在Activity里直接用成員變量持有AgentWeb實(shí)例結(jié)果屏幕旋轉(zhuǎn)時(shí)Activity重建舊的WebView沒銷毀新的又創(chuàng)建了頁(yè)面上會(huì)出現(xiàn)兩個(gè)WebView疊加的詭異現(xiàn)象。后面改成由容器驅(qū)動(dòng)、在onDestroy里徹底釋放AgentWeb并置空所有引用才算穩(wěn)定下來。第二個(gè)坑是JS調(diào)用時(shí)機(jī)太早。有些H5頁(yè)面在iOS上正常在Android上卻偶爾拿不到原生返回的數(shù)據(jù)。排查后發(fā)現(xiàn)是原生調(diào)用quickCallJs的時(shí)間點(diǎn)過早H5那邊的全局方法還沒掛載完。解決方案是在onPageFinished后延遲100毫秒再調(diào)用或者讓H5主動(dòng)發(fā)起拉取原生被動(dòng)返回?，F(xiàn)在遇到不確定的時(shí)序我都默認(rèn)改成H5主動(dòng)拉模式寧可多一次通信也不要搶執(zhí)行時(shí)機(jī)。第三個(gè)坑比較冷門是部分系統(tǒng)ROM的WebView多進(jìn)程崩潰。某次灰度期間小部分用戶反饋打開H5頁(yè)面直接閃退日志顯示是render進(jìn)程崩潰。這類問題的根因可能是ROM的WebView實(shí)現(xiàn)和AgentWeb的某些默認(rèn)配置沖突。我的兜底方案是在崩潰時(shí)捕獲異常通過自定義頁(yè)面引導(dǎo)用戶重啟頁(yè)面并主動(dòng)提示升級(jí)系統(tǒng)WebView組件。雖不是銀彈但至少能把崩潰影響范圍壓到最小。第四個(gè)坑是文件選擇回調(diào)的重復(fù)觸發(fā)。當(dāng)用戶在系統(tǒng)文件選擇器里點(diǎn)擊取消時(shí)某些機(jī)型會(huì)觸發(fā)兩次onShowFileChooser回調(diào)如果沒有把舊回調(diào)清掉第二次進(jìn)入時(shí)會(huì)拿到臟數(shù)據(jù)表現(xiàn)在上傳頁(yè)面上就是選了圖片卻沒反應(yīng)。這個(gè)問題的處理很簡(jiǎn)單每次新回調(diào)進(jìn)來前先判斷mUploadMessage是否為空不為空就先給它傳null防止舊回調(diào)阻塞新回調(diào)。5.3 還沒完后續(xù)系列還能聊什么到這一步AgentWeb的基礎(chǔ)接入和常用功能基本覆蓋了但這個(gè)話題其實(shí)還遠(yuǎn)沒講完。我后續(xù)計(jì)劃把WebView容器組件化改造、統(tǒng)一JSBridge協(xié)議、多WebView實(shí)例復(fù)用以及Native與H5的數(shù)據(jù)埋點(diǎn)上報(bào)單獨(dú)拎出來寫每個(gè)點(diǎn)單獨(dú)成篇會(huì)比這次的一鍋燉更深入。特別是WebView容器組件化跨模塊跳轉(zhuǎn)H5的場(chǎng)景越來越常見如果每個(gè)模塊都自己初始化一個(gè)AgentWeb不僅代碼重復(fù)連接數(shù)、Cookie管理都會(huì)亂套。業(yè)內(nèi)比較常見的做法是做統(tǒng)一的WebView容器SDK上層業(yè)務(wù)只傳URL和各色參數(shù)容器內(nèi)部負(fù)責(zé)所有WebView邏輯和埋點(diǎn)上報(bào)。這個(gè)改造思路我會(huì)在系列第二篇里詳細(xì)展開。最后說點(diǎn)個(gè)人體會(huì)。AgentWeb這種封裝庫(kù)用起來確實(shí)省心但也別養(yǎng)成只會(huì)調(diào)API的習(xí)慣。WebView的官方文檔、不同系統(tǒng)版本的行為差異有時(shí)間還是要翻一翻。封裝庫(kù)幫你擋掉了大部分雷但理解底層原理你才能在被封裝庫(kù)“攔不住”的極端問題面前穩(wěn)住陣腳。混合開發(fā)沒有銀彈把基礎(chǔ)原理和框架特性兩頭吃透頁(yè)面才不會(huì)在你最忙的時(shí)候突然出幺蛾子。