隐藏在应用程序背后的Binder机制

相关文档参考：

点击打开链接 http://blog.csdn.net/lin20044140410/article/details/73739901

点击打开链接 http://blog.csdn.net/lin20044140410/article/details/50951260

如果你对Binder比较陌生，那么对BindService这样的接口应该很熟悉。

BindService这函数，就是希望“绑定某项服务”，之所以成为绑定，是因为发起请求的应用和目标程序原本并没有任何直接联系。也就是说，它们之间的连接属于进程间通信，因而需要一种把两者绑定在一起的机制---Binder。

我们在程序中任何位置通过bindservice,startactivity,sendboradcase等接口可以很方便的实现与其他进程的交互，这得益于Binder driver，service manager的努力，以及android系统专门面向应用开发提供的Binder强有力的封装，使得应用之间顺利进行无缝通信。

选取bindservice为例，看看隐藏在这些接口背后的Binder内部原理。从android应用程序的角度看，service组件不等同于Binder server。换句话说，它并不是一定要处于运行状态才能接受请求。service组件的生命周期起始于startservice或者bindservice，不管是哪一种启动方式，都是客户端发起连接请求后才执行的，可见service组件本身并不存在持续监听的状态。下面是binder机制的主体框架图：

可见部分：android系统提供给应用程序的接口，组成了可见部分，包括bindservice，startactivity，startservice...

隐藏部分：应用程序只要通过不同的可见接口就可以方便的完成IPC通信，可以肯定的是隐藏的庞大的binder通信原理还是没有变。

app1中某个activity通过bindservice(intent)来试图启动符合intent描述的service服务，最终app2中的service将被运行。完成这一操作目标要有以下几个步骤：

step1，应用程序填写intent，调用bindservice发出请求

step2，收到请求的bindservice将与activitymanagerservice（AMS）取得联系。为了获得AMS的binder句柄，还要事先调用serviceManager.getservice，这里已经涉及进程间通信了。在得到AMS的句柄值后，程序才能真正的向他发起请求。

step3，AMS基于特定的最优匹配策略，从内部存储的系统所有服务组件的资料中找到与intent最匹配的一个，然后发送service绑定请求。

step4，被绑定的服务进程需要响应绑定，执行具体操作，并在成功完成后通知AMS，然后由AMS在回调发起请求的应用程序。

我们知道activity的继承关系如下：

public class Activity extends ContextThemeWrapper

public class ContextThemeWrapper extends ContextWrapper

public class ContextWrapper extends Context

继承关系的根是Context，startactivity，bindservice等等，都是包含在context里面的，context是抽象接口，具体实现在contextwraper中，

\frameworks\base\core\java\android\content\contextWraper.java

    @Override
    public boolean bindService(Intent service, ServiceConnection conn,
            int flags) {
        return mBase.bindService(service, conn, flags);
    }

mBase也是一个context变量，由Contextimpl来实现，bindservice间接调用了bindServiceCommon，

\frameworks\base\core\java\android\app\contextimpl.java

    private boolean bindServiceCommon(Intent service, ServiceConnection conn, int flags,
            UserHandle user) {

            int res = ActivityManagerNative.getDefault().bindService(
                mMainThread.getApplicationThread(), getActivityToken(),
                service, service.resolveTypeIfNeeded(getContentResolver()),
                sd, flags, user.getIdentifier());
    }

那么，应用程序如果找到AMS，并与之建立联系的？来看上面函数中的 ActivityManagerNative.getDefault().

\frameworks\base\core\java\android\app\ActivityManagerNative.java中

    /**
     * Retrieve the system's default/global activity manager.
     */
    static public IActivityManager getDefault() {
        return gDefault.get();
    }

gDefault.get();得到了什么？

    private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");//取得了activitymanagerservice的Ibinder对象，
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b); //创建一个activitymanagerproxy
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };
}

Singleton这是个单实例，保证一个对象只会被创建一次。ActivityManagerNative的作用之一就是帮助调用者快速的取得一个activitymanagerproxy。另一个作用就是为activitymanagerservice的实现提供便利。可以说ActivityManagerNative既是面向调用者的，也是面向服务实现本身的。