推送功能，是每一个app都会开发的功能，它可以很大程度的提高app的使用率和用户的保活率。但是问题来了，由于现在安卓系统越来越成熟，对某些权限的限制越来越大，而且各大厂商的定制系统对后台app监控做得也越来越好，如果自己实现一条后台线程来和后台服务器保持长连接，基本前台app退出不到几分钟就被杀死了，所以我选择通过接入第三方的推送SDK来实现推送功能的实现。

    在给公司产品接入推送时，我实现了两种方案，原因下面会解释，第一种方案就是自己集成了目前系统已经开放的厂商通道，到目前为止，已经开发有厂商通道的系统有小米、魅族（flyme）、vivo、oppo、华为（华为移动服务HMS），下面是各平台的入口：

小米开发者平台 

魅族开发者平台 注意：魅族推送分为两种：一种是自己的厂商推送；一种是集成推送；两者不同，使用时记住看清，两者的后台有点区别的

华为开发者联盟 注意：如果要接入华为推送，就必须把华为整一个移动服务框架都要集成进去，这个有点坑，而且华为推送的后台并不支持全量推送，所以在开发时，还必须自己收集注册华为推送返回的token，这个就有点糟心了，增加很多的开发量。我还要吐槽一点，华为开发者的后台响应的有点慢，哈哈哈。

vivo开发者平台 注意：这个需要企业开发者账号才行，暂时不开放个人开发者使用

oppo开发者平台 注意：这个如果想要接入必须是已经上线的app才可以，而且他们后台也会有一定的审核，还有，他们对通知栏的自定义样式有一套很严格的要求，也是比较麻烦的。

上面就是各厂商通道的控制后台，一般要发布推送建议还是使用他们的后台进行操作，不建议自己使用他们的后台接口，因为，第一点，他们的后台挺成熟的，第二点，要接入推送一定不止接入一个厂商通道，这样大大增加后台开发的工作量，所以建议使用他们自己的后台。

在app接入推送时，要注意几点吧，都是我自己踩过的坑，哈哈哈

1、使用一个CallActivity作为跳转activity

这种坑出现的情况是这样的，点击推送后的点击事件是打开app，默认打开的是入口activity，我们的app当然不止仅使用一个activity承载，例如我们正在activityB的界面上，此时一条推送进来，我们点击后的事件是打开app，此时就会出现activityA（即入口Activity）位于栈顶，将ActivityB盖住。这样导致activity栈错乱，流程也可能会因此出现错误。

所以：我提供的解决方案是，指定点击通知栏后，跳转的activity为CallActivity（一个中转activity），只要我们在这个activity判断当前是否已经打开应用，如果已经打开就不做处理，如未打开，再跳转到ActivityA（即入口Activity）走正常打开app的流程。因为CallActivity最后都要finish自己，这样就可以保证不会干扰正常Activity栈，也就不会干扰正常的流程。如果想跳转其他页面，可以在这个基础上进行扩展。

2、建议将各厂商通道的集成的需要代码统一到一个library里面去，因为他们在manifest里面要配置的代码太多，这样就会导致主工程的manifest贼多东西。

3、在测试vivo和oppo机型，记得！记得！打开app的通知栏通知开关，他们是默认关闭的。

这是第一种方案，这种方案的缺点是每一次要推送都得跑到他们的后台去推送，一共又有几个后台，产品他们就不开心了。

所有就有了第二种方案，使用第三方集成推送，例如信鸽、极光，他们都集成了厂商通道，但是这种呢，有缺点，他们并没有把所有的厂商通道都集成进去，例如信鸽里面就还没有集成vivo和oppo，所以在这两种机型上，依旧会出现杀后台收不到推送信息的情况，下面是第三方集成推送的入口：

信鸽 注意：虽然它集成了厂商通道，我们还是要到各自系统的开发者平台上申请推送，再信鸽后台完善相应的信息

极光 同上

这两款是我们现在公司在用推送SDK感觉还是可以的，都有集成了厂商通道，推送效果还行，但是整体还是比不上第一种方案，原因由于这些集成推送都是免费的，所以在时效上、到达率上不能保证百分之百，而且前面说了他们并没有把现有的所有厂商通道都集成进去，so，在没有集成系统上，杀后台时基本收不到。

