android源码解析(二十二)-->Toast加载绘制流程

前面我们分析了Activity、Dialog、PopupWindow的加载绘制流程,相信大家对整个Android系统中的窗口绘制流程已经有了一个比较清晰的认识了,这里最后再给大家介绍一下Toast的加载绘制流程。

其实Toast窗口和Activity、Dialog、PopupWindow有一个不太一样的地方,就是Toast窗口是属于系统级别的窗口,他和输入框等类似的,不属于某一个应用,即不属于某一个进程,所以自然而然的,一旦涉及到Toast的加载绘制流程就会涉及到进程间通讯,看过前面系列文章的同学应该知道,Android间的进程间通讯采用的是Android特有的Binder机制,所以Toast的加载绘制流程也会涉及到Binder进程间通讯。

Toast的显示流程其实内部还是通过Window的窗口机制实现加载绘制的,只不过由于是系统级别的窗口,在显示过程中涉及到了进程间通讯等机制。

下面我们来具体看一下Toast窗口的简单使用。

Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();

上面的代码是Toast的典型使用方式,通过makeText方法创建出一个Toast对象,然后调用show方法将Toast窗口显示出来。

下面我们来看一下makeText方法的具体实现:

public static Toast makeText(Context context, CharSequence text, @Duration int duration) {
        Toast result = new Toast(context);

        LayoutInflater inflate = (LayoutInflater)
                context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
        TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
        tv.setText(text);

        result.mNextView = v;
        result.mDuration = duration;

        return result;
    }

方法体不是很长,在makeText方法中,我们首先通过Toast对象的构造方法,创建了一个新的Toast对象,这样我们就先来看一下Toast的构造方法做了哪些事。

public Toast(Context context) {
        mContext = context;
        mTN = new TN();
        mTN.mY = context.getResources().getDimensionPixelSize(
                com.android.internal.R.dimen.toast_y_offset);
        mTN.mGravity = context.getResources().getInteger(
                com.android.internal.R.integer.config_toastDefaultGravity);
    }

可以看到这里初始化了Toast对象的成员变量mContext和mTN,这里的mContext是一个Context类型的成员变量,那mTN是什么东西呢?

private static class TN extends ITransientNotification.Stub

从类的源码定义来看,我们知道TN是一个继承自ITransientNotification.Stub的类,这里我们暂时只用知道他的继承关系就好了,知道其是一个Binder对象,可以用于进程间通讯,然后回到我们的makeText方法,在调用了Toast的构造方法创建了Toast对象之后,我们又通过context.getSystemService方法获取到LayoutInflater,然后通过调用LayoutInflater的inflate方法加载到了Toast的布局文件:

LayoutInflater inflate = (LayoutInflater)
                context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);

这里我们可以看一下布局文件的具体代码:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:background="?android:attr/toastFrameBackground">

    <TextView
        android:id="@android:id/message"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:layout_gravity="center_horizontal"
        android:textAppearance="@style/TextAppearance.Toast"
        android:textColor="@color/bright_foreground_dark"
        android:shadowColor="#BB000000"
        android:shadowRadius="2.75"
        />

</LinearLayout>

可以发现Toast加载的布局文件只有一个LinearLayout布局,并且只包含一个TextView组件。。。。

然后我们通过调用:

TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
        tv.setText(text);

        result.mNextView = v;
        result.mDuration = duration;

        return result;

初始化了布局文件,Toast的mNextView和mDuration成员变量并返回Toast类型的result对象。这样我们的Toast对象就构造完成了。

然后我们回到我们的Toast.show方法,调用完这个方法之后就准备开始显示Toast窗口了,我们来具体看一下show方法的具体实现:

public void show() {
        if (mNextView == null) {
            throw new RuntimeException("setView must have been called");
        }

        INotificationManager service = getService();
        String pkg = mContext.getOpPackageName();
        TN tn = mTN;
        tn.mNextView = mNextView;

        try {
            service.enqueueToast(pkg, tn, mDuration);
        } catch (RemoteException e) {
            // Empty
        }
    }

