Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 171, comments - 13, trackbacks - 0, articles - 0

置顶随笔

     摘要: 本文的上篇我们讨论了在线实时消息的投递,如果接收方用户B不在线,系统是如何保证离线消息的可达性的呢?这就是本文要讨论的问题。  阅读全文

posted @ 2016-11-18 14:39 Jack Jiang 阅读(2785) | 评论 (0)编辑 收藏

     摘要: 虽然C10K问题已被妥善解决,但对于即时通讯应用(或其它网络编程方面)的开发者而言,研究C10K问题仍然价值巨大,因为技术的发展都是有规律和线索可循的,了解C10K问题及其解决思路,通过举一反三,或许可以为你以后面对类似问题提供更多可借鉴的思想和解决问题的实践思路。而这,也正是撰写本文的目的所在。  阅读全文

posted @ 2016-10-21 16:02 Jack Jiang 阅读(2419) | 评论 (0)编辑 收藏

     摘要: 本文将以新手的视角引导你阅读相关文章,以便为从零开发一个移动端IM做好方方面面的知识准备:包括但不限于网络编程基础、通信协议的选型、IM的架构设计等等。  阅读全文

posted @ 2016-08-29 17:42 Jack Jiang 阅读(2950) | 评论 (0)编辑 收藏

     摘要: 本文将简要介绍TeamTalk开源的过去和现在,为打算研究和采用TeamTalk的同行提供一定程度的参考。  阅读全文

posted @ 2016-08-09 17:25 Jack Jiang 阅读(2512) | 评论 (0)编辑 收藏

     摘要: 本文基于作者的实践以及相关资料的整理,总结了自已对Android进程和Service保活的理解,希望能为你的应用开发带来启发。  阅读全文

posted @ 2016-08-02 22:43 Jack Jiang 阅读(2248) | 评论 (0)编辑 收藏

     摘要: 本文将介绍如何在现有的技术基础上选择合适的方案开发一个“服务器推”(Comet技术)的应用,最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用, 开发 Comet 应用具有一定的挑战性。  阅读全文

posted @ 2016-07-28 11:07 Jack Jiang 阅读(1336) | 评论 (0)编辑 收藏

     摘要: 本文对服务器推送技术(SSE)进行了详细的介绍,包含浏览器端和服务器端的相应实现细节,为在实践中使用该技术提供了指南  阅读全文

posted @ 2016-07-22 18:03 Jack Jiang 阅读(992) | 评论 (0)编辑 收藏

     摘要: Web端即时通讯技术因受限于浏览器的设计限制,一直以来实现起来并不容易,主流的Web端即时通讯方案大致有4种:传统Ajax短轮询、Comet技术、WebSocket技术、SSE(Server-sent Events)。本文将简要介绍这4种技术的原理,并指出各自的异同点、优缺点等。  阅读全文

posted @ 2016-07-15 15:08 Jack Jiang 阅读(1550) | 评论 (2)编辑 收藏

     摘要: Web端的IM应用,由于浏览器的兼容性以及其固有的“客户端请求服务器处理并响应”的通信模型,造成了要在浏览器中实现一个兼容性较好的IM应用,其通信过程必然是诸多技术的组合,本文的目的就是要详细探讨这些技术并分析其原理和过程。   阅读全文

posted @ 2016-07-12 15:59 Jack Jiang 阅读(5235) | 评论 (0)编辑 收藏

     摘要: 文演示的是一个Android客户端程序,通过UDP协议与两个典型的NIO框架服务端(分别用MINA2和Netty4来实现),实现跨平台双向通信的完整Demo。  阅读全文

posted @ 2016-06-30 16:57 Jack Jiang 阅读(578) | 评论 (0)编辑 收藏

     摘要: 本文将演示一个iOS客户端程序,通过UDP协议与两个典型的NIO框架服务端(将分别用MINA2和Netty4来实现),实现跨平台双向通信的完整Demo。  阅读全文

posted @ 2016-06-28 22:11 Jack Jiang 阅读(1173) | 评论 (0)编辑 收藏

     摘要: 本文是《NIO框架入门》系列文章中的第2篇,将演示的是一个基于MINA2的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。  阅读全文

posted @ 2016-06-24 14:38 Jack Jiang 阅读(560) | 评论 (0)编辑 收藏

     摘要: 本文将演示的是一个基于Netty4的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。实际上,Netty4的UDP例子非常难找,官方的代码演示里只有一个简单的UDP广播例子,不足以用于演示Netty4的UDP通信最佳实践。  阅读全文

posted @ 2016-06-20 14:48 Jack Jiang 阅读(1148) | 评论 (0)编辑 收藏

     摘要: MobileIMSDK是一套专为移动端开发的原创即时通讯框架:超轻量级、高度提炼,lib包50KB以内;完全基于UDP协议实现;客户端支持iOS、Android、标准Java平台;可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。  阅读全文

posted @ 2015-12-14 15:18 Jack Jiang 阅读(2600) | 评论 (0)编辑 收藏

     摘要: MobileIMSDK是专为移动端开发的原创即时通讯开源框架:超轻量级、高度提炼,lib包50KB以内;完全基于UDP协议实现;客户端支持iOS、Android、标准Java平台;可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。  阅读全文

posted @ 2015-12-01 16:06 Jack Jiang 阅读(3092) | 评论 (2)编辑 收藏

2020年3月25日

     摘要: 本文原文由微信客户端高级工程师方秋枋原创发表于WeMobileDev公众号,收录时有修订和加工,感谢作者的无私分享。1、引言作为一个重要业务,微信支付在客户端上面临着各种问题。其中最核心问题就是分平台实现导致的问题:1)iOS 和安卓实现不一致:容易出 Bug、通过沟通保证不了质量;2)扩展性差且无法快速响应业务需求:需求变更迭代周期长、数据上报不全面;3)质量保障体系不完善:缺少业务及设计知识沉...  阅读全文

posted @ 2020-03-25 17:00 Jack Jiang 阅读(123) | 评论 (0)编辑 收藏

2020年3月19日

     摘要: 1、引言很多人一想到IM应用开发,第一印象就是“长连接”、“socket”、“保活”、“协议”这些关键词,没错,这些确实是IM开发中肯定会涉及的技术范畴。但,当你真正开始编写第一行代码时,最现实的问题实际上是“聊天消息ID该怎么生成?”这个看似微不足道的小事情。说它看似微不足道,...  阅读全文

posted @ 2020-03-19 17:34 Jack Jiang 阅读(155) | 评论 (0)编辑 收藏

2020年3月13日

本文原文由作者Amazing10原创发布于公众号业余码农,收录时有改动,感谢原作者的技术分享。

1、引言