不过好消息是，谷歌爸爸准备出面解决这个局面了，哈哈哈，说要联合所有厂商一起打造一个推送平台，可能到时接入推送就可以很轻松了。

 

 

 

       在android2.3的时代,这个需求真的很简单,最直接的方法就是开一个守护线程,当主线程被杀死的时候重启应用,这也是当时大多数应用为了保证应用不退出的做法,这也直接导致android手机越用越慢的原因,但是在API18以后,google公司对于android系统的不断优化,很多权限被禁止开发人员拿到,这用做法也已经无法做到了,前段时间，Github还出现了一个很火的“黑科技”进程保活库，声称可以做到进程永生不死,我怀着膜拜和学习的心理去看了下,结果发现很多人提了 Issue 说各种各样的机子无法成功保活。
      看到这里，我瞬间就放心了。坦白的讲，我是真心不希望有这种黑科技存在的，它只会滋生更多的流氓应用，拖垮我大 Android 平台的流畅性。
扯了这么多，接下来就直接进入本文的正题，谈谈关于进程保活的知识。
Android进程保活手段主要分3种:
      1:利用不同的app进程使用广播来进行相互唤醒
      2:它是利用系统的漏洞来启动一个前台的Service进程，与普通的启动方式区别在于，它不会在系统通知栏处出现一个Notification，看起来就如同运行着一个后台Service进程一样。
      3:调用系统api启动一个前台的Service进程，这样会在系统的通知栏生成一个Notification，用来让用户知道有这样一个app在运行着，哪怕当前的app退到了后台.比如网易云音乐.
早前，我在知乎上回答了这样一个问题：怎么让 Android 程序一直后台运行，像 QQ 一样不被杀死？。关于 Android 平台的进程保活这一块，想必是所有 Android 开发者瞩目的内容之一。你到网上搜 Android 进程保活，可以搜出各种各样神乎其技的做法，绝大多数都是极其不靠谱。前段时间，Github还出现了一个很火的“黑科技”进程保活库，声称可以做到进程永生不死。怀着学习和膜拜的心情进去Github围观，结果发现很多人提了 Issue 说各种各样的机子无法成功保活。看到这里，我瞬间就放心了。坦白的讲，我是真心不希望有这种黑科技存在的，它只会滋生更多的流氓应用，拖垮我大 Android 平台的流畅性。
扯了这么多，接下来就直接进入本文的正题，谈谈关于进程保活的知识。提前声明以下四点
本文是本人开发 Android 至今综合各方资料所得
不以节能来维持进程保活的手段，都是耍流氓
本文不是教你做永生不死的进程，如果指望实现进程永生不死，请忽略本文
本文有错误的地方，欢迎留下评论互相探讨（拍砖请轻拍）
保活手段
当前业界的Android进程保活手段主要分为** 黑、白、灰 **三种，其大致的实现思路如下：
黑色保活：不同的app进程，用广播相互唤醒（包括利用系统提供的广播进行唤醒）
白色保活：启动前台Service
灰色保活：利用系统的漏洞启动前台Service
黑色保活
所谓黑色保活，就是利用不同的app进程使用广播来进行相互唤醒。举个3个比较常见的场景：
场景1：开机，网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app
场景2：接入第三方SDK也会唤醒相应的app进程，如微信sdk会唤醒微信，支付宝sdk会唤醒支付宝。由此发散开去，就会直接触发了下面的 场景3
场景3：假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。（只是拿阿里打个比方，其实BAT系都差不多）
没错，我们的Android手机就是一步一步的被上面这些场景给拖卡机的。
针对场景1，估计Google已经开始意识到这些问题，所以在最新的Android N取消了 ACTION_NEW_PICTURE（拍照），ACTION_NEW_VIDEO（拍视频），CONNECTIVITY_ACTION（网络切换）等三种广播，无疑给了很多app沉重的打击。我猜他们的心情是下面这样的，而开机广播的话，记得有一些定制ROM的厂商早已经将其去掉。
针对场景2和场景3，因为调用SDK唤醒app进程属于正常行为，此处不讨论。但是在借助LBE分析app之间的唤醒路径的时候，发现了两个问题：
很多推送SDK也存在唤醒app的功能
app之间的唤醒路径真是多，且错综复杂
我把自己使用的手机测试结果给大家围观一下（我的手机是小米4C，刷了原生的Android5.1系统，且已经获得Root权限才能查看这些唤醒路径）   
  
