android - getSystemService() 是如何工作的？

Question

乍一看下面的代码 mLocationManager对象在 onCreate(...) 之后应该超出范围已完成，预期的行为是 onLocationChanged在对象被垃圾回收之前，永远不会被调用或调用几次。但是 getSystemService 返回的对象似乎是生活在 MainActivity 范围之外的单例(适本地，因为它是一个系统服务:))

在使用 Eclipse 内存分析器进行堆转储并通过它之后，似乎 ContextImpl 保留了对 LocationManager 实例的引用。在内存转储中有两个对 LocationManager 对象的引用，而在代码中显然只有一个，这意味着在其他地方创建了另一个引用。

我的问题是:

在调用以下实现时，是否有人对到底发生了什么有完整的描述:

public abstract Object getSystemService(String name);

对象是否返回了一个懒惰地创建的单例，引用创建/保留的确切位置在哪里？

package com.neusoft.bump.client.storage;

import android.location.Location;
import android.location.LocationListener;
import android.location.LocationManager;
import android.os.Bundle;
import android.app.Activity;
import android.content.Context;
import android.util.Log;
import android.view.Menu;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Log.v("TAG", "STARTED");
        LocationManager mLocationManager = (LocationManager) this
                .getSystemService(Context.LOCATION_SERVICE);

        LocationListener locationListener = new LocationListener() {

            public void onLocationChanged(Location location) {
                Log.v("TAG", "onLocationChanged");
                Log.v("TAG", "Latitude: " + location.getLatitude()
                        + "Longitude: " + location.getLongitude());
            }

            public void onStatusChanged(String provider, int status,
                    Bundle extras) {}

            public void onProviderEnabled(String provider) {}

            public void onProviderDisabled(String provider) {}

        };

        // Register the listener with the Location Manager to receive location
        // updates
        mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,
                600, 0, locationListener);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present
        getMenuInflater().inflate(R.menu.activity_main, menu);
        return true;
    }
}

更新1
LocationManager被创建为单例

private LocationManager getLocationManager() {
    synchronized (sSync) {
        if (sLocationManager == null) {
            IBinder b = ServiceManager.getService(LOCATION_SERVICE);
            ILocationManager service = ILocationManager.Stub.asInterface(b);
            sLocationManager = new LocationManager(service);
        }
    }
    return sLocationManager;
}

但我无法理解调用 ServiceManager.getService(LOCATION_SERVICE); 时会发生什么即使在阅读 ServiceManager 之后代码。

Answer 1

看看我的讨论是否有意义...

dissection of android service internal

正如一位读者所建议的那样，我试图在这里复制部分文章。

你有没有想过一个应用程序如何获得系统服务的句柄，如 POWER MANAGER 或 ACTIVITY MANAGER 或 LOCATION MANAGER 以及其他几个类似的服务。要知道我深入研究了 Android 的源代码并发现了这是如何在内部完成的。
那么让我从应用程序端的java代码开始。

在应用程序端，我们必须调用函数 getService并传递系统服务的 ID(比如 POWER_SERVICE)来获取服务的句柄。

这是 getService 的代码在/frameworks/base/core/java/android/os/ServiceManager.java 中定义

    /**
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    }

假设我们在缓存中没有服务。因此我们需要专注于第 55 行 return getIServiceManager().getService(name);
这个调用实际上获得了服务管理器的句柄，并要求它返回我们作为参数传递的名称的服务的引用。

现在让我们看看 getIServiceManager()函数返回 ServiceManager 的句柄。

这是/frameworks/base/core/java/android/os/ServiceManager.java 中的 getIserviceManager() 的代码

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() 如下所示:

/**
28     * Cast a Binder object into a service manager interface, generating
29     * a proxy if needed.
30     */
31    static public IServiceManager asInterface(IBinder obj)
32    {
33        if (obj == null) {
34            return null;
35        }
36        IServiceManager in =
37            (IServiceManager)obj.queryLocalInterface(descriptor);
38        if (in != null) {
39            return in;
40        }
41
42        return new ServiceManagerProxy(obj);
43    }

所以基本上我们得到了本地服务管理器的句柄。

这个 asInterface 函数实际上是隐藏在两个宏中的 DECLARE_META_INTERFACE(ServiceManager)和 IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");分别在 IserviceManager.h 和 IServiceManager.cpp 中定义。

让我们深入研究/frameworks/base/include/binder/IInterface.h 中定义的两个宏
DECLARE_META_INTERFACE(ServiceManager)宏定义为

// ----------------------------------------------------------------------
73
74#define DECLARE_META_INTERFACE(INTERFACE)                               \
75    static const android::String16 descriptor;                          \
76    static android::sp<I##INTERFACE> asInterface(                       \
77            const android::sp<android::IBinder>& obj);                  \
78    virtual const android::String16& getInterfaceDescriptor() const;    \
79    I##INTERFACE();                                                     \
80    virtual ~I##INTERFACE();                                            \

和 IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");已定义如下:

#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)                       \
84    const android::String16 I##INTERFACE::descriptor(NAME);             \
85    const android::String16&                                            \
86            I##INTERFACE::getInterfaceDescriptor() const {              \
87        return I##INTERFACE::descriptor;                                \
88    }                                                                   \
89    android::sp<I##INTERFACE> I##INTERFACE::asInterface(                \
90            const android::sp<android::IBinder>& obj)                   \
91    {                                                                   \
92        android::sp<I##INTERFACE> intr;                                 \
93        if (obj != NULL) {                                              \
94            intr = static_cast<I##INTERFACE*>(                          \
95                obj->queryLocalInterface(                               \
96                        I##INTERFACE::descriptor).get());               \
97            if (intr == NULL) {                                         \
98                intr = new Bp##INTERFACE(obj);                          \
99            }                                                           \
100        }                                                               \
101        return intr;                                                    \
102    }                                                                   \
103    I##INTERFACE::I##INTERFACE() { }                                    \
104    I##INTERFACE::~I##INTERFACE() { }

因此，如果我们用适当的替换参数替换扩展 IServiceManager.h 和 IServiceManager.cpp 文件中的这两个宏，它们如下所示:

class IServiceManager : public IInterface
{
public:
   static const android::String16 descriptor;  
    static android::sp<IServiceManager> asInterface( const android::sp<android::IBinder>& obj);  
    virtual const android::String16& getInterfaceDescriptor() const; 
    IServicemanager();  
    virtual ~IServiceManager();  
…......
….....
…...
…..

而在
服务管理器.cpp

const android::String16 IServiceManager::descriptor("android.os.IServiceManager”);             
const android::String16&  
       IServiceManager::getInterfaceDescriptor() const {  
    return  IServiceManager::descriptor;
}    
android::sp<IServiceManager> IServiceManager::asInterface(   
        const android::sp<android::IBinder>& obj)  
{   
    android::sp< IServiceManager> intr;    
    if (obj != NULL) {     
        intr = static_cast<IServiceManager*>(   
            obj->queryLocalInterface(  
                    IServiceManager::descriptor).get());    
        if (intr == NULL) {   
            intr = new BpServiceManager(obj);  
        }  
    }     
    return intr;    
}     
IServiceManager::IServiceManager() { }    
IServiceManager::~IIServiceManager { } 

因此，如果您看到第 12 行显示服务管理器是否已启动并正在运行(这应该是因为服务管理器在 Android 启动期间在 init 进程中启动)它会通过 queryLocalinterface 函数返回对它的引用，并且它会全部上升java接口(interface)的方式。

public IBinder getService(String name) throws RemoteException {
116        Parcel data = Parcel.obtain();
117        Parcel reply = Parcel.obtain();
118        data.writeInterfaceToken(IServiceManager.descriptor);
119        data.writeString(name);
120        mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
121        IBinder binder = reply.readStrongBinder();
122        reply.recycle();
123        data.recycle();
124        return binder;
125    }

来自 ServiceManagerNative.java。在这个函数中，我们传递我们正在寻找的服务。

远程 stub 上 GET_SERVICE_TRANSACTION 的 onTransact 函数如下所示:

public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
51    {
52        try {
53            switch (code) {
54            case IServiceManager.GET_SERVICE_TRANSACTION: {
55                data.enforceInterface(IServiceManager.descriptor);
56                String name = data.readString();
57                IBinder service = getService(name);
58                reply.writeStrongBinder(service);
59                return true;
60            }
61
62            case IServiceManager.CHECK_SERVICE_TRANSACTION: {
63                data.enforceInterface(IServiceManager.descriptor);
64                String name = data.readString();
65                IBinder service = checkService(name);
66                reply.writeStrongBinder(service);
67                return true;
68            }
69
//Rest has been discarded for brevity…………………..

………………….
………………….
…………………

它通过函数 getService 返回对所需服务的引用。
/frameworks/base/libs/binder/IServiceManager.cpp 中的 getService 函数
如下所示:

  virtual sp<IBinder> getService(const String16& name) const
134    {
135        unsigned n;
136        for (n = 0; n < 5; n++){
137            sp<IBinder> svc = checkService(name);
138            if (svc != NULL) return svc;
139            LOGI("Waiting for service %s...\n", String8(name).string());
140            sleep(1);
141        }
142        return NULL;
143    }

所以它实际上检查服务是否可用，然后返回对它的引用。在这里我想补充一点，当我们返回对 IBinder 对象的引用时，与其他数据类型不同，它不会被复制到客户端的地址空间中，但它实际上是通过 IBinder 对象共享给客户端的相同引用Binder 驱动程序中称为对象映射的特殊技术。

为了在讨论中添加更多细节，让我再深入一点。

checkService 函数如下所示:

virtual sp<IBinder> checkService( const String16& name) const

    {
        Parcel data, reply;

        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());

        data.writeString16(name);

        remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);

        return reply.readStrongBinder();

    }

所以它实际上调用了一个远程服务并将 CHECK_SERVICE_TRANSACTION 代码(它的枚举值为 2)传递给它。

这个远程服务其实是在frameworks/base/cmds/servicemanager/service_manager.c中实现的
它的 onTransact 如下所示。

switch(txn->code) {
   case SVC_MGR_GET_SERVICE:
           case SVC_MGR_CHECK_SERVICE:
        s = bio_get_string16(msg, &len);
        ptr = do_find_service(bs, s, len);
        if (!ptr)
            break;
        bio_put_ref(reply, ptr);
        return 0;

因此，我们最终调用名为 do_find_service 的函数，该函数获取对服务的引用并将其返回。

来自同一文件的 do_find_service 如下所示:

void *do_find_service(struct binder_state *bs, uint16_t *s, unsigned len)

{

    struct svcinfo *si;

    si = find_svc(s, len);



//    ALOGI("check_service('%s') ptr = %p\n", str8(s), si ? si->ptr : 0);

    if (si && si->ptr) {

        return si->ptr;

    } else {

        return 0;

    }

find_svc 如下所示:

struct svcinfo *find_svc(uint16_t *s16, unsigned len)

{

    struct svcinfo *si;



    for (si = svclist; si; si = si->next) {

        if ((len == si->len) &&

            !memcmp(s16, si->name, len * sizeof(uint16_t))) {

            return si;

        }

    }

    return 0;

}

很明显，它遍历 svclist 并返回我们正在寻找的服务。