Keep the service alive in Android

These days have been preparing for the exam, finally have a half a day to rest, write blog.

How to make service keep alive is a very common problem.

In the app development process, there are too many application scenarios that require service continuity, such as an alarm clock needs to be alerted, so for example, there must be a service to compare the current time and set the time, QQ to be able to smooth chat, it is necessary to receive messages in a timely manner.

But Android does not guarantee that the service has such a function, after all, a system is facing the user, must be user-friendly first.

on how to get service keep alive, the solution I gave in my previous blog post is: Scenario one, sending a push from the server to check if the service is still alive; scenario two, separate the service from the other process.

Some of these two programmes need to be described and improved, and other options will be added.

Scenario One: Use push to ensure service survival.

Scenario one is a bit "lazy". Because it's equivalent to transferring the problem to a push service provider, or simply relying on push, you don't need to think about survival.

Push has always been a hot topic in mobile client development (and is actually a hot topic in traditional software development).

In general, the C/s structure (b/S is a special C/s structure) in the business process is this: the client actively to the server side of the request, the server side response requests, establish a connection between the two. By establishing the link, both parties can send/receive data. Finally, the client and server end are disconnected. That is, the client is the initiator of the request connection, and the server keeps listening on a port (0-1023 is the system port number, such as the 80 port is assigned to HTTP), and passively waits for the client's connection request.

Then push refers to the server side without receiving a request to the client to actively send information, such as the server received a message after the unsolicited client to the mail.

How is push implemented? First, the server-side functionality remains the same, listening to a port waiting for a request. Then we can see that the only time the server can proactively send information is after the server-to-client connection has been established, and before the two are disconnected. Therefore, the implementation of the push is based on keeping the server-side and client connections always present, either by continuous connection or by polling.

Back to the service, the provider of the push service will certainly guarantee the stability of the push technology, rely on push, can wake up our app, then ensure service survival is not a problem.

Scenario Two: Run the service in another process.

Placing the service in another process can prevent the app's process from being closed because of resource constraints or when the user ends it manually.

Another advantage of this approach is that it allows the service to be independent and provide the same services for different apps in the same company. For example, when most apps need the same information, it's obviously not good to write a service for each app, so it's perfectly possible to write a service in a standalone process that provides information for all apps.

Of course, the disadvantage of this scenario is that the service cannot survive when some phone assistants do not have the brain to end all non-system processes.

Scenario Three: Let the Onstartcommand () function return a value of Start_sticky while restarting the service in OnDestroy ()

When the return value is this value, the service is automatically restarted by the system after the kill.

At the same time, restarting the service in the service's OnDestroy () provides a double guarantee of service restart.

But the obvious drawback is that when the app's process is killed, the program will fail.

Scenario Four: Use "Guardian service".

That is, in addition to the service you need to survive, write a service specifically and make the service run in another process.

When one of the two service is killed, the service is restarted in another service.

Judging from the number of processes in the mobile phone, Sohu video, Touch treasure number assistant, and so on is the way to use.

Scenario Five: Elevate the app from the service to the system application level

The application node in the configuration file makes such a setting: Android:persistent= "true" can elevate the app to the system level.

I believe no phone assistant will kill the app.

From the phone QQ is manually killed after the System dialog box to judge, mobile phone QQ is the use of this program.

Programme VI: Broadcast of the receiving system

You can use Broadcastreceiver to receive system broadcasts, such as time-varying broadcasts, power-changing broadcasts, and so on.

So basically the service can't be killed.

Summarize:

The scenario that guarantees that the service will never be killed is programme I and programme six.

The relatively light-weight scenario is Programme II and programme three.

I personally think that the better solution is programme IV and programme five-the choice of such a scheme by the manufacturers makes sense. The specific use of which depends on their own needs.

While the headline is to keep the service alive, it does not mean that it must survive under any circumstances. It is highly recommended that programme I and programme six be used. Because when the user found that no matter how he did not stop an app, the only thing that brought him panic, then the small hands shook the case, the app can only be deleted.

This article synchronizes updates in my blog