几个问题
接着上一篇的内容，本片博客讨论几个问题
1.跨进程传递IBinder对象的情形
2.跨进程回调
3.分析Toast的显示过程：跨进程回调的例子
跨进程传递IBinder对象的情形
会不会觉得传递IBinder有点奇怪呀？Binder机制不是用来做进程间通信的吗，那传递IBinder是为了干啥呢？没错，通信可以是双向的呀，Process A和Process B通信，进程A作为客户端，进程B作为服务端，A向B发消息那么A要获得B的Binder引用才行，那么反过来B要向A发送消息，B也要得到A的Binder引用才行。
上一篇博客在讲ServiceManager的时候，它的ServiceManagerProxy类的addService方法中有这样一句代码
data.writeStrongBinder(service);
我们知道service参数是个IBinder实例，这样两IBinder打包到一个Pracel对象中。其实玄机就在这里。
writeStrongBinder通过JNI调用执行android_os_Parcel_writeStrongBinder函数，在里面java对象转为C++对象。如果传入的是Binder对象则转化为JavaBBinder对象，继承自BBiner，如果是BinderProxy对象，则转化为BpBinder对象。接下来就是在native层面进行了。会根据该IBinder对象是BBinder还是BPBinder创建不同的flat_binder_object对象，里面的type属性由该IBinder对象决定。分别为BINDER_TYPE_BINDER和BINDER_TYPE_HANDLE。在Binder驱动中如果发现该IBinder是BINDER_TYPE_BINDER类型则将其改变为BINDER_TYPE_HANDLE，如果为BINDER_TYPE_HANDLE类型则判断这个IBinder被定义的进程是否和要被传递到的目标进程一样，如果一样，将其类型改变为BINDER_TYPE_BINDER类型，否则为BINDER_TYPE_HANDLE类型。读取和写入是相反的过程。是不是好像少了一种情况：就是该IBinder是BINDER_TYPE_BINDER类型，此时IBinder被定义的进程是和要被传递到的目标进程一样？其实这种情况下不会走到Binder驱动里面，因为不存在IPC。
前面说了这一大堆不理会它了，总结一下就是：
》》Binder对象从进程A传递到进程B，其实在进程B得到的是BinderProxy对象(前面bindService的时候在onServiceConnected回调中的service其实就是BinderProxy类型)，也就是对应于之前说的Binder驱动中的mRemote引用，这个在同一个进程的不同组件/地方获取得到的结果是一样的。
》》如果Binder对象在进程间传递，即使通过再多的进程间的传递，只要最后的目标进程是同一个进程，那么他得到的就是本地的Binder对象。
1.process A → process B → process A
2.process A → process B → process C
对应的IBinder类型就会是：
1.BINDER_TYPE_BINDER → BINDER_TYPE_HANDLE → BINDER_TYPE_BINDER
2.BINDER_TYPE_BINDER → BINDER_TYPE_HANDLE → BINDER_TYPE_HANDLE
跨进程回调：观察者模式的例子
例子：在远程服务中有一个线程每隔三秒回调客户端，同时更新一个计数值用toast显示，大致过程和普通的回调的写法基本一致。
ITimer.aidl 用来构建Binder服务
package org.qhyuan.aidl;
import org.qhyuan.aidl.IListener;
interface ITimer {
void setOnlistener(IListener listener);
void cancel(IListener listener);
}增加IListener.aidl回调的接口package org.qhyuan.aidl;
interface IListener {
void callback(int num);
}
客户端
public class MainActivity extends Activity {
private ITimer itimer;
private boolean isBound;
private Handler handler = new Handler();
private ServiceConnection serviceConn = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
itimer = ITimer.Stub.asInterface(service);
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
// 回调接口
private IListener listener = new IListener.Stub(){
@Override
public void callback(final int num) throws RemoteException {
// error
// Toast.makeText(MainActivity.this, "" + num, 0).show();
handler.post(new Runnable() {
@Override
public void run() {
Toast.makeText(MainActivity.this, "" + num, 0).show();
}
});
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
bind();
}
public void callback(View view){
try {
// 注册回调接口
itimer.setOnlistener(listener);
} catch (RemoteException e) {
e.printStackTrace();
}
}
public void cancelCallback(View view){
try {
// 取消回调接口
itimer.cancel(listener);
} catch (RemoteException e) {
e.printStackTrace();
}
}
private void bind() {
Intent intent = new Intent(MainActivity.this, TimerService.class);
isBound = bindService(intent, serviceConn, Context.BIND_AUTO_CREATE);
}
private void unbind() {
if (isBound) {
MainActivity.this.unbindService(serviceConn);
isBound = false;
}
}
@Override
protected void onDestroy() {
try {
// 退出时取消回调
itimer.cancel(listener);
} catch (RemoteException e) {
e.printStackTrace();
}
unbind();
super.onDestroy();
}
}
服务端
public class TimerService extends Service {
private Timer timer = null;
// 用于保存客户端的回调接口，以便在需要的时候循环通知客户端
private CopyOnWriteArrayList<IListener> listeners = new CopyOnWriteArrayList<IListener>();
// 启动定时器每三秒回调callback函数
public void onCreate() {
super.onCreate();
timer = new Timer();
timer.schedule(new TimerTask() {
private int num = 0;
@Override
public void run() {
num++;
try {
for (int i = 0; i < listeners.size(); i++) {
listeners.get(i).callback(num);
}
} catch (RemoteException e) {
e.printStackTrace();
}
}
}, 0, 2000);
}
// 服务端的Binder
class TimerBinder extends ITimer.Stub {
// 设置回调接口
@Override
public void setOnlistener(final IListener listener) throws RemoteException {
System.out.println("设置---listener" + listener);
System.out.println("设置---binder" + listener.asBinder());
listeners.add(listener);
}
// 取消回调接口，这样以后就不会通知
@Override
public void cancel(IListener listener) throws RemoteException {
System.out.println("取消---listener" + listener);
System.out.println("取消---binder" + listener.asBinder());
listeners.remove(listener);
}
}
@Override
public IBinder onBind(Intent arg0) {
return new TimerBinder();
}
@Override
public void onDestroy() {
timer.cancel();
super.onDestroy();
}
}
同样将Service配置在一个新进程中
<service android:name = "org.qhyuan.binder.TimerService"
android:process=":remote"/>
当点击注册回调按钮后，会每隔3秒弹出toast显示递增的数字，达到了想要的目标。
有以下几个问题需要注意
1.传递的回调接口其实是一个Binder。这不难理解，由于是跨进程通信，服务端要创建Binder对象，然后客户端拿到服务端在驱动中的引用，对应到客户端就是BinderProxy对象。那么，服务端要和客户端通信，这时的情形就反过来了，服务端就变成了客户端，客户端就变成了服务端。
2.当回调callback函数时，由于这是一个远程回调，对于远端的服务端来时其实callback函数是在客户端的Binder线程中执行的，所以不是UI线程，不能直接更新UI，不然弹出如下错误，至于错误也很简单，不过待会还要研究Toast源码，到时候就非常清楚了。
不过还存在一个问题：但是当我们点击取消回调，却不起作用，toast仍然在弹出，说明没有正确取消这个回调接口，即没有从中删除。并且弹出的错误
这个错误正是我们代码中所做的检查：当要取消的回调接口不存在时抛出异常。不过看到上面打印的对象的信息就更加清楚了，明显可以看出来，设置回调的接口和取消的时候的接口就是两个不一样的对象！当然不能达到取消的目的。这也是显然的，跨进程传输的对象不可能占用一样的内存地址，是两个不一样的对象。
同时，注意到asBinder()打印的结果却是一样的。即说明说明底层Binder是一样的，那么就容易解决了，遍历服务端的接口列表中的对象若其底层Binder对象一样那么删除之。
具体说来将cancel做如下这样修改即可
public void cancel(IListener listener) throws RemoteException {
for (int i = 0; i < listeners.size(); i++) {
if (listeners.get(i).asBinder() == listener.asBinder()) {
listeners.remove(listeners.get(i));
}
}
}
这里该怎么理解呢？还是要明白跨进程传递Binder的情形！跨进程传递IBinder的时候，在另一端得到的是BinderProxy对象，这个对象在同一个进程的不同组件/地方获取得到的结果是一样的。
可以看到IListener.aidl生成的类中的setOnlistener方法
public void setOnlistener(org.qhyuan.aidl.IListener listener)
throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeStrongBinder((((listener != null)) ? (listener
.asBinder()) : (null)));
mRemote.transact(Stub.TRANSACTION_setOnlistener, _data,
_reply, 0);
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
以及onTransact中的的处理
case TRANSACTION_setOnlistener: {
data.enforceInterface(DESCRIPTOR);
org.qhyuan.aidl.IListener _arg0;
_arg0 = org.qhyuan.aidl.IListener.Stub.asInterface(data.readStrongBinder());
this.setOnlistener(_arg0);
reply.writeNoException();
return true;
}
可以看到调用了writeStrongBinder函数，并且参数是一个IBinder。根据上面的结论知道，对于这同一个Binder对象来说，传递到服务端的是一个BinderProxy对象，这个代理对象只要是同一个进程来获取就永远是一样的，而如同上面的onTransact中得到BinderProxy后调用asInterface得结果就是又创建了一个IListener$Stub$Proxy对象，当然就是不一样的对象了。但其底层的Binder引用是一样的，就是这个BinderProxy对象。
当然系统给我们提供了RemoteCallbackList类，专门用来做垮进程回调的
public class RemoteCallbackList<E extends IInterface>他的内部原理也很简单，就如同前面说的那样，用一个HashMap保存IBinder和对应的Callback，这样做只是为了提高查找速度，和前面说的遍历的方法本质一样。
Toast源码分析
在了解前面的回调的例子后再来阅读Toast的源码就非常容易了。我们看看平时调用Toast.makeText(context, "Toast", 1).show();这一句到底做了什么？
先大致说一下：调用Toast的show其实执行了一次NotificationManagerService的跨进程调用，将本地的Binder和其它参数传递给远程服务端，远程服务端根据收到的参数构造成ToastRecord对象，远程服务端有一个mToastQueue队列保存ToastRecord对象。接下来，取出队首的元素进行显示，显示的时候也是一个垮进程调用（回调），调用客户端的TN的show函数，在里面通过handler在UI线程调用WindowManager的addView方法添加视图，然后在固定的时间延迟后从窗口移除该视图view，并从mToastQueue中删除队首元素，继续显示队首的ToastRecord。
public static Toast makeText(Context context, CharSequence text, 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;
}
创建Toast对象，他的mNextView属性是要显示的视图view，然后调用show方法
public void show() {
if (mNextView == null) {
throw new RuntimeException("setView must have been called");
}
INotificationManager service = getService();
String pkg = mContext.getPackageName();
TN tn = mTN;
tn.mNextView = mNextView;
try {
// 将Binder作为参数传递给远程服务端，供其回调，这个函数也是个远程调用
service.enqueueToast(pkg, tn, mDuration);
} catch (RemoteException e) {
// Empty
}
}
其中getService是获得与NotificationManagerService服务通信的接口
static private INotificationManager getService() {
if (sService != null) {
return sService;
}
// 获得远程的notification服务的Binder并转化为INotificationManager接口，其实返回的是INotificationManager.Stub.Proxy类
sService = INotificationManager.Stub.asInterface(ServiceManager.getService("notification"));
return sService;
}
其中TN是在客户端创建的Binder，创建该Binder是为了让服务端远程回调。查看ITransientNotification类，就会发现他就是使用aidl工具生成的类。
private static class TN extends ITransientNotification.Stub
接下来调用service.enqueueToast(pkg, tn, mDuration);很明显了它是一个IPC调用。具体的实现在远程服务端，也就是NotificationManagerService，于是我们直接查看NotificationManagerService的enqueueToast方法，参数中的callback实际上是客户端的Binder，callback底层的Binder是客户端的Binder对象的引用，是一个BinderProxy对象。这和前面回调传递的参数是一样的，目的就是为了远程回调该对象的show、hide函数。
public void enqueueToast(String pkg, ITransientNotification callback, int duration)
{
// 判断是不是系统toast
final boolean isSystemToast = ("android".equals(pkg));
// ...
synchronized (mToastQueue) {
int callingPid = Binder.getCallingPid();
long callingId = Binder.clearCallingIdentity();
try {
ToastRecord record;
// 遍历mToastQueue，返回他是不是已经在该队列中，如果不在则返回-1
int index = indexOfToastLocked(pkg, callback);
// 大于0说明已经在该mToastQueue队列中了，就需要更新这次toast的显示时间。
if (index >= 0) {
record = mToastQueue.get(index);
record.update(duration);
} else {
// 队列不存在该toast
// 不是系统toast，不要连续请求显示超过50次
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++;
// MAX_PACKAGE_NOTIFICATIONS是50
if (count >= MAX_PACKAGE_NOTIFICATIONS) {
Slog.e(TAG, "Package has already posted " + count
+ " toasts. Not showing more. Package=" + pkg);
return;
}
}
}
}
// 然后构造ToastRecord对象，并且将其添加到mToastQueue中。
record = new ToastRecord(callingPid, pkg, callback, duration);
mToastQueue.add(record);
index = mToastQueue.size() - 1;
// 保持toast所在进程存活
keepProcessAliveLocked(callingPid);
}
// 如果为0，说明当前的队列中就这一个toast
if (index == 0) {
showNextToastLocked();
}
} finally {
Binder.restoreCallingIdentity(callingId);
}
}
}
如果当前的队列之前已经有toast了，那么僵当前toast添加到队尾即可，否则，队列本来是空的，那么只有当前这一个toast就调用showNextToastLocked();
private 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, false);
return;
} catch (RemoteException e) {
// ...
}
}
}
showNextToastLocked函数里面首先获取队头的ToastRecord对象，record.callback.show();函数是一个远程调用，调用的是客户端的实现。
@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.post(mShow);
}至于为什么使用handler和前面的原因一样，这个函数是在客户端的Binder线程中调用的，不能更改UI，这里使用handler主要为了延时操作。mShow是一个Runnable，里面调用了handleShow函数
public void handleShow() {
// 如果当前的mView和要显示的mNextView不一样，那么调用WindowManager的add方法将该view添加到窗口上
if (mView != mNextView) {
handleHide();
mView = mNextView;
// ...
mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);
// ...
mWM.addView(mView, mParams);
trySendAccessibilityEvent();
}
}
然后在执行scheduleTimeoutLocked(record, false);函数，顾名思义这个函数在超过某个固定时间后做点什么，应该就是隐藏当前toast。
private void scheduleTimeoutLocked(ToastRecord r, boolean immediate) {
Message m = Message.obtain(mHandler, MESSAGE_TIMEOUT, r);
// 如果传入的时间是LENGTH_LONG则延迟LONG_DELAY(3500ms)，否则都延迟SHORT_DELAY(2000ms)
long delay = immediate ? 0 : (r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY);
mHandler.removeCallbacksAndMessages(r);
// 当前环境是在服务端的线程中，使用handler发送一个延时消息
mHandler.sendMessageDelayed(m, delay);
}
mHandler是一个WorkerHandler对象
private WorkerHandler mHandler;
// ...
private final class WorkerHandler extends Handler
{
@Override
public void handleMessage(Message msg)
{
switch (msg.what)
{
case MESSAGE_TIMEOUT:
handleTimeout((ToastRecord)msg.obj);
break;
}
}
}
// ...
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);
// 正常情况下这里是等于0，也就是当前要取消的toast在队头，由于现实时间到了，所以取消显示
if (index >= 0) {
cancelToastLocked(index);
}
}
}
取消显示，调用cancelToastLocked
private void cancelToastLocked(int index) {
ToastRecord record = mToastQueue.get(index);
try {
record.callback.hide();
} catch (RemoteException e) {
}
mToastQueue.remove(index);
keepProcessAliveLocked(record.pid);
if (mToastQueue.size() > 0) {
showNextToastLocked();
}
}
显然里面又通过record.callback.hide();远程调用了客户端的hide方法，类似的，调用到handleHide方法
public void handleHide() {
if (localLOGV) Log.v(TAG, "HANDLE HIDE: " + this + " mView=" + mView);
if (mView != null) {
if (mView.getParent() != null) {
if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
mWM.removeView(mView);
}
mView = null;
}
}
在handleHide方法里面调用WindowManager的removeView方法移除toast的view，至此视图的隐藏就完成了，然后从队列中移除队头元素，并且判断如果队列中仍然有待显示的toast，那么调用showNextToastLocked()，重复之前的步骤。