Android 子執行緒 UI 操作真的不可以?

作者:vivo 互聯網大前端團隊- Zhang Xichen

一、背景及問題

某 SDK 有 PopupWindow 彈窗及動效,由於業務場景要求,對於 App 而言,SDK 的彈窗彈出時機具有隨機性。

在彈窗彈出時,若 App 恰好也有動效執行,則可能出現主執行緒同時繪製兩個動效,進而導致的卡頓,如下圖。

我們以水平移動的方塊模擬App正在進行的動效(如:頁面切換);可以看出,在Snackabr 彈窗彈出時,方塊動效有明顯的卡頓(移動至約1/3處)。

這個問題的根本原因可以簡述為:不可控的動效衝突(業務隨機性) + 無從安置的主執行緒耗時方法(彈窗實例化、視圖infalte)。

因此我們要尋求一個方案來解決動效衝突導致的卡頓問題。我們知道Android編碼規範在要求子執行緒不能操作UI,但一定是這樣嗎?

通過我們的優化,我們可以達到最終達成完美的效果,動效流暢,互不干涉:

二、優化措施

【優化方式一】:動態設置彈窗的延遲實例化及展示時間,躲避業務動效。

結論:可行,但不夠優雅。用於作為兜底方案。

【優化方式二】:能否將彈窗的耗時操作(如實例化、infalte)移至子執行緒運行,僅在展示階段(調用show方法)在主執行緒執行?

結論:可以。attach前的view操作,嚴格意義上講,並不是UI操作,只是簡單的屬性賦值。

【優化方式三】:能否將整個Snackbar的實例化、展示、交互全部放置子執行緒執行?

結論:可以,但有些約束場景,「UI執行緒」雖然大部分時候可以等同理解為「主執行緒」,但嚴格意義上,Android源碼中從未限定「UI執行緒」必須是「主執行緒」。

三、原理分析

下面我們分析一下方案二、三的可行性原理

3.1 概念辨析

【主執行緒】:實例化ActivityThread的執行緒,各Activity實例化執行緒。

【UI執行緒】:實例化ViewRootImpl的執行緒,最終執行View的onMeasure/onLayout/onDraw等涉及UI操作的執行緒。

【子執行緒】:相對概念,相對於主執行緒,任何其他執行緒均為子執行緒。相對於UI執行緒同理。

3.2 CalledFromWrongThreadException來自哪裡

眾所周知,我們在更新介面元素時,若不在主執行緒執行,系統會拋CalledFromWrongThreadException,觀察異常堆棧,不難發現,該異常的拋出是從ViewRootImpl#checkThread方法中拋出。

// ViewRootImpl.java
void checkThread() {
    if (mThread != Thread.currentThread()) {
        throw new CalledFromWrongThreadException(
                "Only the original thread that created a view hierarchy can touch its views.");
    }
}

通過方法引用可以看到,ViewRootImpl#checkThread方法會在幾乎所有的view更新方法中調用,用以防止多執行緒的UI操作。

圖片

為了便於深入分析,我們以TextView#setText方法為例,進一步觀察觸發異常前,究竟都做了些什麼。

通過查看方法調用鏈(Android Studio: alt + ctrl + H)我們可以看到UI更新的操作,走到了VIew這個公共父類的invalidate方法。

其實該方法是觸發UI更新的一個必經方法,View#invalidate調用後,會在後續的操作中逐步執行View的重新繪製。

ViewRootImpl.checkThread()  (android.view)
  ViewRootImpl.invalidateChildInParent(int[], Rect)  (android.view)
    ViewGroup.invalidateChild(View, Rect)  (android.view)
      ViewRootImpl.invalidateChild(View, Rect)  (android.view)
        View.invalidateInternal(int, int, int, int, boolean, boolean)  (android.view)
          View.invalidate(boolean)  (android.view)
            View.invalidate()  (android.view)
              TextView.checkForRelayout()(2 usages)  (android.widget)
                TextView.setText(CharSequence, BufferType, boolean, int)  (android.widget)

3.3 理解 View#invalidate 方法

深入看一下該方法的源碼,我們忽略不重要的程式碼,invalidate方法其實是在標記dirty區域,並繼續向父View傳遞,並最終由最頂部的那個View執行真正的invalidate操作。