15组相互唤醒路径

         
全部唤醒路径
简书唤醒路径             
可以看到以上3条唤醒路径，但是涵盖的唤醒应用总数却达到了23+43+28款，数目真心惊人。请注意，这只是我手机上一款app的唤醒路径而已，到了这里是不是有点细思极恐。
当然，这里依然存在一个疑问，就是LBE分析这些唤醒路径和互相唤醒的应用是基于什么思路，我们不得而知。所以我们也无法确定其分析结果是否准确，如果有LBE的童鞋看到此文章，不知可否告知一下思路呢？但是，手机打开一个app就唤醒一大批，我自己可是亲身体验到这种酸爽的......
白色保活
白色保活手段非常简单，就是调用系统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，看下系统通知栏有没有一个 Notification，如果没有，我们就进入手机的adb shell模式，然后输入下面的shell命令
dumpsys activity services PackageName
打印出指定包名的所有进程中的Service信息，看下有没有 isForeground=true 的关键信息。如果通知栏没有看到属于app的 Notification 且又看到 isForeground=true 则说明了，此app利用了这种灰色保活的手段。
下面分别是我手机上微信、qq、支付宝、陌陌的测试结果，大家有兴趣也可以自己验证一下。
微信
手Q
支付宝
陌陌
其实Google察觉到了此漏洞的存在，并逐步进行封堵。这就是为什么这种保活方式分 API >= 18 和 API < 18 两种情况，从Android5.0的ServiceRecord类的postNotification函数源代码中可以看到这样的一行注释
当某一天 API >= 18 的方案也失效的时候，我们就又要另谋出路了。需要注意的是，使用灰色保活并不代表着你的Service就永生不死了，只能说是提高了进程的优先级。如果你的app进程占用了大量的内存，按照回收进程的策略，同样会干掉你的app。感兴趣于灰色保活是如何利用系统漏洞不显示 Notification 的童鞋，可以研究一下系统的 ServiceRecord、NotificationManagerService 等相关源代码，因为不是本文的重点，所以不做详述。
唠叨的分割线
到这里基本就介绍完了** 黑、白、灰 **三种实现方式，仅仅从代码层面去讲保活是不够的，我希望能够通过系统的进程回收机制来理解保活，这样能够让我们更好的避免踩到进程被杀的坑。
进程回收机制
熟悉Android系统的童鞋都知道，系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫 Low Memory Killer ，它是基于Linux内核的 OOM Killer（Out-Of-Memory killer）机制诞生。
了解完 Low Memory Killer，再科普一下oom_adj。什么是oom_adj？它是linux内核分配给每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收。对于oom_adj的作用，你只需要记住以下几点即可：
进程的oom_adj越大，表示此进程优先级越低，越容易被杀回收；越小，表示进程优先级越高，越不容易被杀回收
普通app进程的oom_adj>=0,系统进程的oom_adj才可能<0
那么我们如何查看进程的oom_adj值呢，需要用到下面的两个shell命令
ps | grep PackageName //获取你指定的进程信息
这里是以我写的demo代码为例子，红色圈中部分别为下面三个进程的ID
UI进程：com.clock.daemon
普通后台进程：com.clock.daemon:bg
灰色保活进程：com.clock.daemon:gray
当然，这些进程的id也可以通过AndroidStudio获得
接着我们来再来获取三个进程的oom_adj
cat /proc/进程ID/oom_adj
从上图可以看到UI进程和灰色保活Service进程的oom_adj=0，而普通后台进程oom_adj=15。到这里估计你也能明白，为什么普通的后台进程容易被回收，而前台进程则不容易被回收了吧。但明白这个还不够，接着看下图
上面是我把app切换到后台，再进行一次oom_adj的检验，你会发现UI进程的值从0变成了6,而灰色保活的Service进程则从0变成了1。这里可以观察到，app退到后台时，其所有的进程优先级都会降低。但是UI进程是降低最为明显的，因为它占用的内存资源最多，系统内存不足的时候肯定优先杀这些占用内存高的进程来腾出资源。所以，为了尽量避免后台UI进程被杀，需要尽可能的释放一些不用的资源，尤其是图片、音视频之类的。
从Android官方文档中，我们也能看到优先级从高到低列出了这些不同类型的进程：Foreground process、Visible process、Service process、Background process、Empty process。而这些进程的oom_adj分别是多少，又是如何挂钩起来的呢？推荐大家阅读下面这篇文章：
http://www.cnblogs.com/angeldevil/archive/2013/05/21/3090872.html
总结（文末有福利）
絮絮叨叨写完了这么多，最后来做个小小的总结。回归到开篇提到QQ进程不死的问题，我也曾认为存在这样一种技术。可惜我把手机root后，杀掉QQ进程之后就再也起不来了。有些手机厂商把这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通app一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。
所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的伪命题！
补充更新 （2016-04-20）
有童鞋问，在华为的机子上发现微信和手Q的UI进程退到后台，oom_adj的值一点都没有变，是不是有什么黑科技在其中。为此，我稍稍验证了一下，验证方式就是把demo工程的包名改成手机QQ的，编译运行在华为的机子上，发现我的进程怎么杀也都是不死的，退到后台oom_adj的值同样不发生变化，而恢复原来的包名就不行了。所以，你懂的，手Q就在华为机子的白名单中。
文章到此结束，相关简单的实践代码请看
https://github.com/D-clock/AndroidDaemonService

 1.新建一个test项目

