context.getSystemService() ->contextImpl.getSystemService -> SystemServiceRegistry.getSystemService
SystemServiceRegistry.put在static代码块注册系统服务
registerService(Context.CLIPBOARD_SERVICE, ClipboardManager.class,
new CachedServiceFetcher<ClipboardManager>() {
@Override
public ClipboardManager createService(ContextImpl ctx) throws ServiceNotFoundException {
return new ClipboardManager(ctx.getOuterContext(),
ctx.mMainThread.getHandler());
}});
static abstract interface ServiceFetcher<T> {
T getService(ContextImpl ctx);
}
泛型设定返回的系统服务类型,函数参数代表着具体的某一个实例去获取
fetcher.getService(ctx)
ServiceManager.getSystemService()
ClipboardManager内部含有一个
IClipboard mService = IClipboard.Stub.asInterface(
ServiceManager.getServiceOrThrow(Context.CLIPBOARD_SERVICE));
第一步：ServiceManager.getService（name）
ServiceManager在每个进程里都存在
而方法，则是从sCache中获取， sCache中保存着所有的系统服务。
这里不得不提一下IBinder的作用：
内部标识这个服务是远程的还是本地的，通过queryLocalInterface(DESCIPTOR),如果能拿到Interface的就是本地的，拿不到就是远程的
提供transact和ontransact方法来做跨进程调用方法
Binder的其他实现是Binder驱动来做的
public static IBinder getService(String name) {
try {
IBinder service = sCache.get(name);
if (service != null) {
return service;
} else {
return Binder.allowBlocking(rawGetService(name));
}
} catch (RemoteException e) {
Log.e(TAG, "error in getService", e);
}
return null;
}
第二步:IClipboard.Stub.asInterface(IBinder)
这里就是通过拿到了系统服务IBinder，再通过IClipboard.Stub.asInterface的转化。
obj.queryLocalInterface：查询是否在本地。否则返回代理对象
所以最终走的的是new Stub.Proxy(object),返回了一个代理对象
我想过如果obj直接强制类型转换会怎么样？
如果是本进程应该OK，但是如果是其他进程应该会返回null，因为这个Ibinder代表的是一个proxy，也不是实际的对象。就算是实际的对象，也因为存在不同的进程，内存地址不同，导致访问失败。所以这里系统做了一下转换
public static android.content.IClipboard asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof android.content.IClipboard))) {
return ((android.content.IClipboard) iin);
}
return new android.content.IClipboard.Stub.Proxy(obj);
}
Proxy对象和Stub对象交互
interface IClipboard extends android.os.IInterface
public static abstract class Stub extends android.os.Binder implements android.content.IClipboard
static class Proxy implements android.content.IClipboard
注意观察这三个类：
IClipboard接口是继承是IInterface接口：为了保证IBinder在query后拿到的IIterface接口可以强制类型转换
Stub继承自Binder，重写三个方法：onTransact（用于方法调用），asInterface（用于查询是否是本地对象），asBinder。但是Binder的其他方法并没有让重写，原因在于这个方法由Binder驱动来实现
Stub虽然写了implements android.content.IClipboard，但是实际内部内没有实现（Stub是一个抽象类），是为了标识不同的Stub拥有的不同能力
Proxy 实现Clipboard的方式并不是直接对象调用，而是内部持有一个IBinder接口，通过transact方法传参数。
transact和onTransact方法调用
简单来说，并没有直接用对象方法的方式，而是用Parcel包装数据，然后把标识符和参数信息，方法信息传给远端
@Override
public int add(int a, int b) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
int _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeInt(a);
_data.writeInt(b);
mRemote.transact(Stub.TRANSACTION_add, _data, _reply, 0);
_reply.readException();
_result = _reply.readInt();
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
}
3.远端呢？ 远端接受到了这个数据包后，解析，并调用实际的this.add()方法，然后调用reply.write()把返回数据写入
@Override
public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
switch (code) {
case INTERFACE_TRANSACTION: {
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_add: {
data.enforceInterface(DESCRIPTOR);
int _arg0;
_arg0 = data.readInt();
int _arg1;
_arg1 = data.readInt();
int _result = this.add(_arg0, _arg1);
reply.writeNoException();
reply.writeInt(_result);
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