可以看到,若要讓程式碼開始遞歸執行,幾個必要條件需要滿足:

  • 父View不為空:該條件顯而易見,父view為空時,是無法調用ParentView#invalidateChild方法的。

  • Dirty區域坐標合法:同樣顯而易見。

  • AttachInfo不為空:目前唯一的變數,該方法為空時,不會真正執行invalidate。

那麼,在條件1、2都顯而易見的情況下,為何多判斷一次AttachInfo對象?這個AttachInfo對象中都有什麼資訊?

void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
            boolean fullInvalidate) {
    // ...
 
    // Propagate the damage rectangle to the parent view.
    final AttachInfo ai = mAttachInfo; // 此處何時賦值
    final ViewParent p = mParent;
    if (p != null && ai != null && l < r && t < b) { // 此處邏輯若不通過,實際也不會觸發invalidate
        final Rect damage = ai.mTmpInvalRect;
        damage.set(l, t, r, b);
        p.invalidateChild(this, damage);
    }
 
    // ...
 
}

mAttachInfo 里有什麼?

注釋描述:attachInfo 是一個view在attach至其父window被賦值的一系列資訊。

其中可以看到有一些關鍵內容:

  1. 窗口(Window)相關的類、資訊及IPC類。

  2. ViewRootImpl對象:這個類就是會觸發CalledFromWrongThreadException的來源。

  3. 其他資訊。

其實通過上面TextView#setText方法調用鏈的資訊,我們已經知道,所有的成功執行的view#invalidate方法,最終都會走到ViewRootImpl中的方法,並在ViewRootImpl中檢查嘗試更新UI的執行緒。

也就是說當一個View由於其關聯的ViewRootImpl對象時,才有可能觸發CalledFromWrongThreadException異常,因此attachInfo是View繼續有效執行invalidate方法的必要對象。

// android.view.view
 
/**
 * A set of information given to a view when it is attached to its parent
 * window.
 */
final static class AttachInfo {
 
    // ...
 
    final IBinder mWindowToken;
 
    /**
     * The view root impl.
     */
    final ViewRootImpl mViewRootImpl;
 
    // ...
 
    AttachInfo(IWindowSession session, IWindow window, Display display,
            ViewRootImpl viewRootImpl, Handler handler, Callbacks effectPlayer,
            Context context) {
 
        // ...
 
        mViewRootImpl = viewRootImpl;
 
        // ...
    }
}

正如注釋描述,結合源碼觀察,mAttachInfo賦值時刻確實只有view的attach與detach兩個時刻。

所以我們進一步推測:view在attach前的UI更新操作是不會觸發異常的。我們是不是可以在attach前把實例化等耗時操作在子執行緒執行完成呢?

那一個view是何時與window進行attach的?

圖片

正如我們編寫布局文件,視圖樹的構建,是通過一個個VIewGroup通過addView方法構建出來的,觀察ViewGroup#addViewInner方法,可以看到子view與attachInfo進行關係綁定的程式碼。

ViewGroup#addView →ViewGroup#addViewInner

// android.view.ViewGroup
 
private void addViewInner(View child, int index, LayoutParams params,
        boolean preventRequestLayout) {
    // ...                                                                      
    AttachInfo ai = mAttachInfo;
    if (ai != null && (mGroupFlags & FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW) == 0) {
 
        // ...
        child.dispatchAttachedToWindow(mAttachInfo, (mViewFlags&VISIBILITY_MASK));
        // ...
    }
    // ...
}

在我們的背景案例中,彈窗的布局inflate操作是耗時的,那這個操作執行時是否已經完成了attachWindow操作呢?

實際上infalte時,可以由開發者自由控制是否執行attach操作,所有的infalte重載方法最終都會執行到LayoutInfaltor#tryInflatePrecompiled。

也就是說,我們可以將inflate操作與addView操作分兩步執行,而前者可以在子執行緒完成。

(事實上google提供的Androidx包中的AsyncLayoutInflater也是這樣操作的)。

private View tryInflatePrecompiled(@LayoutRes int resource, Resources res, @Nullable ViewGroup root,
    boolean attachToRoot) {
    // ...
    if (attachToRoot) {
        root.addView(view, params);
    } else {
        view.setLayoutParams(params);
    }
    // ...
}

