Loading service of Android system programming introduction series

Previous articles briefly sorted out the knowledge points related to the interactive response between the application and the user in one of the four components of the Android system, the most important interface activity. What should be used for the logic that does not need to interact with the user in the application? At the beginning of this article, we will introduce the knowledge points related to the internal interaction of applications without interface interaction. First, we will start with the service, one of the other four components.

In the component declaration in the manifest file, it is already known that the service, like the interface activity, must register the declaration in the manifest file. Similarly, the upward traceability of each registered service class must inherit from the android.app.service parent class, so the service also has its own life cycle.

Service is mainly responsible for long-time operations that do not require interface display or interaction in the application, such as playing music and network requests, which can be completed in the service. Like the life cycle of interface activity, time-consuming operations are not allowed in the declaration cycle of service. Therefore, although long-time operations can be carried out in service, these time-consuming operations still need to be put into the main thread of non Android system.

When a new service is started for the first time, the system will request memory space to store the instantiated object of the service. There are two ways to start a service. One is the same as the interface activity. It needs to call the startservice (intent service) of the context object with the help of the intent object.

The second is the method used for inter process communication. Not only the intent object, but also the object implementing the android.content.serviceconnection interface should be used to call the bindservice (intent service, serviceconnection Conn, int flags) method of the context object, and the parameter 3 flags marks the mode bound when starting the service, Context.bind is usually used_ AUTO_ The create tag automatically creates the currently bound service. In addition, other tags can be appended in the form of bit or, such as | context.bind_ NOT_ Foreround marks that the current bound service is a background service with lower priority. When the mobile phone is on the screen or high-energy and time-consuming, the system will give priority to killing the service with lower priority; Add context.bind_ The import flag can raise the priority of the bound service to the foreground service. In the mobile phone screen or high-energy and time-consuming, as long as the current application survives, the current service will not be killed; If | context.bind is appended_ ABOVE_ The client tag indicates that the priority of the currently bound service is higher than that of the current application. When the mobile phone is silent or high-energy and time-consuming, the system may kill the application first, but the current service is still alive.

The Android system provides a set of Aidl language specifications for communication between different processes. The details will be introduced in future articles. Here, we only need to understand that in implementing the serviceconnection interface, we need to rewrite two methods: the onserviceconnected (componentname, ibinder service) method called back after the process communication interface is successfully connected with the service, And the onservice disconnected (componentname) method of the callback after the connection is disconnected.

The above two startup methods will trigger the system to find the corresponding registered service in the manifest file of the current application. After finding it, it will create its instantiated object. If the corresponding service is not found in the manifest file, there will be no error or exception.

Since service is also a subclass of android.content.contentwrapper, after creating the instantiated object of service, the system will also give priority to loading the context running environment, and bind the parameter base as the context object of the current application to the service. At any position after the method is called, you can obtain and use the context of the current service by calling a series of methods such as getbasecontext().

After creating the service and loading the running environment, the system will call this method first, indicating that the current service has been created. You can override this method to perform some resource initialization operations used internally by the service. After this method is executed, it indicates that the current service has been successfully created and will always be running. At the same time, different life cycle methods will be called according to the above startup methods.

If the service is started through the above startup method, the system will call this method every time startservice () is called. The parameter intent receives the intent intention passed in each time the service is started. The parameter flags marks the status of multiple startup of the current service. Generally, the default is 0; When the method is called for the first time and service.start is returned successfully_ REDELIVER_ After intent = 3, it is inexplicably killed by the system. When the service is started again, the tag parameter is service.start_ FLAG_ REDELIVERY=1 ； If the service is called for the first time and the method does not return results, the system will try to call the method again, and the tag parameter is service.start_ FLAG_ RETRY=2 。 The parameter startid is used as the system unique value to mark the current service. Finally, it returns the specified int type. If it returns the default service.start_ STICKY_ Compatibility = 0, when the system kills the service, calling startservice () again will not be called back by the system; In addition, if service.start is returned_ Sticky = 1. After the system kills the service, calling startservice () again will be re created, instantiated and recalled by the system.

If the service is started through the above starting method 2, the system will call bindservice() after calling bindservice() for the first time. If bindservice() is called multiple times later, the system will call back this method only when the current service has completed the life cycle method of onunbind() unbinding and returns false in the unbinding method. The parameter intent receives the intent intention passed in by the binding service, and finally returns the implementation class object of the android.os.ibinder interface. The returned results can be received in the conn.onserviceconnected (componentname, ibinder service) method of parameter 2 of bindservice (int service, int flags) method, that is, the service of ibinder type of parameter 2.

If the service is started through the above starting method 2, you can call unbindservice() to unbind the service at the position corresponding to the bindservice() binding service position. After that, the system will call back the method, and specify the instruction information to be unbound with the help of the intention instance of the parameter intent.

If the service is started through the above starting method 2, if the current service has completed the unbinding life cycle and returns true in the onunbind() method, the system will call this method to rebind the current service with the original ibinder object, so the method does not need to return a value. Its parameter intent receives the intent intention passed in by the binding service. The final return value is boolean type to mark whether the original bound ibinder object is used when the current service is bound again.

After startup, the service will be running until the system may kill low priority processes due to excessive energy consumption, the current service will be killed passively, or the current service actively calls the code to stop running. Corresponding to the above two start modes, the service also has two stop modes. First, corresponding to the service started by startservice (), call the stopservice (intent service) method of the context object of the context environment to stop running, or call the stopself () method of the current service object to stop running its own service. Second, corresponding to the service bound by bindservice (), call the unbindservice (serviceconnection conn) method of the context object to unbind. Since there can be multiple serviceconnection connections bound to this service, you must call the unbindservice () method to actively unbind each bindservice () bound service location to prevent memory leakage, resource occupation and other misoperations.

After all the bindings of the service have been unbound or actively stopped running, the system will eventually call this method, and then destroy the service instantiation object created in memory. Therefore, you can override this method and release the initialization resources applied in oncreate().

The life cycle of the service is somewhat similar to that of the interface activity, which also ensures that operations without user interaction can be performed in it. How do you build sub thread operations for this application scenario? Moreover, the design of service can also carry out inter process communication. How to write code and build a communication bridge between processes? Please look forward to future articles.