Detailed introduction to underlying analysis of Android intent data transmission

Detailed introduction to underlying analysis of Android intent data transmission

We know that during activity switching, if you need to pass data to the next activityb, you can use the putextra method of the intent object.

But have you ever thought about this question: what is the relationship between the object obtained in activityb and the object in an activity?

In other words, is it possible that the object I obtained through intent in activityb and the object in activitya are the same object?

According to common sense, the blogger puts forward an idea, and the subsequent process is the proof process, but I regret to tell you that this is not the same object. (PS: nonsense. If it's the same object, there are eventbus. What's the matter t_t)

Then the problem comes again. These two activities are in the same process, or even in the same thread. Data can be shared. Why is it that after passing from one activity to another, it is not an object? When did it become another object?

Don't worry, just listen to me slowly.

What is intent?

The above is the complete declaration of the intent class. You can know that it implements the Parcelable interface. What is the Parcelable interface? This thing is specially used to serialize data on Android, and the parseable object can be directly transmitted during cross process communication.

Next, let's look at what we do when we put the data into the intent.

Taking string as an example, let's first look at the code of putextra method

It is very simple to put the data into the bundle object of mextras. By the way, the bundle class also implements the Parcelable interface. Continue with the code

The internal is to save the data in a map. Here, the process of putting data into intent is completed. In fact, there is a bundle object in intent, and there is a map in the bundle object, and then the data is saved here. As for the unparcel () method, it has nothing to do with our analysis process. Interested readers can study it.

Then, let's look at the process of getting data.

Continue to take string as an example and look at the code in intent

Mextras should be familiar with it. This is a bundle object. When you just save data, you save the data in it. Look at its getString method

It is to directly take out the previously saved string from the map. The try statement is only to verify whether the extracted data is of string type. According to this analysis, the objects in the two activities should be the same object!! Why do you say it's not the same object?

Why not the same object?

If you get extra immediately after putextra, the object you take out must be the same object. That's right! But here we should pay attention to two points:

1. There are restrictions on the types of data allowed to be saved in intent. To be exact, it is the restriction of bundle, because in essence, the data is saved in bundle. If we want to save our defined objects, our objects must implement the Parcelable interface or the serializable interface.

2. We use intent, which is basically stored in one activity and then taken out from another activity.

Then, the problem obviously lies in the startup process of activity. For detailed startup process, you can refer to Lao Luo's article activity startup process.

Let's talk about it here. First, our app runs in the app's own process appprocess, and then the system will start a system process systemprocess when the system is started. When an activity starts, it needs to register with a system service called activitymanagerservice so that our activity can have a callback in its life cycle. The activitymanagerservice service runs in systemprocess. After registration, go back to appprocess to start the new activity. In this registration process, our intent is involved in the whole process.

It is clear that when we call startactivity (intent) to start another activity, our intent has completed two cross process communications, and the objects in it have undergone two rounds of serialization and deserialization. It must not be the same object.

Here's a question by the way: why can serializable also transfer across processes?

Students familiar with Aidl know that the data types supported by Aidl cross process communication are:

Serializable types are not included here.

So I looked at the source code and found that parcel is compatible with serializable objects and can write them directly.

Thank you for reading, hope to help you, thank you for your support to this site!