Is it true that Android sub-thread UI operations are not allowed?

Author: Zhang Xichen, vivo Internet Server Team

1. Background and Issues

A certain SDK has a PopupWindow pop-up and animation. Due to business scenario requirements, for the App, the timing of the SDK's pop-up window is random.

When the pop-up window pops up, if the App also happens to have an animation executed, the main thread may draw two animations at the same time, resulting in a lag, as shown in the following figure.

We use horizontally moving blocks to simulate the animation of the App (such as page switching). It can be seen that when the Snackabr pop-up window pops up, the block animation has obvious lag (moving to about 1/3).

The root cause of this problem can be briefly summarized as: uncontrollable animation conflicts (business randomness) + time-consuming methods in the main thread that cannot be placed (pop-up window instantiation, view inflate).

Therefore, we need to find a solution to solve the problem of lag caused by animation conflicts. We know that the Android coding standard requires that child threads cannot operate the UI, but is it necessarily so?

Through our optimization, we can achieve the perfect effect, smooth animation and no interference:

2. Optimization measures

【Optimization method 1】：

Dynamically set the delayed instantiation and display time of pop-up windows to avoid business animations.

Conclusion: It works, but not elegant enough. Use it as a fallback solution.

【Optimization method 2】:

Can the time-consuming operations of the pop-up window (such as instantiation and inflation) be moved to the child thread and executed only in the main thread during the display phase (calling the show method)?

Conclusion: Yes. Strictly speaking, the view operation before attach is not a UI operation, but a simple property assignment.

【Optimization method three】:

Can the instantiation, display, and interaction of the entire Snackbar be placed in a child thread for execution?

Conclusion: Yes, but in some constrained scenarios, although the "UI thread" can be understood as the "main thread" most of the time, strictly speaking, the Android source code has never limited the "UI thread" to be the "main thread".

3. Principle Analysis

Let's analyze the feasibility principles of options 2 and 3.

3.1 Concept Analysis

• [Main thread]: The thread that instantiates ActivityThread. Each Activity instantiates a thread.
• [UI thread]: The thread that instantiates ViewRootImpl, and finally executes View's onMeasure/onLayout/onDraw and other threads involving UI operations.
• 【Sub-thread】: A relative concept. Any other thread is a sub-thread relative to the main thread. The same is true for the UI thread.

3.2 Where does CalledFromWrongThreadException come from

As we all know, when we update interface elements, if we do not execute them on the main thread, the system will throw

CalledFromWrongThreadException, observing the exception stack, it is not difficult to find that the exception is thrown from

Thrown in ViewRootImpl#checkThread method.

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

Through the method reference, we can see that

The ViewRootImpl#checkThread method is called in almost all view update methods to prevent multi-threaded UI operations.

For in-depth analysis, we take the TextView#setText method as an example to further observe what was done before the exception was triggered.

By looking at the method call chain (Android Studio: alt + ctrl + H), we can see that the UI update operation has reached the invalidate method of the common parent class VIew.

In fact, this method is a necessary method to trigger UI updates. After View#invalidate is called, the View will be redrawn step by step in subsequent operations.

 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 Understanding View#invalidate method

Let's take a closer look at the source code of this method. We ignore unimportant code. The invalidate method actually marks the dirty area and continues to pass it to the parent View, and finally the top View performs the real invalidate operation.

As you can see, for the code to start recursive execution, several necessary conditions need to be met:

• The parent View is not empty: This condition is obvious. When the parent view is empty, the ParentView#invalidateChild method cannot be called.
• Dirty area coordinates are legal: also obvious.
• AttachInfo is not empty: Currently the only variable. When this method is empty, invalidate will not be actually executed.

So, if conditions 1 and 2 are obvious, why do we need to check the AttachInfo object once more? What information does this AttachInfo object contain?

 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 ; // When is the value assigned here
 final ViewParent p = mParent ;
 if ( p != null && ai != null && l < r && t < b ) { // If the logic here fails, invalidate will not be triggered
 final Rect damage = ai . mTmpInvalRect ;
 damage .set ( l , t , r , b ) ;
 p . invalidateChild ( this , damage );
 }

 // ...

 }

