Service and Android system design (2)

1. aidl

Since the binder supports RPC, code-based processing may become very complex. Therefore, in actual programming, we also need other auxiliary methods. For example, in actual implementation, we will have a lot of RPC access:

In such a large number of RPC implementations, there will be a lot of repeated code for RPC calls, such as the RPC sending part and the IPC parsing and distribution part implemented by the server side. These repeated codes are meaningless, and in the actual process, such repeated code will also be the source of the error. Imagine how much switch () redirection is required if there are 100 RPC statements. There is another design problem. Of course, if we use a fixed switch () to handle this large number of branch jumps, our code will be solidified in design, we cannot refactor our Code flexibly. Therefore, when implementing the service, we will first use the proxy mode for reconstruction. The standard proxy mode consists of the following:

For the same subject interface class, it will be split into the proxy class and the subjectimpl class of the specific implementation. The implementation of the method is completed in the subjectimpl class, the proxy class implements forwarding some method calls to the subjectimpl class. When the client accesses the client through a unified subject object, the forwarding is actually completed through the proxy class. In this way, interface access and interface implementation will be isolated, and only through the basic interface class subject for interaction, thus reducing the design coupling. The following figure shows how to use the proxy mode in cross-process calls of Android:

The proxy mode used in Android also uses an interface class iinterface to dispatch a specific proxy class and a stub class. The proxy provides the ability to parse the access interface, the specific implementation is provided by stub class. Therefore, we can no longer use the underlying ibinder to access the remote object service, but access through an abstract interface class iinterface. Corresponding to each iinterface abstract class, two different classes are derived, bpxxx and stub. bpxxx is used to provide Proxy functions, and stub class is used to provide specific implementation. Bpxxx, whose name is binder + proxy
+ XXX stands for a specific service name, such as battery. The implementation consisting of this pattern removes the access and implementation of our interfaces. Each of our application processes has a bpxxx object, on the server, there will be a stub object. bpxxx and stub use the iinterface to unify the interface method that can interact with each other. In the application, through a bpxxx, then you can access the methods of stub objects implemented in the service. Therefore, our server only needs to focus on the provision of methods, and implement the methods defined in the iinterface interface class by inheriting the stub object.

We can note that, in fact, the iinterface <XXX> interface, bpxxx, and stub are within the scope of a framework in our figure, of course, it is best to use this part of the access pattern restructured through the proxy design pattern, repetitive code can be implemented by generic code to reduce work. However, this is unrealistic. We cannot predict the methods that an RPC-based object provides. The only clear part of the system is the interface such as iinterface. In this case, if we use a special tool to describe the iinterface interface access method (the remote call method unified by the client and the server) in an intermediate language, then, we can get the goal of reducing repeated code. This tool is IDL, which is further simplified
Android IDL is called aidl.

The full name of IDL is the Interface Definition Language (IDL). It is also the interface specification for interaction proposed by OMG organizations that develop UML specifications. IDL is the implementation of RPC calls. It is defined by an abstract interface language (IDL) to implement cross-platform, cross-language, and cross-network call environments. Since this IDL Language is only a specification, different IDL parsing tools are provided for different software development frameworks, as if HTML is a specification, browsers and HTTP servers can achieve the same performance in different ways. Almost every development environment will build its own set of IDL tools to achieve different interactive development requirements. Ratio
For example, the most commonly used COM/DCOM interface on Windows is used for cross-process cross-Network Environment Development on Windows platforms; in software environments such as Mozilla or OpenOffice, the significance of IDL is to focus more on multi-language support and facilitate plug-in development. Although it also provides cross-process support, but it is not the focus, and does not support networks. The most powerful IDL application environment (Common Object Request Broker Architecture) is provided with a complete cross-platform computing environment, which supports multi-language, multi-platform, and cross-network, the heterogeneous computing environment can be combined into a unified computing environment, Java
Ee also uses CORBA as the underlying mechanism for network interaction.

These different IDL tools play a very similar role, that is, to convert the standard IDL Language into the base class implementation of the development language of your own platform, then, the caller and the implementer implement the specific interfaces respectively. For example, in the preceding RPC example, if you use the C language of IDL to bind, it will look like the following:

The interface method is defined in the IDL file, and the interface rpcfunc1 is defined in the XXX. IDL file. After IDL is translated using a specific IDL tool, xxxstub for the client is generated. h, and xxxskel for the server. h. Then, we can use these two header files to define the implementation of rpcfunc1stub () and rpcfunc1skel () on the server. The result of implementation is that we have an IPC-based cross-process call rpcfunc1 (arg1, arg2 ). Of course, if you have multi-language support, we will also generate versions with different languages. For example, in the object-oriented language environment, xxxstub and xxxskel base classes will be generated, we can inherit the base class and then rewrite this
Specific Method.

For cross-language support, cross-network, and cross-platform environments, the client and server implementations generated by IDL still need to be customized in specific implementations due to complicated application scenarios, for example, handling differences between object-oriented and process-oriented, between the network and single-host environment, between operating systems, and between large and small terminals. Android is much simpler. Our requirements for IDL only solve the problem of cross-Process calling. We only need to support Java language binding and only need to run it in the android environment, only support the standalone environment is required. That is, the IDL itself can be greatly simplified, so there is aidl.

