Ways to keep your service from being killed-dual service daemon && Android dual process daemon 1

This article is divided into two parts, the first part of the dual service daemon, the second part of the two-process daemon

The first part:

First, Service introduction:
Java.lang.Object

? Android.content.Context

? Android.content.ContextWrapper

? Android.app.Service

The service is a component of the application application (component).
It has two points: 1. Used to provide an operation that runs in the background for a long time and does not interact with the user, 2. You can also provide services for other applications.
The service must be declared in Androidmanifest.xml with the <service> tag, just like the other four components.
There are two ways to start a service Context.startservice () and Context.bindservice ().

Note that, in addition to the special designation, the service is not a separate process, and the General Service runs in the main thread (UI thread) of its host process "of course it can also be startservice in a new thread, So the service is not in the Mainthread. " This means that if your service is going to do any time-consuming (such as MP3 playback) or blocking (such as a network) operation, it should generate its own thread to do that work. (Service is not a separate process and not a separate thread)

The service provides two main functions:
Context.startservice () is used to start a service in the background;
Context.bindservice () is used to bind other services in order to obtain services provided by another service;

locally served local service for application internal

It can start and run until someone stops it or it stops itself. In this way, it starts with a call to Context.startservice () and ends with a call to Context.stopservice (). It can call Service.stopself () or Service.stopselfresult () to stop itself. No matter how many times the StartService () method is called, you only need to call once StopService () to stop the service.

"Some time-consuming tasks for implementing the application itself, such as querying the upgrade information, and not consuming the application such as the activity's thread, but the single-threaded background execution, so the user experience is better"

remote service is used between applications within the Android system

It can be manipulated by its own defined and exposed interfaces. The client establishes a connection to the service object and invokes the service through that connection. The connection is established to call the Context.bindservice () method to call Context.unbindservice () to close. Multiple clients can bind to the same service. If the service is not loaded at this time, bindservice () loads it first.

"Can be reused by other applications, such as weather forecasting services, other applications do not need to write such services, call the existing can be"

Second, service operation mode and life cycle diagram:

Starting the service with StartService (), the system will search through the incoming intent for services related to the information in the intent. If the service does not start, run OnCreate first, and then run Onstartcommand (which can handle the intent and other parameters that are passed in at startup) until a significant call to StopService or stopself stops the service. No matter how many times you run StartService, StopService or stopself,service will stop whenever you call. Use the stopself (int) method to ensure that the intent is processed and then stopped. Onstartcommand, the start function for the service was introduced after 2.0 and 2.0 was public void OnStart (Intent Intent, int startid).

The service is enabled with the Bindservice () method, and the caller is bound together with the service, and once the caller exits, the service terminates. Onbind () The method is only invoked when the service is started with the Context.bindservice () method. This method is called when the caller and the service are bound, and the Context.bindservice () method is called multiple times when the caller is tied to the service and does not cause the method to be called more than once. Using the Context.bindservice () method to start a service can only call the Onunbind () method to disassociate the caller from the service and call the OnDestroy () method at the end of the service.

(Note the changes to this new and old API)

void OnStart (Intent Intent, int startid)
This method is deprecated in API level 5. Implement Onstartcommand (Intent, int, int) instead.

int Onstartcommand (Intent Intent, int flags, int startid)
Called by the system every time a client explicitly starts the service by calling StartService (Intent), providing the ARG Uments it supplied and a unique integer token representing the start request.

Iii. Priority of Service

The official documentation tells us that the Android system will try to keep the process running with the service as long as the service has been started (start) or the client is connected (Bindservice) to it. When memory is low, it needs to be maintained, and the process with the service has a higher priority.

