android即时通讯的简单介绍

一些Android开发中常用的第三方sdk

1、Share SDK官网 。免费集成注册短信验证码，友好的分享功能。

2、环信sdk。主要是集成，聊天相关sdk。

3、Ping++聚合支付。解决集成支付sdk。

4、友盟分享、统计。

5、百度统计

6、极光推送、个推推送

7、360加固服务

8、百度加固、统计服务

9、融云通讯---即时通讯

10、容联 云通讯

11、极速数据、阿凡达数据、聚合数据

开源即时通讯开发软件有哪些？

开源即时通讯软件最著名的当属Telegram。

Telegram（非正式简称TG）是跨平台的即时通信软件，其客户端是自由及开放源代码软件，但服务端是专有软件。用户可以相互交换加密与自毁消息、发送照片、视频等所有类型文件。官方提供手机版（Android、iOS、Windows Phone）、桌面版（Windows、macOS、Linux）和网页版等多种平台客户端；同时官方开放应用程序接口（API），因此拥有许多第三方的客户端可供选择。

2020年4月，全球活跃用户突破4亿人次。2021年1月，创办人公布每月活跃用户数目突破5亿。

Telegram的特色功能

秘密聊天

秘密聊天是专为那些比一般人希望获得更高安全性的人们所设计的功能。秘密聊天的内容全部都是以直接的端到端加密来传输。这代表只有你与秘密聊天的对方，才能读取到这些聊天消息 ， 没有任何其他人可以破解它们，包含Telegram团队本身。此外，秘密聊天消息也无法被转寄。而你也可借由设置在对方读取消息后的特定时间，自动销毁消息内容，这样一来不论你或者对方设备上的该消息就会永久消失。秘密和一般聊天之间的最后一个区别就是，秘密聊天的内容不会存储在云端服务器。你只能从秘密聊天双方的设备中访问这些消息。

机器人

在2015年6月，Telegram开放了机器人API，在2017年5月支持了付款功能。机器人是Telegram上以程序运作的账号，可以回复人类的指令、消息，视开发者设置而异。另一种功能称为内联机器人，支持快速发送相关的GIF动图、图片，其来自网络、YouTube视频、维基百科的文章，等等。

语音通话

2017年3月，Telegram 官方应用程序新增了语音通话功能。这采用了跟秘密聊天相同的端到端加密技术，在网络环境许可的情况下，会采用端对端传输，否则会经由最近的服务器连线。

即时查看

在2017年5月时推出的新功能，并同时引导为期一个月的竞赛，提供总额250,000美元的奖金，完善了对两千多个主要网站的支持。

频道

频道为单向传递消息予大量订阅用户的功能。可订阅频道的人数没有上限，但订阅者不能在频道中留言。另外，频道中的消息下方有已观看次数。

翻译平台

用户可以通过翻译平台（页面存档备份，存于互联网档案馆）安装官方未支持的语言及参与翻译。

飞秋

大名鼎鼎的oicq啊，pidgen（可能拼的不准）啊

盘点im即时通讯开发中Android后台保活方案

对于IM应用和消息推送服务的开发者来说，在Android机型上的后台保活是个相当头疼的问题。

老板一句：“为什么微信、QQ能收到消息，而你写的APP却不行？”，直接让人崩溃，话说老板你这APP要是整成微信、APP那么牛，直接进手机厂商白名单，还要程序员在这瞎忙活？

好了，抱怨归抱怨，活还得干，不然靠谁养活广大苦逼的程序员？

正因为Android系统版本的差异，也导致了各种保活黑科技的运行效果大相径庭，所以本文正好借此机会，盘点一下当前主流（截止2019年前）的保活黑科技在市面上各版本Android手机上的运行效果，希望能给大家提供一些客观的参考。