到此為止,看來一切都比較清晰了,一切都與ViewRootImpl有關,那麼我們仔細觀察一下它:

首先ViewRootImpl從哪裡來?—— 在WindowManager#addView

當我們可以通過WindowManager#addView方式新增一個窗口,該方法的實現WindowManagerGlobal#addView中會對ViewRootImpl進行實例化,並將新實例化的ViewRootImpl設置為被添加View的Parent,同時該View也被認定為rootView。

// android.view.WindowManagerGlobal
 
public void addView(View view, ViewGroup.LayoutParams params,
        Display display, Window parentWindow) {
    // ...
 
    root = new ViewRootImpl(view.getContext(), display);
 
    // ...
 
    try {
        root.setView(view, wparams, panelParentView);
    } catch (RuntimeException e) {
        // ...
    }
}
 
 
// android.view.RootViewImpl
 
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    // ...
    mView = view;
    // ...
    mAttachInfo.mRootView = view;
    // ...
    view.assignParent(this);
    // ...
}

我們再觀察一下WindowManagerGlobal#addView方法的調用關係,可以看到很多熟悉類的調用時刻:

WindowManagerGlobal.addView(View, LayoutParams, Display, Window)  (android.view)
    WindowManagerImpl.addView(View, LayoutParams)  (android.view)
        Dialog.show()  (android.app) // Dialog的顯示方法
        PopupWindow.invokePopup(LayoutParams)  (android.widget)
            PopupWindow.showAtLocation(IBinder, int, int, int)  (android.widget) // PopupWindow的顯示方法
        TN in Toast.handleShow(IBinder)  (android.widget) // Toast的展示方法

從調用關係我們看到,如Dialog、PopupWindow、Toast等,均是在調用展示方法時才attach窗口並與RootViewImpl關聯,因而理論上,我們僅需要保障show方法在主執行緒調用即可。

另外的,對於彈窗場景,Androidx的material包也同樣會提供Snackbar,我們觀察一下material包中Snackbar的attach時機及邏輯:

可以發現這個彈窗其實是在業務傳入的View中直接通過addView方法綁定到現有視圖樹上的,並非通過WindowManager新增窗口的方式展示。其attach的時機,同樣是在調用show的時刻。

// com.google.android.material.snackbar.BaseTransientBottomBar
 
final void showView() {
 
    // ...
 
    if (this.view.getParent() == null) {
      ViewGroup.LayoutParams lp = this.view.getLayoutParams();
     
      if (lp instanceof CoordinatorLayout.LayoutParams) {
        setUpBehavior((CoordinatorLayout.LayoutParams) lp);
      }
     
      extraBottomMarginAnchorView = calculateBottomMarginForAnchorView();
      updateMargins();
     
      // Set view to INVISIBLE so it doesn't flash on the screen before the inset adjustment is
      // handled and the enter animation is started
      view.setVisibility(View.INVISIBLE);
      targetParent.addView(this.view);
    }
 
    // ...
 
}

至此,我們可以得出第一個結論:一個未被attach的View的實例化及其中屬性的操作,由於其頂層parent是不存在viewRootImpl對象的,無論調用什麼方法,都不會觸發到checkThread,因此是完全可以放在子執行緒中進行的。

僅在view被attach至window時,它才會作為UI的一部分(掛載至ViewTree),需要被固定執行緒進行控制、更新等管理操作。

而一個view若想attach至window,有兩種途徑:

  1. 由一個已attachWindow的父View調用其addView方法,將子view也attach至同一個window,從而擁有viewRootImpl。(material Snackbar方式)

  2. 通過WindowManager#addView,自建一個Window及ViewRootImpl,完成view與window的attach操作。(PopupWindow方式)

如何理解Window和View以及ViewRootImpl呢?

Window是一個抽象的概念,每一個Window都對應著一個View和一個ViewRootImpl,Window和View通過ViewRootImpl來建立聯繫。——《Android開發藝術探索》

// 理解:每個Window對應一個ViewTree,其根節點是ViewRootImpl,ViewRootImpl自上而下地控制著ViewTree的一切(事件 & 繪製 & 更新)

問題來了:那麼,這個控制View的固定執行緒一定要是主執行緒嗎?