某天中午,吃完午饭,摊在自己的躺椅上,想趁吃饱喝足的午后时间静静享受独自的静谧。

 
 

干点什么好呢?于是单手操作鼠标打开了一个陌生而隐秘的网站。正开着某个视频起劲。。。

突然浏览器弹出了一个提示:

请使用微信扫码登录账号,继续观看

这...

 
 

但是由于强烈的好奇驱使,迫于无奈,只好选择登录再继续观看。于是熟练的掏出手机,打开微信扫一扫对准上面的二维码,只听见 “叮” 的一声,网页上的二维码放佛活过来了,直接刷新出了本尊的微信头像,同时手机上也弹出登录的提醒。

 
 

心中略微惊叹,但没来得及多想。忙点击手机界面中登录按钮。此时网页刷新,恢复了正常,表示可以继续观看。

上网冲浪的时间总是过得很快,很快就有些疲倦。于是闭上眼睛,脑海中却浮现出了刚刚微信扫描二维码,然后登录网页的场景,心中再次惊叹,并开始思考起其中的原理来。。。

言归正传,本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。

推荐阅读:另一篇同类文章《IM的扫码登录功能如何实现?一文搞懂主流的扫码登录技术原理》也值得一读。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-2941-1-1.html

2、IM开发干货系列文章

本文是系列文章中的第23篇,总目录如下:

IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

IM消息送达保证机制实现(二):保证离线消息的可靠投递

如何保证IM实时消息的“时序性”与“一致性”?

IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

IM群聊消息如此复杂,如何保证不丢不重?

一种Android端IM智能心跳算法的设计与实现探讨(含样例代码)

移动端IM登录时拉取数据如何作到省流量?

通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

浅谈移动端IM的多点登录和消息漫游原理

IM开发基础知识补课(一):正确理解前置HTTP SSO单点登录接口的原理

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

IM群聊消息的已读回执功能该怎么实现?

IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)?

IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

一个低成本确保IM消息时序的方法探讨

IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

IM里“附近的人”功能实现原理是什么?如何高效率地实现它?

IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路

IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质

IM的扫码登功能如何实现?一文搞懂主流应用的扫码登录技术原理

IM要做手机扫码登陆?先看看微信的扫码登录功能技术原理》(本文)

3、原理解析

微信扫码登录现在在日常生活中已经是常见不能再常见的场景之一了,但是要知道微信首次公开这项功能时,却是惊艳众人。移动端与PC端以这样一种巧妙的方式链接在了一起,的确是让人惊叹。

以下是一个典型的微信扫码登录全过程: 

本来想在Web版微信上截图,但扫码登陆后出现了下面的提示(貌似很多人都碰到过): 

好吧,这很微信,反正就是不想让你好好用,用户爱咋咋滴。。。

如上图所示,操作过程如下:

1)第一步:电脑上打开PC端(出现2维码);

2)第二步:拿出手机,扫码2维码;

3)第三步:PC端显示扫码成功;

4)第四步:手机端“确认”登录;

5)第五步:成功登陆PC端。

上述实际操作过程,用户体验相当顺滑,也难怪刚出来那会,能惊艳到很多人。

那么,对于上述操作过程的技术实现原理是什么样的呢?

想起来之前听过的前后端的概念,知道账户的数据信息一般都是放在服务器上,前端负责向后端 “讨要数据” 并显示,后端则是对前端的 “讨要” 做出反应。

这样一来,猜测微信登录的过程可能就是:

1)网页前端向微信后台请求账号数据;

2)微信后台接受网页前端的请求,然后将他的账号数据返回;

3)网页前端接收到了数据后,在浏览器里进行显示。

于是,手脚麻利的画了个示意图:

当我正准备沾沾自喜的时候,突然看到桌面上的手机。咦,如果就只是这么个过程,那手机的作用是啥。于是才开始意识到,问题没这么简单。

好吧,我们城要再深入一点探秘微信扫码登录的过程。

4、过程分析

为了更深入的分析整个过程,我们可以去看看微信网页版,地址是:https://wx.qq.com/

 

笔者看着网页中硕大的二维码陷入了沉思——这个二维码跟手机账号有没有什么对应关系呢?如果没有,那它又是怎么生成的呢?

思考间,于是打开了浏览器的开发者工具。

在网络监控一览找到了这幅二维码,与之对应的链接是:

https://login.weixin.qq.com/qrcode/gaO8cOQweA==

如下图所示:

然后习惯性地,尝试多次刷新页面,发现二维码不断发生变化,链接也不断更改:

https://login.weixin.qq.com/qrcode/AencxgKNFQ==

https://login.weixin.qq.com/qrcode/YcD7f_DxvA==

https://login.weixin.qq.com/qrcode/QblN8lCn2g==

似乎发现了些东西:二维码不断变化,其对应的链接尾的代码也相应变化,并且是随机性的变化。

这也就是说,每一次页面刷新都会随机且唯一地生成一个二维码。这或许可以与手机登录的过程联系起来。

似乎开始明白了,于是再次拿起手机,熟练的使用微信扫描了此时的二维码。

“叮” 的一声,网页上的二维码顿时变成了我帅气的微信头像。这个时候,我才突然意识到,是扫码之后网页才与他的微信账号建立起了联系。

如下图所示: 

也就是说:

1)没有扫码之前,页面上的二维码只是随机生成的且与用户无关的码;

2)而当用户扫码之后,二维码便与用户帐号绑定在了一起。

原来手机扫码的用处是这样!

此时注意到,手机微信上弹出了『微信登录确认』的提醒。这个时候谨慎地点击了下方的登录按钮。

如下图所示: 

随着平滑的动画一闪而过,网页上已经显示出了我的微信账号信息,显示微信账号已经登录。再一次体验这个过程,心中开始思索手机微信在登录过程中所起到的具体作用。

首先需要明白几个过程:

1)进入网页登陆界面,随机生成一个二维码;

2)通过手机扫描二维码,将微信账号与二维码绑定;

3)在手机微信点击登录按钮,授权网页登录微信账号;

4)网页获得的账号信息,将数据显示。

5、原理解释

回顾上述过程,结合最开始的原理猜测,开始思索整个环节,是哪里理解的不对。。。

1)网页的二维码到底从何而来?

2)是谁向微信后台请求了账号数据?

实际上:不同的网站可能都需要通过微信后台进行数据的获取,那么每一个网站必然也存在它的后台来给微信后台发送请求。

这样一来,整个过程就能解释得通了:

1)网站页面刷新,网页后台向微信后台请求授权登录;

2)微信后台返回登录所需二维码;

3)用户通过手机扫描二维码,并在手机上授权登录后,微信后台告知网页后台已授权;

4)网页后台向微信后台请求微信账号数据;

5)微信后台返回账号数据;

