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