Killing the background is a topic that the Android system can never get around. The interesting thing about this topic is that some people denounce the background for killing them so that they can’t get a smooth daily use experience, while some people denounce the app’s background staying. Destroyed one’s daily use experience.
With many mobile phone manufacturers increasing the running memory of their phones to 12G or even 16G, the problem of killing the background has once again become a hot spot. Is it really necessary to kill the background of a mobile phone with such a large memory? In fact, it’s not just users who have a headache for this, but also software developers and Android developer Google.
Recently, Google officially launched an investigation into the background killing of third-party customized systems. It is hoped that software developers can provide relevant information to them. After collecting the information, they will find the person in charge of the relevant system and discuss how to make users’ The experience is better guaranteed.
Why did Google shoot?
For Google, the problem of killing the background is actually not the Android system, but a series of background management mechanisms developed by major custom system manufacturers according to their own needs.
At least as far as the Android system itself is concerned, they are not strict in controlling the backend of the system. According to the design of the native version of Android released by Google, only after the system has recovered all the cache and found that it is still insufficient to provide enough memory to maintain the smooth operation of the system and new apps, will it start to force some apps to close according to the opening sequence. The memory they occupy is recycled.
In the near future, it may be that the complaints of developers have finally accumulated to a certain extent, and Google has also decided to stand up and give some responses. In addition, The back-end management mechanism of some customized system vendors may also violate some Google terms.
According to public documents, as early as 2018, developers on the AOSP (Android Open Source Project) had already submitted documents about custom system vendors abusing Android core permissions and imposing strict background control mechanisms, and received a lot of documents. Developer support. At the same time, some developers who are committed to developing accessibility apps that provide assistance to special people are also very bitter in the document, saying that they have developed an accessibility service app, which has been blocked on many systems for background operation permissions, allowing users to use it. The special people of this app cannot get the services they deserve. For some visually impaired users, they need to use some accessibility software to help them control the phone without others.through Normally, similar accessibility software runs silently in the background, and when their accessibility software is killed in the background, it will be difficult for these users to open the software again. From this point of view, the harsh back-office killing mechanism does affect a group of users. For ordinary users, they may just lose the pages they browsed before. For these special people, it may become a part of their lives. big trouble. Now that Google intends to control and kill the back-end problems, what does Google intend to do? At least, Google has not publicly stated what restrictions or requirements it intends to make on the issue of killing the background, but has initiated a series of investigation procedures, such as asking affected developers to provide the following details: The name of the affected application The name of the OEM and device model they observed the problem Android operating system version Steps to reproduce the problem, as well as expected and observed results Affected API Can they reproduce the same problem on Pixel devices (or other devices running the same Android version). Google’s efforts to control and kill the background problem may be a good thing for some users, but from the point of view of all users, it may not be harmless. Is it right to kill the backstage? I think everyone should know the answer to this question. The reason why the system kills the background is very simple. It is to ensure the fluency of the system and the software currently in use. In the past few years, the problem of the system background was a headache for domestic Android phone users. However, the headache at the time was not that the backstage was killed, but the backstage was inexhaustible. At that time, Android mobile phone manufacturers did not control the background as strict as they are today. Although they also gave restrictions to a certain extent, they were useless in the eyes of domestic App developers. What is even more annoying is that many apps at the time not only had to stay in the background, but also associated wake-ups after being woken up, starting a series of apps that the user did not click on and letting them stay in the background. It is precisely because of these problems that Android users at that time almost regarded flashing as a necessary skill, because only after obtaining the ROOT permission of the system can they install the background control App, and kill all the software that has been resident and self-starting, and return to the system. One smooth. However, it is precisely because of the unscrupulous background staying and self-starting of domestic apps that domestic custom system manufacturers can only always strengthen the background management mechanism. Similarly, other overseas mobile phone manufacturers that have market layouts in the country are the same, and they have even arrived. To the extent that it is better to kill by mistake than to let it go. Except for a part of the key software on record, such as WeChat, QQ, etc., will be retained by the system, and the rest of the software will be killed unless the user adds the software to the whitelist in advance. However, for most users, they are not inclined to actively add software to the whitelist, and many users are not even aware of the existence of the whitelist. As a result, some apps that need to stay in the background to provide services for a long time have to actively guide users to add the App to the whitelist on the setting page. For example, for some apps that are connected to smart wearable devices, in order to be able to feedback user operations and record data at any time, these apps must reside in the background. So if you often hear people complaining that your smartwatch is always not working, then it is probably related to killing the background. In addition, in terms of back-end control, the most stringent ones are probably MIUI and Sony. Among them, the problem of MIUI’s back-office killing has been raging some time ago. At the same time, the official also responded, saying that the back-end mechanism will be adjusted. In fact, the problem of MIUI killing the background is mainly derived from the flares function introduced after the last update. This function is mainly aimed at the problem of frequent self-starting of the software, hoping to make the user’s system smoother. The flares function is mainly aimed at the problem that the App can request user permissions and information without a lower limit. It returns blank information and permissions in a targeted manner. The original intention is not to prevent the software from launching. However, there are many softwares in China that use the method of setting the service as a sticky service on the self-starting and resident background. And service is the area that the flares will focus on, so many softwares are blocked by the flares to stay in the background. After the user shrinks them, they are quickly killed by the system. The other part of the App uses the parent-child process. This part of the software is not within the limit of the flares function, so it can stay in the background for a period of time. This is why the background killing problem of MIUI 12 only appears on some software. . However, follow-up Google and MIUI responded to the developer’s troubles, saying that they will modify the relevant mechanisms to ensure the normal use of the software. In any case, the original intention of the system to kill the background is to allow users to use the phone normally, but if this mechanism is too strict, it will in turn affect the normal use of the user, which is indeed a dilemma. If you want to make the back-end management mechanism more reasonable, you need not only the efforts of custom system vendors and Google, but also the responsibility of software developers. After all, if it is not for software developers to keep self-starting and forcibly staying for benefits The background will not make the system manufacturer’s background control mechanism more stringent. At last At least for now, a strict background mechanism is still necessary, especially on some mobile phones with small running memory. If the software is allowed to reside and associate itself, I am afraid it will really not work properly. However, on mobile phones with 12G or higher running memory, you may consider relaxing the background management to make the user’s multi-App experience better. On the other hand, it still depends on whether Google can make a major change to Android’s background management. If it can imitate Apple to design a similar mechanism, then the background problem can be better solved. Because Apple’s iOS system does not actually have a background, the reason why the App on the iPhone can return to the state just before it was closed after re-waking up is actually because the iOS system retains a snapshot of the information when it is closed, and the App returns When you arrive at the front desk, you can restore it to its previous state based on the snapshot. This mechanism is called a “tombstone”, which is quite vivid. However, if you want to implement the tombstone mechanism on Android, the difficulty may be quite large. Finally, Xiao Lei would like to ask: What do you think about the issue of killing the backstage?
You must log in to post a comment.