其实Android端APP搞保活的目的倒不是为了干什么见不得人的坏事（但不排除动机不纯的开发者），主要是像IM即时通讯应用和资讯类应用等需要搞后台消息推送、运动类应用需要在后台实时监测用户的运动数据等，因为现在越来越多的手机厂商为了省电策略考虑，基本上如果你的应用没有被加入白名单，一旦处于后台就会被系统限制甚至干掉，但使用APP的用户才不听你这些解释——反正“我”就要你的APP能如期正常运行，开发者也是不得已而为之。

以消息推送为例，当APP处于后台或关闭时，消息推送对于某些应用来说非常有用，比如：

    1）IM即时通讯聊天应用：聊天消息通知、音视频聊天呼叫等，典型代表有：微信、QQ、易信、米聊、钉钉、Whatsup、Line；

    2）新闻资讯应用：最新资讯通知等，典型代表有：网易新闻客户端、腾讯新闻客户端；

    3）SNS社交应用：转发/关注/赞等通知，典型代表有：微博、知乎；

    4）邮箱客户端：新邮件通知等，典型代表有：QQ邮箱客户端、Foxmail客户端、网易邮箱大师；

    5）金融支付应用：收款通知、转账通知等，典型代表有：支付宝、各大银行的手机银行等；

      .... ....

在上述的各种应用中，尤其对于用户接触最多、最平常的IM聊天应用或新闻资讯来说，保活和消息推送简直事关APP的“生死”，消息推送这种能力已经被越来越多的APP作为基础能力之一，因为移动互联网时代下，用户的“全时在线”能力非常诱人和强大，能随时随地即时地将各种重要信息推送给用户，无疑是非常有意义的。

题外话：实际上，对于后台消息推送能力，Android原版系统早就内置了系统级推送服务（跟iOS上的APNs服务是一个东西），它就是GCM服务（现在升级为FCM了），但众所周之的原因，谷哥的服务在国内都是用不了的（你懂的）——无奈啊！

主要黑科技方案有：

    1）监听广播：监听全局的静态广播，比如时间更新的广播、开机广播、解锁屏、网络状态、解锁加锁亮屏暗屏（3.1版本），高版本需要应用开机后运行一次才能监听这些系统广播，目前此方案失效。可以更换思路，做APP启动后的保活（监听广播启动保活的前台服务）；

    2）定时器、JobScheduler：假如应用被系统杀死，那么定时器则失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0时候有一定影响（可以在电源管理中给APP授权）；

    3）双进程（NDK方式Fork子进程）、双Service守护：高版本已失效，5.0起系统回收策略改成进程组。双Service方案也改成了应用被杀，任何后台Service无法正常状态运行；

    4）提高Service优先级：只能一定程度上缓解Service被立马回收。 即时通讯聊天软件app开发可以咨询蔚可云。

针对上述方案，具体的实现思路，通常是这样的：

    1）进程拉活：AIDL方式单进程、双进程方式保活Service（最极端的例子就是推送厂商的互相唤醒复活：极光、友盟、以及各大厂商的推送，同派系APP广播互相唤醒：比如今日头条系、阿里系）；

    2）降低oom_adj的值：常驻通知栏（可通过启动另外一个服务关闭Notification，不对oom_adj值有影响）、使用”1像素“的Activity覆盖在getWindow()的view上（据传某不可言说的IM大厂用过这个方案，虽然他们从未正面承认过）、循环播放无声音频（黑科技，7.0下杀不掉）；

    3）监听锁屏广播：使Activity始终保持前台；

    4）使用自定义锁屏界面：覆盖了系统锁屏界面；

    5）创建子进程：通过android:process属性来为Service创建一个进程；

    6）白名单：跳转到系统白名单界面让用户自己添加app进入白名单。

使用AIDL绑定方式新建2个Service优先级（防止服务同时被系统杀死）不一样的守护进程互相拉起对方，并在每一个守护进程的ServiceConnection的绑定回调里判断保活Service是否需要重新拉起和对守护线程进行重新绑定。