/**
 * Invalidate the whole view. If the view is visible,
 * {@link #onDraw(android.graphics.Canvas)} will be called at some point in
 * the future.
 * <p>
 * This must be called from a UI thread. To call from a non-UI thread, call
 * {@link #postInvalidate()}.
 */
// 咬文嚼字:「from a UI thread」,不是「from the UI thread」
public void invalidate() {
    invalidate(true);
}

3.4 深入觀察ViewRootImpl及Android螢幕刷新機制

我們不妨將問題換一個表述:是否可以安全地不在主執行緒中更新View?我們能否有多個UI執行緒?

要回到這個問題,我們還是要回歸CalledFromWrongThreadException的由來。

// ViewRootImpl.java
 
void checkThread() {
    if (mThread != Thread.currentThread()) {
        throw new CalledFromWrongThreadException(
                "Only the original thread that created a view hierarchy can touch its views.");
    }
}

再次觀察程式碼我們可以看到checkThread方法的判斷條件,是對mThread對象與當前程式碼的Thread對象是否一致進行判斷,那麼ViewRootImpl.mThread成員變數,就一定是mainThread嗎?

其實不然,縱觀ViewRootImpl類,mThread成員變數的賦值僅有一處,即在ViewRootImpl對象構造函數中,實例化時獲取當前的執行緒對象。

// ViewRootImpl.java
 
public ViewRootImpl(Context context, Display display) {
    // ...
    mThread = Thread.currentThread();
    // ...
    mChoreographer = Choreographer.getInstance();
}

因此我們可以做出推論,checkThread方法判定的是ViewRootImpl實例化時的執行緒,與UI更新操作的執行緒是否一致。而不強約束是應用主進程。

前文中,我們已經說明,ViewRootImpl對象的實例化是由WindowManager#addView → WindowManagerGlobal#addView → new ViewRootImpl調用過來的,這些方法都是可以在子執行緒中觸發的。

為了驗證我們的推論,我們先從源碼層面做一步分析。

首先我們觀察一下ViewRootImpl的注釋說明:

The top of a view hierarchy, implementing the needed protocol between View and the WindowManager. This is for the most part an internal implementation detail of WindowManagerGlobal.

文檔中指出ViewRootImpl是視圖樹的最頂部對象,實現了View與WindowManager中必要的協議。作為WindowManagerGlobal中大部分的內部實現。也即WindowManagerGlobal中的大多重要方法,最終都走到了ViewRootImpl的實現中。

ViewRootImpl對象中有幾個非常重要的成員變數和方法,控制著視圖樹的測繪操作。圖片

在這裡我們,簡單介紹一下Android螢幕刷新的機制,以及其如何與上述幾個核心對象和方法交互,以便於我們更好地進一步分析。

理解Android螢幕刷新機制

我們知道,View繪製時由invalidate方法觸發,最終會走到其onMeasure、onLayout、onDraw方法,完成繪製,這期間的過程,對我們理解UI執行緒管理有很重要的作用。

我們通過源碼,查看一下Andriod繪製流程:

首先View#invalidate方法觸發,逐級向父級View傳遞,並最終傳遞至視圖樹頂層ViewRootImpl對象,完成dirty區域的標記。

// ViewRootImpl.java
 
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
 
    // ...
                                                                        
    invalidateRectOnScreen(dirty);
                                                                        
    return null;
}
 
private void invalidateRectOnScreen(Rect dirty) {
 
    // ...
     
    if (!mWillDrawSoon && (intersected || mIsAnimating)) {
        scheduleTraversals();
    }
}

ViewRootImpl緊接著會執行scheduleTraversal方法,規劃UI視圖樹繪製任務:

  1. 首先會在UI執行緒的消息隊列中添加同步消息屏障,保障後續的繪製非同步消息的優先執行;

  2. 之後會向Choreographer註冊一個Runnable對象,由前者決定何時調用Runnable的run方法;

  3. 而該Runnable對象就是doTraversal方法,即真正執行視圖樹遍歷繪製的方法。

// ViewRootImpl.java
final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
        doTraversal();
    }
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
 
void scheduleTraversals() {
    // ...
    mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
    mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    // ...
}