6)网页后台接收数据并通过浏览器显示;

6、技术剖析

正如上节所述,想清楚了整个过程后,我们应该对整个过程的技术实现进行进一步的探究。

在微信开发官方文档中,我找到了第三方网站应用微信登录开发指南:

https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html

我将整个过程梳理了一遍,画出了这个图: 

如上图所示,整个技术实现如下。

(1)二维码的获得:

  • 1)用户打开网站后,网站后台根据微信OAuth2.0协议向微信开发平台请求授权登录,并传递事先在微信开发平台中审核通过的AppID和AppSecrect等参数;
  • 2)微信开发平台对AppID等参数进行验证,并向网站后台返回二维码;
  • 3)网站后台将二维码传送至网站前端进行显示。

(2)微信客户端授权登录:

  • 1)用户使用微信客户端扫描二维码并授权登录;
  • 2)微信客户端将二维码特定的uid与微信账号绑定,传送至微信开发平台;
  • 3)微信开发平台验证绑定数据,调用网站后台的回调接口,发送授权临时票据code;

(3)网站后台请求数据:

  • 1)网站后台接收到code,表明微信开发平台同意数据请求;
  • 2)网站后台根据code参数,再加上AppID和AppSecret请求微信开发平台换取access_token;
  • 3)微信开发平台验证参数,并返回access_token;
  • 4)网站后台收到access_token后即可进行参数分析获得用户账号数据。

在上述过程中,有几个参数值得解释一下(来源官方文档):

  • 1)AppID:应用唯一标识,在微信开放平台提交应用审核通过后获得;
  • 2)AppSecret:应用密钥,在微信开放平台提交应用审核通过后获得;
  • 3)code:授权临时票据,第三方通过code进行获取access_token的时候需要用到,code的超时时间为10分钟,一个code只能成功换取一次access_token即失效。code的临时性和一次性保障了微信授权登录的安全性。

整个过程从网站后台向微信开发平台请求授权登录开始,最终目的是为了获得access_token:

access_token:用户授权第三方应用发起接口调用的凭证

在获得了access_token后就可以解析用户的一些基本信息,包括头像、用户名、性别、城市等。这样一来,整个微信扫描登录的过程就完成了。

7、写在最后

研究到这,终于大体上对微信扫码登录的整个过程有了清晰的认知。看起来似乎也不难,开发者只需要在网页后端做好对微信公众平台的接口调用即可实现扫码登录。

伸了伸懒腰,忽然又想到在整个过程中还需要考虑超时的问题。比如二维码超时未扫描、二维码扫描后超时授权、获得access_token后超时等等问题。

我发现一个简单的功能实现起来还是需要考虑许多细节,真的是纸上得来终觉浅呀。于是我下定决心,下次得少上网冲浪了,花点时间搭个服务器先把微信扫码登录过程实现看看。

不过,还得先去在微信开放平台注册开发者帐号,并拥有一个已审核通过的网站应用,并获得相应的AppID和AppSecret才行。

想了想,还是让我先趟一会儿吧。。。

 

附录:更多IM开发相关文章

[1] IM开发热门文章:

新手入门一篇就够:从零开发移动端IM

移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

腾讯技术分享:社交网络图片的带宽压缩技术演进之路

小白必读:闲话HTTP短连接中的Session和Token

移动端IM开发需要面对的技术问题

开发IM是自己设计协议用字节流好还是字符流好?

请问有人知道语音留言聊天的主流实现方式吗?

通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

微信对网络影响的技术试验及分析(论文全文)

即时通讯系统的原理、技术和应用(技术论文)

开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀

QQ音乐团队分享:Android中的图片压缩技术详解(上篇)

QQ音乐团队分享:Android中的图片压缩技术详解(下篇)

腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)

腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

字符编码那点事:快速理解ASCII、Unicode、GBK和UTF-8

全面掌握移动端主流图片格式的特点、性能、调优等

子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)

融云技术分享:解密融云IM产品的聊天消息ID生成策略

适合新手:从零开发一个IM服务端(基于Netty,有完整源码)

拿起键盘就是干:跟我一起徒手开发一套分布式IM系统

>> 更多同类文章 …… 

[2] 有关WEB端即时通讯开发:

新手入门贴:史上最全Web端即时通讯技术原理详解

Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

SSE技术详解:一种全新的HTML5服务器推送事件技术

Comet技术详解:基于HTTP长连接的Web端实时通信技术

新手快速入门:WebSocket简明教程

WebSocket详解(一):初步认识WebSocket技术

WebSocket详解(二):技术原理、代码演示和应用案例

WebSocket详解(三):深入WebSocket通信协议细节

WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)

WebSocket详解(五):刨根问底HTTP与WebSocket的关系(下篇)

WebSocket详解(六):刨根问底WebSocket与Socket的关系

socket.io实现消息推送的一点实践及思路

LinkedIn的Web端即时通讯实践:实现单机几十万条长连接

Web端即时通讯技术的发展与WebSocket、Socket.io的技术实践

Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

开源框架Pomelo实践:搭建Web端高性能分布式IM聊天服务器

使用WebSocket和SSE技术实现Web端消息推送

详解Web端通信方式的演进:从Ajax、JSONP 到 SSE、Websocket

MobileIMSDK-Web的网络层框架为何使用的是Socket.io而不是Netty?

理论联系实际:从零理解WebSocket的通信原理、协议格式、安全性

微信小程序中如何使用WebSocket实现长连接(含完整源码)

八问WebSocket协议:为你快速解答WebSocket热门疑问

快速了解Electron:新一代基于Web的跨平台桌面技术

一文读懂前端技术演进:盘点Web前端20年的技术变迁史

Web端即时通讯基础知识补课:一文搞懂跨域的所有问题!

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2941-1-1.html

posted @ 2020-03-13 17:15 Jack Jiang 阅读(159) | 评论 (0)编辑 收藏

2020年3月3日

     摘要: 一、引言对于后端程序员来说,127.0.0.1和0.0.0.0这两个IP地址再熟悉不过了,看起来好像就那么回事,但真正较起真来,这两个IP地址到底有什么作用以及到底有什么不同?貌似谁可以轻松回答,但张嘴却又不知从何说起。。。(这要是面视,估计真会被这搞砸...)本文将系统地总结127.0.0.1和0.0.0.0这两个IP地址的作用,以及它们之间的区别,希望能为你解惑。  * 推...  阅读全文

posted @ 2020-03-03 15:53 Jack Jiang 阅读(341) | 评论 (0)编辑 收藏

2020年2月26日

     摘要: 1、引言上个月在知乎上发表的由“袁辉辉”分享的关于TIM进程永生方面的文章(即时通讯网重新整理后的标题是:《史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术》),短时间内受到大量关注,可惜在短短的几十个小时后,就在一股神秘力量的干预下被强行删除了。。。 ▲ 该文在知乎上从发布到删除的时间历程(中间省略了N条读者的评论)在《史上最强And...  阅读全文

