Win32 COM components x Android Service

Some books introduce and explain the service components of Android, using the term backend services, and are relative to the activity running on the main thread. Because the word backstage is easily misunderstood, the service has been running in the background? What thread is running? Service has always been a thread running? and backstage in different contexts have different understanding. But if you've developed a COM application, the service component is easy to understand.

We review how to use COM, first instance a coinstance, then through the IUnknown interface QueryInterface query out the interface we want, and then call the interface method to access the services provided by the COM component. A COM component may be instances in the same process, or the instance is in an out-of-process local process (or a remote process). For a free-threaded in-process component, an interface call (the code of a COM component) runs on the calling thread. For the components of a suite thread, both in-process and out-of-process, the interface call accesses the COM component's functionality through the IPC (LPC or RPC) serial.

Let's take a look at the use of the service in Android.
For the use of non-system services.
First Context.bindservice, (if there are no service instances in the system scope are created), they say that binding to a service, in fact, the most important is to obtain the service corresponding to the IBinder. This is where you get used to the classes of receiving results that are commonly used in Java or JavaScript programming, which tend to receive results by providing an interface callback method. The second argument like this one is a serviceconnection class, which is considered to be responsible for dealing with the methods associated with the Connect function, but is essentially a callback interface for receiving results. Hey! Nothing to say, get used to it.

Get this ibinder is the key to our visit, but how to access, the general books and posts are not explained. I use the system service Clipboardmanager (just select) code to give an example. In the source code comments, the Android team uses proxying to express this kind of Clipboardmanager to the Iclipboard interface once again, similar to the bridge mode of access.

For the use of system services.
First Context.getsystemservice, we get a proxying encapsulation of the system service interface. For example, the Clipboardmanager package is a call to the Iclipboard interface.
We enter the Clipboardmanager source code.

 static  private   Iclipboard GetService () { synchronized  
   
     (sstaticlock) { 
    if  (sservice!! 
    null  
    ) { 
    return<            /span> Sservice;            } ibinder B  = Servicemanager.getservice ("clipboard"  = IClipboard.Stub.asInterface (b);         return   Sservice; }    }
   

Can see, still want to get the service IBinder. We can laugh, IClipboard.Stub.asInterface (b), is not equivalent to IUnknown QueryInterface? Well, IBinder is the equivalent of a IUnknown, through the "target interface." Stub.asinterface "queries the target interface and, of course, accesses the non-null interface, which is the provided functionality of the service."

For Android, the service is an instance, a system-wide singleton, and the call to the service-process is running on the calling thread (or the main thread), and the call outside the service process is a activeobject-mode access, and the service function call runs within the service process, Interfaces invoke processes and service processes to pass parameters and results through the IPC. By browsing IBinder's implementation of binder source code, most of the functions are doing the IPC and proxy work.

For the service, in addition to providing interface access functionality like COM components, the other approach is to process the intent request, which is done in Service.onstartcommand without the help of IBinder. Access to the functionality of the service through StartService (Intent) to request a visit, once again spit slot, the name will be literally understood to start the service, in fact, mainly through the Intent pass parameters, request a service. And there is no service.onpause and service.onstop, that is service.onstart does not affect the status of service, just deal with intent callback entrance, Hey ~. The Pendingservice has a dedicated thread that uses the message callback pendingservice.onhandleintent to serially process all incoming intent.

In addition context.bindservice with parameter intent, not to process intent requests in service.onbind, but as interface query parameters, return different ibinder, your service can gather more than IBinder.

Win32 COM components x Android Service