Choreographer被調用後,會先後經過以下方法,最終調用到DisplayEventReceiver#scheduleVsync,最終調用到nativeScheduleVsync方法,註冊接受一次系統底層的垂直同步訊號。

Choreographer#postCallback →postCallbackDelayed →

postCallbackDelayedInternal→mHandler#sendMessage →MSG_DO_SCHEDULE_CALLBACK

MessageQueue#next→ mHandler#handleMessage →MSG_DO_SCHEDULE_CALLBACK→ doScheduleCallback→scheduleFrameLocked → scheduleVsyncLocked→DisplayEventReceiver#scheduleVsync

// android.view.DisplayEventReceiver
 
/**
 * Schedules a single vertical sync pulse to be delivered when the next
 * display frame begins.
 */
@UnsupportedAppUsage
public void scheduleVsync() {
    if (mReceiverPtr == 0) {
        Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "
                + "receiver has already been disposed.");
    } else {
        nativeScheduleVsync(mReceiverPtr);
    }
}

系統底層會固定每16.6ms生成一次Vsync(垂直同步)訊號,以保障螢幕刷新穩定,訊號生成後,會回調DisplayEventReceiver#onVsync方法。

Choreographer的內部實現類FrameDisplayEventReceiver收到onSync回調後,會在UI執行緒的消息隊列中發出非同步消息,調用Choreographer#doFrame方法。

// android.view.Choreographer
 
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
        implements Runnable {
 
    // ...
 
    @Override
    public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
        // ...
        // Post the vsync event to the Handler.
        Message msg = Message.obtain(mHandler, this);
        msg.setAsynchronous(true);
        mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
    }
 
    @Override
    public void run() {
        mHavePendingVsync = false;
        doFrame(mTimestampNanos, mFrame);
    }
 
}

Choreographer#doFrame方法執行時會接著調用到doCallbacks(Choreographer.CALLBACK_TRAVERSAL, …)方法執行ViewRootImpl註冊的mTraversalRunnable,也即ViewRootImpl#doTraversal方法。

// android.view.Choreographer
 
void doFrame(long frameTimeNanos, int frame) {
    // ...
    try {
        // ...
        doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
        // ...
    } finally {
        // ...
    }
}

ViewRootImpl#doTraversal繼而移除同步訊號屏障,繼續執行ViewRootImpl#performTraversals方法,最終調用到View#measure、View#layout、View#draw方法,執行繪製。

// ViewRootImpl.java
 
void doTraversal() {
    // ...
    mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
    // ...                                                          
    performTraversals();                                                            
    // ...
}
 
private void performTraversals() {
    // ...
    performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
    // ...
    performLayout(lp, desiredWindowWidth, desiredWindowHeight);
    // ...
    performDraw();
}

那麼整個繪製流程中的UI執行緒是否一致呢?繪製過程中是否有強行取用主執行緒(mainThread)的情況?

縱觀整個繪製流程,期間涉ViewRootImpl、Choreographer均使用了Handler對象,我們觀察一下他們的Handler及其中的Looper都是怎樣來的:

首先ViewRootImpl中的Handler是其內部繼承自Handler對象實現的,並未重載Handler的構造函數,或明示傳入的Looper。

// ViewRootImpl.java
 
final class ViewRootHandler extends Handler {
    @Override
    public String getMessageName(Message message) {
        // ...
    }
                                                                                               
    @Override
    public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        // ...
    }
                                                                                               
    @Override
    public void handleMessage(Message msg) {
        // ...
    }
}
                                                                                               
final ViewRootHandler mHandler = new ViewRootHandler();

我們觀察一下Handler對象的構造函數,在未明示Looper的情況下,默認使用的是Looper.myLooper(),myLooper是從ThreadLocal中獲取當前執行緒的looper對象使用。

結合我們之前討論的ViewRootImpl對象的mThread是其實例化時所在的執行緒,由此,我們知道ViewRootImpl的mHandler執行緒與實例化執行緒是同一個執行緒。

// andriod.os.Handler
public Handler(@Nullable Callback callback, boolean async) {
    // ...
    mLooper = Looper.myLooper();
    // ...
    mQueue = mLooper.mQueue;
    // ...
}
 
// andriod.os.Looper
/**
 * Return the Looper object associated with the current thread.  Returns
 * null if the calling thread is not associated with a Looper.
 */