What is in mAttachInfo?

Note description: attachInfo is a series of information assigned to a view when it is attached to its parent window.

There are some key contents:

• Window related classes, information and IPC classes.
• ViewRootImpl object: This class is the source that triggers CalledFromWrongThreadException.
• Additional information.

In fact, through the information of the above TextView#setText method call chain, we already know that all successfully executed view#invalidate methods will eventually go to the method in ViewRootImpl and check the thread that tries to update the UI in ViewRootImpl.

That is to say, when a View is associated with a ViewRootImpl object, it is possible to trigger

CalledFromWrongThreadException exception, so attachInfo is a necessary object for View to continue to effectively execute the invalidate method.

 // 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 ;

 // ...
 }
 }

As described in the comments, combined with the source code, mAttachInfo is assigned only at the attach and detach moments of the view.

So we further speculate that UI update operations before view attach will not trigger exceptions. Can we perform time-consuming operations such as instantiation in a child thread before attach?

When is a view attached to a window?

Just as we write layout files, the view tree is constructed through the addView method of each VIewGroup. By observing the ViewGroup#addViewInner method, we can see the code for binding the child view with 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 ));
 // ...
 }
 // ...
 }

In our background case, the layout inflation operation of the pop-up window is time-consuming. So has the attachWindow operation been completed when this operation is executed?

In fact, when infalte, the developer can freely control whether to perform the attach operation, and all infalte overloaded methods will eventually execute LayoutInfaltor#tryInflatePrecompiled.

That is to say, we can perform the inflate operation and addView operation in two steps, and the former can be completed in the child thread.

(In fact, the AsyncLayoutInflater in the Androidx package provided by Google also operates in this way).

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

So far, everything seems clearer. Everything is related to ViewRootImpl, so let's take a closer look at it:

• First of all, where does ViewRootImpl come from? - In WindowManager#addView

When we can add a new window through WindowManager#addView, the implementation of this method WindowManagerGlobal#addView will instantiate ViewRootImpl and set the newly instantiated ViewRootImpl as the Parent of the added View. At the same time, the View is also identified as the 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 );
 // ...
 }

Let’s observe again

The calling relationship of the WindowManagerGlobal#addView method shows the calling times of many familiar classes:

 WindowManagerGlobal . addView ( View , LayoutParams , Display , Window ) ( android . view )
 WindowManagerImpl . addView ( View , LayoutParams ) ( android . view )
 Dialog.show ()( android.app ) // Dialog display method
 PopupWindow . invokePopup ( LayoutParams ) ( android . widget )
 PopupWindow.showAtLocation ( IBinder , int , int , int ) ( android.widget ) // PopupWindow display method
 TN in Toast . handleShow ( IBinder ) ( android . widget ) // Toast display method

From the calling relationship, we can see that Dialog, PopupWindow, Toast, etc., are all attached to the window and associated with RootViewImpl when the display method is called. Therefore, in theory, we only need to ensure that the show method is called in the main thread.

In addition, for pop-up scenes, the Androidx material package also provides Snackbar. Let's take a look at the attach timing and logic of Snackbar in the material package:

It can be found that this pop-up window is actually directly bound to the existing view tree through the addView method in the View passed in by the business, rather than being displayed by adding a new window through WindowManager. The timing of its attach is also when show is called.

 // 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 );
 }

 // ...

 }

At this point, we can draw the first conclusion: the instantiation of an unattached View and the operation of its attributes can be completely performed in the child thread because its top-level parent does not have a viewRootImpl object, and no matter what method is called, it will not trigger checkThread.

Only when the view is attached to the window, it will become part of the UI (mounted to the ViewTree) and need to be controlled, updated, and managed by a fixed thread.

