通常情况下 , 公司需要让自己的产品在用户的手机中尽可能存活长的时间,包括不受大数字,手动清理后台等情况的影响.这里给出一种方式 就是 双进程守护: 模型如图所示: 两个service通过aidl的方式 建立一种ipc通信,即在两个service的OnstartCommand方法中通过aidl的方式去bind对方: 例如在s1中: @Override public int onStartCommand(Intent intent, int flags, int startId) { this.b

Android进程回收机制 Low Memory Killer原理 微信团队原创分享:Android版微信后台保活实战分享(网络保活篇) 微信团队原创分享:Android版微信后台保活实战分享(进程保活篇) 关于 Android 进程保活,你所需要知道的一切 Android 进程保活招式大全 Android进程保活之绑定系统服务 一种提高Android应用进程存活率新方法 Android后台保活实践总结:即时通讯应用无法根治的“顽疾” Android 进程常驻----MarsDaemon使用说明

正文: 上一篇我们通过父子进程间建立双管道,来监听进程死掉,经过测试,无耗电问题,无内存消耗问题,可以在设置中force close下成功拉起,也可以在获取到root权限的360/cleanmaster下成功存活. 可是放到5.0+的系统就不能用了,为什么呢?我们来看源码4.4系统和5.0系统在系统force close的时候都做了什么修改. 4.4.3的ActivityManagerService . 实现在这里 然后5.0的AMS 实现 可以看出来5.0的源码中系统强杀的时候会连同同grou

正文: 今天继续昨天,一鼓作气,争取这个礼拜全部写完. 上一篇文章留了一个别人的github链接,他里面的native保活实现方案也是大多数公司采用的方案. 我们先来讲一下他的方案. 他是首先开启一个c进程,将需要保活的service名字传递进去 然后定时给自己主进程发一个intent,如果主进程挂掉了,就可以顺利拉起来保证存活. 所以他只是一个没有主动权的消息轮询器,说是守护其实很勉强 而且,这是要建立在保证c进程不挂的基础上,才能轮询,但是就目前来看,只有5.0以下的非国产机才会有这样的漏洞

1.前言 很多人认为,TCP协议自身先天就有KeepAlive机制,为何基于它的通讯链接,仍然需要在应用层实现额外的心跳保活?本文将从移动端IM实践的角度告诉你,即使使用的是TCP协议,应用层的心跳保活仍旧必不可少. 有关TCP协议的权威理论介绍,请参见<TCP/IP详解>这本书. 说明:本文引用了网易云信项望烽的技术文章,感谢分享. (本文同步发布于:http://www.52im.net/thread-33-1-1.html) 2.学习交流 - 即时通讯开发交流群: 215891622 [

前言 Android进程和Service的保活,是困扰Android开发人员的一大顽疾.因涉及到省电和内存管理策略,各厂商基于自家的理解,在自已ROOM发布于都对标准Android发行版作为或多或少的改动,使得应用层程序在处理进程和Service保活问题上变的异常复杂,且很难兼容,因为说不定哪款手机或者哪个版本的省电策略发生改变,那么随之而来的就是进程和Service保活的差异. 在应用场景上,由于即时通讯应用(包括IM聊天应用.消息推送服务等)为了保证消息的全时.实时送达能力,必须要实现进程或

TCP一共有四个主要的定时器,前面已经讲到了一个--超时定时器--是TCP里面最复杂的一个,另外的三个是: 坚持定时器 保活定时器 2MSL定时器 其中坚持定时器用于防止通告窗口为0以后双方互相等待死锁的情况:而保活定时器则用于处理半开放连接 1.坚持定时器 坚持定时器的原理是简单的,当TCP服务器收到了客户端的0滑动窗口报文的时候,就启动一个定时器来计时,并在定时器溢出的时候向向客户端查询窗口是否已经增大,如果得到非零的窗口就重新开始发送数据,如果得到0窗口就再开一个新的定时器准备下一次查询.

android应用保活的基本原理: 都是通过双进程互拉以及设置进程的重要性,除非你root后 把自己的进程设置成系统进程. 互拉的方式有很多种 1.可以通过监听系统广播来把自己拉起来 2.可以多个app相互拉 3.可以把自己的服务搞成前台服务 4.在service的onstart方法里返回 STATR_STICK 5.添加Manifest文件属性值为android:persistent=“true” 6.覆写Service的onDestroy方法 7.服务互相绑定 8.设置闹钟,定时唤醒 9.自

1. Android 后台任务型App多进程架构演化 http://www.jianshu.com/p/4ac1f373e8cd 2. 关于 Android 进程保活,你所需要知道的一切 http://www.jianshu.com/p/63aafe3c12af# 3. Android App 不死之路 http://www.jianshu.com/p/a4a6222654a0

下图是我遇到tcp keepalive的例子: 以下为转载: TCP保活的缘起 双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电.死机.异常重启等各种意外,当这些意外发生之后,这些TCP连接并未来得及正常释放,那么,连接的另一方并不知道对端的情况,它会一直维护这个连接,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,为了解决这个问题,在传输层可以利用TCP的保活报文来

早前,我在知乎上回答了这样一个问题:怎么让 Android 程序一直后台运行,像 QQ 一样不被杀死?.关于 Android 平台的进程保活这一块,想必是所有 Android 开发者瞩目的内容之一.你到网上搜 Android 进程保活,可以搜出各种各样神乎其技的做法,绝大多数都是极其不靠谱.前段时间,Github还出现了一个很火的“黑科技”进程保活库,声称可以做到进程永生不死.   怀着学习和膜拜的心情进去Github围观,结果发现很多人提了 Issue 说各种各样的机子无法成功保活.   看到

1. TCP保活的必要性 1) 很多防火墙等对于空闲socket自动关闭 2) 对于非正常断开, 服务器并不能检测到. 为了回收资源, 必须提供一种检测机制. 2. 导致TCP断连的因素 如果网络正常, socket也通过close操作来进行优雅的关闭, 那么一切完美. 可是有很多情况, 比如网线故障, 客户端一侧突然断电或者崩溃等等, 这些情况server并不能正常检测到连接的断开. 3. 保活的两种方式: 1) 应用层面的心跳机制 自定义心跳消息头. 一般客户端主动发送, 服务器接收后进行回