后台播放音乐这种保活方法，亲身经历过：

记得当时用的是某运动记步APP，它为了保活就是这么干的。之所以被我发现，是因为在我的Android手机上，每次打开这个APP居然总能莫名其妙听到若有若无的环境噪音样的声音，尤其安静的场所下更明显。我个人估计这个APP里用的保活音频文件，很可能就是程序员在简陋的条件下随手自已录制的，虽然也是不得以为之，但做法确实是有点粗糙。

总结一下，以上方案在当前主流手机上的运行效果

【1】双进程守护方案（基于onStartCommand() return START_STICKY）：

    1）原生5.0、5.1：原生任务栏滑动清理app，Service会被杀掉，然后被拉起，接着一直存活；

    2）金立F100(5.1)：一键清理直接杀掉整个app，包括双守护进程。不手动清理情况下，经测试能锁屏存活至少40分钟；

    3）华为畅享5x（6.0）：一键清理直接杀掉整个app，包括双守护进程。不手动清理下，锁屏只存活10s。结论：双进程守护方案失效；

    4）美图m8s(7.1.1)：一键清理直接杀掉整个app，包括双守护进程。不清理情况下，锁屏会有被杀过程（9分钟左右被杀），之后重新复活，之后不断被干掉然后又重新复活。结论：双守护进程可在后台不断拉起Service；

    5）原生7.0：任务栏清除APP后，Service存活。使用此方案后Service照样存活；

    6）LG V30+(7.1.2)：不加双进程守护的时候，一键清理无法杀掉服务。加了此方案之后也不能杀掉服务，锁屏存活（测试观察大于50分钟）；

    7）小米8(8.1)：一键清理直接干掉app并且包括双守护进程。不清理情况下，不加守护进程方案与加守护进程方案Service会一直存活，12分钟左右closed。结论：此方案没有起作用。

▲ 结论：除了华为此方案无效以及未更改底层的厂商不起作用外（START_STICKY字段就可以保持Service不被杀）。此方案可以与其他方案混合使用。

【2】监听锁屏广播打开1像素Activity（基于onStartCommand() return START_STICKY）：

    1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；

    2）华为畅享5x（6.0）：锁屏只存活4s。结论：方案失效；

    3）美图m8s(7.1.1)：同原生5.0；

    4）原生7.0：同美图m8s；

    5）LG V30+(7.1.2)：锁屏后情况跟不加情况一致，服务一致保持运行，结论：此方案不起作用；

    6）小米8(8.1)：关屏过2s之后app全部被干掉。结论：此方案没有起作用。

▲ 结论：此方案无效果。

【3】故意在后台播放无声的音乐（基于onStartCommand() return START_STICKY）：

    1）原生5.0、5.1：锁屏后3s服务被干掉然后重启（START_STICKY字段起作用）；

    2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务，锁屏8分钟后依然存活。结论：此方案适用；

    3）美图m8s(7.1.1)：同5.0；

    4）原生7.0：任务管理器中关闭APP后服务被干掉，大概过3s会重新复活（同仅START_STICKY字段模式）。结论：看不出此方案有没有其作用；

    5）LG V30+(7.1.2)：使用此方案前后效果一致。结论：此方案不起作用；

    6）小米8(8.1)：一键清理可以杀掉服务。锁屏后保活超过20分钟。

▲ 结论：成功对华为手机保活。小米8下也成功突破20分钟。

【4】使用JobScheduler唤醒Service（基于onStartCommand() return START_STICKY）：

    1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。结论：此方案起作用；

    2）华为畅享5x（6.0）：一键清理直接杀掉APP，过12s左右会自动重启服务，JobScheduler起作用；

    3）美图m8s(7.1.1)：一键清理直接杀掉APP，无法自动重启；

    4）原生7.0：同美图m8s(7.1.1)；

    5）小米8(8.1)：同美图m8s(7.1.1)。

▲ 结论：只对5.0，5.1、6.0起作用。