If a view wants to attach to a window, there are two ways:

• A parent View that has attachedWindow calls its addView method to attach the child view to the same window, thus having viewRootImpl. (Material Snackbar method)
• Through WindowManager#addView, create a Window and ViewRootImpl to complete the attach operation between the view and the window. (PopupWindow method)

How to understand Window, View and ViewRootImpl?

 Window is an abstract concept. Each Window corresponds to a View and a ViewRootImpl. Window and View are connected through ViewRootImpl. —— "Exploring the Art of Android Development"

 // Understanding: Each Window corresponds to a ViewTree, whose root node is ViewRootImpl. ViewRootImpl controls everything in ViewTree from top to bottom (events, drawing, and updating)

The question is: So, must the fixed thread that controls the View be the main thread?

 /**
  * 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()}.
 */
 // Wording: "from a UI thread", not "from the UI thread"
 public void invalidate () {
 invalidate ( true );
 }

3.4 In-depth observation of ViewRootImpl and Android screen refresh mechanism

Let's rephrase the question: Is it safe to update the View off the main thread? Can we have multiple UI threads?

To return to this question, we still have to return

The origin of 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." );
 }
 }

Looking at the code again, we can see that the judgment condition of the checkThread method is to judge whether the mThread object is consistent with the Thread object of the current code. So, is the ViewRootImpl.mThread member variable necessarily mainThread?

In fact, looking at the ViewRootImpl class, the mThread member variable is assigned only once, that is, in the ViewRootImpl object constructor, the current thread object is obtained when instantiated.

 // ViewRootImpl.java

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

Therefore, we can infer that the checkThread method determines whether the thread when ViewRootImpl is instantiated is consistent with the thread of the UI update operation, and does not strictly constrain the main process of the application.

In the previous article, we have explained that the instantiation of the ViewRootImpl object is called by WindowManager#addView → WindowManagerGlobal#addView → new ViewRootImpl. These methods can be triggered in the child thread.

In order to verify our inference, we first analyze it from the source code level.

First, let's look at the comments for 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.

The document states that ViewRootImpl is the topmost object in the view tree, which implements the necessary protocols between View and WindowManager. As most of the internal implementations in WindowManagerGlobal, most of the important methods in WindowManagerGlobal are eventually implemented in ViewRootImpl.

There are several very important member variables and methods in the ViewRootImpl object that control the mapping operations of the view tree.

Here we briefly introduce the mechanism of Android screen refresh and how it interacts with the above core objects and methods, so that we can better analyze it further.

Understanding the Android screen refresh mechanism

We know that when View is drawn, it is triggered by the invalidate method, and eventually it will go to its onMeasure, onLayout, and onDraw methods to complete the drawing. The process during this period plays an important role in our understanding of UI thread management.

Let's look at the Android drawing process through the source code:

First, the View#invalidate method is triggered, passed to the parent View level by level, and finally passed to the ViewRootImpl object at the top level of the view tree to complete the marking of the dirty area.

 // ViewRootImpl.java

 public ViewParent invalidateChildInParent ( int [] location , Rect dirty ) {

 // ...

 invalidateRectOnScreen ( dirty );

 return null ;
 }

 private void invalidateRectOnScreen ( Rect dirty ) {

 // ...

 if ( ! mWillDrawSoon && ( intersected || mIsAnimating )) {
 scheduleTraversals ();
 }
 }

ViewRootImpl will then execute the scheduleTraversal method to plan the UI view tree drawing task:

• First, a synchronous message barrier will be added to the message queue of the UI thread to ensure the priority execution of subsequent drawing asynchronous messages;
• After that, a Runnable object will be registered with Choreographer, which will decide when to call the run method of the Runnable;
• The Runnable object is the doTraversal method, which is the method that actually performs the view tree traversal and drawing.

 // 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 );
 // ...
 }