posted @ 2020-02-26 22:44 Jack Jiang 阅读(185) | 评论 (0)编辑 收藏

2020年2月19日

本文由马蜂窝技术团队电商交易基础平台研发工程师"Anti Walker"原创分享。

一、引言

即时通讯(IM)功能对于电商平台来说非常重要,特别是旅游电商。

从商品复杂性来看,一个旅游商品可能会包括用户在未来一段时间的衣、食、住、行等方方面面。从消费金额来看,往往单次消费额度较大。对目的地的陌生、在行程中可能的问题,这些因素使用户在购买前、中、后都存在和商家沟通的强烈需求。可以说,一个好用的 IM 可以在一定程度上对企业电商业务的 GMV 起到促进作用。

本文我们将结合马蜂窝旅游电商IM系统的发展历程,单独介绍基于Go重构分布式IM系统过程中的实践和总结(本文相当于《从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路》一文的进阶篇),希望可以给有相似问题的朋友一些借鉴。

另外:如果你对Go在高并发系统中的应用感兴趣,即时通讯网的以下两篇也值得一读:

Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)

系列文章:

从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路

从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结

从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践》(* 本文

关于马蜂窝旅游网: 

马蜂窝旅游网是中国领先的自由行服务平台,由陈罡和吕刚创立于2006年,从2010年正式开始公司化运营。马蜂窝的景点、餐饮、酒店等点评信息均来自上亿用户的真实分享,每年帮助过亿的旅行者制定自由行方案。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

(本文同步发布于:http://www.52im.net/thread-2909-1-1.html

二、相关文章

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

以微博类应用场景为例,总结海量社交系统的架构设计步骤

一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)

阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

三、技术背景和问题

与广义上的即时通讯不同,电商各业务线有其特有业务逻辑,如客服聊天系统的客人分配逻辑、敏感词检测逻辑等,这些往往要耦合进通信流程中。随着接入业务线越来越多,即时通讯服务冗余度会越来越高。同时整个消息链路追溯复杂,服务稳定性很受业务逻辑的影响。

之前我们 IM 应用中的消息推送主要基于轮询技术,消息轮询模块的长连接请求是通过 php-fpm 挂载在阻塞队列上实现。当请求量较大时,如果不能及时释放 php-fpm 进程,对服务器的性能消耗很大。

为了解决这个问题,我们曾用 OpenResty+Lua 的方式进行改造,利用 Lua 协程的方式将整体的 polling 的能力从 PHP 转交到 Lua 处理,释放一部 PHP 的压力。这种方式虽然能提升一部分性能,但 PHP-Lua 的混合异构模式,使系统在使用、升级、调试和维护上都很麻烦,通用性也较差,很多业务场景下还是要依赖 PHP 接口,优化效果并不明显。

为了解决以上问题,我们决定结合电商 IM 的特定背景对 IM 服务进行重构,核心是实现业务逻辑和即时通讯服务的分离。

更多有关马蜂窝旅游网的IM系统架构的演进过程,请详读:《从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路》一文,在此不再赘述。

四、基于Go的双层分布式IM架构

4.1、实现目标

1)业务解耦:

将业务逻辑与通信流程剥离,使 IM 服务架构更加清晰,实现与电商 IM 业务逻辑的完全分离,保证服务稳定性。

2)接入方式灵活:

之前新业务接入时,需要在业务服务器上配置 OpenResty 环境及 Lua 协程代码,非常不便,IM 服务的通用性也很差。考虑到现有业务的实际情况,我们希望 IM 系统可以提供 HTTP 和 WebSocket 两种接入方式,供业务方根据不同的场景来灵活使用。

比如已经接入且运行良好的电商定制化团队的待办系统、定制游抢单系统、投诉系统等下行相关的系统等,这些业务没有明显的高并发需求,可以通过 HTTP 方式迅速接入,不需要熟悉稍显复杂的 WebSocket 协议,进而降低不必要的研发成本。

3)架构可扩展:

为了应对业务的持续增长给系统性能带来的挑战,我们考虑用分布式架构来设计即时通讯服务,使系统具有持续扩展及提升的能力。

4.2、语言选择

目前,马蜂窝技术体系主要包括 PHP,Java,Golang,技术栈比较丰富,使业务做选型时可以根据问题场景选择更合适的工具和语言。

结合 IM 具体应用场景,我们选择 Go 的原因包括:

  • 1)运行性能:在性能上,尤其是针对网络通信等 IO 密集型应用场景。Go 系统的性能更接近 C/C++;
  • 2)开发效率:Go 使用起来简单,代码编写效率高,上手也很快,尤其是对于有一定 C++ 基础的开发者,一周就能上手写代码了。

4.3、架构设计

整体架构图如下: 

名词解释:

  • 1)客户:一般指购买商品的用户;
  • 2)商家:提供服务的供应商,商家会有客服人员,提供给客户一个在线咨询的作用;
  • 3)分发模块:即 Dispatcher,提供消息分发的给指定的工作模块的桥接作用;
  • 4)工作模块:即 Worker 服务器,用来提供 WebSocket 服务,是真正工作的一个模块。

架构分层:

  • 1)展示层:提供 HTTP 和 WebSocket 两种接入方式;
  • 2)业务层:负责初始化消息线和业务逻辑处理。如果客户端以 HTTP 方式接入,会以 JSON 格式把消息发送给业务服务器进行消息解码、客服分配、敏感词过滤,然后下发到消息分发模块准备下一步的转换;通过 WebSocket 接入的业务则不需要消息分发,直接以 WebSocket 方式发送至消息处理模块中;
  • 3)服务层:由消息分发和消息处理这两层组成,分别以分布式的方式部署多个 Dispatcher 和 Worker 节点。Dispatcher 负责检索出接收者所在的服务器位置,将消息以 RPC 的方式发送到合适的 Worker 上,再由消息处理模块通过 WebSocket 把消息推送给客户端;
  • 4)数据层:Redis 集群,记录用户身份、连接信息、客户端平台(移动端、网页端、桌面端)等组成的唯一 Key。

4.4、服务流程

步骤一:

如上图右侧所示:

用户客户端与消息处理模块建立 WebSocket 长连接;

通过负载均衡算法,使客户端连接到合适的服务器(消息处理模块的某个 Worker);

连接成功后,记录用户连接信息,包括用户角色(客人或商家)、客户端平台(移动端、网页端、桌面端)等组成唯一 Key,记录到 Redis 集群。

步骤二:

