android 怎么保证服务不被杀死

Service运行方式
以startService()启动服务，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。onStartCommand ，在2.0后被引入用于service的启动函数，2.0之前为public void onStart(Intent intent, int startId) 。

以bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止。onBind()只有采用Context.bindService()方法启动服务时才会回调该方法。该方法在调用者与服务绑定时被调用，当调用者与服务已经绑定，多次调用Context.bindService()方法并不会导致该方法被多次调用。采用Context.bindService()方法启动服务时只能调用onUnbind()方法解除调用者与服务解除，服务结束时会调用onDestroy()方法。

拥有service的进程具有较高的优先级
官方文档告诉我们，Android系统会尽量保持拥有service的进程运行，只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时，需要保持，拥有service的进程具有较高的优先级。
1． 如果service正在调用onCreate,onStartCommand或者onDestory方法，那么用于当前service的进程则变为前台进程以避免被killed。
2． 如果当前service已经被启动(start)，拥有它的进程则比那些用户可见的进程优先级低一些，但是比那些不可见的进程更重要，这就意味着service一般不会被killed.
3． 如果客户端已经连接到service (bindService),那么拥有Service的进程则拥有最高的优先级，可以认为service是可见的。
4． 如果service可以使用startForeground(int, Notification)方法来将service设置为前台状态，那么系统就认为是对用户可见的，并不会在内存不足时killed。
5． 如果有其他的应用组件作为Service,Activity等运行在相同的进程中，那么将会增加该进程的重要性。

1: 正常 stop service的时候会执行生命周期的 onDestory() 可以在销毁方法中执行再次 startService();

2: 当收到内存影响的时候，out-of-memory killer会销毁掉一些优先级低的app：
相较于/data/app下的应用，放在/system/app下的应用享受更多的特权，
比如若在其Manifest.xml文件中设置persistent属性为true，
则可使其免受out-of-memory killer的影响。
如应用程序'Phone'的AndroidManifest.xml文件：
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
...

设置后app提升为系统核心级别，任何情况下不会被kill掉,
settings->applications里面也会屏蔽掉stop操作,再次情况下，发现4.1.2的程序在设置里面的应用里面，程序没有禁止掉停止。
在此情况下还要应用上1的重新启动。

3: force stop service 的时候，则不执行 onDestory(),
还有一种情况是 第三方任务管理器清理掉整个程序的时候；

google 管方就有，ForegroundService 前台服务，让服务一直以前台任务的方式运行，可以在service 的oncreate来实现前台服务， 通过这个方法必须发送一个通知栏，让用户知道服务在运行。我们可以把service修改成前台运行方式，只不过让通知notification不去显示就OK了。