After Choreographer is called, it will go through the following methods in succession, and finally call DisplayEventReceiver#scheduleVsync, and finally call the nativeScheduleVsync method to register to receive the vertical synchronization signal of the underlying system.

 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
 * The 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 );
 }
 }

The underlying system will generate a Vsync (vertical synchronization) signal every 16.6ms to ensure stable screen refresh. After the signal is generated, the DisplayEventReceiver#onVsync method will be called back.

Choreographer's internal implementation class

After FrameDisplayEventReceiver receives the onSync callback, it sends an asynchronous message in the message queue of the UI thread and calls the Choreographer#doFrame method.

 // 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 );
 }

 }

When the Choreographer#doFrame method is executed, doCallbacks will be called next.

(Choreographer.CALLBACK_TRAVERSAL, ...) method executes the mTraversalRunnable registered by ViewRootImpl.

That is the ViewRootImpl#doTraversal method.

 // android.view.Choreographer

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

ViewRootImpl#doTraversal then removes the synchronization signal barrier and continues to execute the ViewRootImpl#performTraversals method, and finally calls the View#measure, View#layout, and View#draw methods to perform drawing.

 // ViewRootImpl.java

 void doTraversal () {
 // ...
 mHandler.getLooper (). getQueue ( ) . removeSyncBarrier ( mTraversalBarrier );
 // ...
 performTraversals ();
 // ...
 }

 private void performTraversals () {
 // ...
 performMeasure ( childWidthMeasureSpec , childHeightMeasureSpec );
 // ...
 performLayout ( lp , desiredWindowWidth , desiredWindowHeight );
 // ...
 performDraw ();
 }

So is the UI thread consistent throughout the entire drawing process? Is there a situation where the main thread is forcibly used during the drawing process?

Throughout the entire drawing process, ViewRootImpl and Choreographer both use Handler objects. Let's take a look at how their Handlers and the Loopers in them come from:

First of all, the Handler in ViewRootImpl is internally inherited from the Handler object, and does not overload the Handler constructor or explicitly pass in the 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 ();

Let's take a look at the constructor of the Handler object. If Looper is not explicitly specified, Looper.myLooper() is used by default. MyLooper gets the looper object of the current thread from ThreadLocal.

Combined with our previous discussion that the mThread of the ViewRootImpl object is the thread where it is instantiated, we know that the mHandler thread of ViewRootImpl is the same thread as the instantiation thread.

 // 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 ();
 }

Let's take a look at which thread the Handler thread is in the mChoreographer object held inside ViewRootImpl.

mChoreographer instantiation is obtained through the Choreographer#getInstance method when the ViewRootImpl object is instantiated.

 // ViewRootImpl.java

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

Observing the Choreographer code, we can see that the getInsatance method also returns the current thread instance obtained through ThreadLocal;

The current thread instance also uses the current thread's looper (Looper#myLooper) instead of forcibly specifying the main thread Looper (Looper#getMainLooper).

Therefore, we conclude that during the entire drawing process,

 From the View #invalidate method to registering the vertical synchronization signal listener ( DisplayEventReceiver 

 #nativeScheduleVsync ) , and the vertical sync signal callback ( DisplayEventReceiver #onVsync ) to the View's measue / layout / draw method calls are all in the same thread ( UI thread ) , and the system does not restrict the scene to be the main thread. 

 // 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 () ;
 }

The Android drawing process and UI thread control analyzed above can be summarized as follows:

At this point we can draw a conclusion: the UI thread of a View displayed by a window can be independent of the App main thread.

Let's verify it with coding practice.

4. Coding Verification and Practice

In fact, in practice, the drawing of screen content is never completed entirely in one thread. The most common scenarios are as follows:

• When the video is playing, the video screen is not drawn in the main thread and UI thread of the App.
• The pop-up drawing of system Toast is controlled by the system level, and is not drawn by the main thread or UI thread of the App itself.

Combined with the working case, we tried to put the entire PopupWindow of the SDK in the child thread, that is, to specify an independent UI thread for the PopupWindow of the SDK.