如图左侧所示,当购买商品的用户要给管家发消息的时候,先通过 HTTP 请求把消息发给业务服务器,业务服务端对消息进行业务逻辑处理。

1)该步骤本身是一个 HTTP 请求,所以可以接入各种不同开发语言的客户端。通过 JSON 格式把消息发送给业务服务器,业务服务器先把消息解码,然后拿到这个用户要发送给哪个商家的客服的。

2)如果这个购买者之前没有聊过天,则在业务服务器逻辑里需要有一个分配客服的过程,即建立购买者和商家的客服之间的连接关系。拿到这个客服的 ID,用来做业务消息下发;如果之前已经聊过天,则略过此环节。

3)在业务服务器,消息会异步入数据库。保证消息不会丢失。

步骤三:

业务服务端以 HTTP 请求把消息发送到消息分发模块。这里分发模块的作用是进行中转,最终使服务端的消息下发给指定的商家。

步骤四:

基于 Redis 集群中的用户连接信息,消息分发模块将消息转发到目标用户连接的 WebSocket 服务器(消息处理模块中的某一个 Worker)

1)分发模块通过 RPC 方式把消息转发到目标用户连接的 Worker,RPC 的方式性能更快,而且传输的数据也少,从而节约了服务器的成本。

2)消息透传 Worker 的时候,多种策略保障消息一定会下发到 Worker。

步骤五:

消息处理模块将消息通过 WebSocket 协议推送到客户端。

1)在投递的时候,接收者要有一个 ACK(应答) 信息来回馈给 Worker 服务器,告诉 Worker 服务器,下发的消息接收者已经收到了。

2)如果接收者没有发送这个 ACK 来告诉 Worker 服务器,Worker 服务器会在一定的时间内来重新把这个信息发送给消息接收者。

3)如果投递的信息已经发送给客户端,客户端也收到了,但是因为网络抖动,没有把 ACK 信息发送给服务器,那服务器会重复投递给客户端,这时候客户端就通过投递过来的消息 ID 来去重展示。

以上步骤的数据流转大致如图所示:

4.5、系统完整性设计

4.5.1 可靠性

(1)消息不丢失:

为了避免消息丢失,我们设置了超时重传机制。服务端会在推送给客户端消息后,等待客户端的 ACK,如果客户端没有返回 ACK,服务端会尝试多次推送。

目前默认 18s 为超时时间,重传 3 次不成功,断开连接,重新连接服务器。重新连接后,采用拉取历史消息的机制来保证消息完整。

(2)多端消息同步:

客户端现有 PC 浏览器、Windows 客户端、H5、iOS/Android,系统允许用户多端同时在线,且同一端可以多个状态,这就需要保证多端、多用户、多状态的消息是同步的。

我们用到了 Redis 的 Hash 存储,将用户信息、唯一连接对应值 、连接标识、客户端 IP、服务器标识、角色、渠道等记录下来,这样通过 key(uid) 就能找到一个用户在多个端的连接,通过 key+field 能定位到一条连接。

4.5.2 可用性

上文我们已经说过,因为是双层设计,就涉及到两个 Server 间的通信,同进程内通信用 Channel,非同进程用消息队列或者 RPC。综合性能和对服务器资源利用,我们最终选择 RPC 的方式进行 Server 间通信。

在对基于 Go 的 RPC 进行选行时,我们比较了以下比较主流的技术方案: 

1)Go STDRPC:Go 标准库的 RPC,性能最优,但是没有治理;

2)RPCX:性能优势 2*GRPC + 服务治理;

3)GRPC:跨语言,但性能没有 RPCX 好;

4)TarsGo:跨语言,性能 5*GRPC,缺点是框架较大,整合起来费劲;

5)Dubbo-Go:性能稍逊一筹, 比较适合 Go 和 Java 间通信场景使用。

最后我们选择了 RPCX,因为性能也很好,也有服务的治理。

两个进程之间同样需要通信,这里用到的是 ETCD 实现服务注册发现机制。

当我们新增一个 Worker,如果没有注册中心,就要用到配置文件来管理这些配置信息,这挺麻烦的。而且你新增一个后,需要分发模块立刻发现,不能有延迟。

如果有新的服务,分发模块希望能快速感知到新的服务。利用 Key 的续租机制,如果在一定时间内,没有监听到 Key 有续租动作,则认为这个服务已经挂掉,就会把该服务摘除。

在进行注册中心的选型时,我们主要调研了 ETCDZooKeeperConsul

三者的压测结果参考如下: 

 

结果显示,ETCD 的性能是最好的。另外,ETCD 背靠阿里巴巴,而且属于 Go 生态,我们公司内部的 K8S 集群也在使用。

综合考量后,我们选择使用 ETCD 作为服务注册和发现组件。并且我们使用的是 ETCD 的集群模式,如果一台服务器出现故障,集群其他的服务器仍能正常提供服务。

小结一下:通过保证服务和进程间的正常通讯,及 ETCD 集群模式的设计,保证了 IM 服务整体具有极高的可用性。

4.5.3 扩展性

消息分发模块和消息处理模块都能进行水平扩展。当整体服务负载高时,可以通过增加节点来分担压力,保证消息即时性和服务稳定性。

4.5.4 安全性

处于安全性考虑,我们设置了黑名单机制,可以对单一 uid 或者 ip 进行限制。比如在同一个 uid 下,如果一段时间内建立的连接次数超过设定的阈值,则认为这个 uid 可能存在风险,暂停服务。如果暂停服务期间该 uid 继续发送请求,则限制服务的时间相应延长。

4.6、性能优化和踩过的坑

4.6.1 性能优化

1)JSON 编解码:

开始我们使用官方的 JSON 编解码工具,但由于对性能方面的追求,改为使用滴滴开源的 Json-iterator,使在兼容原生 Golang 的 JSON 编解码工具的同时,效率上有比较明显的提升。

以下是压测对比的参考图: 

2)time.After:

在压测的时候,我们发现内存占用很高,于是使用 Go Tool PProf 分析 Golang 函数内存申请情况,发现有不断创建 time.After 定时器的问题,定位到是心跳协程里面。

原来代码如下: 

优化后的代码为:

优化点在于 for 循环里不要使用 select + time.After 的组合。

3)Map 的使用:

在保存连接信息的时候会用到 Map。因为之前做 TCP Socket 的项目的时候就遇到过一个坑,即 Map 在协程下是不安全的。当多个协程同时对一个 Map 进行读写时,会抛出致命错误:fetal error:concurrent map read and map write,有了这个经验后,我们这里用的是 sync.Map

4.6.2 踩坑经验

1)协程异常:

基于对开发成本和服务稳定性等问题的考虑,我们的 WebSocket 服务基于 Gorilla/WebSocket 框架开发。其中遇到一个问题,就是当读协程发生异常退出时,写协程并没有感知到,结果就是导致读协程已经退出但是写协程还在运行,直到触发异常之后才退出。