首先判断我们的mNextView是否为空,为空的话,显示逻辑就无法进行了,所以这里判断如果mNextView为空的话,就直接抛出异常,不在往下执行。。。。

然后我们执行了:

INotificationManager service = getService();

这里的INotificationManager是服务器端NotificationManagerService的Binder客户端,我们可以看一下getService方法的实现方式:

static private INotificationManager getService() {
        if (sService != null) {
            return sService;
        }
        sService = INotificationManager.Stub.asInterface(ServiceManager.getService("notification"));
        return sService;
    }

这里获取了INotificationManager对象,然后我们调用了service.enqueueToast方法,并传递了package,TN对象,duration等参数,这里实际执行的是NotificationManagerService的内部类的INotificationManager.Stub的enqueueToast方法,而我们的NoticationManagerService是在SystemServer进程中执行的,这里的底层其实是通过Binder机制传输数据的,具体的Binder机制相关知识可自行学习。。

好吧,我们在看一下INotificationManager.Stub的enqueueToast方法的具体实现:

@Override
        public void enqueueToast(String pkg, ITransientNotification callback, int duration)
        {
            ...
            synchronized (mToastQueue) {
                int callingPid = Binder.getCallingPid();
                long callingId = Binder.clearCallingIdentity();
                try {
                    ToastRecord record;
                    int index = indexOfToastLocked(pkg, callback);
                    // If it‘s already in the queue, we update it in place, we don‘t
                    // move it to the end of the queue.
                    if (index >= 0) {
                        record = mToastQueue.get(index);
                        record.update(duration);
                    } else {
                        // Limit the number of toasts that any given package except the android
                        // package can enqueue.  Prevents DOS attacks and deals with leaks.
                        if (!isSystemToast) {
                            int count = 0;
                            final int N = mToastQueue.size();
                            for (int i=0; i<N; i++) {
                                 final ToastRecord r = mToastQueue.get(i);
                                 if (r.pkg.equals(pkg)) {
                                     count++;
                                     if (count >= MAX_PACKAGE_NOTIFICATIONS) {
                                         Slog.e(TAG, "Package has already posted " + count
                                                + " toasts. Not showing more. Package=" + pkg);
                                         return;
                                     }
                                 }
                            }
                        }

                        record = new ToastRecord(callingPid, pkg, callback, duration);
                        mToastQueue.add(record);
                        index = mToastQueue.size() - 1;
                        keepProcessAliveLocked(callingPid);
                    }
                    // If it‘s at index 0, it‘s the current toast.  It doesn‘t matter if it‘s
                    // new or just been updated.  Call back and tell it to show itself.
                    // If the callback fails, this will remove it from the list, so don‘t
                    // assume that it‘s valid after this.
                    if (index == 0) {
                        showNextToastLocked();
                    }
                } finally {
                    Binder.restoreCallingIdentity(callingId);
                }
            }
        }

可以发现我们首先将我们的ToastRecord(Toast对象在server端的对象)保存到一个List列表mToastQueue中,然后调用了showNextToastLocked方法,这样我们在看一下showNextToastLocked方法的具体实现。

void showNextToastLocked() {
        ToastRecord record = mToastQueue.get(0);
        while (record != null) {
            if (DBG) Slog.d(TAG, "Show pkg=" + record.pkg + " callback=" + record.callback);
            try {
                record.callback.show();
                scheduleTimeoutLocked(record);
                return;
            } catch (RemoteException e) {
                Slog.w(TAG, "Object died trying to show notification " + record.callback
                        + " in package " + record.pkg);
                // remove it from the list and let the process die
                int index = mToastQueue.indexOf(record);
                if (index >= 0) {
                    mToastQueue.remove(index);
                }
                keepProcessAliveLocked(record.pid);
                if (mToastQueue.size() > 0) {
                    record = mToastQueue.get(0);
                } else {
                    record = null;
                }
            }
        }
    }

