android servicemanager与binder源码分析二 ------ servicemanager服务提供者

时间 2019-11-11

标签 android servicemanager binder 源码分析服务提供者栏目 Android 繁體版

原文原文链接

承接上篇，serviceManager是怎么被调用的呢？如何为app提供服务支持？怎么衔接的？。此次我打算从最上层开始逐步把脉络屡清楚。
首先，咱们在写app的时候须要使用AudioManager这类东西的时候，都要调用context.getSystemService(Context.AUDIO_SERVICE);获取服务。逐层看下代码：java

a.activity的getSystemService：android

@Override
    public Object getSystemService(String name) {
        if (getBaseContext() == null) {
            throw new IllegalStateException(
                    "System services not available to Activities before onCreate()");
        }

        if (WINDOW_SERVICE.equals(name)) {
            return mWindowManager;
        } else if (SEARCH_SERVICE.equals(name)) {
            ensureSearchManager();
            return mSearchManager;
        }
        return super.getSystemService(name);
    }

若是是WINDOW_SERVICE或者SEARCH_SERVICE，直接在activity这里就作了处理返回了，不然调用super的同名方法。
b.ContextThemeWrapper的getSystemService：windows

@Override public Object getSystemService(String name) {
        if (LAYOUT_INFLATER_SERVICE.equals(name)) {
            if (mInflater == null) {
                mInflater = LayoutInflater.from(mBase).cloneInContext(this);
            }
            return mInflater;
        }
        return mBase.getSystemService(name);
    }

若是是LAYOUT_INFLATER_SERVICE，在这里直接返回，不然调用mBase的同名方法。
mBase是Context类型，那么其实就是ContextImpl。看下：缓存

1363    @Override
1364    public Object getSystemService(String name) {
1365        return SystemServiceRegistry.getSystemService(this, name);
1366    }

SystemServiceRegistry.java：架构

716    /**
717     * Gets a system service from a given context.
718     */
719    public static Object getSystemService(ContextImpl ctx, String name) {
720        ServiceFetcher<?> fetcher = SYSTEM_SERVICE_FETCHERS.get(name);
721        return fetcher != null ? fetcher.getService(ctx) : null;
722    }

133    private static final HashMap<String, ServiceFetcher<?>> SYSTEM_SERVICE_FETCHERS =
134            new HashMap<String, ServiceFetcher<?>>();

这么逐层看来，你请求的内容在每层都分别回应本身所关心的，若是不关心，交给父类处理，最后会走到SystemServiceRegistry类中，看定义就明白，使用一个hashmap来存储名字和ServiceFetcher的对应关系。那么看到这里大致应该有个了解了，SystemServiceRegistry来维护注册进去的全部服务，固然是其余层级上不关心的。
也同时能够看到责任链的应用，一个请求从上到下会通过不少层，每层都只处理和本身相关的部分，若是没有则交由下层继续传递，若是有直接返回。这种模式的使用其实已经在不少年前就很是普遍了，好比tcp/ip的封包和解包过程，好比windows下的层级调用，再好比android的ui event相应等都采用了相似的思想。不要较真儿说这里是继承那边是调用链什么的，我以为仍是看总体思想为好，不须要拘泥于具体什么什么模式，什么什么规则。
再继续看SystemServiceRegistry这个类，静态类一个，连构造都隐藏了，但不是单例，直接在static中进行了不少服务的注册：app

140    static {
141        registerService(Context.ACCESSIBILITY_SERVICE, AccessibilityManager.class,
142                new CachedServiceFetcher<AccessibilityManager>() {
143            @Override
144            public AccessibilityManager createService(ContextImpl ctx) {
145                return AccessibilityManager.getInstance(ctx);
146            }});
147
148        registerService(Context.CAPTIONING_SERVICE, CaptioningManager.class,
149                new CachedServiceFetcher<CaptioningManager>() {
150            @Override
151            public CaptioningManager createService(ContextImpl ctx) {
152                return new CaptioningManager(ctx);
153            }});
154        ......
707    }

这里使用了静态代码块static，在类被加载的时候必然会走这里。
往下看registerService:tcp

732     * Statically registers a system service with the context.
733     * This method must be called during static initialization only.
734     */
735    private static <T> void registerService(String serviceName, Class<T> serviceClass,
736            ServiceFetcher<T> serviceFetcher) {
737        SYSTEM_SERVICE_NAMES.put(serviceClass, serviceName);
738        SYSTEM_SERVICE_FETCHERS.put(serviceName, serviceFetcher);
739    }

只是向两个hashmap中填充了名字和class而已。在这里已经实例化了。
简单看下ServiceFetcher：ide

741    /**
742     * Base interface for classes that fetch services.
743     * These objects must only be created during static initialization.
744     */
745    static abstract interface ServiceFetcher<T> {
746        T getService(ContextImpl ctx);
747    }

只是个包装interface，根据类型不一样提供了3种子类供各个服务使用：函数

