几个问题
接着上一篇的内容，本片博客讨论几个问题
1.跨进程传递IBinder对象的情形
2.跨进程回调
3.分析Toast的显示过程：跨进程回调的样例
跨进程传递IBinder对象的情形
会不会认为传递IBinder有点奇怪呀？Binder机制不是用来做进程间通信的吗，那传递IBinder是为了干啥呢？没错，通信能够是双向的呀，Process A和Process B通信，进程A作为client。进程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
跨进程回调：观察者模式的样例
样例：在远程服务中有一个线程每隔三秒回调client，同一时候更新一个计数值用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);
}
client
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;
// 用于保存client的回调接口。以便在须要的时候循环通知client
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"/>
当点击注冊回调button后，会每隔3秒弹出toast显示递增的数字，达到了想要的目标。
有下面几个问题须要注意
1.传递的回调接口事实上是一个Binder。这不难理解。因为是跨进程通信，服务端要创建Binder对象。然后client拿到服务端在驱动中的引用，相应到client就是BinderProxy对象。
那么。服务端要和client通信，这时的情形就反过来了，服务端就变成了client。client就变成了服务端。
2.当回调callback函数时，因为这是一个远程回调，对于远端的服务端来时事实上callback函数是在client的Binder线程中运行的，所以不是UI线程。不能直接更新UI。不然弹出例如以下错误，至于错误也非常easy。只是待会还要研究Toast源代码，到时候就非常清楚了。
只是还存在一个问题：可是当我们点击取消回调，却不起作用。toast仍然在弹出，说明没有正确取消这个回调接口，即没有从中删除。
而且弹出的错误
这个错误正是我们代码中所做的检查：当要取消的回调接口不存在时抛出异常。只是看到上面打印的对象的信息就更加清楚了，明显能够看出来，设置回调的接口和取消的时候的接口就是两个不一样的对象！当然不能达到取消的目的。
这也是显然的，跨进程传输的对象不可能占用一样的内存地址，是两个不一样的对象。
同一时候，注意到asBinder()打印的结果却是一样的。即说明说明底层Binder是一样的，那么就easy攻克了。遍历服务端的接口列表中的对象若其底层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>他的内部原理也非常easy，就如同前面说的那样。用一个HashMap保存IBinder和相应的Callback。这样做仅仅是为了提高查找速度，和前面说的遍历的方法本质一样。
Toast源代码分析
在了解前面的回调的样例后再来阅读Toast的源代码就很easy了。我们看看平时调用Toast.makeText(context, "Toast", 1).show();这一句究竟做了什么？
先大致说一下：调用Toast的show事实上运行了一次NotificationManagerService的跨进程调用，将本地的Binder和其他參数传递给远程服务端。远程服务端依据收到的參数构造成ToastRecord对象，远程服务端有一个mToastQueue队列保存ToastRecord对象。接下来。取出队首的元素进行显示，显示的时候也是一个垮进程调用（回调），调用client的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是在client创建的Binder，创建该Binder是为了让服务端远程回调。
查看ITransientNotification类，就会发现他就是使用aidl工具生成的类。
private static class TN extends ITransientNotification.Stub
接下来调用service.enqueueToast(pkg, tn, mDuration);非常明显了它是一个IPC调用。
详细的实如今远程服务端。也就是NotificationManagerService，于是我们直接查看NotificationManagerService的enqueueToast方法。參数中的callback实际上是client的Binder。callback底层的Binder是client的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();函数是一个远程调用。调用的是client的实现。
@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.post(mShow);
}至于为什么使用handler和前面的原因一样，这个函数是在client的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();远程调用了client的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()。反复之前的步骤。