2.点击项目目录中manifest选择App SDK配置选择unipush，然后在选择App模块权限配置选择Push

3.登录https://dev.dcloud.net.cn/ 创建应用，账号要实名认证才能使用推送功能 注意创建的应用名称要跟你HBulider X上的名称一致 这样项目的appid才会相同

4.点击应用，找到Uni Push 选择 uni push  填写包名,这个自己后面要用到

5.填写应用签名，应用签名有三种，1.使用自有证书  2.使用公共测试证书 3.使用DCloud老版证书，现在不推荐使用第三种方式。我为了方便测试选了第2种。在app应用签名下面有个更多公用证书信息，点击进入有个公共测试证书，点击进入，在公共测试证书下边找到应用签名复制到应用签名然后填写ios bundleid

6.开通

7.打开test项目，点击发行，选择原生App云打包，填写与上面一致的包名，上面填写的是公共测试证书的签名所以这里选择使用公共测试证书，由于要在手机上运行所以选择打自定义调试基座，然后选择打包。

8.打包完成后，登录https://dev.dcloud.net.cn/ 选择test项目，选择unipush 选择创建推送，填写标题、通知内容，点击预览，会让你填cid，cid就是你手机的一个标志。获得cid的代码是

var cid = plus.device.uuid;

console.log('==CID=='+cid);

9.写好代码，选择 运行->运行到手机或模拟器->运行基座选择->自定义调试基座 然后再次运行项目。拿到cid。填写的网站上，点击预览，大概2秒钟，你的手机就会收到通知。

安卓开发使用Notifiation推送通知没有声音、振动等
写在前面的话
问题表现
权限方面
控制台相关警告
其他说明
2019/10/22 再次更新，手机版本

写在前面的话
这里不打算写教程，网上一搜大同小异，但是遇到的问题却让人摸不到头脑，我去安卓官方查看doc也没发现哪里写错。非常疑惑，所以记录下来，解决后作为自己经验的累积。
问题表现


通知可以发出，但

builder.setAutoCancel(true) .setDefaults(NotificationCompat.DEFAULT_ALL)

（点击自动消失，设置声音振动等为系统默认）无效果，然而

builder.setContentTitle("title") .setSmallIcon(R.mipmap.ic_launcher_new_round) .setContentText(serverMessage) .setContentIntent(messagePendingIntent)

是有效的。


我也分别使用过 Notification.Builder和NotificationCompat.Builder 声明builder以及使用

notification.flags = Notification.XXXXXX 的方式设置声音振动呼吸灯等，依然没有效果；