这样虽然从表面上看不影响业务逻辑,但是浪费后端资源。在编码时应该注意要在读协程退出后主动通知写协程,这样一个小的优化可以这在高并发下能节省很多资源。

2)心跳设计:

举个例子:之前我们在闲时心跳功能的开发中走了一些弯路。最初在服务器端的心跳发送是定时心跳,但后来在实际业务场景中使用时发现,设计成服务器读空闲时心跳更好。因为用户都在聊天呢,发一个心跳帧,浪费感情也浪费带宽资源。

这时候,建议大家在业务开发过程中如果代码写不下去就暂时不要写了,先结合业务需求用文字梳理下逻辑,可能会发现之后再进行会更顺利。

3)每天分割日志: 

日志模块在起初调研的时候基于性能考虑,确定使用 Uber 开源的 ZAP 库,而且满足业务日志记录的要求。日志库选型很重要,选不好也是影响系统性能和稳定性的。

ZAP 的优点包括:

1)显示代码行号这个需求,ZAP 支持而 Logrus 不支持,这个属于提效的。行号展示对于定位问题很重要;

2)ZAP 相对于 Logrus 更为高效,体现在写 JSON 格式日志时,没有使用反射,而是用内建的 json encoder,通过明确的类型调用,直接拼接字符串,最小化性能开销。

小坑:每天写一个日志文件的功能,目前 ZAP 不支持,需要自己写代码支持,或者请求系统部支持。

五、性能表现

压测 1:

上线生产环境并和业务方对接以及压测,目前定制业务已接通整个流程,写了一个 Client。模拟定期发心跳帧,然后利用 Docker 环境。开启了 50 个容器,每个容器模拟并发起 2 万个连接。这样就是百万连接打到单机的 Server 上。单机内存占用 30G 左右。

压测 2:

同时并发 3000、4000、5000 连接,以及调整发送频率,分别对应上行:60万、80 万、100 万、200 万, 一个 6k 左右的日志结构体。

其中有一半是心跳包 另一半是日志结构体。在不同的压力下的下行延迟数据如下: 

结论:

随着上行的并发变大,延迟控制在 24-66 毫秒之间。所以对于下行业务属于轻微延迟。另外针对 60 万 5k 上行的同时,用另一个脚本模拟开启 50 个协程并发下行 1k 的数据体,延迟是比没有并发下行的时候是有所提高的,延迟提高了 40ms 左右。

六、本文小结

基于 Go 重构的 IM 服务在 WebSocket 的基础上,将业务层设计为配有消息分发模块和消息处理模块的双层架构模式,使业务逻辑的处理前置,保证了即时通讯服务的纯粹性和稳定性;同时消息分发模块的 HTTP 服务方便多种编程语言快速对接,使各业务线能迅速接入即时通讯服务。

最后,我还想为 Go 摇旗呐喊一下。很多人都知道马蜂窝技术体系主要是基于 PHP,有一些核心业务也在向 Java 迁移。与此同时,Go 也在越来越多的项目中发挥作用。现在,云原生理念已经逐渐成为主流趋势之一,我们可以看到在很多构建云原生应用所需要的核心项目中,Go 都是主要的开发语言,比如 Kubernetes,Docker,Istio,ETCD,Prometheus 等,包括第三代开源分布式数据库 TiDB。

所以我们可以把 Go 称为云原生时代的母语。「云原生时代,是开发者最好的时代」,在这股浪潮下,我们越早走进 Go,就可能越早在这个新时代抢占关键赛道。希望更多小伙伴和我们一起,加入到 Go 的开发和学习阵营中来,拓宽自己的技能图谱,拥抱云原生。

附录:更多IM架构设计方面的文章

[1] 有关IM架构设计的文章:

浅谈IM系统的架构设计

简述移动端IM开发的那些坑:架构设计、通信协议和客户端

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

一套原创分布式即时通讯(IM)系统理论架构方案

从零到卓越:京东客服即时通讯系统的技术架构演进历程

蘑菇街即时通讯/IM服务器开发之架构选择

腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT

微信后台基于时间序的海量数据冷热分级架构设计实践

微信技术总监谈架构:微信之道——大道至简(演讲全文)

如何解读《微信技术总监谈架构:微信之道——大道至简》

快速裂变:见证微信强大后台架构从0到1的演进历程(一)

17年的实践:腾讯海量产品的技术方法论

移动端IM中大规模群消息的推送如何保证效率、实时性?

现代IM系统中聊天消息的同步和存储方案探讨

IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

WhatsApp技术实践分享:32人工程团队创造的技术神话

微信朋友圈千亿访问量背后的技术挑战和实践总结

王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等

IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

以微博类应用场景为例,总结海量社交系统的架构设计步骤

快速理解高性能HTTP服务端的负载均衡技术原理

子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进

社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节

社交软件红包技术解密(四):微信红包系统是如何应对高并发的

社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

社交软件红包技术解密(七):支付宝红包的海量高并发技术实践

社交软件红包技术解密(八):全面解密微博红包技术方案

社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等

即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?

即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途

多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了

从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路

从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结

IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)

阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

>> 更多同类文章 ……

[2] 更多其它架构设计相关文章:

腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

快速理解高性能HTTP服务端的负载均衡技术原理

子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力

优秀后端架构师必会知识:史上最全MySQL大表优化方案总结

小米技术分享:解密小米抢购系统千万高并发架构的演进和实践

一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等

通俗易懂:如何设计能支撑百万并发的数据库架构?

多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了

从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路

美团技术分享:深度解密美团的分布式ID生成算法

12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2909-1-1.html

posted @ 2020-02-19 16:47 Jack Jiang 阅读(146) | 评论 (0)编辑 收藏

2020年1月14日

     摘要: 1、引言随着Android系统的不断升级,即时通讯网技术群和社区里的IM和推送开发的程序员们,对于进程保活这件事是越来越悲观,必竟系统对各种保活黑科技的限制越来越多了,想超越系统的挚肘,难度越来越大。但保活这件事就像“激情”之后的余味,总是让人欲罢不能,想放弃又不甘心。那么,除了像上篇《2020年了,Android后台保活还有戏吗?看我如何优雅的实现!》这样的正经白名单方式...  阅读全文

posted @ 2020-01-14 14:33 Jack Jiang 阅读(54) | 评论 (0)编辑 收藏

2020年1月8日

     摘要: 1、引言扫码登录这个功能,最早应该是微信的PC端开始搞,虽然有点反人类的功能(不扫码也没别的方式登录),但不得不说还是很酷的。下面这张图,不管是IM开发者还是普通用户,应该很熟悉: 于是,搞IM产品的老板和产品经理们,从此又多了一个要抛给程序员们的需求——“为什么微信有扫一扫登录,而我们的没有?”。好吧,每次只要是微信有的功能,IM程序员们...  阅读全文