We use PopupWindow to implement a customized interactive Snackbar popup window. In the popup window management class, define and instantiate the customized UI thread and Handler;

Note that the showAtLocation method of PopupWindow will be thrown into the custom UI thread (the same applies to dismiss). In theory, the UI thread of the popup window will become our custom thread.

 // Snackbar pop-up management class
 public class SnackBarPopWinManager {

 private static SnackBarPopWinManager instance ;

 private final Handler h ; // UI thread Handler for pop-up window

 // ...

 private SnackBarPopWinManager () {
 // UI thread of pop-up window
 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 operations are thrown to the custom UI thread
 h . postDelayed ( new SafeRunnable () {
 @Override ​
 public void safeRun () {
 // ..
 // Display pop-up window
 snackBarPopWin . getPopWin () . showAtLocation ( dependentView , Gravity . BOTTOM | Gravity . CENTER_HORIZONTAL , 0 , y );
 // Automatically close the timer
 snackBarPopWin . dismissAfter ( 5000 );
 // ...
 });
 }

 public void dismissPopWin ( final SnackBarPopWin snackBarPopWin ) {
 // UI operations are thrown to the custom UI thread
 h . postDelayed ( new SafeRunnable () {
 @Override ​
 public void safeRun () {
 // ...
 // dismiss the popup
 snackBarPopWin .getPopWin () .dismiss ();
 // ...
 });
 }

 // ...
 }

After that, we define the pop-up window itself, and its pop-up and disappearance methods are implemented and executed through the management class.

 // Snackbar popup window itself (implemented through 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 and other time-consuming operations
 // ...
 View popView = LayoutInflater . from ( context ) . inflate ( R . layout . popwin_layout , null );
 // ...
 mPopWin = new PopupWindow ( popView , ... );
 // ...
 }

 // User's UI operation, callback should also be in UI thread
 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 );
 }

 // ...

 }

At this point, we instantiate the pop-up window in the child thread, and after 2 seconds, we also change the TextView content in the child thread.

 // MainActivity.java

 public void snackBarSubShowSubMod ( View view ) {

 WorkThreadHandler . getInstance () . post ( new SafeRunnable () {
 @Override ​
 public void safeRun () {
 String htmlMsg = "Read <font color=#ff1e02>5</font> pieces of news, remaining <font color=#00af57>10</font> times, delay 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 ();
 }

 // Update the view in the custom UI thread
 SnackBarPopWinManager . getInstance () . getSnackbarWorkHandler () . postDelayed ( new SafeRunnable () {
 @Override ​
 public void safeRun () {
 try {
 snackbar . alertText ( "Congratulations on completing the <font color='#ff00ff'>"UI Update"</font> task, please collect your points" );
 } catch ( Exception e ) {
 DemoLogUtils . e ( TAG , "error: " , e );
 }
 }
 }, 2000 );
 }
 });
 }

Display effect, UI displays interaction normally, and because the UI is drawn in different threads, it does not affect the operation and animation of the main thread of the App:

Observe that the response thread of the click event is the custom UI thread, not the main thread:

(Note: The code in practice has not been actually put online. The UI thread of PopupWindow in the online version of the SDK is still consistent with the App and uses the main thread).

V. Conclusion

A deeper understanding of why Android child threads cannot operate the UI: the thread that controls the View drawing and the thread that notifies the View to update must be the same thread, that is, the UI thread.

For scenarios such as pop-up windows that are relatively independent of other App services, multi-UI thread optimization can be considered.

In subsequent work, clearly distinguish the concepts of UI thread, main thread, and child thread, and try not to mix them.

Of course, there are some scenarios where multiple UI threads are not applicable, such as the following logic:

• All method calls of Webview must be in the main thread, because the main thread check is mandatory in its code. If Webview is built into PopupWindow, multi-UI threads are not applicable.
• The use of Activity must be in the main thread, because the Handler used in its creation and other operations is also forced to be specified as mainThreadHandler.