【5】混合使用的效果，并且在通知栏弹出通知：

    1）原生5.0、5.1：任务管理器中干掉APP，服务会在周期时间后重新启动。锁屏超过11分钟存活；

    2）华为畅享5x（6.0）：一键清理后服务依然存活，需要单独清理才可杀掉服务。结论：方案适用；

    3）美图m8s(7.1.1)：一键清理APP会被杀掉。正常情况下锁屏后服务依然存活；

    4）原生7.0：任务管理器中关闭APP后服务被干掉，过2s会重新复活；

    5）小米8(8.1)：一键清理可以杀掉服务，锁屏下后台保活时间超过38分钟；

    6）荣耀10（8.0）：一键清理杀掉服务，锁屏下后台保活时间超过23分钟。

IM即时通讯开发如何实现Android版智能心跳机制

IM即时通讯开发如何实现Android版智能心跳机制。

大体思路

a）延迟心跳测试法：这是测试结果准确的前提保障，我们认为长连接建立后连续三次成功的短心跳就可以很大程度的保证下一次心跳环境是正常的。

b）成功一次认定，失败连续累积认定：成功是绝对的，连续失败多次才可能是失败。

c）临界值避免：我们使用比计算出的心跳稍微小一点的值做为稳定心跳避免临界值。

d）动态调整：即使在一次完整的智能心跳计算过程中，我们没有找到最好的值，我们还有机会来进行校正。

方案需考虑到影响连接寿命的思素

在Android下，不管是GCM，还是微信，都是通过TCP长连接来进行消息收发的，TCP长连接存活，消息收发就及时，所以要对影响TCP连接寿命的因素进行研究。

1、NAT超时

大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断（NAT超时的更多描述见附录9.1）。NAT超时是影响TCP连接寿命的一个重要因素(尤其是国内)，所以客户端自动测算NAT超时时间，来动态调整心跳间隔，是一个重要的优化点。

2、DHCP的租期 （lease time）

目前测试发现安卓系统对DHCP的处理有Bug，DHCP租期到了不会主动续约并且会继续使用过期IP，这个问题会造成TCP长连接偶然的断连。（租期问题的具体描述见附录9.2）。

3、网络状态变化

手机网络和WIFI网络切换、网络断开和连上等情况有网络状态的变化，也会使长连接变为无效连接，需要监听响应的网络状态变化事件，重新建立Push长连接。

心跳范围选择

1、前后台区分处理：

为了保证微信收消息及时性的体验，当微信处于前台活跃状态时，使用固定心跳。微信进入后台（或者前台关屏）时，先用几次最小心跳维持长链接。然后进入后台自适应心跳计算。这样做的目的是尽量选择用户不活跃的时间段，来减少心跳计算可能产生的消息不及时收取影响。

2、后台自适应心跳选择区间：

可根据自身产品的特点选择合适的心跳范围。

自适应心跳算法量化描述

因为每个网络的NAT时间可能不一致。所以需要区分计算，数据网络按subType做关键字，WIFI按WIFI名做关键字。对稳定的网络，因为NAT老化时间的存在，在自适应计算态的时候，暂设计以下步骤在当前心跳区间逼近出最大可用的心跳。 即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

a）变量说明：

[MinHeart，MaxHeart]——心跳可选区间。

successHeart——当前成功心跳，初始为MinHeart

curHeart——当前心跳初始值为successHeart

heartStep——心跳增加步长

successStep——稳定期后的探测步长

经过该流程，会找到必然使心跳失败的curHeart（或者MaxHeart），为了保险起见，我们选择比前一个成功值稍微小一点的值作为后台稳定期的心跳间隔。

影响手机网络测试的因素太多，为了尽量保证测试结果的可靠性，我们使用延迟心跳测试法。在我们重新建立TCP连接后，先使用  短心跳连续成功三次，我们才认为网络相对稳定，可以使用curHeart进行一次心跳测试。图4-2显示了一次有效心跳测试过程。图4-3显示了在没有达到稳定网络环境时，我们会一直使用固定短心跳直到满足三次连续短心跳成功。