posted @ 2020-01-08 13:39 Jack Jiang 阅读(38) | 评论 (0)编辑 收藏

2020年1月2日

     摘要: 本文由腾讯WXG应用研究员breezecheng原创发表于公众号“腾讯技术工程”,原题“微信「扫一扫识物」 的背后技术揭秘”。一、引言现在市面上主流的移动端IM应用于都有“扫一扫”功能,看起来好像也就能扫一扫加好友、加群,但实际上作为一个IM产品的重要信息入口,“扫一扫”功能也可以很强大。▲...  阅读全文

posted @ 2020-01-02 20:54 Jack Jiang 阅读(60) | 评论 (0)编辑 收藏

2019年12月27日

1、引言

对于移动端IM应用和消息推送应用的开发者来说,Android后台保活这件事是再熟悉不过了。

自从Android P(即Android 8.0)出现以后,Android已经从系统层面将后台保活这条路给堵死了(详见:《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》),曾今那些层出不穷的保活黑科技能用的也越来越少了(详见:《全面盘点当前Android后台保活方案的真实运行效果(截止2019年前)》。虽然可以自已对接厂商的ROOM级推送通道,但一方面各厂商的推送接口都不一样(而且同一厂商不同的系统版本间也存在推送接口的兼容性问题),很不方便。另一方面要一家家引入各自的推送服务SDK包会让APP变的很大,这让APP的下载变的很不友好。

总之,Android应用的后台保活在某些场景下,还是有持续的需求。除了之前那些耳熟能详的保活黑科技以外,在Android 9.0(甚至Android 10)时代,我们还有哪些保活方法可以用?那么,请跟着本文作者的思路,看看更优雅的后台保活实现方法吧。

(本文同步发布于:http://www.52im.net/thread-2881-1-1.html

 

2、关于作者

网名NanBox:毕业于华中科技大学,现为"悦跑圈APP”高级Android开发工程师。主要负责公司 Android 项目,核心模块的开发。涉及 GPS 定位、地图、图片编辑等功能。独立开发了手表应用项目。 在项目中应入了 Flutter 跨平台开发技术,实现了原生和 Flutter 的混合开发。

本文作者乐于分享,平时会写技术文章并分享在多个平台,是掘金专栏作者的一员,文章总阅读量超过 10 万。在 GitHub 上有多个开源项目,多次在团队内部进行技术分享。是 Android 和 Flutter 官方中文文档译者。

3、相关文章

如果你想详细了解目前Android平台上后台保活技术的挑战,请阅读:

Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》。

如果你想回顾那些曾今出现的Android保活黑科技,以下文章值得好好读读:

全面盘点当前Android后台保活方案的真实运行效果(截止2019年前)

应用保活终极总结(一):Android6.0以下的双进程守护保活实践

应用保活终极总结(二):Android6.0及以上的保活实践(进程防杀篇)

应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)

Android进程保活详解:一篇文章解决你的所有疑问

Android端消息推送总结:实现原理、心跳保活、遇到的问题等

深入的聊聊Android消息推送这件小事

为何基于TCP协议的移动端IM仍然需要心跳保活机制?

微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)

融云技术分享:融云安卓端IM产品的网络链路保活技术实践

4、Android保活现状

我们知道,Android 系统会存在杀后台进程的情况,并且随着系统版本的更新,杀进程的力度还有越来越大的趋势(见:《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》)。

系统这种做法本身出发点是好的,因为可以节省内存,降低功耗,也避免了一些流氓行为。

但有一部分应用,应用本身的使用场景就需要在后台运行,用户也是愿意让它在后台运行的,比如跑步类应用、一些懒得对接厂商推送通道的IM应用、消息推送资讯类应用等。

一方面流氓软件用各种流氓手段进行保活,另一方面系统加大杀后台的力度,导致我们一些真正需要在后台运行的应用被误杀,苦不堪言。

5、优雅的保活?

为了做到保活,出现了不少「黑科技」,比如 1 个像素的 Activity,播放无声音频,双进程互相守护等(可以读读这个系列:《应用保活终极总结(一):Android6.0以下的双进程守护保活实践》、《应用保活终极总结(二):Android6.0及以上的保活实践(进程防杀篇)》、《应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)》)。

这些做法可以说是很流氓了,甚至破坏了 Android 的生态,好在随着 Android 系统版本的更新,这些非常规的保活手段很多都已失效了。

对于那些确实需要在后台运行的应用,我们如何做到优雅的保活呢?

6、加入后台运行白名单,可以优雅的实现保活

从 Android 6.0 开始,系统为了省电增加了休眠模式,系统待机一段时间后,会杀死后台正在运行的进程。但系统会有一个后台运行白名单,白名单里的应用将不会受到影响,在原生系统下,通过:「设置」 - 「电池」 - 「电池优化」 - 「未优化应用」,可以看到这个白名单。

通常会看到下面这两位: 

下次被产品说「 XXX 都可以保活,为什么我们不行!」的时候,你就知道怎么怼回去了。大厂通过和手机厂商的合作,将自己的应用默认加入到白名单中。如果你在一个能谈成这种合作的大厂,也就不用往下看了。

好在系统还没有抛弃我们,允许我们申请把应用加入白名单。

首先,在 AndroidManifest.xml 文件中配置一下权限:

<uses-permissionandroid:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

可以通过以下方法,判断我们的应用是否在白名单中:

@RequiresApi(api = Build.VERSION_CODES.M)

private boolean isIgnoringBatteryOptimizations() {

    boolean isIgnoring = false;

    PowerManager powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);

    if(powerManager != null) {

        isIgnoring = powerManager.isIgnoringBatteryOptimizations(getPackageName());

    }

    return isIgnoring;

}

如果不在白名单中,可以通过以下代码申请加入白名单:

@RequiresApi(api = Build.VERSION_CODES.M)

public void requestIgnoreBatteryOptimizations() {

    try{

        Intent intent = newIntent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);

        intent.setData(Uri.parse("package:"+ getPackageName()));

        startActivity(intent);

    } catch(Exception e) {

        e.printStackTrace();

    }

}

申请时,应用上会出现这样一个窗口:

可以看到,这个系统弹窗会有影响电池续航的提醒,所以如果想让用户点允许,必须要有相关的说明。如果要判断用户是否点击了允许,可以在申请的时候调用 startActivityForResult,在 onActivityResult 里再判断一次是否在白名单中。

7、加入后台运行白名单的多厂商适配方法

7.1 基本说明

