背景

大家如果經(jīng)歷過(guò)Hybrid項(xiàng)目的開(kāi)發(fā)，即項(xiàng)目中涉及到H5與Native之間的交互，那么很有可能會(huì)遇到各種各樣的H5容器。為什么會(huì)有那么多各種各樣的容器呢...這也是輪子多的通病了，輪子多到業(yè)務(wù)方不知道選哪個(gè)。當(dāng)然，也有可能大家壓根就不會(huì)使用到H5容器，直接用系統(tǒng)WebView就完事兒了，比如我的前東家就是這樣做的。那這篇文章的主題就是與前者相關(guān)的：當(dāng)項(xiàng)目中擁有很多個(gè)H5容器時(shí)，怎樣封裝才能讓業(yè)務(wù)側(cè)用得爽呢？ 

下面按慣例，拋出這篇文章要解決的三個(gè)問(wèn)題：

• 如何優(yōu)雅地提供接口調(diào)用？
• 怎樣封裝多個(gè)不同類型的H5容器？
• 這樣的架構(gòu)能帶來(lái)什么樣的好處？

術(shù)語(yǔ)對(duì)齊

探索

如何優(yōu)雅地提供接口調(diào)用？

業(yè)務(wù)側(cè)調(diào)用的接口其實(shí)很有限，可以說(shuō)90%的業(yè)務(wù)都只是打開(kāi)一個(gè)網(wǎng)頁(yè)而已。

我們根據(jù)業(yè)務(wù)需要新建一個(gè)接口類：

/**
 * WebPage服務(wù)接口類
 */
public interface IWebPageService {
    /**
     * 打開(kāi)url
     * @param url
     */
    void openUrl(String url);

    /**
     * 創(chuàng)建Fragment內(nèi)置到某頁(yè)面中使用
     * @return
     */
    Fragment buildFragment(String url, Context context);

    /**
     * 獲取當(dāng)前Url
     * @return
     */
    String getCurrentUrl();

    /**
     * 給h5發(fā)通知
     * @param eventData
     * @param eventName
     */
    void postNotificationToJS(String eventName, String eventData);
}

以上列舉了4個(gè)非常常見(jiàn)的接口。如果有需要，還可以擴(kuò)展其它的，比如設(shè)置容器生命周期相關(guān)的監(jiān)聽(tīng)、設(shè)置H5發(fā)通知來(lái)時(shí)的監(jiān)聽(tīng)等等。拿openUrl的實(shí)現(xiàn)舉例，實(shí)現(xiàn)類通過(guò)url中的參數(shù)判斷需要打開(kāi)A容器還是B容器。

@Override
public void openUrl(String url) {
     // 若url中含有A參數(shù)，則用A容器打開(kāi)
     // if (urlParamHasA) {
        // startAContainer();
     // } else {
        // 否則用B容器打開(kāi)
        // startBContainer();
     //}
}

這就從接口層這一層面屏蔽了內(nèi)部框架容器。其它接口也是類似，原則就是不讓業(yè)務(wù)側(cè)感知到具體的實(shí)現(xiàn)細(xì)節(jié)，而不是跳個(gè)頁(yè)面還需要知道這個(gè)url是要用A容器打開(kāi)還是B容器打開(kāi)。在應(yīng)用啟動(dòng)時(shí)，可以將實(shí)現(xiàn)類注入到公共依賴中去，也可以通過(guò)ARouter等框架實(shí)現(xiàn)依賴注入，方便業(yè)務(wù)側(cè)的調(diào)用。

怎樣封裝多個(gè)不同類型的H5容器容器？

整體架構(gòu)

先上一張圖：

接口層上面已經(jīng)講過(guò)了，這里我們直接看容器層。

通用容器

第一層就是我們抽出來(lái)的通用容器，WebPageActivity與WebPageFragement。項(xiàng)目中，不管是哪個(gè)H5框架容器，勢(shì)必都是用Activity或者Fragment來(lái)承載的，所以我們相應(yīng)的也需要有這兩者作為父類去進(jìn)行封裝。而通用容器中，最重要的職責(zé)就是去執(zhí)行通用邏輯，即每個(gè)框架容器都需要執(zhí)行的邏輯。

通用職責(zé)可以有以下幾點(diǎn)：

• 設(shè)置頁(yè)面屬性，包括window flag、activity的主題等。
• 解析url，將url中的關(guān)鍵參數(shù)記錄下來(lái)，從而決定以哪種策略渲染UI。比如可以通過(guò)disableNav參數(shù)決定是否顯示導(dǎo)航欄，通過(guò)statusBarStyle參數(shù)決定狀態(tài)欄的風(fēng)格等。
• 控制通用UI的渲染，包括何時(shí)改變TitleBar、何時(shí)加載/隱藏Loading，何時(shí)渲染異常態(tài)UI等。
• 決定框架容器加載時(shí)的邏輯順序，如setContentView()->loadUrl()。
• 接收生命周期事件與系統(tǒng)回調(diào)事件，并且分發(fā)回調(diào)。生命周期就不用說(shuō)了，系統(tǒng)回調(diào)這里特指onActivityResult、onRequestPermissionResult這類事件，然后將結(jié)果分發(fā)給各listener。

拿WebPageActivity#onCreate舉例：

