简单说Binder(2)
几个问题
接着上一篇的内容,本片博客讨论几个问题
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()。反复之前的步骤。