749    /**
750     * Override this class when the system service constructor needs a
751     * ContextImpl and should be cached and retained by that context.
752     */
753    static abstract class CachedServiceFetcher<T> implements ServiceFetcher<T> {
754        private final int mCacheIndex;
755
756        public CachedServiceFetcher() {
757            mCacheIndex = sServiceCacheSize++;
758        }
759
760        @Override
761        @SuppressWarnings("unchecked")
762        public final T getService(ContextImpl ctx) {
763            final Object[] cache = ctx.mServiceCache;
764            synchronized (cache) {
765                // Fetch or create the service.
766                Object service = cache[mCacheIndex];
767                if (service == null) {
768                    service = createService(ctx);
769                    cache[mCacheIndex] = service;
770                }
771                return (T)service;
772            }
773        }
774
775        public abstract T createService(ContextImpl ctx);
776    }
777
778    /**
779     * Override this class when the system service does not need a ContextImpl
780     * and should be cached and retained process-wide.
781     */
782    static abstract class StaticServiceFetcher<T> implements ServiceFetcher<T> {
783        private T mCachedInstance;
784
785        @Override
786        public final T getService(ContextImpl unused) {
787            synchronized (StaticServiceFetcher.this) {
788                if (mCachedInstance == null) {
789                    mCachedInstance = createService();
790                }
791                return mCachedInstance;
792            }
793        }
794
795        public abstract T createService();
796    }
797
798    /**
799     * Like StaticServiceFetcher, creates only one instance of the service per process, but when
800     * creating the service for the first time, passes it the outer context of the creating
801     * component.
802     *
803     * TODO: Is this safe in the case where multiple applications share the same process?
804     * TODO: Delete this once its only user (ConnectivityManager) is known to work well in the
805     * case where multiple application components each have their own ConnectivityManager object.
806     */
807    static abstract class StaticOuterContextServiceFetcher<T> implements ServiceFetcher<T> {
808        private T mCachedInstance;
809
810        @Override
811        public final T getService(ContextImpl ctx) {
812            synchronized (StaticOuterContextServiceFetcher.this) {
813                if (mCachedInstance == null) {
814                    mCachedInstance = createService(ctx.getOuterContext());
815                }
816                return mCachedInstance;
817            }
818        }
819
820        public abstract T createService(Context applicationContext);
821    }
822
823}

暂时不深究到底这3种是什么用途，不过均可看到getService内部会走到createService(ctx);中，而这个抽象方法是必须被实现的。而后在static代码块中注册服务的时候都要有选择的去根据这3种类型实现ServiceFetcher，实现createService。那么不管这个服务是单例非单例，或者在建立的时候须要作什么事情，均可以在这个createService中来进行。那么这3类里面又使用了惰性加载，若是缓存有或者单例有就不用走createService，没有的时候就走。
回过头来看，getService最终返回的是一个注册过的服务的实例化对象。
说了这么半天，跟servicemanager有什么关系？其实在于getService的实现上。以AudioManager为例 /frameworks/base/media/java/android/media/AudioManager.java：fetch

655    private static IAudioService getService()
656    {
657        if (sService != null) {
658            return sService;
659        }
660        IBinder b = ServiceManager.getService(Context.AUDIO_SERVICE);
661        sService = IAudioService.Stub.asInterface(b);
662        return sService;
663    }

看到了吧，这里已经开始对ServiceManager的使用了，而且是经过binder来获得的。那么结合以前的分析，ServiceManager是在一个独立的进程中的，那么其余进程要是想经过它拿到Service等操做，就须要借助Binder这个跨进程的通信方式。再往下看：
/frameworks/base/core/java/android/os/ServiceManager.java:

43    /**
44     * Returns a reference to a service with the given name.
45     *
46     * @param name the name of the service to get
47     * @return a reference to the service, or <code>null</code> if the service doesn't exist
48     */
49    public static IBinder getService(String name) {
50        try {
51            IBinder service = sCache.get(name);
52            if (service != null) {
53                return service;
54            } else {
55                return getIServiceManager().getService(name);
56            }
57        } catch (RemoteException e) {
58            Log.e(TAG, "error in getService", e);
59        }
60        return null;
61    }

简单说：先从缓存中拿，若是没有经过getIServiceManager()去拿，看getIServiceManager：

33    private static IServiceManager getIServiceManager() {
34        if (sServiceManager != null) {
35            return sServiceManager;
36        }
37
38        // Find the service manager
39        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
40        return sServiceManager;
41    }

单例，而后调用到ServiceManagerNative.asInterface，继续看：
/frameworks/base/core/java/android/os/ServiceManagerNative.java：

33    static public IServiceManager asInterface(IBinder obj)
34    {
35        if (obj == null) {
36            return null;
37        }
38        IServiceManager in =
39            (IServiceManager)obj.queryLocalInterface(descriptor);
40        if (in != null) {
41            return in;
42        }
43
44        return new ServiceManagerProxy(obj);
45    }

经过IBinder对象去查询本地接口，若是没查到须要帮助，就创建一个ServiceManagerProxy。这个代理对象是这样的：

