Android context for the management of various services

Often, when we need to use the service can be obtained through the fruit Context: Context.getsystemservice (name), such as: when we want to know the current phone status (call//sim card status, etc.), We can get telephonymanager through the context:

Final Telephonymanager TM = (Telephonymanager) getsystemservice (Context.telephony_service);

Do you know why you can access various services through the context?

We know that the implementation class of the context is actually: Contextimpl, so let's see Contextimpl has something on it. Through code analysis, you'll soon know: In Contextimpl, the individual service objects are created and saved through the Factory mode and single-column mode. More complex, so the following one is introduced:

(1) Define one of the following hashmap in Contextimpl,

Private static final hashmap<string, servicefetcher> system_service_map = new hashmap<string, servicefetcher& gt; ();

This is a static/final HashMap, which holds the servicefetcher of each service. Where string identifies the current service name and Servicefetcher is the tool class for the service! is actually the object used to create the service.

When we get this service through Getsystemservice (String name), it is through this servicefetcher that we get the services we need:

    Public Object Getsystemservice (String name) {        Servicefetcher fetcher = system_service_map.get (name);        return fetcher = = null? Null:fetcher.getService (this);    }

As the above code shows: In fact, through the Servicefetcher GetService () to obtain.

(2) so we focus on the servicefetcher to realize what function , Servicefetcher is actually a simple factory pattern design ideas, and also used for single-row mode! When using GetService () to obtain a service object, first determine whether the service object already exists: if it already exists, return it immediately, otherwise call him a virtual method CreateService () to create, and save the created service object. Servicefetcher of different services implements different methods of creating objects CreateService (). This way, you can pass the System_service_ The servicefetcher of each service in the map to get its object.

    /*package*/static class Servicefetcher {int mcontextcacheindex =-1; /** * Main entrypoint;         Only the override if you don ' t need caching.            */Public Object GetService (Contextimpl ctx) {arraylist<object> cache = Ctx.mservicecache;            Object Service; Synchronized (cache) {if (cache.size () = = 0) {//Initialize the cache vector on first                    Access.                    At this point Snextpercontextservicecacheindex//is the number of potential services                    Cached Per-context.                    for (int i = 0; i < Snextpercontextservicecacheindex; i++) {cache.add (null);                    }} else {service = Cache.get (Mcontextcacheindex);                    if (service! = NULL) {return service; }} Service = CreateService (CTX);                Cache.set (mcontextcacheindex, service);            return service;  }}/** * Override this to create a new Per-context instance of the * service.         GetService () would handle locking and caching.        */Public Object CreateService (Contextimpl ctx) {throw new RuntimeException ("not implemented"); }    }

( 3) Initialization of the System_service_map.

In Contextimp, there is a static block of code that initializes the servicefetcher of all services and joins the System_service_map.

Here's a look at the initialization of the Power Management Service:

        Registerservice (Power_service, New Servicefetcher () {public                Object CreateService (Contextimpl ctx) {                    IBinder b = Servicemanager.getservice (power_service);                    Ipowermanager service = IPowerManager.Stub.asInterface (b);                    return new PowerManager (Ctx.getoutercontext (),                            Service, Ctx.mMainThread.getHandler ());                });

Registerservice is actually a static method, its main work is: System_service_map.put (ServiceName, fetcher);

With the above analysis, you can get a good understanding of the mixed use of the Factory mode and single-row mode, so that there is no problem? say the above design pattern for the enjoy meta-mode seems more appropriate! Of course, not enough I think no matter the above design mode is actually a kind of name! It is important to know how to solve the actual problem! The enjoy meta mode is equal to the Factory mode + single row mode + (or other mode). It should be clear that the focus of the meta-mode is to share, not to repeat. Its purpose is often to solve: a large number of repeating magnitude objects are used.

Android context for the management of various services