【Android开发之漫漫长途 IX——彻底掌握Binder】上下观古今,起伏千万途。这篇文章主要讲述Android开发之漫漫长途 IX——彻底掌握Binder相关的知识,希望能为你提供帮助。
该文章是一个系列文章,是本人在android开发的漫漫长途上的一点感想和记录,我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索》以及《深入理解Android 卷Ⅰ,Ⅱ,Ⅲ》中的相关知识,另外也借鉴了其他的优质博客,在此向各位大神表示感谢,膜拜!!!另外,本系列文章知识可能需要有一定Android开发基础和项目经验的同学才能更好理解,也就是说该系列文章面向的是Android中高级开发工程师。
前言上一次还不如不说去面试了呢,估计是挂了,数据结构与算法方面虽然面试前突击了一波,但是时间太短,当时学的也不好。另外Android的一些知识也不是很了解。不过这也加大了我写博客的动力。许多知识总觉得自己掌握的还挺好,不过一问到比较细节的方面就不太清楚了。所以写这整个博客的目的也是加深自己的知识,培养自己的沟通能力,和大家一起学习吧。
好了,闲话少说,我们这一篇先解决上一篇中遗留的问题,之后有时间的话,我把这次的面试经历单写一篇博客,和大家共勉。
本篇我们来看一下ServiceManager。上一篇中没怎么说它,ServiceManager作为Android系统服务的大管家。我们还是有必要来看一下它的。
ServiceManager概述ServiceManager是Android世界中所有重要系统服务的大管家。像前文提到的AMS(ActivityManagerService),还有许多以后可能分析到的PackageManagerService等等服务都需要像ServiceManager中注册。那么为何需要一个ServiceManager呢,其重要作用何在呢?私认为有以下几点:
- ServiceManager能集中管理系统内的所有服务,它能施加权限控制,并不是任何进程都能注册服务的。
- ServiceManager支持通过字符串名称来查找对应的Service。这个功能很像DNS。由于各种原因的影响,Server进程可能生死无常。 如果让每个Client都去检测,压力实在太大了。 现在有了统一的管理机构,Client只需要查询ServiceManager,就能把握动向,得到最新信息。
public void setSystemProcess() {
try {
//注册服务,第二个参数为this,这里假设SystemServer通过“socket”与SM交互
ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
..........
} catch (PackageManager.NameNotFoundException e) {
........
}
}
我们SystemServer进程中的AMS通过SM的代理与SM进程交互(读者也可以把这个过程想象为你所能理解的进程间通信方式,例如管道、Socket等),并把自己注册在SM中。这个情况下,我们使用ServiceManager的代理与SM进程交互,既然有代理,那么也得有对应的服务端。那么根据我们之前博客的思路分析的话,就是如下的流程:
ServiceManager是如何启动的?按照我们之前博客的思路,我们在SystemServer端有了个ServiceManager的代理,那么Android系统中应该提供类似AMS这样的继承或间接继承自java层Binder然后重写onTransact方法以处理请求。但是并没有,ServiceManager并没有使用如AMS这样复杂的Binder类结构。而是直接与Binder驱动设备打交道。所以我们上一篇说了ServiceManager不一样。我们来看具体看一下。
ServiceManager在init.rc配置文件中配置启动,是一个以c/c++语言编写的程序。init进程、SM进程等关系如下图
文章图片
我们来看它的main方法。
int main(int argc, char **argv)
{
struct binder_state *bs;
//①应该是打开binder设备吧?
bs = binder_open(128*1024);
if (!bs) {
ALOGE("failed to open binder driver\n");
return -1;
}
//②成为manager
if (binder_become_context_manager(bs)) {
ALOGE("cannot become context manager (%s)\n", strerror(errno));
return -1;
}......//③处理客户端发过来的请求
binder_loop(bs, svcmgr_handler);
return 0;
}
①打开Binder设备
[binder.c]
struct binder_state*binder_open(unsigned mapsize)
{
struct binder_state*bs;
bs=malloc(sizeof(*bs));
......
//打开Binder设备
bs->
fd=open("/dev/binder",O_RDWR);
......
bs->
mapsize=mapsize;
//进行内存映射
bs->mapped=mmap(NULL,mapsize,PROT_READ,MAP_PRIVATE,bs->
fd,0);
}
这一步的目的是把内核层的binder驱动映射到用户空间。我们知道进程之间是独立的,进程呢运行在用户空间内,内核层的Binder驱动可以看成是一个文件(实际上它也是,Linux上都是文件)。这一步呢,可以看成把一个文件映射到用户空间,我们的进程呢通过这个文件进行交互。
文章图片
②成为manager
[Binder.c]
int binder_become_context_manager(struct binder_state*bs)
{
//实现太简单了!这个有个0,什么鬼?
return ioctl(bs->
fd,BINDER_SET_CONTEXT_MGR,0);
}
③处理客户端发过来的请求
[Binder.c]
void binder_loop(struct binder_state *bs, binder_handler func)
{
int res;
struct binder_write_read bwr;
uint32_t readbuf[32];
bwr.write_size = 0;
bwr.write_consumed = 0;
bwr.write_buffer = 0;
readbuf[0] = BC_ENTER_LOOPER;
binder_write(bs, readbuf, sizeof(uint32_t));
for (;
;
) {//果然是循环
bwr.read_size = sizeof(readbuf);
bwr.read_consumed = 0;
bwr.read_buffer = (uintptr_t) readbuf;
res = ioctl(bs->
fd, BINDER_WRITE_READ, &
bwr);
if (res <
0) {
ALOGE("binder_loop: ioctl failed (%s)\n", strerror(errno));
break;
}
//接收到请求交给binder_parse,最终会调用func来处理这些请求
res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
if (res == 0) {
ALOGE("binder_loop: unexpected reply?!\n");
break;
}
if (res <
0) {
ALOGE("binder_loop: io error %d %s\n", res, strerror(errno));
break;
}
}
}
上面传入func的是svcmgr_ handler函数指针,所以会在svcmgr_handler中进行集中处理客户端的请求。
[service_manager.c]
int svcmgr_handler(struct binder_state *bs,
struct binder_transaction_data *txn,
struct binder_io *msg,
struct binder_io *reply)
{
struct svcinfo *si;
uint16_t *s;
size_t len;
uint32_t handle;
uint32_t strict_policy;
int allow_isolated;
if (txn->
target.ptr != BINDER_SERVICE_MANAGER)
return -1;
if (txn->
code == PING_TRANSACTION)
return 0;
strict_policy = bio_get_uint32(msg);
s = bio_get_string16(msg, &
len);
if (s == NULL) {
return -1;
}if ((len != (sizeof(svcmgr_id) / 2)) ||
memcmp(svcmgr_id, s, sizeof(svcmgr_id))) {
fprintf(stderr,"invalid id %s\n", str8(s, len));
return -1;
}if (sehandle &
&
selinux_status_updated() >
0) {
struct selabel_handle *tmp_sehandle = selinux_android_service_context_handle();
if (tmp_sehandle) {
selabel_close(sehandle);
sehandle = tmp_sehandle;
}
}switch(txn->
code) {
case SVC_MGR_GET_SERVICE://得到某个service的信息,service用字符串表示。
case SVC_MGR_CHECK_SERVICE:
s = bio_get_string16(msg, &
len);
//s是字符串表示的service名称。
if (s == NULL) {
return -1;
}
handle = do_find_service(bs, s, len, txn->
sender_euid, txn->
sender_pid);
if (!handle)
break;
bio_put_ref(reply, handle);
return 0;
case SVC_MGR_ADD_SERVICE://对应addService请求。
s = bio_get_string16(msg, &
len);
if (s == NULL) {
return -1;
}
handle = bio_get_ref(msg);
allow_isolated = bio_get_uint32(msg) ? 1 : 0;
if (do_add_service(bs, s, len, handle, txn->
sender_euid,
allow_isolated, txn->
sender_pid))
return -1;
break;
case SVC_MGR_LIST_SERVICES: {//得到当前系统已经注册的所有service的名字。
uint32_t n = bio_get_uint32(msg);
if (!svc_can_list(txn->
sender_pid)) {
ALOGE("list_service() uid=%d - PERMISSION DENIED\n",
txn->
sender_euid);
return -1;
}
si = svclist;
while ((n-- >
0) &
&
si)
si = si->
next;
if (si) {
bio_put_string16(reply, si->
name);
return 0;
}
return -1;
}
default:
ALOGE("unknown code %d\n", txn->
code);
return -1;
}bio_put_uint32(reply, 0);
return 0;
}
ServiceManager的代理是如何获得的?我们来回到最初的调用
[SystemServer.java]
public void setSystemProcess() {
try {
//注册服务,第二个参数为this,这里假设SystemServer通过“socket”与SM交互
ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
..........
} catch (PackageManager.NameNotFoundException e) {
........
}
}
上面的请求最终是通过SM服务代理发送的,那这个代理是怎么来的呢?我们来看
[ServiceManager.java]
public static void addService(String name, IBinder service) {
try {
getIServiceManager().addService(name, service, false);
} catch (RemoteException e) {
Log.e(TAG, "error in addService", e);
}
}private static IServiceManager getIServiceManager() {
if (sServiceManager != null) {
return sServiceManager;
}// 是这里,没错了
sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
return sServiceManager;
}
我们先来看BinderInternal.getContextObject()
[BinderInternal.java]
//好吧,它还是个native函数
public static final native IBinder getContextObject();
跟进[android_ util_Binder.cpp]
static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
sp<
IBinder>
b = ProcessState::self()->
getContextObject(NULL);
return javaObjectForIBinder(env, b);
}
跟进[ProcessState.cpp]
sp<
IBinder>
ProcessState::getContextObject(const sp<
IBinder>
&
/*caller*/)
{
return getStrongProxyForHandle(0);
}/*这个函数是不是我们之前见过*/
sp<
IBinder>
ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<
IBinder>
result;
AutoMutex _l(mLock);
handle_entry* e = lookupHandleLocked(handle);
if (e != NULL) {IBinder* b = e->
binder;
if (b == NULL || !e->
refs->
attemptIncWeak(this)) {
if (handle == 0) {//这里我们的handle为0Parcel data;
//在handle对应的BpBinder第一次创建时
//会执行一次虚拟的事务请求,以确保ServiceManager已经注册
status_t status = IPCThreadState::self()->
transact(
0, IBinder::PING_TRANSACTION, data, NULL, 0);
if (status == DEAD_OBJECT)
return NULL;
//如果ServiceManager没有注册,直接返回
}
//这里还是以handle参数创建了BpBinder
b = new BpBinder(handle);
e->
binder = b;
if (b) e->
refs = b->
getWeakRefs();
result = b;
} else {result.force_set(b);
e->
refs->
decWeak(this);
}
}return result;
}
我们再一步步返回
[android_ util_Binder.cpp]
static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
sp<
IBinder>
b = ProcessState::self()->
getContextObject(NULL);
//这里的b = new BpBinder(0);
return javaObjectForIBinder(env, b);
}
/*这个函数我们上一篇是不是也见过*/
jobject javaObjectForIBinder(JNIEnv* env, const sp<
IBinder>
&
val) {
if (val == NULL) return NULL;
//如果val是Binder对象,进入下面分支,此时val是BpBinder
if (val->
checkSubclass(&
gBinderOffsets)) {
// One of our own!
jobject object = static_cast<
JavaBBinder*>
(val.get())->
object();
LOGDEATH("objectForBinder %p: it‘s our own %p!\n", val.get(), object);
return object;
}
.........
//调用BpBinder的findObject函数
//在Native层的BpBinder中有一个ObjectManager,它用来管理在Native BpBinder上创建的Java BinderProxy对象
//findObject用于判断gBinderProxyOffsets中,是否存储了已经被ObjectManager管理的Java BinderProxy对象
jobject object = (jobject)val->
findObject(&
gBinderProxyOffsets);
if (object != NULL) {
jobject res = jniGetReferent(env, object);
............
//如果该Java BinderProxy已经被管理,则删除这个旧的BinderProxy
android_atomic_dec(&
gNumProxyRefs);
val->
detachObject(&
gBinderProxyOffsets);
env->
DeleteGlobalRef(object);
}//创建一个新的BinderProxy对象
object = env->
NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
if (object != NULL) {env->
SetLongField(object, gBinderProxyOffsets.mObject, (jlong)val.get());
val->
incStrong((void*)javaObjectForIBinder);
jobject refObject = env->
NewGlobalRef(
env->
GetObjectField(object, gBinderProxyOffsets.mSelf));
//新创建的BinderProxy对象注册到BpBinder的ObjectManager中,同时注册一个回收函数proxy_cleanup
//当BinderProxy对象detach时,proxy_cleanup函数将被调用,以释放一些资源
val->
attachObject(&
gBinderProxyOffsets, refObject,
jnienv_to_javavm(env), proxy_cleanup);
// Also remember the death recipients registered on this proxy
sp<
DeathRecipientList>
drl = new DeathRecipientList;
drl->
incStrong((void*)javaObjectForIBinder);
//将死亡通知list和BinderProxy联系起来
env->
SetLongField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<
jlong>
(drl.get()));
// Note that a new object reference has been created.
android_atomic_inc(&
gNumProxyRefs);
//垃圾回收相关;利用gNumRefsCreated记录创建出的BinderProxy数量
//当创建出的BinderProxy数量大于200时,该函数将利用BinderInternal的ForceGc函数进行一个垃圾回收
incRefsCreated(env);
return object;
}
}
接着返回到[ServiceManager.java]
private static IServiceManager getIServiceManager() {
if (sServiceManager != null) {
return sServiceManager;
}// 是这里,没错了BinderInternal.getContextObject()是BinderProxy对象
sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
return sServiceManager;
}
跟进[[ServiceManagerNative.java]]
static public IServiceManager asInterface(IBinder obj)
{
if (obj == null) {
return null;
}
我们知道这里的obj指向的是BinderProxy对象
IServiceManager in =
(IServiceManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}return new ServiceManagerProxy(obj);
}
跟进[Binder.java]
final class BinderProxy implements IBinder {public IInterface queryLocalInterface(String descriptor) {
return null;
}
}
跟进[ServiceManagerNative.java]
class ServiceManagerProxy implements IServiceManager {
public ServiceManagerProxy(IBinder remote) {
//这里的mRemote指向了BinderProxy,与我们上一篇博客中讲述的遥相呼应
mRemote = remote;
}
}
本节小结我们详尽讲述了SM进程的启动以及它作为服务大管家的意义。结合上一篇的内容我们总算是把Binder讲述的比较清楚了。
Binder补充说明 AIDL经过上面的介绍,你应该明白Java层Binder的架构中,Bp端可以通过BinderProxy的transact()方法与Bn端发送请求,而Bn端通过集成Binder重写onTransact()接收并处理来自Bp端的请求。这个结构非常清晰简单,在Android6.0,我们可以处处看到这样的设计,比如我们的ActivityManagerNavtive这个类,涉及到Binder通信的基本上都是这种设计。不过如果我们想要自己来定义一些远程服务。那这样的写法就比较繁琐,还好Android提供了AIDL,并且在Android8.0之后,我们可以看到与ActivityManagerNavtive相似的许多类已经被标注过时,因为Android系统也使用AIDL了。
AIDL的语法与定义一个java接口非常类似。下面我就定以一个非常简单的aidl
IMyAidlInterface.aidl
interface IMyAidlInterface {
int getTest();
}
然后基本上就行了,我们重新build之后会得到一个
IMyAidlInterface.java文件,这个文件由aidl工具生成,我们现在使用的基本是AndroidStudio,即使你使用的是Eclipse也没关系,这个文件会自动生成,不需要你操心。但是我们还是得来看看我们生成的这个文件
public interface IMyAidlInterface extends android.os.IInterface {
//抽象的Stub类,继承自Binder并实现我们定义的IMyAidlInterface接口
//继承自Binder,重写onTransact方法,是不是感觉跟我们的XXXNative很像
public static abstract class Stub extends android.os.Binder implements com.mafeibiao.testapplication.IMyAidlInterface {
private static final java.lang.String DESCRIPTOR = "com.mafeibiao.testapplication.IMyAidlInterface";
/**
* Construct the stub at attach it to the interface.
*/
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}/**
* Cast an IBinder object into an com.mafeibiao.testapplication.IMyAidlInterface interface,
* generating a proxy if needed.
*/
public static com.mafeibiao.testapplication.IMyAidlInterface asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) &
&
(iin instanceof com.mafeibiao.testapplication.IMyAidlInterface))) {
return ((com.mafeibiao.testapplication.IMyAidlInterface) iin);
}
return new com.mafeibiao.testapplication.IMyAidlInterface.Stub.Proxy(obj);
}@Override
public android.os.IBinder asBinder() {
return this;
}@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_getTest: {
data.enforceInterface(DESCRIPTOR);
int _result = this.getTest();
reply.writeNoException();
reply.writeInt(_result);
return true;
}
}
return super.onTransact(code, data, reply, flags);
}/*这个Proxy不用说肯定是代理了,其内部还有个mRemote对象*/
private static class Proxy implements com.mafeibiao.testapplication.IMyAidlInterface {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}@Override
public android.os.IBinder asBinder() {
return mRemote;
}public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}@Override
public int getTest() throws android.os.RemoteException {
android.os.Parcel _data = https://www.songbingjia.com/android/android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
int _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getTest, _data, _reply, 0);
_reply.readException();
_result = _reply.readInt();
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
}static final int TRANSACTION_getTest = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
}public int getTest() throws android.os.RemoteException;
}
可见,AIDL的本质与XXXNative之类的类并没有什么本质的不同,不过他的出现使得构建一个Binder服务的工作大大简化了。
本篇总结我们本篇详细分析了ServiceManager,ServiceManager并没有使用复杂的类结构,他直接与Binder驱动设备交互达到IPC通信的目的。(欠下的债终于补上了)
下篇预告下篇我们来讲一下Android序列化相关知识。
此致,敬礼
推荐阅读
- Android 比SwipeRefreshLayout更漂亮和强大的下拉刷新控件(Android-MaterialRefreshLayout)
- android dialog
- 洋葱头一键装机如何运用,本文教您运用洋葱头一
- 一键还原系统,本文教您如何运用一键还原软件还
- 安装系统 黑云一键重装系统,本文教您如何迅速安装系统
- 电脑装系统图文详细教程,本文教您华为笔记本怎样装win
- 安装系统 笔记本怎样光盘重装系统,本文教您联想笔记本怎
- 一键安装win7,本文教您小马一键重装win7的办法
- 安装系统 360怎样重装系统,本文教您电脑运用360安全卫士怎