@Override
protected void onCreate(Bundle savedInstanceState) {
    // setWindowFlags(); 設(shè)置window屬性
    // setTheme(); 設(shè)置主題
    // setTransition(); 設(shè)置轉(zhuǎn)場(chǎng)動(dòng)畫(huà)
    
    super.onCreate(savedInstanceState);

    // parseUrl(); 解析url
    // initCommonUI(); 渲染通用UI 比如TitleBar、底部導(dǎo)航欄等
    
    setContentView();
    loadUrl();
}

protected abstract void setContentView();

protected abstract void loadUrl();

我們可以將設(shè)置window屬性、設(shè)置主題這些通用行為放在通用容器中執(zhí)行，而setContentView與loadUrl交由框架容器去執(zhí)行。setContentView是因?yàn)椴煌娜萜?，layout xml可能是不一樣的。loadUrl是因?yàn)槊總€(gè)容器用WebView去加載url的方式也可能不同，無(wú)法統(tǒng)一。類似的行為，若執(zhí)行時(shí)機(jī)可統(tǒng)一，則由通用容器統(tǒng)一執(zhí)行時(shí)機(jī)，比如setContentView與loadUrl。若時(shí)機(jī)也沒(méi)法確定，甚至邏輯只會(huì)存在于某個(gè)框架容器中，那么就要寫到子類中去了。

框架容器

圖中第二層的容器A、容器B、容器C指的就是框架容器。有了通用容器承載共同的邏輯后，框架容器需要做的事情就比較少了。只需要加載各自的布局，初始化WebView，然后將url加載到WebView中就可以了（除非有某個(gè)框架容器需要特殊適配，那就得寫些額外的代碼）。具體的實(shí)現(xiàn)需要根據(jù)項(xiàng)目中框架容器的使用方式來(lái)確定。

基礎(chǔ)組件

第三層表示基礎(chǔ)組件。這里只列一些常見(jiàn)的基礎(chǔ)組件。

• Components：各類UI組件，比如TitleBar與異常態(tài)控件。
• JS Bridge：JS Bridge可以單獨(dú)放到一個(gè)類中做收口，然后分發(fā)給各個(gè)listener。listenr通過(guò)接口層進(jìn)行注入。
• WebViewClient：WebViewClient在日常開(kāi)發(fā)中算是維護(hù)的非常頻繁的一個(gè)類，職責(zé)主要是在shouldOverrideUrlLoading重定向時(shí)對(duì)url進(jìn)行攔截，以及根據(jù)相應(yīng)的生命周期回調(diào)（onPageStarted、onPageFinished、onReceviedError等）進(jìn)行l(wèi)oading或異常態(tài)UI的渲染時(shí)。若每個(gè)框架容器可以設(shè)置同一個(gè)WebViewClient，那就非常方便了，只要改一處地方，所有容器就都生效了。
• Interceptors：即用于WebView重定向時(shí)的攔截器。像我的項(xiàng)目中會(huì)有很多攔截相關(guān)的邏輯，比如將A頁(yè)面攔截跳轉(zhuǎn)到原生頁(yè)面，就需要在重定向時(shí)進(jìn)行攔截。但邏輯堆疊太多會(huì)提高維護(hù)的成本，因此建議用責(zé)任鏈模式（沒(méi)用過(guò)的同學(xué)可以百度一下，很簡(jiǎn)單滴~）去處理攔截的這塊邏輯。
• Managers、Listeners：容器中總是需要很多輔助類去來(lái)幫助我們?nèi)ス芾硪恍〇|西，比如WebView的管理，url的管理。這里就不延伸了，根據(jù)實(shí)際需要去加。Listener也一樣，關(guān)于容器生命周期的Listener，與JS Bridge交互相關(guān)的Listener，都可以通過(guò)接口層去實(shí)現(xiàn)注入與銷毀。

當(dāng)然，除此之外，根據(jù)每個(gè)項(xiàng)目的完整度與負(fù)責(zé)度，還會(huì)衍生出很多基礎(chǔ)組件。比如H5的監(jiān)控體系，H5的預(yù)加載體系，以及WebView預(yù)創(chuàng)建相關(guān)的緩存體系等。他們作為框架容器共同的底座承擔(dān)相應(yīng)的職責(zé)。

這樣的架構(gòu)能帶來(lái)什么樣的好處？

• 對(duì)業(yè)務(wù)側(cè)而言，接口統(tǒng)一收口到IWebPageService中去，調(diào)用方式更加簡(jiǎn)單明了，不需要再關(guān)注容器的具體類型。
• 對(duì)容器側(cè)而言，代碼邏輯性清晰的同時(shí)，有效降低了日后的維護(hù)成本與開(kāi)發(fā)成本。Loading、異常態(tài)不需要再在各類容器中重復(fù)寫N遍，各種url params都統(tǒng)一收口到通用容器中去，重定向攔截邏輯也不再需要重復(fù)寫N遍...總而言之，通用邏輯統(tǒng)一給通用容器與基礎(chǔ)組件去承擔(dān)，框架容器的代碼，都是各框架容器所“獨(dú)有”的。

到此這篇關(guān)于Android H5通用容器架構(gòu)設(shè)計(jì)詳解的文章就介紹到這了,更多相關(guān)Android H5容器架構(gòu)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論