权限方面
权限方面，这里只列出部分，相关的大概有以下：
<uses-permission android:name="android.permission.INTERNET" />
<!-- android 9.0上使用前台服务，需要添加权限 -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<!-- 允许程序振动 -->
<uses-permission android:name="android.permission.VIBRATE" />
<!-- 允许程序在手机屏幕关闭后后台进程仍然运行 -->
<uses-permission android:name="android.permission.WAKE_LOCK" />
<!-- 允许程序禁用键盘锁 -->
<uses-permission android:name="android.permission.DISABLE_KEYGUARD" />
<!--闪光灯-->
<uses-permission android:name="android.permission.FLASHLIGHT"/>

控制台相关警告
调制控制台输出Warning，不知道是否与这个有关：
W/Notification:Use of stream types is deprecated for operations other than volume control
W/Notification:See the documentation of setSound() for what to use instead with android.media.AudioAttributes to qualify your playback use case

我也尝试过用setSound()设置uri来指定铃声，但依然无效，给出来的警告不变。
其他说明

API版本：分别使用Android 8.0，Android 8.1，Android 9.0测试都无效
手机：小米 8（Android 9）

– 2019/4/22 8:42 –
– 2019/10/22 16:08 –

没想到会有一天再翻出这篇文章。

上面的问题由于项目弃置，所以就一直没解决。不过最近由于在新的项目里又用了Notification来推送通知。这次的app是从头到尾我一人完成。因此并没有出现之前的问题。
2019/10/22 再次更新，手机版本

API 版本：Android 8.0
手机 小米8 （Android 9）


MainActivity.java
//启动状态栏通知Service
Intent intent = new Intent(this, NotificationService.class);
intent.setAction("app.SERVICE");
startService(intent);


NotificationService.java
import android.app.Notification;
import android.app.NotificationChannel;
import android.app.NotificationManager;
import android.app.Service;
import android.content.Intent;
import android.graphics.Color;
import android.os.IBinder;

/**
 * @author hiYuzu
 * @version V1.0
 * @description 推送通知Service
 * @date 2019/10/15 10:24
 */
public class NotificationService extends Service {
    private static final String TAG = NotificationService.class.getSimpleName();
    private static final String CHANNEL_ID = "NotificationService";

    //线程获取信息
    private MessageThread messageThread = null;

    @Override
    public IBinder onBind(Intent intent) {
        return null;
    }
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        return START_STICKY;
    }

    @Override
    public void onCreate() {
        super.onCreate();
        messageThread = new MessageThread();
        messageThread.isRunning = true;
        messageThread.start();
    }

    class MessageThread extends Thread {
        //循环控制
        boolean isRunning = true;
        public void run() {
            while (isRunning) {
                try {
                    //间隔60s
                    Thread.sleep(60000);
                    //推送消息
                    if (MainActivity.notifyMessage) {
                        notifyMessage();
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }
    }

    private void notifyMessage() {
        NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);
        NotificationChannel channel = new NotificationChannel(CHANNEL_ID, "报警通知", NotificationManager.IMPORTANCE_HIGH);
        channel.enableLights(true);//提示灯
        channel.setLightColor(Color.GREEN);//提示灯颜色
        channel.setShowBadge(true);//显示Logo
        channel.setDescription("通知的描述");
        channel.setLockscreenVisibility(Notification.VISIBILITY_PUBLIC);//设置锁屏可见
        if (manager != null) {
            manager.createNotificationChannel(channel);
        }
        Notification notification = new Notification.Builder(this, CHANNEL_ID)
                .setContentTitle("标题")
                .setContentText("内容")
                .setSmallIcon(R.mipmap.ic_launcher_round)
                .setAutoCancel(true)
//                .setContentIntent(PendingIntent.getActivity(this, 0, new Intent(), 0))
                .build();
        startForeground(1, notification);
    }

    @Override
    public void onDestroy() {
        messageThread.isRunning = false;
        super.onDestroy();
    }
}

补充说明：

代码经过修改，实际的描述、标题、内容都可以通过后台获取。
除了使用 startService(Intent) 方法启动服务，还可以使用 startForegroundService(Intent) 启动。但是要注意的是，使用 startForegroundService(Intent) 时，服务要在 5s 内 startForeground，否则会出错导致应用闪退。在 stackOverflow 上看了一下，有人说这是 BUG，以后会修复。