这里主要执行了record.callback.show方法,而这里的callback对象就是我们创建Toast对象的时候传递的TN对象,显然的,这了的show方法就是我们的Toast内部类TN的show方法,然后我们调用了scheduleTimeoutLocked方法,这里先看一下scheduleTimeoutLocked方法的实现。

private void scheduleTimeoutLocked(ToastRecord r)
    {
        mHandler.removeCallbacksAndMessages(r);
        Message m = Message.obtain(mHandler, MESSAGE_TIMEOUT, r);
        long delay = r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY;
        mHandler.sendMessageDelayed(m, delay);
    }

可以发现这里发送了一个异步消息,并且这里的异步消息是在duration时间之后发送的,也就是说我们在Toast端传递的duration参数就是这里的message消息delay发送的时间,而我们发送MESSAGE_TIMEOUT异步消息之后最终会被方法handleTimeout执行。

private void handleTimeout(ToastRecord record)
    {
        if (DBG) Slog.d(TAG, "Timeout pkg=" + record.pkg + " callback=" + record.callback);
        synchronized (mToastQueue) {
            int index = indexOfToastLocked(record.pkg, record.callback);
            if (index >= 0) {
                cancelToastLocked(index);
            }
        }
    }

好吧,方法体里面又调用了cancelToastLocked方法,然后我们看一下cancelToastLocked方法的实现:

void cancelToastLocked(int index) {
        ToastRecord record = mToastQueue.get(index);
        try {
            record.callback.hide();
        } catch (RemoteException e) {
            Slog.w(TAG, "Object died trying to hide notification " + record.callback
                    + " in package " + record.pkg);
            // don‘t worry about this, we‘re about to remove it from
            // the list anyway
        }
        mToastQueue.remove(index);
        keepProcessAliveLocked(record.pid);
        if (mToastQueue.size() > 0) {
            // Show the next one. If the callback fails, this will remove
            // it from the list, so don‘t assume that the list hasn‘t changed
            // after this point.
            showNextToastLocked();
        }
    }

好吧,这里又是调用了record.callback.hide方法,显然的这里的hide方法和刚刚的show方法是相似的,都是调用的Toast内部类TN的hide方法,所以这里可以看出Toast的显示与隐藏操作都是在Toast内部类TN的show和hide方法实现的,然后我们调用了:

mToastQueue.remove(index);

清除这个Toast对象,并继续执行showNextToastLocked方法,直到mToastQueue的大小为0。。。

这样关于Toast窗口的显示与隐藏操作都是在Toast内部类TN的show方法和hide方法中,我们先看一下TN内部类的show方法的具体实现:

@Override
        public void show() {
            if (localLOGV) Log.v(TAG, "SHOW: " + this);
            mHandler.post(mShow);
        }

好吧,这里也是发送一个异步消息,我们看一下Runnable类型的mShow的定义。

final Runnable mShow = new Runnable() {
            @Override
            public void run() {
                handleShow();
            }
        };

可以看到再其run方法中调用了handleShow方法,继续看handleShow方法的实现逻辑。

public void handleShow() {
            if (localLOGV) Log.v(TAG, "HANDLE SHOW: " + this + " mView=" + mView
                    + " mNextView=" + mNextView);
            if (mView != mNextView) {
                // remove the old view if necessary
                handleHide();
                mView = mNextView;
                Context context = mView.getContext().getApplicationContext();
                String packageName = mView.getContext().getOpPackageName();
                if (context == null) {
                    context = mView.getContext();
                }
                mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);
                // We can resolve the Gravity here by using the Locale for getting
                // the layout direction
                final Configuration config = mView.getContext().getResources().getConfiguration();
                final int gravity = Gravity.getAbsoluteGravity(mGravity, config.getLayoutDirection());
                mParams.gravity = gravity;
                if ((gravity & Gravity.HORIZONTAL_GRAVITY_MASK) == Gravity.FILL_HORIZONTAL) {
                    mParams.horizontalWeight = 1.0f;
                }
                if ((gravity & Gravity.VERTICAL_GRAVITY_MASK) == Gravity.FILL_VERTICAL) {
                    mParams.verticalWeight = 1.0f;
                }
                mParams.x = mX;
                mParams.y = mY;
                mParams.verticalMargin = mVerticalMargin;
                mParams.horizontalMargin = mHorizontalMargin;
                mParams.packageName = packageName;
                if (mView.getParent() != null) {
                    if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
                    mWM.removeView(mView);
                }
                if (localLOGV) Log.v(TAG, "ADD! " + mView + " in " + this);
                mWM.addView(mView, mParams);
                trySendAccessibilityEvent();
            }
        }