1. If the service is calling the Oncreate,onstartcommand or Ondestory method, then the process used for the current service becomes the foreground process to avoid being killed.
2. If the current service has been started (start), the process that owns it has a lower priority than those visible to the user, but is more important than the invisible process, which means that the service is generally not killed.
3. If the client is already connected to service (Bindservice), the process that owns the service has the highest priority and can be considered to be visible.
4. If the service can use the startforeground (int, Notification) method to set the service as the foreground state, the system is considered to be visible to the user and does not killed when the memory is low.
5. If there are other application components running in the same process as service,activity, it will increase the importance of the process.

Iv. keep the service out of the kill

Method One:

Start_sticky is used for services it is explicitly started and stopped as needed, while start_not_sticky or Start_redel Iver_intent is used for services this should only remain running while processing any commands sent to them

Introduction to several return values for the Onstartcommand method:

1, Start_sticky

After the service process is killed after running Onstartcommand, that will remain in the start state, but those incoming intent are not preserved. Shortly after the service tries to recreate it again, because it remains in the start state, it is guaranteed to call Onstartcommand after the service is created. If no start command is passed to the service, that will get the intent to null.

2, Start_not_sticky

After the service process is killed after running Onstartcommand, and no new intent is passed to it. The service moves out of the start state and is not re-created until a new, obvious method (StartService) call is made. Because if no intent is passed, then the service will not start, that is, the period Onstartcommand will not receive any null intent.

3, Start_redeliver_intent

After the service process is killed after running Onstartcommand, the service is started again and the last intent is passed to Onstartcommand. The pass-through intent is not stopped until stopself (int) is called. If there is still an unhandled intent after the kill, the service will start automatically after the kill. Therefore, Onstartcommand does not receive any null intent.

[Java]View PlainCopy

1. @Override
2. public int Onstartcommand (Intent Intent, int flags, int startid) {
3. Flags = Start_sticky;
4. return Super.onstartcommand (intent, flags, Startid);
5. }

"Conclusion" manual return Start_sticky, pro-Test when the service is killed due to insufficient memory, when the memory is again, the service is re-created, it is good, but can not be guaranteed to be rebuilt under any circumstances, such as the process was killed ....

Method Two:

Improve service Priority

In the Androidmanifest.xml file, for Intent-filter, you can set the highest priority by Android:priority = "1000", 1000 is the highest value, and if the number is smaller, the lower the priority and applies to the broadcast.

[Java]View PlainCopy

1. <service
2. Android:name="Com.dbjtech.acbxt.waiqin.UploadService"
3. android:enabled="true" >
4. <intent-filter android:priority="> "
5. <action android:name="Com.dbjtech.myservice"/>
6. </intent-filter>
7. </service>

"Conclusion" it appears that the priority attribute seems to apply only to broadcast, which may not be valid for service

Method Three:

Elevate Service Process Priority

Processes in Android are managed, and when the system process is tight, the process is automatically recycled according to the priority level. Android divides the process into 6 levels, which are ranked from highest to lowest in order of precedence:

1. Foreground process (Foreground_app)
2. Visual process (Visible_app)
3. Secondary service process (Secondary_server)
4. Background process (Hidden_app)
5. Content Provisioning Node (content_provider)
6. Empty process (Empty_app)

When the service is running in a low-memory environment, some of the existing processes will be killed. Therefore, the priority of the process will be important, and you can use Startforeground to put the service into the foreground state. This will reduce the chance of being killed at low memory.

Add the following code within the Onstartcommand method:

[Java]View PlainCopy

2. Notification Notification = new Notification (R.drawable.ic_launcher,getstring (R.string.app_name),  System.currenttimemillis ());
6. Pendingintent pendingintent = pendingintent.getactivity (this, 0,new Intent (This, Appmain.   Class), 0);
8. Notification.setlatesteventinfo (This, "Uploadservice", "please keep the program running in the background", pendingintent);
10. Startforeground (0x111, notification);

Note that in OnDestroy you also need Stopforeground (true), the runtime will see your app in the drop-down list:

"Conclusion" if under extreme low memory pressure, the service will still be killed, and will not necessarily be restart

How to keep the service from being killed-dual service daemon && Android for dual process daemon 1