What is the difference between star and bind for a service
Start Indicates the service to be started. The service has an independent life cycle and does not depend on the component. The onStartCommand method is repeated by calling the start method multiple times. The service started by start must be stopped by stopService or stopSelf (intentService automatically calls stopSelf).
Calling Bind multiple times only calls onBind once. Bind The bound service that depends on these components. The service is also destroyed when these components are destroyed
2 How do I stop the same service, startService and Bindservice
No matter how many times startService is called, just stopService and stopSelf once
If bindService is called n times on the same object, the unBindService method must be called once. Therefore, there is no order in which the stopService and unBindService methods need to be called once. The last StopService and unBindService will result in the execution of Service onDestroy
The service lifecycle method oncreate onbind onstart runs in that thread
A Service is run on the main thread by default and its lifecycle methods are run on the main thread. Therefore, to do time-consuming operations in a Service, you must start another thread (or use intentService), otherwise anR will be generated
Multiple calls to startService will only call onCreate once. Multiple calls to onStartCommand through startService can only be stopped by StopService and stopSelf
Start the Service by using StartService
Once started with startService, the service continues indefinitely and is destroyed only when stopService() or stopSelf() is called externally.
1. All callback methods are executed on the main thread with ID 1. 2. Only one onCreate callback and three onStartCommand callback are triggered when startService is invoked for three times, and startId is 1, 2, and 3 respectively. Prove that the onCreate callback is not repeated by startService multiple times, but that the onStartCommand callback is executed each time.
To create such a Service, you need to make the class inherit from the Service class and override the following methods:
OnCreate () 1. If the service has not been created, the onCreate() callback will be executed after startService() is called; 2. If the service is already running, calling startService() does not execute onCreate(). That is, onCreate() is called only when the service is created for the first time, and multiple startService() calls do not repeat onCreate(). This method is suitable for doing some initialization.
OnStartCommand () If Context’s startService() method is executed multiple times, Service’s onStartCommand() method will be called multiple times. The onStartCommand() method is important, where we do the actual action based on the incoming Intent parameter, such as creating a thread for downloading data or playing music.
OnBind () : onBind() : onBind() : onBind() : onBind() : onBind() : onBind() : onBind(
OnDestory () executes the Service method on destruction.
These methods are callback methods that are executed in the main thread and are called by the Android operating system at the appropriate time.
BindService startup features:
1. The service started by bindService and the caller are in a typical client-server mode. The caller is the client and the service is the server. There is only one service, but there can be one or more clients bound to the service. By client, I mean a component, such as an Activity. 2. The client can obtain the Service instance through the IBinder interface, so that the client can directly call the methods in the Service to achieve flexible interaction, which cannot be achieved through the startService method. 3. BindService starts a service whose life cycle is closely related to its bound clients. When a client is destroyed, the client is automatically unbound from the Service. Of course, the client can explicitly call the Context’s unbindService() method to unbind the Service. When no client is bound to a Service, the Service destroys itself.
To summarize the bindService lifecycle:
The first call to bindService instantiates TestTwoService, and then executes its onBind() method to get an instance of IBinder. Passing it as a parameter to ActivityA’s ServiceConnection’s onServiceConnected method marks ActivityA’s binding to TestTwoService.
2. Click the bindService button in ActivityB. Since TestTwoService is already running, calling bindService again will not recreate its instance. So the onCreate() and onBind() methods of TestTwoService are not executed either. ActivityB shares IBinder instances with ActivityA. At this point, there are two clients bound to TestTwoService.
ActivityB is unbound from TestTwoService. The onUnbind() method of the Service is executed only when there are no clients bound to the Service. At this point, ActivityA is still in a binding connection, so the unbinding method of Service is not performed.
4. After unbindService is executed by ActivityA, ActivityA and TestTwoService are unbound. No client is bound to TestTwoService. Android then destroys TestTwoService, executing TestTwoService’s onUnbind() method before destroying it, and then executing its onDestroy() method, which destroys TestTwoService.
5. If the client is destroyed, the client is automatically unbound from the Service.
How can Service not be killed?
1. In onStartCommand, START_STICKY is returned
First let’s look at what values onStartCommand can return:
When you call context. startService to start a Service, if Android is running out of memory, it may destroy the current Service and rebuild the Service when the memory is sufficient. The behavior of a Service being destroyed and rebuilt by the Android system depends on the return value of the Service’s onStartCommand() method.
START_NOT_STICKY If START_NOT_STICKY is returned, the Service will not be created after the process running on it is forcibly killed by the Android system. Of course, if startService is called again some time after it is killed, the Service will be instantiated again. When is it appropriate to return this value? If it doesn’t matter how many times one of our services is interrupted or if it’s acceptable for Android to run out of memory and need to be killed without immediately recreating, we can set the return value of onStartCommand to START_NOT_STICKY. For example, a Service needs to get the latest data from the server periodically: a timer is used to start the Service every N minutes to get the latest data from the server. When the onStartCommand of the Service is executed, a timer is planned in this method after N minutes to start the Service again and start a new thread to perform network operations. If the Service is killed by the Android system in the process of getting the latest data from the server, the Service will not be created again, which is fine because after N minutes the timer will start the Service again and get the data again
START_STICKY If START_STICKY is returned, the Android system will set the Service to the started state after the process running the Service is forcibly killed by the Android system. Instead of saving the intent object passed in by the onStartCommand method, the Android system will try to recreate the Service and execute the onStartCommand callback. The intent parameter of the onStartCommand callback is null. The onStartCommand method executes but doesn’t get the intent information. If your Service can run or end at any time with no problem and does not require intent information, then return START_STICKY in the onStartCommand method. For example, a Service that plays background music is suitable to return this value.
START_REDELIVER_INTENT If START_REDELIVER_INTENT is returned, the process running the Service is forcibly killed by the Android system, similar to the situation when START_REDELIVER_INTENT is returned. The Android system recreates the Service again and executes the onStartCommand callback method, but the difference is, The Android system saves the Intent that the Service last passed to the onStartCommand method before it was killed and passes it back to the onStartCommand method of the newly created Service so that we can read the Intent parameters. As long as START_REDELIVER_INTENT is returned, the intent must not be null. If our Service relies on a specific Intent to run (read data from the Intent, etc.) and needs to be re-created after being forcibly destroyed, then it is appropriate to return START_REDELIVER_INTENT.
2. Improve the Service priority
In the androidmanifest.xml file, you can set the highest priority for intent-filter by android:priority = “1000”. 1000 is the highest value. If the number is smaller, the priority is lower.
3. Improve the Service process priority
When the system process space is limited, the system automatically reclaims processes based on their priorities. Android divides processes into six levels, in descending order of priority:
Foreground_app Visible process Visible_app Secondary service process secondary_server Background process HiddenA_app Content provider node content_provider Empty process EMPty_app Use startForeground to foreground the service, so that the probability of being killed is low when the memory is low. 12345678Copy the code4. Restart Service in onDestroy
When the service goes to onDestroy(), it sends a custom broadcast, and when it receives a broadcast, it restarts the service.
6. Install APK to/System /app and change it to a system-level application