可能有这样的备用现实TCP连接:流通过. 也就是说.假设TCP连接的两方都没有向对方发送数据.则在两个TCP模块之间不交换不论什么信息,这意味着我们能够启动一个客户与server建立连接,然后长时间不使用,而连接依旧保持.中间的路由器能够崩溃和重新启动,电话线能够被挂断再连接,但仅仅要两端的主机没有被重新启动.则连接依旧保持建立. 然而,很多时候一个server希望知道客户主机是否崩溃并关机或者崩溃又又一次启动.很多实现提供的保活定时器能够提供这样的能力.保活并非TCP规范中的一部分. 保活定时

一.坚持定时器   1.坚持定时器的由来         TCP通过让接收方指明希望从发送方接受的窗口大小来进行流量控制.设置窗口大小为0可以组织发送方传送数据,直至窗口变为非0为止.         如果接收方向发送方通告了一个为0的接口,然后又向发送方通告了窗口更新,恰好这个确认丢失了,那么接收方等待接收数据,发送方等待允许他继续发送数据的窗口更新,就会形成死锁.为了防止这种死锁,发送方使用一个坚持定时器来周期性地向接收方查询,以便发现窗口是否增大.这些从发送方发出的报文段称为窗口探查.  

转载自:http://blog.csdn.net/marswin89/article/details/50917098 这是一个轻量级的库,配置几行代码,就可以实现在Android上实现进程常驻,也就是在系统强杀下,以及360获取root权限下,clean master获取root权限下都无法杀死进程 支持系统2.3到6.0 支持大部分设备,包括三星,华为,oppo,nexus,魅族等等 可以简单对开机广播进行保护 github地址: https://github.com/Marswin/Mar

主要内容:保活定时器的实现,TCP_USER_TIMEOUT选项的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 原理 HTTP有Keepalive功能,TCP也有Keepalive功能,虽然都叫Keepalive,但是它们的目的却是不一样的. 为了说明这一点,先来看下长连接和短连接的定义. 连接的"长短"是什么? 短连接:建立一条连接,传输一个请求,马上关闭连接. 长连接:建立一条连接,传输一个请求,过会儿,又传输若干个请求,最后

本文原作者“minminaya”,作者网站:minminaya.cn,为了提升文章品质,即时通讯网对内容作了幅修订和改动,感谢原作者. 1.引言 对于IM应用和消息推送服务的开发者来说,在Android机型上的后台保活是个相当头疼的问题. 老板一句:“为什么微信.QQ能收到消息,而你写的APP却不行?”,直接让人崩溃,话说老板你这APP要是整成微信.APP那么牛,直接进手机厂商白名单,还要程序员在这瞎忙活? 好了,抱怨归抱怨,活还得干,不然靠谁养活广大苦逼的程序员? 回到正题,Android程序

参考大神教程:http://blog.sina.com.cn/s/blog_62a85b950101aw8x.html   老衲五木 :http://blog.sina.com.cn/s/blog_62a85b950102vrr4.html     老衲五木 :http://blog.csdn.net/zhzht19861011/article/details/46564699 朱工 第一步:在opt.h中 LWIP_TCP_KEEPALIVE  置1 /** * LWIP_TCP_KEEPAL

3.针对以往Android版本的各种保活技术回顾 Android P之前为了搞定客户的投诉:“为什么微信能收到消息而你们的IM却不能?”,为了解决这个“痛点”,广大的Android开发者们只能让各种黑科技轮番上场.各显神通,最典型的:比如曾今在手机QQ上的1像素保活(虽然QQ官方从没正面承认过).后台无限播放无声音的音频.应用互相拉活等,大家都耳熟能详. 下面就是即时通讯网整理过的各种典型保活需求和思路,可以回顾学习一下: <应用保活终极总结(一):Android6.0以下的双进程守护保活实践>

众所周知,IM 即时通讯是一项对即时性要求非常高的技术,而保障消息即时到达的首要条件就是链路存活.那么在复杂的网络环境和国内安卓手机被深度定制化的条件下,如何保障链路存活呢?本文详解了融云安卓端 SDK 在基于 TCP 协议实现链路保活方面的探索和经验. IM 系统整体框架 如上图所示,为了保障链路存活,一套成熟的 IM 系统一般会包含消息链路和推送链路两条长连接通道.当有新消息到达时,消息服务首先会判断消息链路是否存活,如果消息链路处于存活状态,消息优先从消息链路下发到客户端,否则会被路由到推

1.前言 对于广大Android开发者来说,Android O(即Android 8.0)还没玩热,Andriod P(即Andriod 9.0)又要来了.   下图上谷歌官方公布的Android P发布路线图:   Android P的最后一个开发者预览版(即DP5)已如期发布于2018年7月26日,根据上面这张发布路线图,相信Android P的正式版将很快到来.对于Andriod开发者来说,不管Andriod P有多少新功能或者特性(反正“我”用iPhone啊,哈哈),是否影响“我”撸的A