Android bottom-up knowledge for Android app developers (6)

(11) Broadcastreceiver

Broadcastreceiver, also known as radio, is called receiver.

Many app developers say they never use receiver. In fact, for the music playing class app, with the service and receiver or quite a lot of, if you used QQ music, the app back to the background, the music will not stop, this is the service you wrote in the background to play a role.

Activity at the front desk, click the Stop button, will send a receiver to the background service, notify it to stop playing music, click the Play button, still send this receiver, just carry the value changed, so the service received the request to play music.

In turn, the background service plays a piece of music every time, next ready to play the next music, will give the foreground activity receiver, let activity show the next music name.

So the music player principle, is a front and back activity and service to each other to send and receive receiver process.

Receiver is divided into two types: static broadcast and dynamic broadcast.

Receiver, declared in manifest, is a static broadcast:

To manually write the registration code in the program is a dynamic broadcast:

The two have the same function, but differ in their wording. In this case, we can change all static broadcasts to dynamic broadcasts, which are declared in the manifest file, avoiding the AMS check. What do you think next? Yes, receiver's plug-in solution, that's the idea.

Next we see how receiver and AMs deal with, divided into two parts, one is registration, and the other is to send the broadcast.

You only have to register this broadcast, send this broadcast, can notify you, execute OnReceive method.

We'll take a music player for example, register Receiver in activity, send a broadcast on the service. When the service plays the next piece of music, the activity is notified to modify the name of the music that is currently playing.

The registration process is as follows:

1) In the activity, register receiver and notify AMS.

The activity here uses the Registerreceiver method provided by the context and passes a receiver to AMs via Amn/amp.

When creating this receiver object, you need to specify Intentfilter for receiver, which is the receiver's ID, which describes receiver.

In the Registerreceiver method of the context, it uses the PMS to obtain information about the package, which is the loadedapk object.

This is the Loadedapk object, its Getreceiverdispatcher method, which encapsulates receiver into a binder object that implements the Iintentreceiver interface.

We're just going to pass this binder object and filter to AMs.

Just passing receiver to AMs is not enough, and when sending a broadcast, AMS does not know who to send it to? So the process of activity also sends its object to AMS.

2) After the AMS receives the message, it will put the above information, there is a list, this list holds all receiver.

Note that the busy day here is registered with dynamic receiver.

When did the static receiver register with AMS? is when the app is installed. The PMS will parse the four components in the manifest to save the receiver.

The dynamic receiver and the static receiver exist in different AMS variables, and when the broadcast is sent, the two receiver are combined and sent. Where the dynamic is in front of the static, so dynamic receiver always takes precedence over the static receiver to receive the message.

In addition, the Android system will register the static broadcast recipient with AMS each time it is started. Because every time the Android system starts, it will reinstall all the APK, the detailed process, we will see in the relevant section of the PMS later.

---------------the splendid dividing line------------------------

The process for sending broadcasts is as follows:

1) in the service, through the Amm/amp, send broadcast to AMS, the broadcast carries the filter.

2) After AMS receives this broadcast, in the receiver list, according to filter to find the corresponding receiver, may be multiple, put them all in a broadcast queue. Finally, a message is sent to the AMS message queue.

When this message in the message queue is processed, AMS finds the appropriate receiver from the broadcast queue and broadcasts the broadcast to the process where the broadcast receiver is located.

3) receiver is in the process of receiving the broadcast, and does not send the broadcast directly to receiver, but the broadcast into a message, sent to the main thread of the message queue, when the message is processed, the message will be sent to receiver.

Let's take a closer look at these 3 stages through the diagram below:

1th step, the service sends a broadcast to AMS

Sending the broadcast, by intent this parameter, carries the filter, which tells AMS what receiver can accept the broadcast.

The 2nd step, AMS receives the broadcast, sends the broadcast.

Receive broadcasts and send broadcasts are out of sync. When AMS receives a broadcast, it throws it into the broadcast send queue, and it doesn't matter if the transmission is successful.

Because receiver is divided into random receiver and ordered receiver, the broadcast send queue is divided into two, respectively, to send the two broadcasts.

AMS sends a broadcast to the client, which is another cross-process communication, or through ATP, sending messages to apt. Because the receiver is being passed, it is also a binder object before it can pass through. As we said earlier, when registering receiver with AMS, receiver is encapsulated as a binder object of the Iintentreceiver interface. So next, AMS is to transfer this Iintentreceiver interface object back.

3rd step, App processing broadcast

This process is described as follows:

1) The message from the AMS to the client, the AMS Iintentreceiver interface object into the Innerreceiver object, this is receiver, which is a aidl cross-process communication.

2) then encapsulate a args object in the Receiverdispatcher (this is a Runnable object, to implement the Run method), including all the information required by the broadcast receiver, and give activtythread to send

3) The next path is what we are familiar with, activtythread the args message into the H Hanlder, sending a message to the main thread message queue. When executing the args message, it is natural to execute the args run method.

4) in the Run method of args, instantiate a receiver object and invoke its Onreceiver method.

5) Finally, in the args run method, as receiver's Onreceiver method call ends, a message is sent via Amn/amp to AMS, telling AMs that the broadcast was sent successfully. After AMS is notified, it sends a broadcast to the next receiver.

Note: Innerreceiver is the stub of the Iintentreceiver, which is the receiving end of the binder object.

Types of Broadcasts

There are three types of Android broadcasts categorized by send: Unordered broadcast, ordered broadcast (orderedbroadcast), and sticky Broadcast (stickybroadcast).

1) unordered broadcasts are the most common broadcasts.

2) An ordered broadcast differs from an unordered broadcast in that it can specify a priority.

These two types of receiver exist in different AMS variables, which can be considered as two receiver sets, sending different classes of broadcasts.

3) Sticky broadcasting is a kind of disordered broadcasting.

Sticky broadcast, we don't usually see much, but I say a scene you understand, that is the battery power. When the charge is less than 20%, the user is prompted.

The information about how to get the battery is realized by broadcasting.

But the general broadcast, the end is finished. We need to have such a broadcast, after it has been issued, can still exist, the future registrant can also receive this broadcast, this broadcast is sticky broadcast.

Because dynamic receiver can only register and receive broadcasts when the activity's OnCreate () method is called, the broadcast cannot be accepted when the program is not running, but static registration does not depend on whether the program is running.

At this point, all the concepts about the broadcast, all introduced, even I was more surprised, I actually did not put any code. Hopefully these 2000 + words will guide app developers into a magical world.

Next article, let's go and see ContentProvider.

Android bottom-up knowledge for Android app developers (6)