使用延迟心跳测试的好处是，可以剔除偶然失败，和网络变化较大的情况（如地铁），使测试结果相对可靠（五次延迟测试确定结论）。同时在网络波动较大的情况，使用短心跳，保证收取消息相对及时。

c）运行时的动态调整策略(已经按测算心跳稳定值后)

NAT超时值算出来后，在维持心跳的过程中的策略。

-  无网络、网络时好时坏、偶然失败、NAT超时变小：

在后台稳定期发生心跳发生失败后，我们使用延迟心跳测试法测试五次。如果有一次成功，则保持当前心跳值不变；如果五次测试全失败，重新计算合理心跳值。该过程如图4-4所示，有一点需要注意，每个新建的长连接需要先用短心跳成功维持3次后才用successHeart进行心跳。

NAT超时变大：

以周为周期，每周三将后台稳定态调至自适应计算态，使用心跳延迟法往后探测心跳间隔。

-  successHeart是NAT超时临界值：

因为我们现在选择的是一个比successHeart稍小的值作为稳定值，所以在计算过程中可以避开临界值。当运营商在我们后台稳定期将NAT超时调整为我们当前计算值，那么由于我们每周会去向下探索，所以下一周探测时也可以及时调整正确。

d）冗余Sync和心跳

在用户的一些主动操作以及联网状态改变时，增加冗余Sync和心跳，确保及时收到消息。

1、当用户点亮屏幕的时候，做一次心跳。

2、当微信切换到前台时，做一次Sync。

3、联网时重建信令TCP，做一次Sync。

可能存在的风险及预防措施

DHCP租期因素：

1、问题：根据目前的测试结果显示，安卓不续约到期的IP Bug，会导致TCP连接在不确定的时间点失效，从而会导致一次心跳失败。

2、预防：统计后台稳定期的心跳成功率，上报给后台。后台可以按地区分网络监控这个指标的波动，并且后台可以根据不同的波动，动态调整某区域特定网络下可选的心跳区间。

NAT超时介绍

因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换(Network Address Translation，NAT)。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。

Android 中使用MQTT(第一篇)

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议。它是一种发布/订阅，极其简单和轻量级的消息传递协议，专为受限设备和低带宽，高延迟或不可靠的网络而设计。它的设计思想是轻巧、开放、简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境。相对于XMPP，MQTT更加轻量级，并且占用的宽带低。

MQTT协议有以下特点：

那么问题来了？重连连接成功后重复接收到最后一条消息

MQTT推送消息订阅端重复接收问题。

（背景）订阅端断开的时候，发布端多次推送消息。

（现象）订阅端启动时，接收到最后一条推送消息有两次；即使Qos设置为2；依然是两次。

经排查是因为

MqttMessage的Retained设置为了true;

该值很多文章上只说了是 消息保留机制，若设置为true，mqtt服务器会保留每次发布的消息；较少提到 若订阅某主题的客户端重启，则会把此主题之前发布的消息重新推送到客户端。该值默认为false;去掉修改该值即可

那么问题来了？重连连接后手动那么多遗漏的消息，怎么选择只接收最新的一条消息呢？

MQTT推送消息订阅端重复接收问题。

（背景）订阅端断开的时候，发布端多次推送消息。

（现象）订阅端启动时，接收到msg1，msg2，msg3 （这三个消息都是同一个类型消息，只需要处理最新的msg3就好，不然界面会刷新三次）这个谁有什么好办法没呢？

GitHub地址：

mqtt的官方文档：

Github上有中文翻译：

在module的build.gradle文件中添加依赖

在 AndroidManifest.xml 添加限权

在 AndroidManifest.xml 注册Service （MyMqttService为自己写的服务，下文会讲到）