public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}

我們再觀察一下ViewRootImpl內部持有的mChoreographer對象中的Handler執行緒是哪一個執行緒。

mChoreographer實例化是在ViewRootImpl對象實例化時,通過Choreographer#getInstance方法獲得。

// ViewRootImpl.java
 
public ViewRootImpl(Context context, Display display) {
    // ...
    mThread = Thread.currentThread();
    // ...
    mChoreographer = Choreographer.getInstance();
}

觀察Choreographer程式碼,可以看出,getInsatance方法返回的也是通過ThreadLocal獲取到的當前執行緒實例;

當前執行緒實例同樣使用的是當前執行緒的looper(Looper#myLooper),而非強制指定主執行緒Looper(Looper#getMainLooper)。

由此,我們得出結論,整個繪製過程中,

自View#invalidate方法觸發,至註冊垂直同步訊號監聽(DisplayEventReceiver#nativeScheduleVsync),以及垂直同步訊號回調(DisplayEventReceiver#onVsync)至View的measue/layout/draw方法調用,均在同一個執行緒(UI執行緒),而系統並未限制該現場必須為主執行緒。

// andriod.view.Choreographer
 
// Thread local storage for the choreographer.
private static final ThreadLocal<Choreographer> sThreadInstance =
        new ThreadLocal<Choreographer>() {
    @Override
    protected Choreographer initialValue() {
        Looper looper = Looper.myLooper();
        // ...
        Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
        if (looper == Looper.getMainLooper()) {
            mMainInstance = choreographer;
        }
        return choreographer;
    }
};
 
/**
 * Gets the choreographer for the calling thread.  Must be called from
 * a thread that already has a {@link android.os.Looper} associated with it.
 *
 * @return The choreographer for this thread.
 * @throws IllegalStateException if the thread does not have a looper.
 */
public static Choreographer getInstance() {
    return sThreadInstance.get();
}

上文分析的Android繪製流程和UI執行緒控制,可以總結為下圖:

圖片

至此我們可以得到一個推論:擁有窗口(Window)展示的View,其UI執行緒可以獨立於App主執行緒

下面我們編碼實踐驗證一下。

四、編碼驗證與實踐

其實實際中螢幕內容的繪製從來都不是完全在一個執行緒中完成的,最常見的場景比如:

  1. 影片播放時,影片畫面的繪製並不是App的主執行緒及UI執行緒。

  2. 系統Toast的彈出等繪製,是由系統層面統一控制,也並非App自身的主執行緒或UI執行緒繪製。

結合工作案例,我們嘗試將SDK的整個PopupWindow彈窗整體置於子執行緒,即為SDK的PopupWindow指定一個獨立的UI執行緒。

我們使用PopupWindow實現一個訂製的可交互的Snackbar彈窗,在彈窗的管理類中,定義並實例化好自定義的UI執行緒及Handler;

注意PopupWindow的showAtLocation方法執行,會拋至自定義UI執行緒中(dismiss同理)。理論上,彈窗的UI執行緒會變為我們的自定義執行緒。

// Snackbar彈窗管理類
public class SnackBarPopWinManager {
 
    private static SnackBarPopWinManager instance;
 
    private final Handler h; // 彈窗的UI執行緒Handler
 
    // ...
 
    private SnackBarPopWinManager() {
        // 彈窗的UI執行緒
        HandlerThread ht = new HandlerThread("snackbar-ui-thread");
        ht.start();
        h = new Handler(ht.getLooper());
    }
 
    public Handler getSnackbarWorkHandler() {
        return h;
    }
 
    public void presentPopWin(final SnackBarPopWin snackBarPopWin) {
        // UI操作拋至自定義的UI執行緒
        h.postDelayed(new SafeRunnable() {
            @Override
            public void safeRun() {
                // ..
                // 展示彈窗
                snackBarPopWin.getPopWin().showAtLocation(dependentView, Gravity.BOTTOM | Gravity.CENTER_HORIZONTAL, 0, y);
                // 定時自動關閉
                snackBarPopWin.dismissAfter(5000);
                // ...
        });
    }
 
    public void dismissPopWin(final SnackBarPopWin snackBarPopWin) {
        // UI操作拋至自定義的UI執行緒
        h.postDelayed(new SafeRunnable() {
            @Override
            public void safeRun() {
                // ...
                // dismiss彈窗
                snackBarPopWin.getPopWin().dismiss();
                // ...
        });
    }
 
    // ...
}

之後,我們定義好彈窗本身,其彈出、消失等方法均通過管理類實現執行。

// Snackbar彈窗本身(通過PopupWindow實現)
public class SnackBarPopWin extends PointSnackBar implements View.OnClickListener {
 
    private PopupWindow mPopWin;
 
    public static SnackBarPopWin make(String alertText, long points, String actionId) {
        SnackBarPopWin instance = new SnackBarPopWin();
        init(instance, alertText, actionId, points);
        return instance;
    }
 
    private SnackBarPopWin() {
        // infalte等耗時操作
        // ...
        View popView = LayoutInflater.from(context).inflate(R.layout.popwin_layout, null);
        // ...
        mPopWin = new PopupWindow(popView, ...);
        // ...
    }
 
    // 用戶的UI操作,回調應該也在UI執行緒
    public void onClick(View v) {
        int id = v.getId();
        if (id == R.id.tv_popwin_action_btn) {
            onAction();
        } else if (id == R.id.btn_popwin_cross) {
            onClose();
        }
    }
 
    public void show(int delay) {
        // ...
        SnackBarPopWinManager.getInstance().presentPopWin(SnackBarPopWin.this);
    }
 
    public void dismissAfter(long delay) {
        // ...
        SnackBarPopWinManager.getInstance().dismissPopWin(SnackBarPopWin.this);
    }
 
    // ...
 
}

此時,我們在子執行緒中實例化彈窗,並在2s後,同樣在子執行緒中改變TextView內容。

// MainActivity.java
 
public void snackBarSubShowSubMod(View view) {
 
    WorkThreadHandler.getInstance().post(new SafeRunnable() {
        @Override
        public void safeRun() {
            String htmlMsg = "已讀新聞<font color=#ff1e02>5</font>篇,剩餘<font color=#00af57>10</font>次,延遲0.3s";
            final PointSnackBar snackbar = PointSnackBar.make(htmlMsg, 20, "");
            if (null != snackbar) {
                snackbar.snackBarBackgroundColor(mToastColor)
                        .buttonBackgroundColor(mButtonColor)
                        .callback(new PointSnackBar.Callback() {
                    @Override
                    public void onActionClick() {
                        snackbar.onCollectSuccess();
                    }
                }).show();
            }
 
            // 在自定義UI執行緒中更新視圖
            SnackBarPopWinManager.getInstance().getSnackbarWorkHandler().postDelayed(new SafeRunnable() {
                @Override
                public void safeRun() {
                    try {
                        snackbar.alertText("恭喜完成<font color='#ff00ff'>「UI更新」</font>任務,請領取積分");
                    } catch (Exception e) {
                        DemoLogUtils.e(TAG, "error: ", e);
                    }
                }
            }, 2000);
        }
    });
}

展示效果,UI正常展示交互,並在由於在不同的執行緒中繪製UI,也並不會影響到App主執行緒操作及動效:

觀察點擊事件的響應執行緒為自定義UI執行緒,而非主執行緒:

圖片

(註:實踐中的程式碼並未真實上線。SDK線上版本中PopupWindow的UI執行緒仍然與App一致,使用主執行緒)。

五、總結

對於Android子執行緒不能操作UI的更深入理解:控制View繪製的執行緒和通知View更新的執行緒必須是同一執行緒,也即UI執行緒一致。

對於彈窗等與App其他業務相對獨立的場景,可以考慮多UI執行緒優化。

後續工作中,清晰辨析UI執行緒、主執行緒、子執行緒的概念,盡量不要混用。

當然,多UI執行緒也有一些不適用的場景,如以下邏輯:

  1. Webview的所有方法調用必須在主執行緒,因為其程式碼中強製做了主執行緒校驗,如PopupWindow中內置Webview,則不適用多UI執行緒。

  2. Activity的使用必須在主執行緒,因為其創建等操作中使用的Handler也被強制指定為mainThreadHandler。

參考:

  1. Android 螢幕刷新機制

  2. 為什麼Android必須在主執行緒更新UI