详解Android Service 使用时的注意事项

概述最近有个项目刚好使用了Service，特别是AIDL远程服务，经过这次项目对Service有了更好的理解，在这里作个总结。

最近有个项目刚好使用了Service，特别是AIDL远程服务，经过这次项目对Service有了更好的理解，在这里作个总结。

startService / bindService 混合使用

每一次调用 startService 都会回调onStartCommand，之后调用了stopService之后就会 destroy Service。即使有多个clIEnt启动服务，那调用一次stopService 就能 destroy Service 。通过这种方式还有一个好处就是Service可以通过调用 stopSelf 主动退出。 第一次调用bindService 的时候才会回调 onBind，如果有多个clIEnt连接服务，在最后一个clIEnt调用unbindService时才会回调 onUnbind，并destroy Service。

如果startService / bindService 混合使用 那Service的生命同期会怎样呢，其实只要记住以上的思路，这种问题很好理解。首先 startService 与 stopService 对应 ，没有stopService 之前不会 destroy Service ， bindService 与 unbindService对应 ，没有 unbindService 前也不会destroy Service。

为服务添加权限

相信大家做的服务都是公共的，即所有应用都可以调用。但是如果我想我的服务只给特定的应用调用，应该如何设置呢？我们可以给服务添加权限。关于权限，AndroID系统给权限为了四个类别：

普通级： 这些权限并不能真正伤害到用户（比如更换壁纸），当程序需要这些权限是，开发者不需要指定程序会自动赋予这些权限。 危险级： 这些权限可能会带来真的伤害（比如打电话，打开网络链接等），如果要使用它们需要开发者在AndroIDManifest.xml中声明对应的权限。 签名级： 如果应用使用的是相同的签名证书时，这些权限会自动授予给声明或者创建这些权限的程序。设计这一层级权限的目的是方便组件间数据共享。 签名/系统级： 和签名级一样，例外的是系统镜像是自动获取这些权限的，这一层级是专为设备制造商设计的。

<uses-permission androID:name="androID.permission.custom.XXX"/>

如果我们想让自己开发的Service只能被特定的ClIEnt调用，那就可以添加自定义的权限。比如危险级，我们可以在AndroIDManifest.xml中声明对应的权限，只有应用也设置了这个权限，才能正常启动服务。

关于AIDL远程服务

所谓的AIDL远程服务 就是运行在另一个进程的服务，平时我们调用的服务都运行在主线程。要使用AIDL服务就必须写AIDL接口，向外暴露接口就可以与远程服务进行交互了。对于AIDL有如下几个值得注意的地方：

AIDL接口的函数都不支持重载，即函数名不能一样，即使函数参数个数不一样。 AIDL接口传递的参数只有是基本数据类型、String 和CharSequence、List 和 Map、实现androID.os.Parcelable 接口的类。 既然AIDL是在另一个进程的服务，那客户端调用的AIDL接口是否堵塞？ 答案是肯定的。如果不加 oneway 修饰符，那客户端调用的接口都是堵塞的，但是oneway修饰符也有限制，就是oneway接口下面的方法都必须是返回voID类型，不能返回其他类型的数据。

AIDL的接口如何升级？

在做一个比较大型的项目，那项目会不断迭代，那就有可能增加、修改AIDL接口，那如何保证AIDL接口和老的接口不会混乱呢，根据我的经验有如下总结：

对于增删参数的接口：AIDL函数的访问会检测参数，ClIEnt有参数的接口可以调用Service的接口（不管有无参数），反过来，ClIEnt的接口没参数就只能调用Service没有参数的接口。比如我们的新接口定义函数添加了参数，那clIEnt必须同时或提前修改，不然我们发布了新接口的Service应用，ClIEnt就不能调用了，但是ClIEnt用新接口是可以去访问老接口的服务的。 对于增删函数的接口：服务端增加函数并不影响客户端，相反客户端增加服务端没有的接口就会访问无效果，如果客户端增加接口有返回值就返回默认值。

Service管理多个客户端

如果Service有多个客户端，如何安全地与它们通信呢？如何给各个客户端回调结果呢？ 在这里我要说说我在最近项目出现的一个问题，我在项目中要做一个公共的服务，类似于指纹解锁，其它应用通过调用我的服务来获取结果，我设计了start(callback),stop()两个接口，一开始我就用单回调的方式，即在代码中定义一个callback的属性，谁调用了start就把callback设置成谁，只有最后一个调用start的ClIEnt能够获得回调，代码如下 ：

private Callbak mCallback;public voID start(Callback callback) {   this.mCallback = callback;}public voID stop() {   this.mCallback = null;}

这种方式，在单个应用时是很有效的，在多个应用时，只要应用能按顺序执行start、stop 那这个接口的设计也没什么问题。但是事情没想象中那么简单，如果ClIEnt1调用了start，跟着ClIEnt2也调用了start，这时ClIEnt1 要stop，那会怎样，那整个服务都stop了。这个就是我设计的服务中出现的大问题，之后我想着为我的服务接口作一些改变，以适应这种多应用的不按顺序的调用 。我第一个想法就是用register、unregister的方式，用一个List收集所有的callback ，回调时可以轮循，stop时也可以通过判断List的个数，如果是小于等于1，那就执行stop ：

private List<Callbak> mCallbacks;public voID start(Callback callback) {   mCallbacks.add(callback);}public voID stop(Callback callback) {   mCallbacks.remove(callback);   if(List.size() >= 1)     return;}

考虑到接口的升级，这个改动是最小的，只给stop添加了一个参数。但是这个方式也有毛病，我们服务对Callback的引用是强引用，如果ClIEnt异常退出了，那引用还在并且会越积越多，在回调的时候，也可能出现DeadobjectException的错误。通过网络查找资料，我找到了RemoteCallbackList，RemoteCallbackList也是一个列表，保存的是回调接口，使用link-To-Death回调 （在Sevice中接受到这个Binder对象，并且使用 binder.linkToDeath()，注册一个DeathRecipIEnt回调；实现DeathRecipIEnt。当ClIEnt意外退出的时候，DeathRecipIEnt.binderDIEd()将被回调，我们可以在这里释放相关的资源。）。最终代码如下：

private RemoteCallbackList<Callback> mCallbacks = new RemoteCallbackList<>();public voID start(Callback callback) {   mCallbacks.register(callback);}public voID stop(Callback callback) {   mCallbacks.unregister(callback);   if(mCallbacks.getbroadcastItem() >= 1)     return;}private voID notifyResult(String result) {  final int len = mCallbacks.beginbroadcast(); for (int i = 0; i < len; i++) {    try {      mCallbacks.getbroadcastItem(i).onResult(result);    } catch (remoteexception e) {      e.printstacktrace();    } } mCallbacks.finishbroadcast();}

使用Messenger 实现 ServIE与ClIEnt端通信

Messenger是基于Handler的，通过为Messenger添加Handler来传递处理数据，之后Service与ClIEnt的通信都是通过传递的Handler来进行。用这种方式可以不需要定义AIDL接口，也就不出现因为修改AIDl接口所造成的接口版本不对应的麻烦。

Messenger的使用就是通过 Handler传递消息， 客户端send方法发送的是一个Message，这个Message.replyTo指向的是一个Messenger，Messenger又持有客户端的一个Binder对象（MessengerImpl），服务端正是利用这个Binder对象做的与客户端的通信。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持编程小技巧。

总结

以上是内存溢出为你收集整理的详解Android Service 使用时的注意事项全部内容，希望文章能够帮你解决详解Android Service 使用时的注意事项所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。