Android 开发的一个难点在于,各大手机厂商对原生系统进行了不同的定制,导致我们需要进行不同的适配,后台管理就是一个很好的体现。几乎各个厂商都有自己的后台管理,就算应用加入了后台运行白名单,仍然可能会被厂商自己的后台管理干掉。

如果能把应用加入厂商系统的后台管理白名单,可以进一步降低进程被杀的概率。不同的厂商在不同的地方进行设置,一般是在各自的「手机管家」,但更难的是,就算同一个厂商的系统,不同的版本也可能是在不同地方设置。

最理想的做法是,我们根据不同手机,甚至是不同的系统版本,给用户呈现一个图文操作步骤,并且提供一个按钮,直接跳转到指定页面进行设置。但需要对每个厂商每个版本进行适配,工作量是比较大的。我使用真机测试了大部分主流 Android 厂商的手机后,整理出了部分手机的相关资料。

首先我们可以定义这样两个方法:

/**

 * 跳转到指定应用的首页

 */

private void showActivity(@NonNull String packageName) {

    Intent intent = getPackageManager().getLaunchIntentForPackage(packageName);

    startActivity(intent);

}

 

/**

 * 跳转到指定应用的指定页面

 */

private void showActivity(@NonNull String packageName, @NonNull String activityDir) {

    Intent intent = new Intent();

    intent.setComponent(newComponentName(packageName, activityDir));

    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

    startActivity(intent);

}

以下是部分手机的厂商判断,跳转方法及对应设置步骤,跳转方法不保证在所有版本上都能成功跳转,都需要加 try catch。

7.2 华为

厂商判断:

public boolean isHuawei() {

    if(Build.BRAND == null) {

        return false;

    } else{

        return Build.BRAND.toLowerCase().equals("huawei") || Build.BRAND.toLowerCase().equals("honor");

    }

}

跳转华为手机管家的启动管理页:

private void goHuaweiSetting() {

    try{

        showActivity("com.huawei.systemmanager",

            "com.huawei.systemmanager.startupmgr.ui.StartupNormalAppListActivity");

    } catch(Exception e) {

        showActivity("com.huawei.systemmanager",

            "com.huawei.systemmanager.optimize.bootstart.BootStartActivity");

    }

}

操作步骤:应用启动管理 -> 关闭应用开关 -> 打开允许自启动

7.3 小米

厂商判断:

public static boolean isXiaomi() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("xiaomi");

}

跳转小米安全中心的自启动管理页面:

private void goXiaomiSetting() {

    showActivity("com.miui.securitycenter",

        "com.miui.permcenter.autostart.AutoStartManagementActivity");

}

操作步骤:授权管理 -> 自启动管理 -> 允许应用自启动

7.4 OPPO

厂商判断:

public static boolean isOPPO() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("oppo");

}

跳转 OPPO 手机管家:

private void goOPPOSetting() {

    try{

        showActivity("com.coloros.phonemanager");

    } catch(Exception e1) {

        try{

            showActivity("com.oppo.safe");

        } catch(Exception e2) {

            try{

                showActivity("com.coloros.oppoguardelf");

            } catch(Exception e3) {

                showActivity("com.coloros.safecenter");

            }

        }

    }

}

操作步骤:权限隐私 -> 自启动管理 -> 允许应用自启动

7.5 VIVO

厂商判断:

public static boolean isVIVO() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("vivo");

}

跳转 VIVO 手机管家:

private void goVIVOSetting() {

    showActivity("com.iqoo.secure");

}

操作步骤:权限管理 -> 自启动 -> 允许应用自启动

7.6 魅族

厂商判断:

public static boolean isMeizu() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("meizu");

}

跳转魅族手机管家:

private void goMeizuSetting() {

    showActivity("com.meizu.safe");

}

操作步骤:权限管理 -> 后台管理 -> 点击应用 -> 允许后台运行

7.7 三星

厂商判断:

public static boolean isSamsung() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("samsung");

}

跳转三星智能管理器:

private void goSamsungSetting() {

    try{

        showActivity("com.samsung.android.sm_cn");

    } catch(Exception e) {

        showActivity("com.samsung.android.sm");

    }

}

操作步骤:自动运行应用程序 -> 打开应用开关 -> 电池管理 -> 未监视的应用程序 -> 添加应用

7.8 乐视

厂商判断:

public static boolean isLeTV() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("letv");

}

跳转乐视手机管家:

private void goLetvSetting() {

    showActivity("com.letv.android.letvsafe",

        "com.letv.android.letvsafe.AutobootManageActivity");

}

操作步骤:自启动管理 -> 允许应用自启动

7.9 锤子

厂商判断:

public static boolean isSmartisan() {

    return Build.BRAND != null&& Build.BRAND.toLowerCase().equals("smartisan");

}

跳转手机管理:

private void goSmartisanSetting() {

    showActivity("com.smartisanos.security");

}

操作步骤:权限管理 -> 自启动权限管理 -> 点击应用 -> 允许被系统启动。

8、友商致敬?

在之前做的跑步应用中,我在设置里增加了一个权限设置页面,将上面提到的设置放在这里面。

最近发现友商某咚也跟进了,图 1 是我们做的,图 2 是某咚做的: 

某咚从设计、从我写的不够好的文案,甚至是我从十几台手机上一张一张截下来的图,进行了全方位的致敬。感谢某咚的认可,但最近在某个发布会上听到这么一句话:在致敬的同时,能不能说一句谢谢?

某咚的致敬,一方面说明了目前确实存在进程容易被杀,保活难度大的问题,另一方面也说明了这种引导用户进行白名单设置的手段是有效的。

附录:更多相关技术文章

应用保活终极总结(一):Android6.0以下的双进程守护保活实践

应用保活终极总结(二):Android6.0及以上的保活实践(进程防杀篇)

应用保活终极总结(三):Android6.0及以上的保活实践(被杀复活篇)

Android进程保活详解:一篇文章解决你的所有疑问

Android端消息推送总结:实现原理、心跳保活、遇到的问题等

深入的聊聊Android消息推送这件小事

为何基于TCP协议的移动端IM仍然需要心跳保活机制?

微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)

微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)

移动端IM实践:实现Android版微信的智能心跳机制

移动端IM实践:WhatsApp、Line、微信的心跳策略分析

Android P正式版即将到来:后台应用保活、消息推送的真正噩梦

全面盘点当前Android后台保活方案的真实运行效果(截止2019年前)

一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等

融云技术分享:融云安卓端IM产品的网络链路保活技术实践

正确理解IM长连接的心跳及重连机制,并动手实现(有完整IM源码)

2020年了,Android后台保活还有戏吗?看我如何优雅的实现!

>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-2881-1-1.html

posted @ 2019-12-27 14:51 Jack Jiang 阅读(79) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang