前言

在開發(fā)webview的loading效果的時(shí)候會(huì)有一些問題，這邊記錄一些碰到的常見的問題，并且設(shè)計(jì)出一套Loading的方案來解決相關(guān)的問題。

1. loading的選擇

開發(fā)loading效果的原因在于webview加載頁面的時(shí)候，有時(shí)候會(huì)耗時(shí)，導(dǎo)致不顯示內(nèi)容又沒有任何提示，效果不太好，所以需要在webview使用的地方加上loading的效果，其實(shí)更好的體驗(yàn)是還要加上EmptyView，我這邊主要就以loadingView來舉例。

那開發(fā)這loading基本有兩種方式，一種是使用window，也就是Dialog這些彈窗的方式，在加載時(shí)彈出彈窗，在加載結(jié)束后關(guān)閉彈窗，有些人可能會(huì)封裝好一些loading彈窗，然后在這里復(fù)用。

這個(gè)方法的好處是如果你封裝好了，能直接復(fù)用，省去很多代碼。缺點(diǎn)也很明顯，彈窗彈出的時(shí)候是否處于一個(gè)不允許交互的情況，如果這個(gè)流程有問題，那便一直無法和頁面做交互

另一種方法是直接在webview的上層覆蓋一個(gè)LoadingView，webview是繼承FrameLayout，就是也可以直接addView。

這個(gè)方法的好處就是不會(huì)出現(xiàn)上面的問題，因?yàn)槲襴ebview所在的頁面關(guān)閉了，它的loading也會(huì)跟著一起消失，而且顯示的效果會(huì)好一些。缺點(diǎn)就是可能一些特殊的webview你會(huì)單獨(dú)做操作，導(dǎo)致會(huì)多寫一些代碼

沒有說哪種方法是實(shí)現(xiàn)會(huì)比較好，主要看使用的場(chǎng)景和具體的需求。

2. loading顯示時(shí)機(jī)的問題

我們做loading的思路就是加載開始的時(shí)候顯示，加載完成之后關(guān)閉，那選擇這個(gè)開始的時(shí)機(jī)和結(jié)束的時(shí)機(jī)就比較重要了。

大多數(shù)人都會(huì)直接使用WebViewClient的onPageStarted回調(diào)作為開始時(shí)機(jī)，把onPageFinished的回調(diào)，覺得直接這樣寫就行了，無所謂，反正webview會(huì)出手。

這個(gè)思路確實(shí)能在正常的情況下顯示正常，但是在弱網(wǎng)情況下呢？復(fù)雜的網(wǎng)絡(luò)環(huán)境下呢？有些人可能也會(huì)碰到一些這樣的情況，loading的show寫在onPageStarted中，加載時(shí)會(huì)先白屏一下，才開始顯示loading，但是這個(gè)白屏的時(shí)間很短，所以覺得無所謂。但有沒有想過這在正常網(wǎng)絡(luò)環(huán)境下的白屏一下放到復(fù)雜的有問題的網(wǎng)絡(luò)環(huán)境中會(huì)被放大成什么樣。

這個(gè)加載過程其實(shí)大體分為兩個(gè)階段，從loadurl到WebViewClient的onPageStarted和從WebViewClient的從onPageStarted到onPageFinished

所以我的做法是在loadurl的時(shí)候去start loading，而不是WebViewClient的onPageStarted回調(diào)的時(shí)候。

這個(gè)是開始的時(shí)機(jī)，那結(jié)束的時(shí)機(jī)會(huì)不會(huì)有問題，還真可能有，有時(shí)候你會(huì)發(fā)現(xiàn)一種現(xiàn)象，加載完之后，你的H5內(nèi)容和loading會(huì)同時(shí)顯示一段時(shí)間，才關(guān)閉loading（幾年前有碰到過，寫這篇文章的時(shí)候測(cè)試沒有復(fù)現(xiàn)過，不知道是不是版本更新修復(fù)了這個(gè)問題）

那如果碰到這個(gè)問題該怎么解決呢？

碰到這個(gè)問題，說明onPageFinished的回調(diào)時(shí)機(jī)在頁面加載完之后，所以不可信。我們知道除了這個(gè)方法之外，BaseWebChromeClient也有個(gè)方法onProgressChanged表示加載的進(jìn)度，當(dāng)然這個(gè)進(jìn)度你拿去判斷也會(huì)有問題，因?yàn)樗⒉粫?huì)每次都會(huì)回調(diào)100給你，可能有時(shí)候給你96,就沒了。我以前的做法是雙重判斷，判斷是進(jìn)度先返回>85還是onPageFinished先調(diào)用，只要有一個(gè)調(diào)用，我都會(huì)關(guān)閉loading

3. 體驗(yàn)優(yōu)化

當(dāng)然處理好顯示的關(guān)閉的時(shí)機(jī)還不行，想想如果在loadurl中show loading會(huì)怎樣，沒錯(cuò)，就算網(wǎng)速快的情況，頁面讓loading一閃而過，那這樣所造成的體驗(yàn)就很不好，所以我們需要做一個(gè)延遲顯示，我個(gè)人習(xí)慣是延遲0.5秒。當(dāng)然延遲顯示也會(huì)有延遲顯示的問題，比如延遲到0.3秒的時(shí)候你關(guān)閉頁面怎么辦，再0.2秒之后我總不不能讓它顯示吧。

說了顯示，再說關(guān)閉。無論是onPageFinished方法還是onProgressChanged，你能保證它一定會(huì)有回調(diào)嗎？這些代碼都不是可控的，里面會(huì)不會(huì)出現(xiàn)既沒拋異常，也沒給回調(diào)的情況。也許有人說不會(huì)的，我都用了這么多年了，沒出現(xiàn)過這種問題，但是既然不是我們可控的代碼，加一層保險(xiǎn)總沒錯(cuò)吧。

其實(shí)這也簡(jiǎn)單，定一個(gè)timeout的邏輯就行，我個(gè)人是定義10秒超時(shí)時(shí)間，如果10秒后沒有關(guān)閉loading，我就手動(dòng)關(guān)閉并顯示emptyview的error頁面。這個(gè)超時(shí)時(shí)間還是比較實(shí)用，最上面說了loading的選擇，如果你的loading做成view，那即便沒有這個(gè)邏輯也影響不大，最多就會(huì)菊花一直轉(zhuǎn)，但如果你是window做的，沒有超時(shí)的處理，又沒有回調(diào)，那你的window會(huì)一直顯示卡住頁面。

4. loading最終設(shè)計(jì)效果

基于上面的情況，我寫個(gè)Demo，首先loading的選擇，我選擇基于view，所以要寫個(gè)自定義View

public class WebLoadingView extends RelativeLayout {
    private Context mContext;
    // 0：正常狀態(tài)；1：loading狀態(tài)；2：顯示loadingview狀態(tài)
    private AtomicInteger state;  
    private Handler lazyHandler;
    private Handler timeOutHandler;
    public BaseWebLoadingView(Context context) {
        super(context);
        init(context);
    }
    public BaseWebLoadingView(Context context, AttributeSet attrs) {
        super(context, attrs);
        init(context);
    }
    public BaseWebLoadingView(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        init(context);
    }
    private void init(Context context) {
        this.mContext = context;
        state = new AtomicInteger(0);
        lazyHandler = new Handler(Looper.getMainLooper());
        timeOutHandler = new Handler(Looper.getMainLooper());
        initView();
    }
    private void initView() {
        LayoutInflater.from(mContext).inflate(R.layout.demo_loading, this, true);
    }
    public void show() {
        if (state.compareAndSet(0, 1)) {
            lazyHandler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    if (state.compareAndSet(1, 2)) {
                        setVisibility(View.VISIBLE);
                    }
                }
            }, 500);
            timeOutHandler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    close();
                }
            }, 10000);
        }
    }
    public void close() {
        state.set(0);
        setVisibility(View.GONE);
        try {
            lazyHandler.removeCallbacksAndMessages(null);
            timeOutHandler.removeCallbacksAndMessages(null);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

代碼應(yīng)該都比較好理解，就不過多介紹了，然后在自定義webview的loadurl里面展示

@Override
public void loadUrl(String url) {
    if (webLoadingView != null && !TextUtils.isEmpty(url) && url.startsWith("http")) {
        webLoadingView.show();
    }
    super.loadUrl(url);
}

寫這里主要是有個(gè)地方要注意，就是調(diào)方法時(shí)也會(huì)執(zhí)行這個(gè)loadUrl，所以要判斷是加載網(wǎng)頁的時(shí)候才顯示loading。

總結(jié)

總結(jié)幾個(gè)重點(diǎn)吧，第一個(gè)是對(duì)第三方的東西（webview這個(gè)也類似第三方吧，坑真的很多），我們沒辦法把控它的流程，或者說沒辦法把控它的生命周期，所以要封裝一套流程邏輯去給調(diào)用端方便去使用。
第二個(gè)問題是版本的問題，也許會(huì)出現(xiàn)不同的版本所體現(xiàn)的效果不同，這個(gè)是需要留意的。

如果要完美解決這堆loading相關(guān)的問題，最好的方法就是看源碼，你知道它里面是怎么實(shí)現(xiàn)的，為什么會(huì)出現(xiàn)onPageStarted之前還會(huì)有一段間隔時(shí)間，那就去看loadUrl和onPageStarted回調(diào)之間的源碼，看它做了什么操作嘛。我個(gè)人是沒看源碼，所以這里只能說是淺談。

以上就是淺談Android開發(fā)Webview的Loading使用效果的詳細(xì)內(nèi)容，更多關(guān)于Android Webview Loading的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論