好吧,在handleShow方法中经过一系列的初始化操作,初始化mWN对象,初始化mView对象,初始化了mParams对象,然后调用了mWM的addView方法,到了这里大家应该就很熟悉了(不熟悉的同学可以看一下Activity的加载绘制流程等文章http://blog.csdn.net/qq_23547831/article/details/51285804

http://blog.csdn.net/qq_23547831/article/details/51284556)通过这个方法就实现了Toast窗口的显示逻辑。

继续看一下TN的hide方法:

@Override
        public void hide() {
            if (localLOGV) Log.v(TAG, "HIDE: " + this);
            mHandler.post(mHide);
        }

好吧,和show方法类似,也是发送了一个异步消息,这里看一下Runnable类型的mHide对象的定义:

final Runnable mHide = new Runnable() {
            @Override
            public void run() {
                handleHide();
                // Don‘t do this in handleHide() because it is also invoked by handleShow()
                mNextView = null;
            }
        };

可以发现在其run方法中调用了handleHide方法,显然的,与show方法类似,这里的handleHide方法也是执行Toast窗口销毁的逻辑:

public void handleHide() {
            if (localLOGV) Log.v(TAG, "HANDLE HIDE: " + this + " mView=" + mView);
            if (mView != null) {
                // note: checking parent() just to make sure the view has
                // been added...  i have seen cases where we get here when
                // the view isn‘t yet added, so let‘s try not to crash.
                if (mView.getParent() != null) {
                    if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
                    mWM.removeView(mView);
                }

                mView = null;
            }
        }

可以发现,在方法体重调用了mWM.removeView(mView),又是熟悉的代码,通过执行这里的removeView方法,我们可以实现Toast窗口的销毁流程,至此我们就分析完了Toast窗口的显示与销毁流程。

总结:

  • Toast是一个系统窗口,Toast在显示与销毁流程设计到进程间通讯(Binder机制实现)
  • Toast的show方法首先会初始化一个Toast对象,然后将内部对象TN与duration传递给NotificationManagerService,并在NotificationManagerService端维护一个Toast对象列表。
  • NotificationManagerService接收到Toast的show请求之后,保存Toast对象并回调Toast.TN的show方法具体实现Toast窗口的显示逻辑。
  • Toast窗口的显示与销毁机制与Activity、Dialog、PopupWIndow都是类似的,都是通过WIndow对象实现的。
  • NotificationManagerService端在执行show方法执行会发送一个异步消息用于销毁Toast窗口,这个异步消息会在duration时间段之后发出,这样,在设置Toast显示的时间就会被传递到NotificationManagerService端,并在这段时间之后发送异步消息销毁Toast窗口。
时间: 2024-11-10 01:33:27

android源码解析(二十二)-->Toast加载绘制流程的相关文章

android源码解析(十八)--&gt;Activity布局绘制流程

这篇文章是承接上一篇文章(Android布局加载流程:http://blog.csdn.net/qq_23547831/article/details/51284556)来写的,大家都知道Activity在Android体系中扮演者一个界面展示的角色,通过上一篇文章的分析,我们知道Activity是通过Window来控制界面的展示的,一个Window对象就是一个窗口对象,而每个Activity中都有一个相应的Window对象,所以说一个Activity对象也就可以说是一个窗口对象,而Window

android源码解析(十六)--&gt;应用进程Context创建流程

今天讲讲应用进程Context的创建流程,相信大家平时在开发过程中经常会遇到对Context对象的使用,Application是Context,Activity是Context,Service也是Context,所以有一个经典的问题是一个App中一共有多少个Context? 这个问题的答案是Application + N个Activity + N个Service. 还有就是我们平时在使用Context过程中许多时候由于使用不当,可能会造成内存泄露的情况等等,这个也是需要我们注意的.这里有篇不错的

android源码解析(二十一)--&gt;PopupWindow加载绘制流程

在前面的几篇文章中我们分析了Activity与Dialog的加载绘制流程,取消绘制流程,相信大家对Android系统的窗口绘制机制有了一个感性的认识了,这篇文章我们将继续分析一下PopupWindow加载绘制流程. 在分析PopupWindow之前,我们将首先说一下什么是PopupWindow?理解一个类最好的方式就是看一下这个类的定义,这里我们摘要了一下Android系统中PopupWindow的类的说明: A popup window that can be used to display

android源码解析(十九)--&gt;Dialog加载绘制流程

前面两篇文章,我们分析了Activity的布局文件加载.绘制流程,算是对整个Android系统中界面的显示流程有了一个大概的了解,其实Android系统中所有的显示控件(注意这里是控件,而不是组件)的加载绘制流程都是类似的,包括:Dialog的加载绘制流程,PopupWindow的加载绘制流程,Toast的显示原理等,上一篇文章中,我说在介绍了Activity界面的加载绘制流程之后,就会分析一下剩余几个控件的显示控制流程,这里我打算先分析一下Dialog的加载绘制流程. 可能有的同学问这里为什么

android源码解析之(二)--&gt;异步任务AsyncTask

android的异步任务体系中还有一个非常重要的操作类:AsyncTask,其内部主要使用的是java的线程池和Handler来实现异步任务以及与UI线程的交互.本文主要解析AsyncTask的的使用与源码. 首先我们来看一下AsyncTask的基本使用: class MAsyncTask extends AsyncTask<Integer, Integer, Integer> { @Override protected void onPreExecute() { super.onPreExe

Mybaits 源码解析 (十二)----- Mybatis的事务如何被Spring管理?Mybatis和Spring事务中用的Connection是同一个吗?

不知道一些同学有没有这种疑问,为什么Mybtis中要配置dataSource,Spring的事务中也要配置dataSource?那么Mybatis和Spring事务中用的Connection是同一个吗?我们常用配置如下 <!--会话工厂 --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name=&qu

android源码解析之(八)--&gt;Zygote进程启动流程

大家都知道android系统的Zygote进程是所有的android进程的父进程,包括SystemServer和各种应用进程都是通过Zygote进程fork出来的.Zygote(孵化)进程相当于是android系统的根进程,后面所有的进程都是通过这个进程fork出来的,而Zygote进程则是通过linux系统的init进程启动的,也就是说,android系统中各种进程的启动方式 init进程 –> Zygote进程 –> SystemServer进程 –>各种应用进程 init进程:li

android源码解析之(九)--&gt;SystemServer进程启动流程

上面一文中我们讲过android系统中比较重要的几个进程:init进程,Zygote进程,SystemServer进程已经各种应用进程,其中Zygote进程是整个android系统的根进程,包含SystemServer进程已经各种应用进程在内的进程都是通过Zygote进程fork出来的,具体可参见:http://blog.csdn.net/qq_23547831/article/details/51104873 那么SystemServer进程是做什么用的呢? 其实SystemServer进程主

kafka源码解析之十二KafkaController(中篇)

12.3 KafkaController PartitionStateMachine 它实现了topic的分区状态切换功能,Partition存在的状态如下: 状态名 状态存在的时间 有效的前置状态 NonExistentPartition 1.partition重来没有被创建 2.partition创建之后被删除 OfflinePartition NewPartition 1.partition创建之后,被分配了replicas,但是还没有leader/isr NonExistentParti