android前台service
① Android基础：Service —— 默默为你服务
Service有两种启动方式，分别为 context.startService() 和 context.bindService() 。这里要提到Service的生命周期，两种不同的启动方式有不同的生命周期：
Tips：
首先创建自己的Service类，重写其生命周期，并在mainfest.xml中进行注册。
必须注册Service，不然不会调用。简单注册：
补充下Service在manifest中的属性以及作用：
接下来，我们就可以用下面的两个方法来启动和停止服务。
首先在我们的Activity中创建Service连接对象，重写连接和断开的方法。创建自定义的Binder对象，在 onServiceConnected() 中赋值然后可以调用自定义Binder中的方法。使用下方的bind()方法来绑定服务，使用 unBind() 来解绑服务。
这里会用到Service的 onBind() 和 onUnbind() 的生命周期，我们在TestService中重写之。这里要注意的是，使用bindService()方法启动的Service，不会调用 onStartCommand() 的生命周期。此外，创建自定义Binder类和对象。
这样，当我们使用Activity中的bind()方法来绑定服务，会自动启动服务，而我们又重写了 onServiceConnected() 方法并使用myBinder来调用方法。这样我们就可以用它来Activity和Service来进行通信。
特别Tips：
如果先使用 startService() 来开启服务和 bindService() 来绑定服务，当使用 unbindService() 解绑时，Service并不会被销毁。而是使用 stopService() 才能销毁服务。
前台服务和后台服务的区别：
在Service中进行操作，将服务类型以前台的方式运行显示在通知栏。
运行效果：
暂时引用吧，有空再实现一个：
参考资料：
② Android重学系列 Service 启动和绑定原理
我们已经了解了BroadcastReceiver的原理，我们再来看看四大组件之一的Service是怎么启动的，以及怎么运行的原理。
如果遇到什么问题可以来到 https://www.jianshu.com/p/c4927c0b80a9 本文下进行交流
启动Service的入口就是startService和bindService方法。我们先来看看startService在ContextImpl中做了什么。
文件：/ frameworks / base / core / java / android / app / ContextImpl.java
此时调用的就是AMS的startService方法。
mServices是一个ActiveServices对象。这个对象是在AMS的构造函数中初始化好的。
这里调用了ActiveServices的startServiceLocked。
文件：/ frameworks / base / services / core / java / com / android / server / am / ActiveServices.java
核心流程有如下三个：
注意这里addToStarting是一个比较关键的判断，addToStarting默认为false。
如果此时不是启动前台服务，则需要进一步进行处理。如果ProcessRecord为空或者curProcState大于PROCESS_STATE_RECEIVER这个优先级数值；也就是优先级更小。
为了避免此时App应用是没有任何的前台ui，或者App应用还没有声明。避免有的App通过startService进行应用的包活或者拉起应用。就会进行如下能够存在的最大后台服务数量，则放入mDelayedStartList中进行延时启动后台服务，现在直接返回了。
不然则说明能够允许启动后台服务， 就设置为addToStarting为true。
通过ComponentName也就是包名和类名查找ServiceRecord；通过Intent意图过滤找到ServiceRecord。·
核心方法是bringUpServiceLocked。如果bringUpServiceLocked返回了异常，就返回一个特殊的ComponentName对象。
addToStarting为true，说明此时是一个能够启动的后台服务，则ServiceRecord添加到mStartingBackground中。如果mStartingBackground的数量为0，则直接调用ServiceMap的rescheleDelayedStartsLocked启动后台服务。
这几个关键的步骤，让我们依次的考察，先来看看scheleCreateService中做了什么。
如果第一次启动就走第一个if的分支：
能看到和BroadcastReceiver的ANR思路一样，通过一个延时的Handler，如果达到时间了还没有移除这个Handler消息则报ANR异常。
这里根据启动前台和后台分为两种超时时间：
前台分别是10秒，后台服务不属于后台进程组(判断adj是否在SCHED_GROUP_BACKGROUND)是20秒，后台服务属于后台进程组 200秒。
把数据封装成CreateServiceData后，通过Handler调用如下方法：
透三点的核心原理可以看我写的的Application创建和BroadcastReceiver原理两篇文章。来看看Service中都做了什么？
很简单就是保存了传递过来的参数，值得注意的是这个IBinder对象其实就是指ServiceRecord对象。
接着执行Service.onCreate这个空实现的方法。
本质上还是调用了ActiveServices的serviceDoneExecutingLocked方法。
type是SERVICE_DONE_EXECUTING_ANON，所不会做更多的处理。 最后执行了serviceDoneExecutingLocked方法。
这个方法不断的循环遍历List<ServiceStartArgs>分发SERVICE_ARGS消息，这个消息通过主线程的Looper调用handleServiceArgs。
bindService在开发中用的不是很多，这里稍微提一下他的使用。
首先申明一个ServiceConnection对象，用于绑定服务端的Service。
调用bindService的方法绑定到某个Service中。当服务端的service成功回调onBind方法，我们只需要返回对应的Binder对象。就能使用调用bindService的客户端在ServiceConnection的onServiceConnected的回调中获得Binder对象。
之后就能通过这个Binder调用本进程或者其他进程的的方法了。实际上我们可以把这个过程看成一个多对多的服务-客户端模型。多个客户端通过Binder向多服务端Service通信，每一次我们都可以通过ComponentName判断不同服务返回来的Binder对象。
这里面很简单，和BroadcastReceiver的思路很像。动态注册的BroadcastReceiver会封装成一个ReceiverDispatcher，而这里把ServiceConnection封装成LoadedApk.ServiceDispatcher对象。
并且会把ServiceDispatcher作为value，ServiceConnection作为key缓存一个map中。并且以context为key，把这个临时的map作为value缓存起来。这样一个Context就映射有了多个ServiceDispatcher对象，也就可以注册多个监听被绑定Service状态的监听者了。
③ Android 如何进行进程保活
每一个 Android 应用启动后至少对应一个进程，有的是多个进程，而且主流应用中多个
进程的应用比例较大
对于任何一个进程，我们都可以通过 adb shell ps|grep <package_name>的方式来查看
它的基本信息
Android 中的进程跟封建社会一样，分了三流九等，Android 系统把进程的划为了如下
几种（重要性从高到低），网上多位大神都详细总结过（备注：严格来说是划分了 6 种）。
场景：
1.某个进程持有一个正在与用户交互的 Activity 并且该 Activity 正处于 resume 的
状态。
2.某个进程持有一个 Service，并且该 Service 与用户正在交互的 Activity 绑定。
3.某个进程持有一个 Service，并且该 Service 调用 startForeground()方法使之位于前台运行。
4.某个进程持有一个 Service，并且该 Service 正在执行它的某个生命周期回调方法，比如 onCreate()、 onStart()或 onDestroy()。
5.某个进程持有一个 BroadcastReceiver，并且该 BroadcastReceiver 正在执行其onReceive()方法。用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。
场景：
1.拥有不在前台、但仍对用户可见的 Activity（已调用 onPause()）。
2.拥有绑定到可见（或前台）Activity 的 Service
用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程
不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，
要保持某个或多个前台进程存活
场景
1.某个进程中运行着一个 Service 且该 Service 是通过 startService()启动的，与用户看见的界面没有直接关联。
在内存不足以维持所有前台进程和可见进程同时运行的情况下，服务进程会被杀死
场景：
在用户按了"back"或者"home"后,程序本身看不到了,但是其实还在运行的程序，
比如 Activity 调用了 onPause 方法系统可能随时终止它们，回收内存
场景：
某个进程不包含任何活跃的组件时该进程就会被置为空进程，完全没用,杀了它只有好处没坏处,第一个干它!
上面是进程的分类，进程是怎么被杀的呢？系统出于体验和性能上的考虑，app 在退到
后台时系统并不会真正的 kill 掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制
来判断要 kill 掉哪些进程，以腾出内存来供给需要的 app, 这套杀进程回收内存的机制
就叫 Low Memory Killer。那这个不足怎么来规定呢，那就是内存阈值，我们可以使用
cat /sys/mole/lowmemorykiller/parameters/minfree 来查看某个手机的内存阈值。
其实系统在进程回收跟内存回收类似也是有一套严格的策略，可以
自己去了解，大概是这个样子的，oom_adj 越大，占用物理内存越多会被最先 kill 掉，OK，那么现在对于进程如何保活这个问题就转化成，如何降低 oom_adj 的值，以及如
何使得我们应用占的内存最少。
据说这个是手 Q 的进程保活方案，基本思想，系统一般是不会杀死前台进程的。所以要
使得进程常驻，我们只需要在锁屏的时候在本进程开启一个 Activity，为了欺骗用户，
让这个 Activity 的大小是 1 像素，并且透明无切换动画，在开屏幕的时候，把这个 Activity
关闭掉，所以这个就需要监听系统锁屏广播，我试过了，的确好使，如下。
如果直接启动一个 Activity，当我们按下 back 键返回桌面的时候，oom_adj 的值是 8，
上面已经提到过，这个进程在资源不够的情况下是容易被回收的。现在造一个一个像素
的 Activity。
为了做的更隐藏，最好设置一下这个 Activity 的主题，当然也无所谓了
在屏幕关闭的时候把 LiveActivity 启动起来，在开屏的时候把 LiveActivity 关闭掉，所以
要监听系统锁屏广播，以接口的形式通知 MainActivity 启动或者关闭 LiveActivity。
现在 MainActivity 改成如下
按下 back 之后，进行锁屏，现在测试一下 oom_adj 的值
果然将进程的优先级提高了。
但是还有一个问题，内存也是一个考虑的因素，内存越多会被最先 kill 掉，所以把上面
的业务逻辑放到 Service 中，而 Service 是在另外一个 进程中，在 MainActivity 开启这
个服务就行了，这样这个进程就更加的轻量，
OK，通过上面的操作，我们的应用就始终和前台进程是一样的优先级了，为了省电，
系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了
这个问题。但是还是有被杀掉的可能，所以我们还需要做双进程守护，关于双进程守护，
比较适合的就是 aidl 的那种方式，但是这个不是完全的靠谱，原理是 A 进程死的时候，
B 还在活着，B 可以将 A 进程拉起来，反之，B 进程死的时候，A 还活着，A 可以将 B
拉起来。所以双进程守护的前提是，系统杀进程只能一个个的去杀，如果一次性杀两个，
这种方法也是不 OK 的。
事实上
那么我们先来看看 Android5.0 以下的源码，ActivityManagerService 是如何关闭在应用
退出后清理内存的
在应用退出后，ActivityManagerService 不仅把主进程给杀死，另外把主进程所属的进
程组一并杀死，这样一来，由于子进程和主进程在同一进程组，子进程在做的事情，也
就停止了。所以在 Android5.0 以后的手机应用在进程被杀死后，要采用其他方案。
这种大部分人都了解，据说这个微信也用过的进程保活方案，移步微信 Android 客户端
后台保活经验分享，这方案实际利用了 Android 前台 service 的漏洞。
原理如下
对于 API level < 18 ：调用 startForeground(ID， new Notification())，发送空的
Notification ，图标则不会显示。
对于 API level >= 18：在需要提优先级的 service A 启动一个 InnerService，两个服务
同时 startForeground，且绑定同样的 ID。Stop 掉 InnerService ，这样通知栏图标即
被移除。
public class KeepLiveService extends Service{
public static final int NOTIFICATION_ID=0x11;
public KeepLiveService() {
}
@Override
public IBinder onBind(Intent intent){
throw new UnsupportedOperationException("Not yet implemented");
}
@Override
public void onCreate() {
super.onCreate(); //API 18 以下，直 接发 送 Notification 并 将 其 置 为 前 台
if(Build.VERSION.SDK_INT<Build.VERSION_CODES.JELLY_BEAN_MR2){
startForeground(NOTIFICATION_ID,new Notification());
} else { //API 18 以上，发送 Notification 并将其置为前台后，启动 InnerService
Notification.Builder builder=new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);
startForeground(NOTIFICATION_ID, builder.build());
startService(new Intent(this, InnerService.class));
}
}
public class InnerService extends Service{
@Override public IBinder onBind(Intent intent) {
return null;
}
@Override public void onCreate() {
super.onCreate(); //发送与 KeepLiveService中 ID 相同的 Notification，然后将其取消并取消自己的前台显示
Notification.Builder builder = new Notification.Builder(this);
builder.setSmallIcon(R.mipmap.ic_launcher);startForeground(NOTIFICATION_ID,
builder.build());
new Handler().postDelayed(new Runnable() {
@Override public void run() {
stopForeground(true);
NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
manager.cancel(NOTIFICATION_ID);
stopSelf();
}
},
100);
}
}
}
在没有采取前台服务之前，启动应用，oom_adj 值是 0，按下返回键之后，变成 9（不
同 ROM 可能不一样）
相互唤醒的意思就是，假如你手机里装了支付宝、淘宝、天猫、UC 等阿里系的 app，
那么你打开任意一个阿里系的 app 后，有可能就顺便把其他阿里系的 app 给唤醒了。
这个完全有可能的。此外，开机，网络切换、拍照、拍视频时候，利用系统产生的广播
也能唤醒 app，不过 Android N 已经将这三种广播取消了。
如果应用想保活，要是 QQ，微信愿意救你也行，有多少手机上没有 QQ，微信呢？或
者像友盟，信鸽这种推送 SDK，也存在唤醒 app 的功能。
拉活方法
JobSheler是作为进程死后复活的一种手段，
native进程方式最大缺点是费电，Native
进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环
或定时器，轮训判断主进程是否存活，当主进程不存活时进行拉活。其次 5.0 以上系统
不支持。 但是 JobSheler 可以替代在 Android5.0 以上 native 进程方式，这种方式即
使用户强制关闭，也能被拉起来，亲测可行。
JobSheler@TargetApi(Build.VERSION_CODES.LOLLIPOP)
public class MyJobService extends JobService {
@Override
public void onCreate() {
super.onCreate();
startJobSheler();
}
public void startJobSheler() {
try {
JobInfo.Builder builder = new JobInfo.Builder(1,new ComponentName(getPackageName(), MyJobService.class.getName()));
builder.setPeriodic(5); builder.setPersisted(true); JobScheler jobScheler =(JobScheler)
this.getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheler.schele(builder.build());
}
catch
(Exception ex)
{ ex.printStackTrace(); } }
@Override
public boolean onStartJob(JobParameters jobParameters) {
return false;
} @Override public boolean onStopJob(JobParameters jobParameters) {
return false;
}
}
这个是系统自带的，onStartCommand 方法必须具有一个整形的返回值，这个整形的返
回值用来告诉系统在服务启动完毕后，如果被 Kill，系统将如何操作，这种方案虽然可
以，但是在某些情况 or 某些定制 ROM 上可能失效，我认为可以多做一种保保守方案。
1.START_STICKY
如果系统在 onStartCommand 返回后被销毁，系统将会重新创建服务并依次调用
onCreate 和 onStartCommand（注意：根据测试 Android2.3.3 以下版本只会调用
onCreate 根本不会调用 onStartCommand，Android4.0 可以办到），这种相当于服务
又重新启动恢复到之前的状态了）。
2.START_NOT_STICKY
如果系统在 onStartCommand 返回后被销毁，如果返回该值，则在执行完
onStartCommand 方法后如果 Service 被杀掉系统将不会重启该服务
3.START_REDELIVER_INTENT
START_STICKY 的兼容版本，不同的是其不保证服务被杀后一定能重启。
4.相比与粘性服务与系统服务捆绑更厉害一点，这个来自爱哥的研究，这里说的系统服务
很好理解，比如 NotificationListenerService，NotificationListenerService 就是一个监听
通知的服务，只要手机收到了通知，NotificationListenerService 都能监听到，即时用户
把进程杀死，也能重启，所以说要是把这个服务放到我们的进程之中，那么就可以呵呵
了
所以你的应用要是有消息推送的话，那么可以用这种方式去欺骗用户。
④ 如何让Android service进程变成前台进程
这里只是修改了Service中onCreate()方法的代码。可以看到，我们首先创建了一个Notification对象，然后调用了它的setLatestEventInfo()方法来为通知初始化布局和数据，并在这里设置了点击通知后就打开MainActivity。然后调用startForeground()方法就可以让MyService变成一个前台Service，并会将通知的图片显示出来。
现在重新运行一下程序， Service就会以前台Service的模式启动了，并且在系统状态栏会弹出一个通栏图标，下拉状态栏后可以看到通知的详细内容
⑤ Android应用组件 —— Service
官方原文： 地址
本文摘录自官方原文，方便自己观看。
service 是一个可以在后台长时间运行的操作而不提供用户界面的应用组件。服务可以由其他应用组件启动，而且即使用户切换到其他应用程序，服务仍将在后台继续运行。此外，组件可以绑定到服务，以与之进行交互，甚至执行进程间的通信（IPC）
服务基本分为两种形式：
启动
绑定
上述虽然分开概括这两种服务，但是服务可以同时以这两种方式运行，也就是说，他既可以是启动服务（以无限期运行），也允许绑定。问题在于是否实现了一组回调方法： onStartCommand() （允许组件启动服务）和 onBing() （允许绑定服务）。
无论应用是出于启动状态还是绑定状态，亦或处于启动并且绑定状态，任何应用组件均可以像使用Activity那么调用Itent来使用服务（即使此服务来自另一应用）。 不过，您可以通过清单文件将服务声明为私有服务，并阻止其他应用访问。 使用清单文件声明服务部分将对此做更详尽的阐述。
注意：
服务在其托管进程的主线程中运行，它既不创建自己的线程，也不在单独的进程中运行（除非另行指定）。这意味着，如果服务将执行任何CPU密集型工作或者阻止性操作（我理解为耗时操作，例如 MP3 播放或联网），则应在服务内创建新线程来完成这项工作。通过使用单独的线程，可以降低发生“应用无响应”(ANR) 错误的风险，而应用的主线程仍可继续专注于运行用户与 Activity 之间的交互。
要创建服务，您必须创建 Service 的子类（或使用它的一个现有子类）。在实现中，您需要重写一些回调方法，以处理服务生命周期的某些关键方面并提供一种机制将组件绑定到服务（如适用）。 应重写的最重要的回调方法包括：
onStartCommand()
onBind()
onCreate()
onDestroy()
如果组件通过调用 startService() 启动服务（这会导致对 onStartCommand() 的调用），则服务将一直运行，直到服务使用 stopSelf() 自行停止运行，或由其他组件通过调用 stopService() 停止它为止。
如果组件是通过调用 bindService() 来创建服务（且未调用 onStartCommand() ，则服务只会在该组件与其绑定时运行。一旦该服务与所有客户端之间的绑定全部取消，系统便会销毁它。
如同 Activity（以及其他组件）一样，您必须在应用的清单文件中声明所有服务。
要声明服务，请添加 <service> 元素作为 <application> 元素的子元素。例如：
为了确保应用的安全性， 请始终使用显式 Intent 启动或绑定 Service，且不要为服务声明 Intent 过滤器。 启动哪个服务存在一定的不确定性，而如果对这种不确定性的考量非常有必要，则可为服务提供 Intent 过滤器并从 Intent 中排除相应的组件名称，但随后必须使用 setPackage() 方法设置 Intent 的软件包，这样可以充分消除目标服务的不确定性。
此外，还可以通过添加 android:exported 属性并将其设置为 "false" ，确保服务仅适用于您的应用。这可以有效阻止其他应用启动您的服务，即便在使用显式 Intent 时也如此
Service
IntentService
简单地说，服务是一种即使用户未与应用交互也可在后台运行的组件。 因此，您应仅在必要时才创建服务。
如需在主线程外部执行工作，不过只是在用户正在与应用交互时才有此需要，则应创建新线程而非服务。 例如，如果您只是想在 Activity 运行的同时播放一些音乐，则可在 onCreate() 中创建线程，在 onStart() 中启动线程，然后在 onStop() 中停止线程。您还可以考虑使用 AsyncTask 或 HandlerThread，而非传统的 Thread 类。
前台服务被认为是用户主动意识到的一种服务，因此在内存不足时，系统也不会考虑将其终止。 前台服务必须为状态栏提供通知，放在“正在进行”标题下方，这意味着除非服务停止或从前台移除，否则不能清除通知。
要请求让服务运行于前台，请调用 startForeground() 。此方法采用两个参数：唯一标识通知的整型数和状态栏的 Notification 。例如：
注意 ：提供给 startForeground() 的整型 ID 不得为 0。
要从前台移除服务，请调用 stopForeground() 。此方法采用一个布尔值，指示是否也移除状态栏通知。 此方法不会停止服务。 但是，如果您在服务正在前台运行时将其停止，则通知也会被移除。
与 Activity 类似，服务也拥有生命周期回调方法，您可以实现这些方法来监控服务状态的变化并适时执行工作。 以下框架服务展示了每种生命周期方法：
注 ：与 Activity 生命周期回调方法不同，您 不 需要调用这些回调方法的超类实现。
注 ：尽管启动服务是通过调用 stopSelf() 或 stopService() 来停止，但是该服务并无相应的回调（没有 onStop() 回调）。因此，除非服务绑定到客户端，否则在服务停止时，系统会将其销毁 — onDestroy() 是接收到的唯一回调。
⑥ Android的startForeground前台Service如何去掉通知显示
首先写一个BootstarpService，顾名思义，这个service只是起引导作用，干完活就退出了。最精华的部分其实就是这句stopSelf()，说白了这个service其实还没起起来就被停掉了，这样onDestroy()里就会调用stopForeground()，通知栏的常驻通知就会被消掉。
[java]viewplain
{
@Override
publicvoidonCreate(){
super.onCreate();
startForeground(this);
//
stopSelf();
}
@Override
publicvoidonDestroy(){
super.onDestroy();
stopForeground(true);
}
(Servicecontext){
NotificationManagernm=(NotificationManager)context.getSystemService(NOTIFICATION_SERVICE);
NotificationCompat.Builderbuilder=newNotificationCompat.Builder(context);
builder.setContentTitle("I'mrunning")
.setContentText("")
.setWhen(System.currentTimeMillis())
.setPriority(Notification.PRIORITY_MIN)
.setSmallIcon(R.drawable.notification_icon)
.setAutoCancel(true);
Notificationnotification=builder.build();
context.startForeground(8888,notification);
}
}
接下来写我们的主service，主service会先调用一次startForeground()，然后再启动BootstrapService。
[java]viewplain
{
@Override
publicvoidonCreate(){
super.onCreate();
BootstrapService.startForeground(this);
//
Intentintent=newIntent(this,BootstrapService.class);
startService(intent);
}
@Override
publicvoidonDestroy(){
super.onDestroy();
stopForeground(true);
}
}
看到这里大家应该已经明白了，说白了就是两个service共用一个notificationID，第一个service起来的时候会显示通知栏，然后第二个service停掉的时候去除通知栏。
最后再doubleconfirm一下主service是前台运行的：
[plain]viewplain
root@hammerhead:/#mpsysactivityservices|grepxinxin
*ServiceRecord{f393843u0com.xinxin.startforeground/.MainService}
intent={cmp=com.xinxin.startforeground/.MainService}
packageName=com.xinxin.startforeground
processName=com.xinxin.startforeground
baseDir=/data/app/com.xinxin.startforeground-1/base.apk
dataDir=/data/user/0/com.xinxin.startforeground
app=ProcessRecord{6af09dd22261:com.xinxin.startforeground/u0a122}
isForeground=trueforegroundId=8888foregroundNoti=Notification(pri=-2contentView=com.xinxin.startforeground/0x1090085vibrate=nullsound=nulldefaults=0x0flags=0x72color=0x00000000vis=PRIVATE)
可以看到isForeground=true，主service是不受影响的。
说到底我觉得这应该算是个漏洞，我要是google工程师给每个notification加个referencecount你就跪得笔挺挺的...不过不管怎么说，目前这个方法还是能够解决问题的。
⑦ Android 服务的限制
Google官网将Android服务分为了三种，前台服务，后台服务和绑定服务：
前台服务执行一些用户能注意到的操作。例如，音频应用会使用前台服务来播放音频曲目。前台服务必须显示 通知 。即使用户停止与应用的交互，前台服务仍会继续运行。
后台服务执行用户不会直接注意到的操作。例如，如果应用使用某个服务来压缩其存储空间，则此服务通常是后台服务。
当应用组件通过调用 bindService() 绑定到服务时，服务即处于 绑定 状态。绑定服务会提供客户端-服务器接口，以便组件与服务进行交互、发送请求、接收结果，甚至是利用进程间通信 (IPC) 跨进程执行这些操作。仅当与另一个应用组件绑定时，绑定服务才会运行。多个组件可同时绑定到该服务，但全部取消绑定后，该服务即会被销毁。
我个人理解服务可以分为两种， 前台 和 后台 ，而 绑定 应该是被当作一种状态，因为 前台服务 和 后台服务 都可以进行绑定。
基于这个理解，我们将限制分成了前台和后台两个部分：
从 Android 5.0（API 级别 21）开始，如果使用隐式 Intent 调用 bindService() ，则系统会抛出异常。为确保应用的安全性，在启动 Service 时，请始终使用显式 Intent，且不要为服务声明 Intent 过滤器。
在后台中运行的 Service 会消耗设备资源，这可能会降低用户体验。 为了缓解这一问题，系统对这些 Service 施加了一些限制。
处于前台时，应用可以自由创建和运行前台与后台 Service。
Android 8.0 开始：系统不允许后台应用创建后台 Service。否则该函数将引发一个 IllegalStateException。
Android 8.0 开始：进入后台时，在一个持续数分钟的时间窗内，应用仍可以创建和使用 Service。 在该时间窗结束后，应用将被视为处于 空闲 状态。 此时，系统将停止应用的后台 Service，就像应用已经调用 Service 的 Service.stopSelf() 方法一样。
为了解除这种限制，可以使用 JobScheler 作业替换后台 Service。
在 Android 8.0 之前，创建前台 Service 的方式通常是先创建一个后台 Service，然后将该 Service 推到前台。
而在Android 8.0 之后，系统不允许后台应用创建后台 Service。
解决方案：调用 startForegroundService() ，以在前台启动新 Service。
在系统创建 Service 后，应用有五秒的时间来调用该 Service 的 startForeground() 方法以显示新 Service 的用户可见通知。 如果应用在此时间限制内 未 调用 startForeground() ，则系统将停止此 Service 并声明此应用为 ANR 。
前台服务必须显示优先级为 PRIORITY_LOW 或更高的 状态栏通知 ，这有助于确保用户知道应用正在执行的任务。如果某操作不是特别重要，因而您希望使用最低优先级通知，则可能不适合使用服务；相反，您可以考虑使用 计划作业 。
在 Android 9 (API 28)之后，使用前台服务必须申请 FOREGROUND_SERVICE 权限，否则会报 SecurityException 。 这是普通权限，因此，系统会自动为请求权限的应用授予此权限。
每个运行服务的应用都会给系统带来额外负担，从而消耗系统资源。如果应用尝试使用低优先级通知隐藏其服务，则可能会降低用户正在主动交互的应用的性能。因此，如果某个应用尝试运行拥有最低优先级通知的服务，则系统会在抽屉式通知栏的底部调用出该应用的行为。
以 Android 12 为目标平台的应用在后台运行时无法再启动 前台服务 。
在 Android 11 及以后，系统对前台服务何时可以访问设备的位置、摄像头或麦克风进行了限制。
如果您的应用以 Android 11 或更高版本为目标平台，且在前台服务中访问摄像头或麦克风，则必须添加 前台服务类型 camera 和 microphone 。
如果你的应用 在后台运行时启动了某项前台服务 ：
如果某服务的功能（位置、麦克风 和 相机）受到了限制，则Logcat中会打印如下语句：
⑧ Android中怎么启动关闭Service及功能解释
下面根据问题，作出详细解答：
Service不是分离开的进程，除非其他特殊情况，它不会运行在自己的进程，而是作为启动运行它的进程的一部分。
Service不是线程，这意味着它将在主线程里劳作。
启动service有两种方法：
Context.startService()调用者与服务之间没有关联，即使调用者退出，服务仍可运行
Context.bindService() 调用者与服务绑定在一起，调用者一旦退出，服务也就终止
Service的生命周期
如果使用startService()启动service，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。
控制service运行的主要方式有两种，主要是根据onStartCommand方法返回的数值。方法：
START_STICKY
START_NOT_STICKY or START_REDELIVER_INTENT
这里主要解释这三个变量的意义：
START_STICKY
在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent
START_NOT_STICKY
在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。
START_REDELIVER_INTENT
在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。
客户端也可以使用bindService来保持跟service持久关联。谨记：如果使用这种方法，那么将不会调用onstartCommand（跟startService不一样，下面例子注释也有解析，大家可试试）。客户端将会在onBind回调中接收到IBinder接口返回的对象。通常IBinder作为一个复杂的接口通常是返回aidl数据。
Service也可以混合start和bind一起使用。
要运行service，首先必须在AndroidManifest.xml里申明<service>标签。
Service能够保护个人的IPC调用，所以在执行实现该调用时前先使用checkCallingPermission(String) 方法检查是否有这个权限。
进程生命周期
当service运行在低内存的环境时，将会kill掉一下存在的进程。因此进程的优先级将会很重要：
如果service当前正在执行onCreate、onStartCommand、onDestroy方法，主进程将会成为前台进程来保证代码可以执行完成避免被kill
如果service已经启动了，那么主进程将会比其他可见的进程的重要性低，但比其他看不见的进程高。因为只有少部分进程始终是用户可见的，因此除非在极度低内存的时候，不然 service是不会被kill的。
如果有客户端关联到service，那么service永远比客户端重要。也就是说客户端可见，那么service也可见（我理解这里的可见并不是可以看到，而是重要性，因为可见往往就表示重要性高）。
Service可以使用startForeground API将service放到前台状态。这样在低内存时被kill的几率更低，但是文档后面又写了，如果在极度极度低内存的压力下，该service理论上还是会被kill掉。但这个情况基本不用考虑。
当然如果service怎么保持还是被kill了，那你可以通过重写onStartCommand返回变量来设置它的启动方式。比如：START_STICKY、START_REDELIVER_INTENT等等，前面已经讨论了它们的作用，这里就不再累赘了
另外：
service 的onCreate和onStartCommand 是运行在主线程的，所以如果里面有处理耗时间的任务。两种处理：
请将它们都挪到新的线程里。
用系统提供的IntentService，它继承了Service，它处理数据是用自身新开的线程。
⑨ Android的startForeground前台Service如何去掉通知显示
一、正常的前台Service
我们都知道，Service几乎都是在后台运行的，所以Service的系统优先级还是比较低的，当系统出现内存不足情况时，就有可能回收掉正在后台运行的Service。如果你希望Service可以一直保持运行状态，而不会由于系统内存不足的原因导致被回收，那么就要提高Service的优先级，而提高优先级的方法有多种，其中一种就是考虑使用前台Service。
如何把Service设置为前台Service？很简单，使用startForeground即可。要取消前台，使用stopForeground即可。
不多说，直接上代码，非常的简单，不解释：
public class MyService extends Service {
private static final String TAG = "wxx";
@Override
public IBinder onBind(Intent intent) {
// TODO Auto-generated method stub
return null;
}
@Override
public void onCreate() {
// TODO Auto-generated method stub
super.onCreate();
Log.d(TAG, "MyService: onCreate()");
//定义一个notification
Notification notification = new Notification();
Intent notificationIntent = new Intent(this, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);
notification.setLatestEventInfo(this, "My title", "My content", pendingIntent);
//把该service创建为前台service
startForeground(1, notification);
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
// TODO Auto-generated method stub
Log.d(TAG, "MyService: onStartCommand()");
return super.onStartCommand(intent, flags, startId);
}
}
有留心的朋友会发现，每当启动该前台Service的时候，手机都会收到一个通知，下拉通知栏，会看到一个通知如“XXService正在运行。”，如下图：
查看文档，知道，当SDK<18时，系统不会有该通知，当SDK>=18时，系统有显示该通知。系统显示该通知，应该是为了防止滥用“startForeground”。
那，如果我就是不想显示该通知给用户？怎么搞？
二、去掉startForeground的通知
本人之前因接触过一些通知相关的内容，于是，大胆假设：把2个同进程的Service都用startForeground设置为前台进程，但他们使用相同的Notification ID,那么他们只会产生一个通知，然后把其中一个Service取消前台效果，那么就会把通知关闭，剩下的那个Service就是前台Service了，而且通知栏没有通知。
有了假设，当然就要验证是否可行~~
看代码吧。。。
先看最后要保留的那个Service的代码：
public class MyService extends Service {
private static final String TAG = "wxx";
private final int PID = android.os.Process.myPid();
private AssistServiceConnection mConnection;
@Override
public IBinder onBind(Intent intent) {
// TODO Auto-generated method stub
return null;
}
@Override
public void onCreate() {
// TODO Auto-generated method stub
super.onCreate();
Log.d(TAG, "MyService: onCreate()");
setForeground();
}
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
// TODO Auto-generated method stub
Log.d(TAG, "MyService: onStartCommand()");
return super.onStartCommand(intent, flags, startId);
}
@Override
public void onDestroy() {
// TODO Auto-generated method stub
super.onDestroy();
Log.d(TAG, "MyService: onDestroy()");
}
public void setForeground() {
// sdk < 18 , 直接调用startForeground即可,不会在通知栏创建通知
if (VERSION.SDK_INT < 18) {
this.startForeground(PID, getNotification());
return;
}
if (null == mConnection) {
mConnection = new AssistServiceConnection();
}
this.bindService(new Intent(this, AssistService.class), mConnection,
Service.BIND_AUTO_CREATE);
}
private class AssistServiceConnection implements ServiceConnection {
@Override
public void onServiceDisconnected(ComponentName name) {
Log.d(TAG, "MyService: onServiceDisconnected");
}
@Override
public void onServiceConnected(ComponentName name, IBinder binder) {
Log.d(TAG, "MyService: onServiceConnected");
// sdk >=18
// 的，会在通知栏显示service正在运行，这里不要让用户感知，所以这里的实现方式是利用2个同进程的service，利用相同的notificationID，
// 2个service分别startForeground，然后只在1个service里stopForeground，这样即可去掉通知栏的显示
Service assistService = ((AssistService.LocalBinder) binder)
.getService();
MyService.this.startForeground(PID, getNotification());
assistService.startForeground(PID, getNotification());
assistService.stopForeground(true);
MyService.this.unbindService(mConnection);
mConnection = null;
}
}
private Notification getNotification() {
// 定义一个notification
Notification notification = new Notification();
Intent notificationIntent = new Intent(this, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0,
notificationIntent, 0);
notification.setLatestEventInfo(this, "My title", "My content",
pendingIntent);
return notification;
}
再看那个辅助消除通知的Service的代码，非常的简单：
public class AssistService extends Service {
private static final String TAG = "wxx";
public class LocalBinder extends Binder {
public AssistService getService() {
return AssistService.this;
}
}
@Override
public IBinder onBind(Intent intent) {
Log.d(TAG, "AssistService: onBind()");
return new LocalBinder();
}
@Override
public void onDestroy() {
// TODO Auto-generated method stub
super.onDestroy();
Log.d(TAG, "AssistService: onDestroy()");
}
}
代码就这么多，上面大体思路是：一个最后保留的MyService，一个辅助消除通知的AssistService, 利用MyService去绑定AssistService，在关联函数onServiceConnected()中实现两个Service调用startForeground变为前台服务，注意一定要使用一样的Notification ID，然后AssistService取消前台效果stopForeground从而删除通知。
⑩ Android的startForeground前台Service如何去掉通知显示
设置成前台的service一般的清理软件就杀不掉service了~~//，SERVICE_=newNotification();status.flags|=Notification.FLAG_FOREGROUND_SERVICE;startForeground(SERVICE_STATUS,status);