Shulou(Shulou.com)06/02 Report--

Most people do not understand the knowledge points of this article "how to solve the Toast problem of Android", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to solve the Toast problem of Android" article.

1. Review

How to build windows in Toast system (generate system windows through system service NotificationManager)

The cause of the Toast exception (the timing disorder of the system calling Toast)

two。 Solution idea

Based on the knowledge of the first article, we know that the window of Toast belongs to the system window, and its generation and life cycle depend on the system service NotificationManager. Once the window lifecycle managed by NotificationManager is inconsistent with our local process, an exception occurs. So, can we not use the system's window, but use our own window, and let us control the life cycle? In fact, SnackBar is such a solution. However, if you don't use system-type windows, it means that your Toast interface cannot be displayed on top of other applications. (for example, we often see a scenario in which you call the Toast.show function in your application many times, and then return to the desktop, only to find that the desktop will also pop up Toast because the system Toast uses the system window and has a high level.) however, on some versions of the phone, your application can apply for permission to add a TYPE_SYSTEM_ALERT window to the system, which is also a system window. It is often used as a floating layer on top of all applications. However, this approach requires permission to apply, and it is not possible for all versions of the system to work properly.

From an experience point of view, when the user leaves the process, the Toast prompt of another process should not pop up to interfere with the user's. The Android system seems to be aware of this, and many permissions related to the desktop prompt window are limited in the new version of the system update. So, in terms of experience, this situation is not a problem.

"so which types of windows can we choose?"

Using child windows: within the Android process, we can directly use windows with a child window type. The direct application in Android code is PopupWindow or Dialog. Of course, but this kind of window depends on its host window, and it is available if your host window is available.

Using View system: using View system to simulate the behavior of a Toast window, it is not only convenient to do, but also can realize the animation effect more quickly. Our SnackBar adopts this set of scheme. This is also the plan that we focus on today.

"if I use the View system scheme, which control should I add my Toast control to?"

In the Android process, all of our visual operations depend on an Activity. Activity provides context (Context) and view window (Window) objects. Any View objects we pass through the Activity.setContentView method will be decorated with DecorView in the view window (Window). Among the child nodes of DecorView, a FrameLayout node whose id is android.R.id.content (hereinafter referred to as the content node) is used to hold the View object that we pass in. In general, this node occupies all areas except the notification bar. This is particularly suitable for using as the parent control node of Toast.

"when is the right time for me to add this content node? when will the content node be initialized?"

Depending on your needs, you may pay attention to the following two times:

Content node generation

Content content display

In fact, we just need to add our Toast to the Content node, as long as the first item is satisfied. If you are doing performance testing, measurement, or other purposes, then you may be more concerned about the second item. So under what circumstances is the Content node generated? As we just said, the Content node is contained in our DecorView control, and DecorView is the control held by the Window object of Activity. The implementation class of Window in Android is PhoneWindow. (you can read this part of the code if you are interested.) Let's take a look at the source code:

/ / code PhoneWindow.java@Override public void setContentView (int layoutResID) {if (mContentParent = = null) {/ / mContentParent is our content node installDecor (); / / generate a DecorView} else {mContentParent.removeAllViews ();} mLayoutInflater.inflate (layoutResID, mContentParent); final Callback cb = getCallback () If (cb! = null & &! isDestroyed ()) {cb.onContentChanged ();}}

The PhoneWindow object uses the installDecor function to generate DecorView and the content node we need (which will eventually be stored in mContentParent) variables. However, the setContentView function requires us to call it actively, and if I didn't call the setContentView function, the installDecor method will not be called. So, is there a time when content nodes are bound to be generated? Of course, in addition to calling installDecor in the setContentView function, there is another function that also calls this, that is:

/ / code PhoneWindow.java@Override public final View getDecorView () {if (mDecor = = null) {installDecor ();} return mDecor;}

And this function will be called when Activity.findViewById:

/ / code Activity.javapublic View findViewById (@ IdRes int id) {return getWindow () .findViewById (id);} / / code Window.javapublic View findViewById (@ IdRes int id) {return getDecorView () .findViewById (id);}

Therefore, as long as we call the findViewById function, we can still ensure that the content is initialized normally. So we explain the first "ready" (Content node generation). Let's take a look at the second "ready", that is, when will the Android interface be displayed? I'm sure you can't wait to answer, isn't it time for an onResume callback? In fact, in onResume, we didn't deal with the interface at all. Let's take a look at how the Android process handles resume messages:

(note: AcitivityThread is the entry class of the Android process, and the Android process will call the AcitivityThread.handleResumeActivity function when handling resume-related messages.)

/ / code AcitivityThread.javavoid handleResumeActivity (...) {. ActivityClientRecord r = performResumeActivity (token, clearHide); / / call onResume is called later. View decor = r.window.getDecorView (); / / call getDecorView to generate content node decor.setVisibility (View.INVISIBLE);. If (r.activity.mVisibleFromClient) {r.activity.makeVisible (); / / add to WM Management}...} / / code Activity.java void makeVisible () {if (! mWindowAdded) {ViewManager wm = getWindowManager (); wm.addView (mDecor, getWindow (). GetAttributes ()); mWindowAdded = true;} mDecor.setVisibility (View.VISIBLE);}

When the Android process processes resume messages, it follows the following process:

Call the onResume function of performResumeActivity callback Activity

Call getDecorView of Window to generate DecorView object and content node

Integrate DecorView into the management of WindowManager (in-process Services)

Call Activity.makeVisible to display the current Activity

According to the above process, the control is not brought into the management of the local service WindowManager until after the Activity.onResume callback. In other words, Activity.onResume doesn't show anything at all. We might as well write a code to verify it:

/ / code DemoActivity.javapublic DemoActivity extends Activity {private View view; @ Override protected void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState); view = new View (this); this.setContentView (view);} @ Override protected void onResume () {super.onResume (); Log.d ("cdw", "onResume:" + view.getHeight ()); / / height is a necessary condition for display}}

Here, we verify whether the interface is drawn by getting the height in onResume, and finally we will output the log:

D cdw: onResume: 0

So, when was the interface drawn? Is it after WindowManager.addView? We will call Activity.makeVisible after onResume, and WindowManager.addView will be called inside. So we can detect the situation after WindowManager.addView by post a message in onResume:

@ Override protected void onResume () {super.onResume (); this.runOnUiThread (new Runnable () {@ Override public void run () {Log.d ("cdw", "onResume:" + view.getHeight ());}});} / / console output: 01-02 21 Fran 30 this.runOnUiThread 27.445 2562 2562 D cdw: onResume: 0

As a result, we didn't draw the interface after WindowManager.addView. So, when did the drawing of Android start? When will it end again?

In Android system, each drawing is controlled by a VSYNC signal about 16ms, which may come from hardware or software simulation. Each non-animated drawing contains three functions: measurement, layout, and drawing. Generally speaking, the actions that trigger this event are:

Changes to some properties of View

View relayout Layout

Add and delete View nodes

When WindowManager.addView is called to add space to WM service management, an Layout request is invoked, which triggers a VSYNC drawing. Therefore, we only need to post a frame callback in onResume to detect the start time of painting:

@ Override protected void onResume () {super.onResume (); Choreographer.getInstance () .postFrameCallback (new Choreographer.FrameCallback () {@ Override public void doFrame (long frameTimeNanos) {/ / TODO drawing start});}

Let's first take a look at how View.requestLayout triggers the interface redrawing:

/ / code View.javapublic void requestLayout () {.... If (mParent! = null) {... If (! mParent.isLayoutRequested ()) {mParent.requestLayout ();}

The View object will delegate processing to its parent node when it calls requestLayout. The reason why it is not called the parent control but the parent node is that in addition to the control, there is a non-control type ViewRootImpl as the parent node, and this parent node will serve as the root node of the entire control tree. According to the delegate mechanism we mentioned above, requestLayout will eventually be called to ViewRootImpl.requestLayout.

/ / code ViewRootImpl.java@Override public void requestLayout () {if (! mHandlingLayoutInLayoutRequest) {checkThread (); mLayoutRequested = true; scheduleTraversals (); / / apply for drawing request}} void scheduleTraversals () {if (! mTraversalScheduled) {mTraversalScheduled = true;.... MChoreographer.postCallback (Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); / / apply for drawing. }}

ViewRootImpl will eventually put the mTraversalRunnable processing commands into the CALLBACK_TRAVERSAL drawing queue:

Final class TraversalRunnable implements Runnable {@ Override public void run () {doTraversal (); / execute layout and drawing}} void doTraversal () {if (mTraversalScheduled) {mTraversalScheduled = false;... PerformTraversals ();...}}

The mTraversalRunnable command will eventually call the performTraversals () function:

Private void performTraversals () {final View host = mView;... Host.dispatchAttachedToWindow (mAttachInfo, 0); / / attachWindow. GetRunQueue (). ExecuteActions (attachInfo.mHandler); / / execute an instruction. ChildWidthMeasureSpec = getRootMeasureSpec (desiredWindowWidth, lp.width); childHeightMeasureSpec = getRootMeasureSpec (desiredWindowHeight, lp.height); host.measure (childWidthMeasureSpec, childHeightMeasureSpec); / / Measurement. Host.layout (0,0, host.getMeasuredWidth (), host.getMeasuredHeight ()); / / layout. Draw (fullRedrawNeeded); / / draw.}

The performTraversals function implements the following process:

Call dispatchAttachedToWindow to notify the child control tree that the current control is attach into the window

Execute a command queue getRunQueue

Execute meausre measurement instructions

Execute layout layout function

Perform drawing draw

Here we see a method call:

GetRunQueue () executeActions (attachInfo.mHandler)

This function executes a deferred command queue. Before the View object is attach to the View tree, you can add the execution message command to the deferred execution queue by calling the View.post function:

/ / code View.javapublic boolean post (Runnable action) {Handler handler; AttachInfo attachInfo = mAttachInfo; if (attachInfo! = null) {handler = attachInfo.mHandler;} else {/ / Assume that post will succeed later ViewRootImpl.getRunQueue () .post (action); return true;} return handler.post (action);}

When the getRunQueue (). ExecuteActions function is executed, the command message is delayed by a UI thread message, which ensures that the command message is executed after our drawing:

/ / code RunQueue.java void executeActions (Handler handler) {synchronized (mActions) {... For (int I = 0; I

< count; i++) { final HandlerAction handlerAction = actions.get(i); handler.postDelayed(handlerAction.action， handlerAction.delay);//推迟一个消息 } } } 所以，我们只需要在视图被 attach 之前通过一个 View 来抛出一个命令消息，就可以检测视图绘制结束的时间点: //code DemoActivity.java @Override protected void onResume() { super.onResume(); Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() { @Override public void doFrame(long frameTimeNanos) { start = SystemClock.uptimeMillis(); log("绘制开始:height = "+view.getHeight()); } }); } @Override protected void onCreate( Bundle savedInstanceState) { super.onCreate(savedInstanceState); view = new View(this); view.post(new Runnable() { @Override public void run() { log("绘制耗时:"+(SystemClock.uptimeMillis()-start)+"ms"); log("绘制结束后:height = "+view.getHeight()); } }); this.setContentView(view); }//控制台输出:01-03 23:39:27.251 27069 27069 D cdw : --->

Drawing begins: height = 27069 2339 cdw 27.295 27069 D cdw:-- > time spent on drawing: 44ms01-03 23 Swiss 39 44ms01 27.295 27069 27069 D cdw:-> after drawing: height = 1232

With our knowledge stock above, let's take a look at how SnackBar does it:

3.Snackbar

The SnackBar system mainly depends on two classes:

SnackBar acts as a facade to interact with business programs

SnackBarManager acts as a timing manager. The interaction between SnackBar and SnackBarManager is carried out through the Callback callback object.

The timing management of SnackBarManager is very similar to that of NotifycationManager.

SnackBar constructs a SnackBar statically through the static method make:

Public static Snackbar make (@ NonNull View view, @ NonNull CharSequence text, @ Duration int duration) {Snackbar snackbar = new Snackbar (findSuitableParent (view)); snackbar.setText (text); snackbar.setDuration (duration); return snackbar;}

Here is a key function findSuitableParent. The purpose of this function is to find a suitable container for the Toast control defined by SnackBar, just like the findViewById (R.id.content) above:

Private static ViewGroup findSuitableParent (View view) {ViewGroup fallback = null; do {if (view instanceof CoordinatorLayout) {return (ViewGroup) view;} else if (view instanceof FrameLayout) {if (view.getId () = = android.R.id.content) {/ / use the `Content` node as a container. Return (ViewGroup) view;} else {/ / It's not the content view but we'll use it as our fallback fallback = (ViewGroup) view;}}...} while (view! = null) / / If we reach here then we didn't find a CoL or a suitable content view so we'll fallback return fallback;}

We found that, in addition to containing the CoordinatorLayout control, by default, SnackBar is also the Content node found. The parent node found is used as the parameter of the Snackbar constructor:

Private Snackbar (ViewGroup parent) {mTargetParent = parent; mContext = parent.getContext ();... LayoutInflater inflater = LayoutInflater.from (mContext); mView = (SnackbarLayout) inflater.inflate (R.layout.design_layout_snackbar, mTargetParent, false);...}

Snackbar will generate a SnackbarLayout control as the Toast control. Finally, when the SnackBarManager callback from the current sequence controller returns, the notification SnackBar shows that SnackBar.mView is being added to the mTargetParent control.

Some people here may wonder whether the use of strong references here will cause memory leaks for a period of time.

If you play 10 Toast now, the display time of each Toast is 2s. This means that your last SnackBar will be held by SnackBarManager for at least 20s. In SnackBar, there is a strong reference to the parent control mTargetParent. It is equivalent to that your mTargetParent and the Context it holds (usually Activity) cannot be released during these 20 seconds.

This is not going to happen because SnackBarManager uses weak references when managing this callback callback.

Private static class SnackbarRecord {final WeakReference callback;....}

However, we can see from SnackBar's design that SnackBar cannot customize the specific style: SnackBar can only generate controls and layouts like SnackBarLayout, which may not meet your business needs. Of course, you can also change the SnackBarLayout to achieve the goal. However, with the above knowledge reserve, we can write our own Snackbar.

4. Reform based on Toast

We know from the first article that it makes no sense for us to add try-catch directly to the Toast.show function. Because Toast.show actually just sends a command to the NotificationManager service. The real display can only be triggered when NotificationManager notifies our TN object show. All messages notified by NotificationManager to the TN object are processed by the internal object TN.mHandler.

/ / code Toast.java private static class TN {final Runnable mHide = new Runnable () {/ / execute @ Override public void run () {handleHide (); mNextView = null;} via mHandler.post (mHide) Final Handler mHandler = new Handler () {@ Override public void handleMessage (Message msg) {IBinder token = (IBinder) msg.obj; handleShow (token); / / processing show messages}};}

When NotificationManager notifies the TN object to display, the TN object sends a message to the mHandler object and executes it in the mHandler's handleMessage function. When NotificationManager tells TN that the object is hidden, the hidden instruction is sent through the mHandler.post (mHide) method. Regardless of the way the instruction is sent, the dispatchMessage (Message msg) function of Handler is executed:

/ / code Handler.javapublic void dispatchMessage (Message msg) {if (msg.callback! = null) {handleCallback (msg); / / execute messages in the form of post (Runnable)} else {. HandleMessage (msg); / / execute a message in sendMessage form}}

Therefore, we only need to add try-catch to the body of the dispatchMessage method to avoid the impact of Toast crashes on the application:

Public void dispatchMessage (Message msg) {try {super.dispatchMessage (msg);} catch (Exception e) {}}

Therefore, we can define a secure Handler decorator:

Private static class SafelyHandlerWarpper extends Handler {private Handler impl; public SafelyHandlerWarpper (Handler impl) {this.impl = impl;} @ Override public void dispatchMessage (Message msg) {try {super.dispatchMessage (msg) } catch (Exception e) {}} @ Override public void handleMessage (Message msg) {impl.handleMessage (msg); / / needs to be delegated to the original Handler to execute}}

Because the handleMessage method is overridden by the TN.mHandler object, in the Handler decorator, the handleMessage method needs to be delegated to TN.mHandler execution. After defining the decorator, we can inject it into our Toast object by reflection:

Public class ToastUtils {private static Field sField_TN; private static Field sField_TN_Handler; static {try {sField_TN = Toast.class.getDeclaredField ("mTN"); sField_TN.setAccessible (true); sField_TN_Handler = sField_TN.getType (). GetDeclaredField ("mHandler"); sField_TN_Handler.setAccessible (true) } catch (Exception e) {}} private static void hook (Toast toast) {try {Object tn = sField_TN.get (toast); Handler preHandler = (Handler) sField_TN_Handler.get (tn); sField_TN_Handler.set (tn,new SafelyHandlerWarpper (preHandler)) } catch (Exception e) {}} public static void showToast (Context context,CharSequence cs, int length) {Toast toast = Toast.makeText (context,cs,length); hook (toast); toast.show ();}}

Let's test it again with the code from Chapter 1:

Public void showToast (View view) {ToastUtils.showToast (this, "hello", Toast.LENGTH_LONG); try {Thread.sleep (10000);} catch (InterruptedException e) {}}

After waiting for 10 seconds, the process runs normally and will not crash because of Toast problems.

The above is the content of this article on "how to solve the Toast problem of Android". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.