Android Service

 

1.Service概念

Service定义：通常service用来执行一些耗时操作，或者后台执行不提供用户交互界面的操作，

Service与Thread：Service运行在主线程里的。Activity很难对Thread进行控制，当Activity被销毁之后，就没有任何其它的办法可以再重新获取到之前创建的子线程的实例。而且在一个Activity中创建的子线程，另一个Activity无法对其进行操作。但是Service就不同了，所有的Activity都可以与Service进行关联，然后可以很方便地操作其中的方法，即使Activity被销毁了，之后只要重新与Service建立关联，就又能够获取到原有的Service中Binder的实例。因此，使用Service来处理后台任务，Activity就可以放心地finish，完全不需要担心无法对后台任务进行控制的情况。

2.Service启动与关闭

startService：onCreate->onStartCommand

bindService：onCreate->onBind

 

多次调用startService：会多次执行onStartCommand函数，

对次调用bindServic：:不会多次onBind函数

stopService:onDestroy。service通过Context.startService()方法开始，通过Context.stopService()方法停止；也可以通过Service.stopSelf()方法或者Service.stopSelfResult()方法来停止自己。只要调用一次stopService()方法便可以停止服务，无论之前它被调用了多少次的启动服务方法。

unbindService:onUnbind->onDestroy。客户端建立一个与Service的连接，并使用此连接与Service进行通话，通过Context.bindService()方法来绑定服务，Context.unbindService()方法来关闭服务。多个客户端可以绑定同一个服务，如果Service还未被启动，bindService()方法可以启动服务。

混合启动与关闭:上面startService()和bindService()两种模式是完全独立的。你可以绑定一个已经通过startService()方法启动的服务。例如：一个后台播放音乐服务可以通过startService(intend)对象来播放音乐。可能用户在播放过程中要执行一些操作比如获取歌曲的一些信息，此时activity可以通过调用bindServices()方法与Service建立连接。这种情况下，stopServices()方法实际上不会停止服务，直到最后一次绑定关闭。

 

如果没有程序停止它或者它自己停止，service将一直运行。在这种模式下，service开始于调用Context.startService() ，停止于Context.stopService(). service可以通过调用Android Service 生命周期() 或 Service.stopSelfResult()停止自己。不管调用多少次startService() ，只需要调用一次 stopService() 就可以停止service。

 

可以通过接口被外部程序调用。外部程序建立到service的连接，通过连接来操作service。建立连接调开始于Context.bindService(), 结束于Context.unbindService(). 多个客户端可以绑定到同一个service，如果service没有启动， bindService() 可以选择启动它。

 

这2种模式不是完全分离的。你可以可以绑定到一个通过startService()启动的服务。如一个intent想要播放音乐，通过startService() 方法启动后台播放音乐的service。然后，也许用户想要操作播放器或者获取当前正在播放的乐曲的信息，一个activity就会通过bindService()建立一个到此service的连接. 这种情况下 stopService() 在全部的连接关闭后才会真正停止service。

 

3.前台Service

public class MyService extends Service {

 

public static final String TAG = "MyService";

 

private MyBinder mBinder = new MyBinder();

 

@Override

public void onCreate() {

super.onCreate();

Notification notification = new Notification(R.drawable.ic_launcher,

"有通知到来", System.currentTimeMillis());

Intent notificationIntent = new Intent(this, MainActivity.class);

PendingIntent pendingIntent = PendingIntent.getActivity(this, 0,

notificationIntent, 0);

notification.setLatestEventInfo(this, "这是通知的标题", "这是通知的内容",

pendingIntent);

startForeground(1, notification);

Log.d(TAG, "onCreate() executed");

}

 

.........

 

}

4.onStartCommand

下面重点关注下onStartCommand(Intent intent, int flags, int startId)方法。

其中参数flags默认情况下是0，对应的常量名为START_STICKY_COMPATIBILITY。startId是一个唯一的整型，用于表示此次Client执行startService(...)的请求请求标识，在多次startService(...)的情况下，呈现0,1,2....递增。另外，此函数具有一个int型的返回值，具体的可选值及含义如下：

START_NOT_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，即使系统内存足够可用，系统也不会尝试重新创建此Service。除非程序中Client明确再次调用startService(...)启动此Service。