109class ServiceManagerProxy implements IServiceManager {
110    public ServiceManagerProxy(IBinder remote) {
111        mRemote = remote;
112    }
113
114    public IBinder asBinder() {
115        return mRemote;
116    }
117
118    public IBinder getService(String name) throws RemoteException {
119        Parcel data = Parcel.obtain();
120        Parcel reply = Parcel.obtain();
121        data.writeInterfaceToken(IServiceManager.descriptor);
122        data.writeString(name);
123        mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
124        IBinder binder = reply.readStrongBinder();
125        reply.recycle();
126        data.recycle();
127        return binder;
128    }
129
130    public IBinder checkService(String name) throws RemoteException {
131        Parcel data = Parcel.obtain();
132        Parcel reply = Parcel.obtain();
133        data.writeInterfaceToken(IServiceManager.descriptor);
134        data.writeString(name);
135        mRemote.transact(CHECK_SERVICE_TRANSACTION, data, reply, 0);
136        IBinder binder = reply.readStrongBinder();
137        reply.recycle();
138        data.recycle();
139        return binder;
140    }
141
142    public void addService(String name, IBinder service, boolean allowIsolated)
143            throws RemoteException {
144        Parcel data = Parcel.obtain();
145        Parcel reply = Parcel.obtain();
146        data.writeInterfaceToken(IServiceManager.descriptor);
147        data.writeString(name);
148        data.writeStrongBinder(service);
149        data.writeInt(allowIsolated ? 1 : 0);
150        mRemote.transact(ADD_SERVICE_TRANSACTION, data, reply, 0);
151        reply.recycle();
152        data.recycle();
153    }
154
155    public String[] listServices() throws RemoteException {
156        ArrayList<String> services = new ArrayList<String>();
157        int n = 0;
158        while (true) {
159            Parcel data = Parcel.obtain();
160            Parcel reply = Parcel.obtain();
161            data.writeInterfaceToken(IServiceManager.descriptor);
162            data.writeInt(n);
163            n++;
164            try {
165                boolean res = mRemote.transact(LIST_SERVICES_TRANSACTION, data, reply, 0);
166                if (!res) {
167                    break;
168                }
169            } catch (RuntimeException e) {
170                // The result code that is returned by the C++ code can
171                // cause the call to throw an exception back instead of
172                // returning a nice result...  so eat it here and go on.
173                break;
174            }
175            services.add(reply.readString());
176            reply.recycle();
177            data.recycle();
178        }
179        String[] array = new String[services.size()];
180        services.toArray(array);
181        return array;
182    }
183
184    public void setPermissionController(IPermissionController controller)
185            throws RemoteException {
186        Parcel data = Parcel.obtain();
187        Parcel reply = Parcel.obtain();
188        data.writeInterfaceToken(IServiceManager.descriptor);
189        data.writeStrongBinder(controller.asBinder());
190        mRemote.transact(SET_PERMISSION_CONTROLLER_TRANSACTION, data, reply, 0);
191        reply.recycle();
192        data.recycle();
193    }
194
195    private IBinder mRemote;
196}

至此，已经开始进入binder的跨进程部分，能够看到其中的getService函数是怎么运做的：
1.创建2个Parcel数据data和reply，一个是入口数据，一个是出口数据；
2.data中写入要获取的service的name；
3.关键：走mRemote的transact函数；
4.读取出口数据；
5.回收资源，返回读取到的binder对象；

够晕吧，这一通调用，可是这部分没办法，实在很差层级总结，只能是一口气跟着调用走下来，而后回过头再看。上面那么多步骤的调用都是为了这最后一步作准备，那么为何要分为这么多层次呢？任何一个操做系统都是很是复杂的，每一个地方都要考虑到不少的扩展性及健壮性，随时能够在某个版本或补丁上去除或扩展出一些内容来。也为了利于多人协做，那么分层的调用可以保证在每个层级上都有可扩展的余地，再进行修改的时候不至于要动不少代码，动的越少就越不容易出错。所以虽然看着费劲点，可是在此仍是要对搞操做系统的以及研究操做系统的人们给予敬意。

最后总结一下，这篇主要说的是从应用层开始与servicemanager衔接的过程，是怎么将servicemanager应用起来的。写这篇的缘由也是发现网上这部分的衔接的资料较少，我以为梳理一下仍是有助于理解系统的机制的，难点并很少，只是帮助理解系统的机制，做为参考吧。顺便再说下，若是你的兴趣在于底层，那么不看此文也罢，不过个人建议是不只要了解各个环节的运做机制，还要在一个更高的角度去看待每一个环节的衔接过程，不然可能你费劲心血在底层作了各类优化后发现效率仍是上不来，那么每每问题出在衔接过程。固然这么庞大复杂的系统不多是一我的写的，每一个人的能力也各有差异，瓶颈总会有的，可是若是你站的够高，那么架构的角度去理解每一个细节及衔接，就可以找出问题所在。不是吗？总之都是我的愚见而已，各位海涵。

下面该说binder的远程通信机制内部的内容了，下一篇文我会继续的。