===
- 设置service为前台
- 把进程做拆分，分成app进程和push进程，其实就是把push进程做到最小，push进程尽量不做业务逻辑处理，只做数据转发和接收,这样push进程占用的内存就变小了，被回收的几率自然也下降
- 把这两个service都设置成前台进程
- 守护Service，开一个Service单独运行在独立的进程中，在守护service里面定时去start app进程的service，而app进程里面的service也定时去start守护service；或者在这两个service之间维护一条tcp连接也可以做到实时检测
- 如果你想在进程中的Service里处理更复杂的逻辑，务必尽量多地使用弱引用或软引用，或者说尽量多地去置空一些不必要的引用并在需要的时候再赋值，其次Service本身也提供了onTrimMemory方法来告诉我们系统何时需要释放掉不必要的资源，灵活使用这类方法可以最大程度的让我们的后台Service长盛不衰。还是那句话，尽量让我们的后台进程做更少的事情，及时释放资源，才是硬道理。
- 进程守护 AB两个进程，A进程里面轮询检查B进程是否存活，没存活的话将其拉起，同样B进程里面轮询检查A进程是否存活，没存活的话也将其拉起，而我们的后台逻辑则随便放在某个进程里执行即可，一个简单的例子是使用两个Service：
- service重启 在onDestroy方法里面重启service START_STICKY
- Receiver触发
- AlarmManager or JobScheduler循环触发
- 进程守护
- 采用bind service加上start service，因为bing service之后即使stop service那service也还是存在，不会调用onDestroy，只有等service被解绑之后才用调用onDestroy，有时候你到应用程序里面去停止了进程的service，列表里面看运行中的程序是找不到service了，但是实际上service还是在运行的，过一会儿就又刷出来了
- 捕获第三方推送的广播接收，在app程序中添加一个静态广播专门用来接收第三方的广播，收到广播后就唤醒Service，例如捕获小米推送，个推，但是有些第三方的广播是有权限限制的，因此不是所有的第三方广播都能被收到
- 监听系统静态广播，开机自启广播，网络变换广播，USB接入和拔出的广播，系统屏幕解锁广播，这几个广播都是静态注册的广播；但是这种方式也是不可靠的，因为有些手机在程序停止运行之后连静态广播都不能收到了。。。增加广播监听只是在一定程度上降低service被杀后重新拉起的概率，但是系统的静态广播在app被杀死后是无法收到的
- 监听第三方的静态自定义广播，静态自定义广播是有可能可以被接收的，只要发送方按照一定的方式发送就行，具体可以参考：如何在app被杀死的情况下仍然可接收静态自定义广播，这边有个前提就是第三方推送发送广播的时候必须要按照指定方式发送才可行，优点是无需接入第三方推送，只是监听他们的广播即可，很轻量级
- 接入第三方推送服务，但是我们不用他们的推送，我们还是用我们自己的推送，不过我们可以捕捉到他们的一些广播，service启动的action等来让它们来触发拉起我们的程序，比如说集成友盟推送，当启动uc的时候可能会发一些广播，通过action启动一些service，我们就专门监听这种广播，监听这些action就能成功的拉起我们的服务，这种办法是通过第三方推送来触发我们的推送服务，人家是专门做推送的，更专业，那我们就直接用呗，达到不使用他们的推送，但是们的app也加入了互相唤醒的app 的行列中去了