前言
IPC 系列文章:
建议按顺序阅读。
Android IPC 之Service 还可以这么理解
Android IPC 之Binder基础
Android IPC 之Binder应用
Android IPC 之AIDL应用(上)
Android IPC 之AIDL应用(下)
Android IPC 之Messenger 原理及应用
Android IPC 之获取服务(IBinder)
通过前面的文章我们知道,要进行线程通信的核心是能拿到另一个进程暴露出来的IBiner引用。本篇将重点分析获取IBinder的方式及其原理。
通过本篇文章,你将了解到:
1、获取系统服务
2、获取自定义服务
3、两者区别与联系
本篇文章,系统服务、自定义服务里的服务并非单纯是指Service,而是提供某一类功能的"服务"。
1、获取系统服务
简单例子
以手机振动为例:
Vibrator vibrator = (Vibrator)getSystemService(Context.VIBRATOR_SERVICE);
vibrator.vibrate(1000);
调用Context 方法getSystemService(xx),xx表示服务名字,最终返回Vibrator。
拿到Vibrator 引用后就可以调用相应的方法让手机振动。
继续沿着方法调用分析:
#ContextImpl.java
@Override
public Object getSystemService(String name) {
return SystemServiceRegistry.getSystemService(this, name);
}
#SystemServiceRegistry
public static Object getSystemService(ContextImpl ctx, String name) {
//从map 里获取键值
ServiceFetcher fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
return fetcher != null ? fetcher.getService(ctx) : null;
}
这个map从哪里来呢?在SystemServiceRegistry 静态代码块里注册的:
#SystemServiceRegistry.java
static {
...
registerService(Context.VIBRATOR_SERVICE, Vibrator.class,
new CachedServiceFetcher() {
@Override
public Vibrator createService(ContextImpl ctx) {
return new SystemVibrator(ctx);
}});
...
}
可以看出返回了SystemVibrator,它是Vibrator(抽象类)的子类。
Vibrator.vibrate(xx)最终调用了如下方法:
#SystemVibrator.java
private final IVibratorService mService;
public SystemVibrator(Context context) {
super(context);
//获取服务端提供的接口
mService = IVibratorService.Stub.asInterface(ServiceManager.getService("vibrator"));
}
public void vibrate(int uid, String opPkg, VibrationEffect effect,
String reason, AudioAttributes attributes) {
if (mService == null) {
Log.w(TAG, "Failed to vibrate; no vibrator service.");
return;
}
try {
//真正调用之处
mService.vibrate(uid, opPkg, effect, usageForAttributes(attributes), reason, mToken);
} catch (RemoteException e) {
Log.w(TAG, "Failed to vibrate.", e);
}
}
了解过AIDL的同学都会知道,熟悉的套路:
- mService 为服务端提供的接口,客户端调用其提供的方法即可实现相应的功能。
- 客户端为当前待使用振动服务的App进程,服务端为提供振动服务的进程。
获取IBinder
振动服务的IBinder是通过:
ServiceManager.getService("vibrator")
获取的。
#ServiceManager.java
public static IBinder getService(String name) {
try {
IBinder service = sCache.get(name);
if (service != null) {
return service;
} else {
//获取IBinder
return Binder.allowBlocking(rawGetService(name));
}
} catch (RemoteException e) {
Log.e(TAG, "error in getService", e);
}
return null;
}
private static IServiceManager getIServiceManager() {
if (sServiceManager != null) {
return sServiceManager;
}
//获取服务端的ServiceManager
sServiceManager = ServiceManagerNative
.asInterface(Binder.allowBlocking(BinderInternal.getContextObject()));
return sServiceManager;
}
private static IBinder rawGetService(String name) throws RemoteException {
...
final IBinder binder = getIServiceManager().getService(name);
...
return binder;
}
又是熟悉的套路,IServiceManager 为ServiceManager服务端提供的接口,通过该接口获取振动服务的IBinder引用。
其中BinderInternal.getContextObject()) 获取ServiceManager的IBinder。
此处需要说明一下:
Client 需要从ServiceManager获取震动服务的IBinder,而Client本身需要和ServiceManager通信,要通信那么得有IBinder吧。BinderInternal.getContextObject())就是为了获取ServiceManager的IBinder,该方法从Binder驱动获取了IBinder引用。
注册服务
ServiceManager是如何找到振动服务的呢?
Android 系统启动后,会开启system_server进程,该进程里开启了很多系统服务,包括AMS、WMS、振动服务等。
#SystemServer.java
private void startOtherServices() {
...
VibratorService vibrator = null;
...
vibrator = new VibratorService(context);
//向ServiceManager注册振动服务
ServiceManager.addService("vibrator", vibrator);
...
}
继续来看addService(xx):
#ServiceManager.java
public static void addService(String name, IBinder service) {
addService(name, service, false, IServiceManager.DUMP_FLAG_PRIORITY_DEFAULT);
}
public static void addService(String name, IBinder service, boolean allowIsolated,
int dumpPriority) {
try {
//IPC 调用注册服务
getIServiceManager().addService(name, service, allowIsolated, dumpPriority);
} catch (RemoteException e) {
Log.e(TAG, "error in addService", e);
}
}
调用ServiceManager接口添加服务到ServiceManager里。
小结
好了,现在从头到尾再捋一下。
1、ServiceManager 进程启动
2、system_server 进程启动,并将各个服务(包括振动服务)添加到ServiceManager里
3、客户端从ServiceManager里获取振动服务
用图表示:
其中 Client、ServiceManager、SystemServer 分别运行于三个不同的进程,三者之间通过Binder进行IPC。实线为其调用目的,虚线为其调用手段。
1、SystemServer 通过IPC1 向ServiceManager注册服务的IBinder引用
2、Client想要使用服务(如振动服务),先通过IPC2 向ServiceManager获取
3、Client拿到服务IBinder后,调用服务接口(IPC3),使用服务提供的具体功能
为了减少多次无用IPC调用,因此Client会将拿到的各种服务缓存到数组里,当要查询的服务已经存在,则不用进行IPC2,直接使用IPC3。
系统提供的服务如AMS、WMS、PMS等都将IBinder封装在xxManager(如WindowManager等)里,通过xxManager就可以进行IPC使用具体的服务。
2、获取自定义服务
上面说了系统提供的服务需要注册到ServiceManager里,以便后来者查询使用之。那么我们自己定义的服务该如何使用呢?
Service 的绑定流程
先来看看典型的绑定流程:
服务端代码:
IStudentServer iStudentServer = new IStudentServer.Stub() {
@Override
public void say(String world) throws RemoteException {
Log.d(TAG, "hello " + world);
}
};
@Nullable
@Override
public IBinder onBind(Intent intent) {
return iStudentServer.asBinder();
}
客户端代码:
ServiceConnection serviceConnection = new ServiceConnection() {
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
//重点在service 类型
IStudentServer iStudentServer = IStudentServer.Stub.asInterface(service);
try {
iStudentServer.say("hello");
} catch (Exception e) {
}
}
@Override
public void onServiceDisconnected(ComponentName name) {
}
};
private void bindService() {
Intent intent = new Intent(MainActivity.this, MyService.class);
bindService(intent, serviceConnection, Context.BIND_AUTO_CREATE);
}
大致阐述上述流程:
1、Service 构造Binder对象,并将IBinder在onBind(xx)传递出去
2、客户端在绑定Service成功后会收到服务端传递过来的IBinder
3、通过该IBinder获取关联的接口操作服务端
可以看出,我们在Service里定义业务逻辑(Server端),并开放了接口,通过Service的绑定功能将接IBinder传递给客户端,这和获取系统服务的逻辑是一样的,核心都是IBinder的传递,接下来从源头入手查看IBinder的传递。
从Context.bindService(xx)开始
由于涉及到的代码较多,此处就不贴完整源码了,重点关注关键之处和IPC 流程,多用图示之。
绑定流程图:
大致解释上图元素构成:
最顶上方框为类名。
红色表示它们都运行在同一进程,暂且称之为客户端进程。
绿色表示它们都运行在同一进程,暂且称之为系统服务进程。
黄色表示它们都运行在同一进程,暂且称之为服务端进程。
红色箭头表示该调用为进程间调用,用IPC 表示之。其余为本进程内的对象调用。
分别来分析重点1、2、3。
重点1
客户端发起绑定操作,传入ServiceConnection 引用,该引用在ContextImpl.bindServiceCommon(xx)里被封装在ServiceDispatcher里,而ServiceDispatcher又持有InnerConnection引用,InnerConnection 继承自IServiceConnection.Stub 可以跨进程调用。
也就是说,客户端进程留下了一个"桩",等待别的进程调用。
重点2
AMS 收到客户端的绑定指令后,发起绑定操作,通过IPC 调用服务端接口。
最终调用到服务端的onBind(xx)方法,该方法里返回服务端的IBinder引用。
重点3
服务端返回IBinder引用后,委托AMS 发布这个IBinder,IBinder找到对应的客户端进程。而在重点1里客户端已经留下了"桩",此时AMS 顺势找到这个"桩"直接调用ServiceConnection的onServiceConnected(xx),就能将IBinder传递给客户端。
可能比较绕,我们从进程的角度再简化一下:
可以看出,以上发生了四次IPC 操作(当然里面还涉及到其它的IPC,此处忽略)。IBinder传递要经过两次IPC。
IBinder 传递
上面分析了通过绑定流程返回服务端的IBinder引用。
但是运行的过程中却发现问题:
服务端返回的IBinder是:IStudentServer
而客户端收到的IBinder是:BinderProxy
这个是怎么回事呢?
既然IBinder是通过进程间传递的,看看其是否是支持序列化。
public interface IBinder {
...
}
public class Binder implements android.os.IBinder {
...
}
发现它们都没有实现Parcelable 接口。它是怎么支持序列化的呢?
那只能从Parcel本身分析了。
Parcel 除了支持
readInt()
writeInt()
...
等基本数据类型外,还支持
public final IBinder readStrongBinder() {
return nativeReadStrongBinder(mNativePtr);
}
public final void writeStrongBinder(IBinder val) {
nativeWriteStrongBinder(mNativePtr, val);
}
顾名思义,应该是专门读写IBinder的方法,也就是说虽然没有实现Parcelable,但是Parcel 内置支持了IBinder。
接着继续查看其native方法,看看有何奥妙之处。
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr)
{
Parcel* parcel = reinterpret_cast(nativePtr);
if (parcel != NULL) {
return javaObjectForIBinder(env, parcel->readStrongBinder());
}
return NULL;
}
static void android_os_Parcel_writeStrongBinder(JNIEnv* env, jclass clazz, jlong nativePtr, jobject object)
{
Parcel* parcel = reinterpret_cast(nativePtr);
if (parcel != NULL) {
const status_t err = parcel->writeStrongBinder(ibinderForJavaObject(env, object));
if (err != NO_ERROR) {
signalExceptionForError(env, clazz, err);
}
}
}
注:方法在/frameworks/core/jni/android_os_Parcel.cpp
先分析写入IBinder的情况:
parcel->writeStrongBinder(xx) 调用了Parcel.cpp里的writeStrongBinder(xx)进而调用flatten_binder(xx)函数
status_t flatten_binder(const sp& /*proc*/,
const sp& binder, Parcel* out)
{
flat_binder_object obj;
...
if (binder != NULL) {
IBinder *local = binder->localBinder();
if (!local) {
//本地引用不存在
BpBinder *proxy = binder->remoteBinder();
if (proxy == NULL) {
ALOGE("null proxy");
}
const int32_t handle = proxy ? proxy->handle() : 0;
//type 标记为非本地Binder
obj.hdr.type = BINDER_TYPE_HANDLE;
obj.binder = 0; /* Don't pass uninitialized stack data to a remote process */
obj.handle = handle;
obj.cookie = 0;
} else {
//IBinder为本地的Binder引用,也就是和Server处在同一进程
//type 标记为本地Binder
obj.hdr.type = BINDER_TYPE_BINDER;
obj.binder = reinterpret_cast(local->getWeakRefs());
obj.cookie = reinterpret_cast(local);
}
} else {
...
}
return finish_flatten_binder(binder, obj, out);
}
可以看出,根据传入的IBinder是不是本地Binder然后打上type标记。
再来看看读取IBinder的情况
parcel->readStrongBinder()里最终调用了:
status_t unflatten_binder(const sp& proc,
const Parcel& in, sp* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
//根据Type 标记判断
switch (flat->hdr.type) {
case BINDER_TYPE_BINDER:
//本地引用
*out = reinterpret_cast(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
//非本地引用,获取代理对象
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
由此可见,如果是Server端的IBinder与Client端不在同一进程,则会转换为Proxy对象,最终体现在Java层的就是BinderProxy类型。
注:函数在/frameworks/native/libs/binder/Parcel.cpp
综上所述,IBinder跨进程传递时:
- 如果客户端、服务端同一进程,则服务端回传的IBinder为当前引用
- 如果客户端、服务端处在不同进程,则服务端回传的IBinder为BinderProxy
3、两者区别与联系
获取系统服务
系统服务会往ServiceManager注册,ServiceManager运行在单独的进程里,客户端进程需要先向ServiceManager里请求IBinder,再使用IBinder获取关联接口进而使用系统服务。
获取自己定义的服务
服务端进程开启后,暴露出IBinder。客户端通过绑定服务端进程里的Service,将IBinder跨进程传递至客户端,客户端再使用IBinder获取关联接口进而使用自定义服务。此过程没有借助于ServiceManager。
不论是哪种方式,核心都需要获得IBinder,IBinder的获取需要IPC。
至此,Android IPC 系列文章已经分析完毕
本文基于Android 10.0。
您若喜欢,请点赞、关注,您的鼓励是我前进的动力
持续更新中,和我一起步步为营系统、深入学习Android
1、Android各种Context的前世今生
2、Android DecorView 一窥全貌(上)
3、Android DecorView 一窥全貌(下)
4、Window/WindowManager 不可不知之事
5、View Measure/Layout/Draw 真明白了
6、Android事件分发全套服务
7、Android invalidate/postInvalidate/requestLayout 彻底厘清
8、Android Window 如何确定大小/onMeasure()多次执行原因
9、Android事件驱动Handler-Message-Looper解析
10、Android 键盘一招搞定
11、Android 各种坐标彻底明了
12、Android Activity/Window/View 的background
13、Android IPC 之Service 还可以这么理解
14、Android IPC 之Binder基础
15、Android IPC 之Binder应用
16、Android IPC 之AIDL应用(上)
17、Android IPC 之AIDL应用(下)
18、Android IPC 之Messenger 原理及应用