Aidl is the IDL in Android. It only supports the Java environment and is applicable only to the android environment. After the aidl proxy model is introduced, you can almost start RPC programming in the "Dummies" way. Shows the role of aidl:

For the code duplication problem of the interface, proxy, and stub classes we saw earlier, we got a good solution in aidl. With aidl, the definition of these three classes is automatically generated by the aidl tool escape. We will have it in the system. the aidl file is a simplified Java-oriented IDL file that defines the interface methods used by the caller and the called party. The aidl file uses the aidl compilation tool to compile the definition of three base classes: interface, proxy, and stub. Of course, the three classes in the binder environment will be: iinterface <XXX>, bpxxx, and XXX. stub. These are automatically generated and do not need to be modified. The application will
Interface Definition, directly access the remote stub, but in fact the underlying layer will use the bpxxx proxy class to complete forwarding. In our implementation, we only need to inherit from the service class and implement the extended interfaces of the stub class. Therefore, we can easily obtain the RPC multi-process interaction capability based on the binder.

The remote service that uses aidl to compile cross-process remote services is a powerful programming model provided by Android. We need to use Java programming. When using binder IPC to program other parts of the system, or when applications share certain functional interfaces, we must use aidl. Therefore, aidl is not only important for application programming, but also for Android system layer development. aidl does not bring a lot of overhead in programming and is not very complex. Let's take a look at aidl programming in Android.

1.1 Use aidl to declare remote interfaces

The syntax of aidl is actually very simple. Basically, we can regard it as a format similar to the C header file in Java. It only includes the method definition, but does not contain the implementation. Most of these interfaces define one or more interfaces. abstract definitions of these interface methods define the parameter list and return values of the methods. The aidl of this definition method is the entry for aidl parsing. To support data type expansion, it also supports data type expansion through the parcelable interface class. This is because aidl only supports the basic data types of Java and basic classes in some Android environments. In this way, the implementation of the entire environment of aidl and the automatically generated code can be simplified, data Types not directly supported by aidl must be imported by referencing other aidl definitions.

Aidl supports the following data types:

• Java basic data types (metadata type, primitive javaprogramming language types), such as int and Boolean.
• The following basic classes:
  • String
  • List
  • Map
  • Charsequences
• Import the content defined in other aidl files through aidl, which is generally used to import other interface classes
• Other parcelable interface classes imported through aidl are used to import data types not supported by aidl
• Aidl can only be used to define methods. It cannot be used to define the class structure. Although the parcelable interface definition will also be imported, parcelable only describes the existence of a class and does not describe the class structure.
• Aidl uses the In, out, And inout descriptors in parameters. They are mainly used to specify one-way inbound, one-way outbound, and two-way transmission when passed through the binder. We can see from the following parcel that there is overhead for transferring data across processes, and this can be more efficient. For example, "in" and "out" indicates that only one copy is performed at both ends of the sending and receiving processes. "inout" requires two-way replication, copying data from the client to the server, and then sending the data back to the client after the call is complete. We can specify the parameter based on its purpose. If it is not specified, the parameter is in by default.

With the support of such data types, aidl can be applied to almost any situation. When defining an aidl file, you can add it to the eclipse application project. the aidl file is placed in the src/package name/directory, so that the ADT tool will automatically use the aidl tool to compile this file, you can also manually add such a file, then use android. the MK file specifies the aidl job to compile. Finally, aidl will put the compilation result in the gen directory (the same as the storage location of R. Java ).

Defining an aidl file is very simple. You can basically consider it to remove the attributes and implementations in the Java definition and name the obtained file. aidl. For naming conventions, we generally increase the I (first letter of the Interface) before defining the class that needs to throw the interface. For example, we want to declare a remote interface class taskservice, we usually define an itaskservice. aidl file. Of course, since aidl acts on Java, we also need to specify the package name to limit the Domain Name Space of this interface class. In this case, the same as the Java language, the package is used to add the package name.

Packageorg. lianlab. Service

Then, after this line, define the interface class we need to throw through an interface, which is usually different from ours. aidl file names are consistent. For example, we use itaskservice. aidl, we will use interface itaskservice {}, and then define the method we need in the itaskservice scope. The. aidl file we get is probably like this:

Packageorg. lianlab. Service;

Interfaceitaskservice {

Int getpid ();

}

Isn't it easy? Actually it corresponds to Java implementation, because the aidl file only defines methods in the interface class, so no additional reference is required, so the content will be very simple. Because the two remote interface methods we need now only use the most basic data types. If you want to use a class other than the data types supported by aidl, we will also need to reference other aidl files to import these new data definitions to our current aidl definition. Then we will use the Import Statement to import such aidl definitions.

Therefore, the basic syntax of aidl is composed of a format such as package, import, and interface, and then defines the method to be used in the interface. Using import to reference the interface classes defined in each aidl file avoids repeated definitions of the interface classes. Using import to reference the parcelable interface class, therefore, aidl can transmit complex data structures flexibly and conveniently. The only thing to note is that the aidl parsing tool is simple in implementation, and there is no complicated fault tolerance check. When compiling aidl, we need to note lattice problems, such as intgetpid (void ); the format is incorrect.

Later, we will see how to write a remote service for the aidl files that are just a few simple lines and provide this special getpid () Remote Call.