START_STICKY：当Service因为内存不足而被系统kill后，接下来未来的某个时间内，当系统内存足够可用的情况下，系统将会尝试重新创建此Service，一旦创建成功后将回调onStartCommand(...)方法，但其中的Intent将是null，pendingintent除外。

START_REDELIVER_INTENT：与START_STICKY唯一不同的是，回调onStartCommand(...)方法时，其中的Intent将是非空，将是最后一次调用startService(...)中的intent。

START_STICKY_COMPATIBILITY：此值一般不会使用，所以注意前面三种情形就好。

以上的描述中，”当Service因为内存不足而被系统kill后“一定要非常注意，因为此函数的返回值设定只是针对此种情况才有意义的，换言之，当认为的kill掉Service进程，此函数返回值无论怎么设定，接下来未来的某个时间内，即使系统内存足够可用，Service也不会重启。

5.保活方式

 

黑色保活：不同的app进程，用广播相互唤醒（包括利用系统提供的广播进行唤醒）

白色保活：启动前台Service

灰色保活：利用系统的漏洞启动前台Service

黑色保活

所谓黑色保活，就是利用不同的app进程使用广播来进行相互唤醒。举个3个比较常见的场景：

场景1：开机，网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app（最新的Android N取消了 ACTION_NEW_PICTURE（拍照），ACTION_NEW_VIDEO（拍视频），CONNECTIVITY_ACTION（网络切换）等三种广播）

场景2：接入第三方SDK也会唤醒相应的app进程，如微信sdk会唤醒微信，支付宝sdk会唤醒支付宝。由此发散开去，就会直接触发了下面的 场景3

场景3：假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。（只是拿阿里打个比方，其实BAT系都差不多）

白色保活

白色保活手段非常简单，就是调用系统api启动一个前台的Service进程，这样会在系统的通知栏生成一个Notification，用来让用户知道有这样一个app在运行着，哪怕当前的app退到了后台。如下方的LBE和QQ音乐

灰色保活

灰色保活，这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service进程，与普通的启动方式区别在于，它不会在系统通知栏处出现一个Notification，看起来就如同运行着一个后台Service进程一样。这样做带来的好处就是，用户无法察觉到你运行着一个前台进程（因为看不到Notification）,但你的进程优先级又是高于普通后台进程的。那么如何利用系统的漏洞呢，大致的实现思路和代码如下：

· 思路一：API < 18，启动前台Service时直接传入new Notification()；

· 思路二：API >= 18，同时启动两个id相同的前台Service，然后再将后启动的Service做stop处理；

public class GrayService extends Service {

 

    private final static int GRAY_SERVICE_ID = 1001;

 

    @Override

    public int onStartCommand(Intent intent, int flags,int startId){

        if (Build.VERSION.SDK_INT <18) {

            startForeground(GRAY_SERVICE_ID,new Notification());//API < 18 ，此方法能有效隐藏Notification上的图标

        }else {

            Intent innerIntent =new Intent(this, GrayInnerService.class);

            startService(innerIntent);

            startForeground(GRAY_SERVICE_ID,new Notification());

        }

 

        return super.onStartCommand(intent, flags, startId);

    }

 

    ...

    ...

 

    /**

     * 给 API >= 18 的平台上用的灰色保活手段

     */

    public static class GrayInnerService extends Service {

 

        @Override

        public int onStartCommand(Intent intent, int flags,int startId){

            startForeground(GRAY_SERVICE_ID,new Notification());

            stopForeground(true);

            stopSelf();

            return super.onStartCommand(intent, flags, startId);

        }

 

    }

}

，使用灰色保活并不代表着你的Service就永生不死了，只能说是提高了进程的优先级。如果你的app进程占用了大量的内存，按照回收进程的策略，同样会干掉你的app。

 

手机root后，杀掉QQ进程之后就再也起不来了。有些手机厂商把这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通app一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。

所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的伪命题！

利用Native进程拉活

主要思想：利用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。

主要原理：在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。而且，通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。

利用 JobScheduler 机制拉活

Android5.0 以后系统对 Native 进程等加强了管理，Native 拉活方式失效。系统在 Android5.0 以上版本提供了 JobScheduler 接口，系统会定时调用该进程以使应用进行一些逻辑操作。