Jack Jiang

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

2024年8月15日

     摘要: 本文由百度技术团队分享,引用自百度Geek说,原题“百度Android IM SDK组件能力建设及应用”,本文进行了排版和内容优化。1、引言移动互联网时代,随着社交媒体、移动支付、线上购物等行业的快速发展,对即时通讯功能的需求不断增加。对于各APP而言,接入IM SDK(即时通讯软件开发工具包)能够大大降低开发成本、提高开发效率,快速构建自己的IM系统。本文主要介绍了百度公...  阅读全文

posted @ 2024-10-10 12:35 Jack Jiang 阅读(22) | 评论 (0)编辑 收藏

     摘要: 本文来自微信团队工程师张文瑞的技术分享,由“极客邦科技Geekbang”编辑发布,下文有修订和改动。一、开场白谢谢大家!我是来自腾讯WXG技术架构部的张文瑞,今天下午跟大家分享的主题是:微信团队是如何从0到1实现“有把握”的微信春晚摇一摇红包系统的。回忆一下春晚的活动,有什么样的活动形式呢?当时我们是直接复用客户端摇一摇入口,专门给春晚摇一摇定制了一...  阅读全文

posted @ 2024-10-10 10:18 Jack Jiang 阅读(23) | 评论 (0)编辑 收藏

     摘要: 1、前言在猴年新春的时候,腾讯当时推出了新春广告片(点击观看视频),作为《弹指间 心无间》的延续。片中通过春节期间发送QQ红包让家人打车回家团聚,让我们感受到了“最温暖的红包,给最爱的人”那种弹指间的感动。而就在这弹指一挥间,此次腾讯新春广告片距离2011年腾讯发布《弹指间 心无间》“亲情篇”已经好几年过去了。在这几年的时间里,腾讯QQ从音频、视频、...  阅读全文

posted @ 2024-09-29 12:18 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

本文由萤火架构分享,原题“localhost和127.0.0.1的区别是什么?”,原文链接“juejin.cn/post/7321049446443417638”,下文进行了排版和内容优化。

1、引言

继《你真的了解127.0.0.1和0.0.0.0的区别?》、《深入操作系统,彻底搞懂127.0.0.1本机网络通信》之后,这是整理收录的第3篇有关本机网络的网络编程基础文章。以下是正文内容。

今天在网上逛的时候看到一个问题,没想到大家讨论的很热烈,就是标题中这个:

前端同学本地调试的时候,应该没少和localhost打交道吧,只需要执行 npm run 就能在浏览器中打开你的页面窗口,地址栏显示的就是这个 http://localhost:xxx/index.html。

可能大家只是用,也没有去想过这个问题。联想到我之前合作过的一些开发同学对它们俩的区别也没什么概念,所以我觉得有必要普及下。

 
 

2、系列文章

本文是该系列文章中的第 4 篇:

网络编程入门如此简单(一):假如你来设计网络,会怎么做?

网络编程入门如此简单(二):假如你来设计TCP协议,会怎么做?

网络编程入门如此简单(三):什么是IPv6?漫画式图文,一篇即懂!

网络编程入门如此简单(四):一文搞懂localhost和127.0.0.1》(* 本文)

3、localhost是什么呢?

localhost是一个域名,和大家上网使用的域名没有什么本质区别,就是方便记忆。

只是这个localhost的有效范围只有本机,看名字也能知道:local就是本地的意思。

张三和李四都可以在各自的机器上使用localhost,但获取到的也是各自的页面内容,不会相互打架。

4、从域名到程序

要想真正的认清楚localhost,我们还得从用户是如何通过域名访问到程序说起。

以访问百度为例。

1)当我们在浏览器输入 baidu.com 之后,浏览器首先去DNS中查询 baidu.com 的IP地址。

为什么需要IP地址呢?打个比方,有个人要寄快递到你的公司,快递单上会填写:公司的通讯地址、公司名称、收件人等信息,实际运输时快递会根据通信地址进行层层转发,最终送到收件人的手中。网络通讯也是类似的,其中域名就像公司名称,IP地址就像通信地址,在网络的世界中只有通过IP地址才能找到对应的程序。(请详读《什么是公网IP和内网IP?NAT转换又是什么鬼?》)

DNS就像一个公司黄页,其中记录着每个域名对应的IP地址,当然也有一些域名可能没做登记,就找不到对应的IP地址,还有一些域名可能会对应多个IP地址,DNS会按照规则自动返回一个。我们购买了域名之后,一般域名服务商会提供一个域名解析的功能,就是把域名和对应的IP地址登记到DNS中。(请详读《理论联系实际,全方位深入理解DNS》)

这里的IP地址从哪里获取呢?每台上网的电脑都会有1个IP地址,但是个人电脑的IP地址一般是不行的,个人电脑的IP地址只适合内网定位,就像你公司内部的第几栋第几层,公司内部人明白,但是直接发给别人,别人是找不到你的。

如果你要对外部提供服务,比如百度这种,你就得有公网的IP地址,这个IP地址一般由网络服务运营商提供,比如你们公司使用联通上网,那就可以让联通给你分配一个公网IP地址,绑定到你们公司的网关服务器上,网关服务器就像电话总机,公司内部的所有网络通信都要通过它,然后再在网关上设置转发规则,将网络请求转发到提供网络服务的机器上。

2)有了IP地址之后,浏览器就会向这个IP地址发起请求,通过操作系统打包成IP请求包,然后发送到网络上。

网络传输有一套完整的路由协议,它会根据你提供的IP地址,经过路由器的层层转发,最终抵达绑定该IP的计算机。

3)计算机上可能部署了多个网络应用程序,这个请求应该发给哪个程序呢?

这里有一个端口的概念,每个网络应用程序启动的时候可以绑定一个或多个端口,不同的网络应用程序绑定的端口不能重复,再次绑定时会提示端口被占用。

通过在请求中指定端口,就可以将消息发送到正确的网络处理程序。但是我们访问百度的时候没有输入端口啊?这是因为默认不输入就使用80和443端口,http使用80,https使用443。我们在启动网络程序的时候一定要绑定一个端口的,当然有些框架会自动选择一个计算机上未使用的端口。

5、localhost和127.0.0.1的区别是什么?

有了前面的知识储备,我们就可以很轻松的搞懂这个问题了。

localhost是域名,上文已经说过了。

127.0.0.1 呢?是IP地址,当前机器的本地IP地址,且只能在本机使用,你的计算机不联网也可以用这个IP地址,就是为了方便开发测试网络程序的。

我们调试时启动的程序就是绑定到这个IP地址的。

这里简单说下,我们经常看到的IP地址一般都是类似 X.X.X.X 的格式,用"."分成四段。其实它是一个32位的二进制数,分成四段后,每一段是8位,然后每一段再转换为10进制的数进行显示。

那localhost是怎么解析到127.0.0.1的呢?经过DNS了吗?没有。每台计算机都可以使用localhost和127.0.0.1,这没办法让DNS来做解析。

那就让每台计算机自己解决了。每台计算机上都有一个host文件,其中写死了一些DNS解析规则,就包括 localhost 到 127.0.0.1 的解析规则,这是一个约定俗成的规则。

如果你不想用localhost,那也可以,随便起个名字,比如 wodehost,也解析到 127.0.0.1 就行了。

甚至你想使用 baidu.com 也完全可以,只是只能自己自嗨,对别人完全没有影响。

PS:以下两篇可以深入进行阅读:

  1. 你真的了解127.0.0.1和0.0.0.0的区别?
  2. 深入操作系统,彻底搞懂127.0.0.1本机网络通信

6、域名的等级划分

localhost不太像我们平常使用的域名,比如 www.juejin.cn 、baidu.com、csdn.net, 这里边的 www、cn、com、net都是什么意思?localhost为什么不需要?

域名其实是分等级的,按照等级可以划分为顶级域名、二级域名和三级域名...

1)顶级域名(TLD):

顶级域名是域名系统中最高级别的域名。它位于域名的最右边,通常由几个字母组成。顶级域名分为两种类型:通用顶级域名和国家顶级域名。常见的通用顶级域名包括表示工商企业的.com、表示网络提供商的.net、表示非盈利组织的.org等,而国家顶级域名则代表特定的国家或地区,如.cn代表中国、.uk代表英国等。

2)二级域名(SLD):

二级域名是在顶级域名之下的一级域名。它是由注册人自行选择和注册的,可以是个性化的、易于记忆的名称。例如,juejin.cn 就是二级域名。我们平常能够申请到的也是这种。目前来说申请 xxx.com、xxx.net、xxx.cn等等域名,其实大家不太关心其顶级域名com\net\cn代表的含义,看着简短好记是主要诉求。

3)三级域名(3LD):

三级域名是在二级域名之下的一级域名。它通常用于指向特定的服务器或子网。例如,在blog.example.com中,blog就是三级域名。www是最常见的三级域名,用于代表网站的主页或主站点,不过这只是某种流行习惯,目前很多网站都推荐直接使用二级域名访问了。

域名级别还可以进一步细分,大家可以看看企业微信开放平台这个域名:developer.work.weixin.qq.com,com代表商业,qq代表腾讯,weixin代表微信,work代表企业微信,developer代表开发者。这种逐层递进的方式有利于域名的分配管理。

按照上边的等级定义,我们可以说localhost是一个顶级域名,只不过它是保留的顶级域,其唯一目的是用于访问当前计算机。

7、多网站共用一个IP和端口

上边我们说不同的网络程序不能使用相同的端口,其实是有办法突破的。

以前个人博客比较火的时候,大家都喜欢买个虚拟主机,然后部署个开源的博客程序,抒发一下自己的感情。为了挣钱,虚拟主机的服务商会在一台计算机上分配N多个虚拟主机,大家使用各自的域名和默认的80端口进行访问,也都相安无事。这是怎么做到的呢?

如果你有使用Nginx、Apache或者IIS等Web服务器的相关经验,你可能会接触到主机头这个概念。主机头其实就是一个域名,通过设置主机头,我们的程序就可以共用1个网络端口。

首先在Nginx等Web程序中部署网站时,我们会进行一些配置,此时在主机头中写入网站要使用的域名。

然后Nginx等Web服务器启动的时候,会把80端口占为己有。

然后当某个网站的请求到达Nginx的80端口时,它会根据请求中携带的域名找到配置了对应主机头的网络程序。

然后再转发到这个网络程序,如果网络程序还没有启动,Nginx会把它拉起来。

8、私有IP地址

除了127.0.0.1,其实还有很多私有IP地址,比如常见的 192.168.x.x。

这些私有IP地址大部分都是为了在局域网内使用而预留的,因为给每台计算机都分配一个独立的IP不太够用,所以只要局域网内不冲突,大家就可劲的用吧。你公司可以用 192.168.1.1,我公司也可以用192.168.1.1。

但是如果你要访问我,就得通过公网IP进行转发。

大家常用的IPv4私有IP地址段分为三类:

  • 1)A类:从10.0.0.0至10.255.255.255;
  • 2)B类:从172.16.0.0至172.31.255.255;
  • 3)C类:从192.168.0.0至192.168.255.255。

这些私有IP地址仅供局域网内部使用,不能在公网上使用。

除了上述三个私有的IPv4地址段外,还有一些保留的IPv4地址段:

1)用于本地回环测试的127.0.0.0至127.255.255.255地址段,其中就包括题目中的127.0.0.1,如果你喜欢也可以给自己分配一个127.0.0.2的IP地址,效果和127.0.0.1一样。

2)用于局域网内部的169.254.0.0至169.254.255.255地址段,这个很少接触到,如果你的电脑连局域网都上不去,可能会看到这个IP地址,它是临时分配的一个局域网地址。

这些地址段也都不能在公网上使用。

近年来,还有一个现象,就是你家里或者公司里上网时,光猫或者路由器对外的IPv4地址也不是公网IP了,这时候获得的可能是一个类似 100.64.x.x 的地址,这是因为随着宽带的普及,运营商手里的公网IP也不够了,所以运营商又加了一层局域网,而100.64.0.0 这个网段是专门分给运营商做局域网用的。

如果你使用阿里云等公有云,一些云产品的IP地址也可能是这个,这是为了将客户的私有网段和公有云厂商的私有网段进行有效的区分。

其实还有一些不常见的专用IPv4地址段,完整的IP地址段定义可以看这里:www.iana.org/assignments

9、IPv6  

你可能也听说过IPv6,因为IPv4可分配的地址太少了,不够用,使用IPv6甚至可以为地球上的每一粒沙子分配一个IP。只是喊了很多年,大家还是喜欢用IPv4,这里边原因很多,这里就不多谈了。

IPv6地址类似于:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX。

它是128位的,用":"分成8段,每个X是一个16进制数(取值范围:0-F),IPv6地址空间相对于IPv4地址有了极大的扩充。比如:2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b 就是一个有效的IPv6地址。(请详读《什么是IPv6?漫画式图文,一篇即懂!》)

10、参考资料  

[1] 你真的了解127.0.0.1和0.0.0.0的区别?

[2] 深入操作系统,彻底搞懂127.0.0.1本机网络通信

[3] 什么是IPv6?漫画式图文,一篇即懂!

[4] 一文读懂什么是IPv6

[5] IPv6技术详解:基本概念、应用现状、技术实践(上篇)

[6] 什么是公网IP和内网IP?NAT转换又是什么鬼?

[7] 深入操作系统,一文搞懂Socket到底是什么

[8] 面视必备,史上最通俗计算机网络分层详解

[9] 通俗讲解,有了IP地址,为何还要用MAC地址?

[10] 理论联系实际,全方位深入理解DNS


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

posted @ 2024-09-26 10:23 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

     摘要: 1、前言微信——腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿...在技术架构上,微信是如何做到的?日前,在腾讯大讲堂在中山大学校园宣讲活动上,腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。周颢把微信的成功归结于腾讯式的“三位一体&...  阅读全文

posted @ 2024-09-25 11:17 Jack Jiang 阅读(69) | 评论 (0)编辑 收藏

► 相关链接:

一、技术准备

您是否已对Web端即时通讯技术有所了解?

您需要对WebSocket技术有所了解:

WebSocket标准文档、API手册:

二、开发工具准备

1)WebStorm:

(JackJiang 使用的版本号如上图所示,建议你也使用此版或较新版本)

2)一站式下载地址:WebStorm官方下载地址点此进入

三、工程文件用途说明

3.1文件概览

纯原生JS实现,无任何重框架依赖:

MobileIMSDK-H5端SDK本身只是JS文件源码的集合,本工程中自带的前端Demo的目的只是为了方便随时测试MobileIMSDK-H5端的SDK代码而已,在此工程中的使用也仅仅只涉及了一个主Demo页面而已。

工程目录说明:

3.2详细说明

SDK 各模块/文件作用说明:

四、主要 API 接口

4.1主要 API 接口概览

如下图所示:所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。,接口设计跟MobileIMSDK 的APP版一样,均为高内聚和低侵入的回调方式传入SDK处理逻辑,无需(也不建议)开发者直接修改sdk级代码。

▲ 图上为浏览器端SDK的对外接口文件位置

▲ 图上为浏览器SDK为开发者提供的回调接口

▲ 图上浏览器端SDK的对外接口文件全图

4.2主要 API 接口用途说明

1)IMSDK.isLogined():

  • 用途:是否已经完成过首次登陆。
  • 说明 :用户一旦从自已的应用中完成登陆IM服务器后,本方法就会一直返回true(直到退出登陆IM)。
  • 返回值:{boolean},true表示已完成首次成功登陆(即已经成功登陆过IM服务端了,后面掉线时不影响此标识),否则表示尚未连接IM服务器。

2)IMSDK.isOnline():

  • 用途:是否在线。
  • 说明 :表示网络连接是否正常。
  • 返回值:{boolean},true表示网络连接正常,否则表示已掉线,本字段只在this._logined=true时有意义(如果都没有登陆到IM服务器,怎么存在在线或掉线的概念呢)。

3)IMSDK.getLoginInfo():

  • 用途:返回登陆时提交的登陆信息(用户名、密码/token等)。
  • 说明 :格式形如:{loginUserId:'',loginToken:''},此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见:PLoginInfo
  • 返回值:{boolean},true表示网络连接正常,否则表示已掉线,本字段只在this._logined=true时有意义(如果都没有登陆到IM服务器,怎么存在在线或掉线的概念呢)。

4)IMSDK.sendData(p, fnSucess, fnFail, fnComplete):

  • 用途:向某人发送一条消息。
  • 参数p:{Protocal} 要发送的消息协议包对象,Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
  • 返回值:{int} 0表示成功,否则表示错误码,错码详见“/module/mb_constants.js”下的MBErrorCode对象属性说明。

5)IMSDK.disconnectSocket():

  • 用途:客户端主动断开客户端socket连接。
  • 说明 :当开发者登陆IM后,需要退出登陆时,调用本函数就对了,本函数相当于登陆函数 loginImpl()的逆操作。

6)IMSDK.setDebugCoreEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端核心算法层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

7)IMSDK.setDebugSDKEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端框架层的log输入,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

8)IMSDK.setDebugPingPongEnable(enable):

  • 用途:是否开启MobileIMSDK-H5端框架层的底层网络WebSocket心跳包的log输出,方便开发者调试。
  • 参数enable :{boolean} true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。
  • 注意:必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时,心跳log才会真正输出,方便控制。
  • 返回值:true表示开启log输出,否则不输出,开发者不调用本函数的话系统默认是false(即不输出log)。

9)IMSDK.loginImpl(varloginInfo, wsUrl):

  • 用途:登陆/连接MobileIMSDK服务器时调用的方法。
  • 说明 :登陆/连接MobileIMSDK服务器由本函数发起
  • 参数varloginInfo:{PLoginInfo} 必填项,登陆要提交给Websocket服务器的认证信息,不可为空,对象字段定义见:PLoginInfo
  • 参数wsUrl:{string} 必填项:要连接的Websocket服务器地址,不可为空,形如:wss://yousite.net:3000/websocket。

10)IMSDK.callback_onIMLog(message, toConsole):

  • 用途:由开发者设置的回调方法:用于debug的log输出。
  • 推荐用法 :开发者可在此回调中按照自已的意图打印MobileIMSDK微信小程序端框架中的log,方便调试时使用。
  • 参数1: {String}:必填项,字符串类型,表示log内容。
  • 参数2: {boolean}:选填项,true表示输出到console,否则默认方式(由开发者设置的回调决定)。

11)IMSDK.callback_onIMData(p, options):

  • 用途:由开发者设置的回调方法:用于收到聊天消息时在UI上展现出来(事件通知于收到IM消息时)。
  • 推荐用法:开发者可在此回调中处理收到的各种IM消息。
  • 参数1: {Protocal}:详情请见“/module/mb_constants.js”下的Protocal类定义)。

12)IMSDK.callback_onIMAfterLoginSucess():

  • 用途:由开发者设置的回调方法:客户端的登陆请求被服务端成功认证完成后的回调(事件通知于 登陆/认证 成功后)。
  • 推荐用法 :开发者可在此回调中进行登陆IM服务器成功后的处理。

13)IMSDK.callback_onIMAfterLoginFailed(isReconnect):

  • 用途:由开发者设置的回调方法:客户端的登陆请求被服务端认证失败后的回调(事件通知于 登陆/认证 失败后)。
  • 说明 :登陆/认证失败的原因可能是用户名、密码等不正确等,但具体逻辑由服务端的 callBack_checkAuthToken回调函数去处理。
  • 推荐用法:开发者可在此回调中提示用户登陆IM服务器失败。。
  • 参数1: {boolean}:true表示是掉线重连后的认证失败(在登陆其间可能用户的密码信息等发生了变更),否则表示首次登陆时的认证失败。

14)IMSDK.callback_onIMReconnectSucess():

  • 用途:由开发者设置的回调方法:掉线重连成功后的回调(事件通知于掉线重连成功后)。
  • 推荐用法 :开发者可在此回调中处理掉线重连成功后的界面状态更新等,比如设置将界面上的“离线”文字更新成“在线”。

15)IMSDK.callback_onIMDisconnected():

  • 用途:由开发者设置的回调方法:网络连接已断开时的回调(事件通知于与服务器的网络断开后)。
  • 推荐用法 :开发者可在此回调中处理掉线时的界面状态更新等,比如设置将界面上的“在线”文字更新成“离线”。

16)IMSDK.callback_onIMPing():

  • 用途:由开发者设置的回调方法:本地发出心跳包后的回调通知(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

17)IMSDK.callback_onIMPong():

  • 用途:由开发者设置的回调方法:收到服务端的心跳包反馈的回调通知(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 推荐用法 :开发者可在此回调中处理底层网络的活动情况。

18)IMSDK.callback_onIMShowAlert(alertContent):

  • 用途:由开发者设置的回调方法:框架层的一些提示信息显示回调(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 说明 :开发者不设置的情况下,框架默认将调用wx.showModal()显示提示信息,否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示,提升UI体验,别无它用】。
  • 参数1:{String}:必填项,文本类型,表示提示内容。

19)IMSDK.callback_onIMKickout(kickoutInfo):

  • 用途:由开发者设置的回调方法:收到服务端的“踢出”指令(本回调并非MobileIMSDK-H5端核心逻辑,开发者可以不需要实现!)。
  • 参数1 :{PKickoutInfo}:非空,详见:PKickoutInfo

20)IMSDK.callback_onMessagesLost(lostMessages):

  • 用途:由开发者设置的回调方法:消息未送达的回调事件通知。
  • 发生场景 :比如用户刚发完消息但网络已经断掉了的情况下,表现形式如:就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
  • 参数1:{Array}:由框架的QoS算法判定出来的未送达消息列表。

21)IMSDK.callback_onMessagesBeReceived(theFingerPrint):

  • 用途:由开发者设置的回调方法:消息已被对方收到的回调事件通知。
  • 说明 :目前,判定消息被对方收到是有两种可能:1) 对方确实是在线并且实时收到了;2) 对方不在线或者服务端转发过程中出错了,由服务端进行离线存储成功后的反馈(此种情况严格来讲不能算是“已被收到”,但对于应用层来说,离线存储了的消息原则上就是已送达了的消息:因为用户下次登陆时肯定能通过HTTP协议取到)。
  • 建议用途:应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
  • 参数1:{String}:已被收到的消息的指纹特征码(唯一ID),应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、前端开发指南

5.1如何引入SDK文件到您的前端工程中?

很简单:只需要将第2节中提到的SDK所有JS文件复制到您的Uniapp工程下即可。

SDK内容见下图:

5.2如何在代码中调用SDK?

第一步:在你的网页中引用SDK的js文件(具体例子详见Demo中的index.html文件)

第二步:直接在你的JS文件中编写回调配置代码(具体例子详见Demo中的index.js文件)

第三步:在你的JS文件中调用IM的登陆方法即可(具体例子详见Demo中的index.js文件)

注意:上图中登录连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

六、Demo运行方法(在WebStorm中直接预览)

6.1重要说明

特别说明:MobileIMSDK的H5端(包括Demo在内),全部是静态的HTML+JS资源,可以通过WebStorm自带的HTML页面预览功能,直接自动加载到电脑的浏览器中运行和预览。

6.2预览方法

1)在Demo中的index.html文件中,移动鼠标,会在右上角出现如下图所示的浮出菜单:

2)点击右上角浮出菜单上相应的浏览器就可以自动预览了这里以我电脑上已安装的Edge浏览器为例):

七、Demo运行方法(在Web服务器中部署并访问)

7.1重要说明

特别说明:MobileIMSDK的H5端(包括Demo在内),全部是静态的HTML+JS资源,对于服务端是没有任何依赖的,只需要保证浏览器端能加载到即可,可以把它们放置在Tomcat、Apache、IIS、Nginx等等传统Web服务器中即可,无需任何动态运行环境。

7.2安装Tomcat

提示:以下Demo的部署,以Java程序员最常用和Tomcat为例(Apache、IIS、Nginx等依此类推)。

Tomcat的安装就没什么好说的,直接官网下载对应的版本即可:https://tomcat.apache.org/download-90.cgi

7.3配置要连接的MobileIMSDK服务器IP

注意:下图中登陆连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

友情提示: MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了,你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助:Server端》。

▲ 配置要连接的服务器IP(以上代码详见demo/index.js 文件)

7.4部署Demo

说“部署”有点扯蛋,因为Demo(包括SDK)在内,全是HTML静态内容,只需要直接复制到任何一种Web服务器即可。

以下是复制到Tomcat服务器网页目录后的截图:

7.5启动Tomcat

提示:本手册中仅以启Tomcat为例,Apache、IIS、Nginx等Web服务器的启动请自动百度。

运行startup.bat启动Tomcat:

7.6Demo的运行效果预览

八、Demo功能预览和说明

九、Demo运行效果实拍图

1)Demo在手机端浏览器中的真机实拍图:

2)Demo在电脑端浏览器中的真机实拍图:

十、更多Demo运行效果截图

1)Demo在PC端浏览器运行效果:

2)Demo在手机端浏览器运行效果:

3)Demo在PC端各主流浏览器的运行效果:

十一、常见问题(FAQ)

11.1为什么浏览控制台下有些log不显示?

原因是浏览器控制台下的日志级别默认进行了过滤,勾选所有日志级别,就能看到SDK的详细日志输出了。

勾选所有的日志输出级别:

然后就能看到SDK中详细的日志输出了(就像下图这样),方便调试和研究:

十二、引用资料

[1] WebSocket 标准API手册

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码Github地址点此

[4] MobileIMSDK-H5端基本介绍

[5] MobileIMSDK-H5端的开发手册(* 精编PDF版)

[6] MobileIMSDK的Demo使用帮助:Server端

[7] WebSocket从入门到精通,半小时就够!

posted @ 2024-09-19 13:14 Jack Jiang 阅读(55) | 评论 (0)编辑 收藏

一、基本介绍

MobileIMSDK的H5端是一套纯JS编写的基于标准WebSocket的即时通讯库:
  • 1)超轻量级、极少依赖;
  • 2)纯JS编写、高度提炼,简单易用;
  • 3)基于标准WebSocket协议,客户端兼容性好;
  • 4)支持运行于iOS、Android等移动端浏览器和各种PC端浏览器;
  • 5)能与 MobileIMSDKGithub托管链接)的各种APP原生代码客户端完美互通;
  • 6)可应用于手机端/PC端的网页聊天应用、企业OA、Web端等即时通讯场景。

二、与MobileIMSDK的关系

MobileIMSDK-H5端 是基于标准HTML5的WebSocket协议的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的通信架构图:

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架:

  • 1)历经8年、久经考验;
  • 2)超轻量级、高度提炼,lib包50KB以内;
  • 3)精心封装,一套API同时支持UDP、TCP、WebSocket三种协议(可能是全网唯一开源的);
  • 4)客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp:new:(暂未开源);
  • 5)服务端基于Netty,性能卓越、易于扩展;
  • 6)可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;
  • 7)可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS: MobileIMSDK一直在持续开发和升级中,新Uniapp端是MobileIMSDK工程的最新成果。

三、与MobileIMSDK-Web的关系

MobileIMSDK-Web也是一套纯JS编写的Web端即时通讯框架(含服务端)。

MobileIMSDK-Web框架与MobileIMSDK-H5端的相同点:
  • 1)都是Web端即时通讯框架;
  • 2)都是纯JS编写;
  • 3)都可以运行在手机、pc端的浏览器或web容器内。
MobileIMSDK-Web框架与MobileIMSDK-H5端的不同点:
  • 1)MobileIMSDK-Web可以兼容不支持HTML5的旧版浏览器或容器,而MobileIMSDK-H5端必须运行在当前主流的HTML5浏览器或容器;
  • 2)MobileIMSDK-Web需依赖于socket.io这种第3方通信层库,而MobileIMSDK-H5端无任何额外依赖。
我该如何选型?
  • 选择一:如果您的应用必须兼容旧版浏览器(包括旧版IE等)
    那唯一的选择就是MobileIMSDK-Web,因为它存在的主要价值就是为了兼容旧版浏览器;
  • 选择二:如果您的应用只需运行在现今主流的HTML5浏览器或容器
    那么建议您优先使用MobileIMSDK的H5端,必竟直接调用标准HTML5的WebSocket API,要简洁、轻量多了,也没有第3方依赖。

四、设计目标

直接使用原生的WebSocket有以下问题和劣势:
  • 1)功能有限:没有提供心跳保活、断线重连、送达保证(重传和去重)等即时通讯关键算法和逻辑;
  • 2)API 简陋:在如此有限的标准API下,能逻辑清晰和健壮地实现并组合心跳保活、断线重连、送达保证等算法,需要相当高的技术掌控力
  • 3)逻辑耦合:经验欠缺的开发人员,会将WebSocket通信代码与前端UI界面代码混在一起,使得UI界面的编写、维护、改版都非常困难。
针对以上问题,而MobileIMSDK-H5端库将让开发者专注于UI应用层的开发,网络通信层的专业代码交由SDK开发人员,从而解偶UI前端和通信层的逻辑耦合性,大大降低技术复杂性。

总结一下,MobileIMSDK-H5端库的设计目标是为您的Web端IM带来以下便利:
  • 1)前端与通信解偶:前端UI与网络通信代码解耦,UI界面的重构、维护、改版都非常容易和优雅;
  • 2)轻量级和兼容性:受益于标准WebSocket,可很好地运行于现今主流的H5浏览器上,且无需额外依赖;
  • 3)核心内聚和收敛:得益于长期的提炼和经验积累,SDK核心层高度封装,开发者无需理解复杂算法即可简单上手。
  • 4)纯JS轻量级实现:纯JS编写,无Angular、EmberJS、VUE等各种重量级前端框架依赖,方便对接各种既有系统;

五、技术亮点

  • 1)轻量易使用:超轻量级——纯JS编写且极少依赖,高度提炼——简单易用;
  • 2)兼容性很好:基于标准WebSocket,可很好地运行于现今主流的H5浏览器上,且无需额外依赖;
  • 3)断网恢复能力:拥有网络状况自动检测、断网自动治愈的能力;
  • 4)送达保证机制:完善的QoS消息送达保证机制(自动重传、消息去重、状态反馈等),不漏过每一条消息;
  • 5)支持多种设备:支持运行于iOS、Android等移动端浏览器和各种PC端浏览器;
  • 6)通信协议封装:实现了一个对上层透明的即时通讯通信协议模型;
  • 7)身份认证机制:实现了简单合理的身份认证机制;
  • 8)完善的log信息:在开发调试阶段,确保每一个算法关键步骤都有日志输出,让您的运行调试更为便利;
  • 9)前端代码解耦:实现了UI前端代码与sdk网络通信代码解偶,防止前端代码跟IM核心代码混在一起,不利于持续升级、重用和维护;
  • 10)多端协议兼容:实现了与MobileIMSDK各APP端完全兼容的协议模型;

六、文件组成

SDK代码文件概览:

SDK代码文件用途说明:

七、Demo功能预览和说明

八、Demo运行效果实拍图

1)Demo在手机端浏览器中的真机实拍图:

2)Demo在电脑端浏览器中的真机实拍图:

八、更多Demo运行效果截图

1)Demo在PC端浏览器运行效果:

 

2)Demo在手机端浏览器运行效果(点击可看大图 ▼):

3)Demo在PC端主流浏览器的运行效果(点击可看大图 ▼):

十、详尽开发者手册

① MobileIMSDK-H5端的详细介绍:点此查看 👈
② MobileIMSDK-H5端的开发手册(网页版):点此查看 👈
 MobileIMSDK-H5端的开发手册(精编PDF版):点此查看 👈 (* 推荐
④ MobileIMSDK-开源框架的详细介绍:https://gitee.com/jackjiang/MobileIMSDK (Github托管链接)👈

十一、相关资料

[1] HTML5 WebSocket API 文档
[2] MobileIMSDK开源框架的API文档
[3] MobileIMSDK开源IM框架源码Github地址点此
[4] MobileIMSDK-Web框架基础介绍

posted @ 2024-09-18 10:36 Jack Jiang 阅读(48) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨、GavinX分享,原题“得物App白屏优化系列|网络篇”,下文进行了排版和内容优化。1、引言图片加载作为重中之重的App体验指标,端侧的白屏问题则是其中最为严重、也是最为常见的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下,图片无法完成加载是多么糟糕的体验。如上图所示,通过线上白屏问题归因,我们看到网络问题导致比例最高,占比达81.97%...  阅读全文

posted @ 2024-09-12 11:02 Jack Jiang 阅读(61) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《老司机揭秘手机定位技术,这下彻底明白啦!》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-11 12:07 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“鲜枣课堂”的《坐高铁手机没信号?原因远比你想的要复杂!》文章内容。为了更好的内容呈现,本文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收...  阅读全文

posted @ 2024-09-06 12:02 Jack Jiang 阅读(76) | 评论 (0)编辑 收藏

本文由携程技术Jim分享,原题“日访问过亿,办公IM及开放式平台在携程的实践”,下文进行了排版和内容优化。

1、引言

携程内部的办公IM项目最早在2016年立项,经历了初期简单办公场景下的纯IM服务,到支持简单办公组件的IM应用,又演变为一体化办公集成平台,进而演变为目前集成IM功能的开放式企业效率平台。

本文总结了携程办公IM这些年的发展历程及未来的演进方向,并着重从高可用、高性能和可扩展的角度,探讨开放式平台的技术实现及发展方向。

 
 

2、关于作者

Jim:携程高级研发经理,关注Java & Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

3、什么是IM

IM(Instant Message)即时消息,是一种通过网络提供实时消息传输的在线沟通技术。

在移动互联网时代,IM的使用变得越来越广泛,通过各种技术手段使得用户之间的交流成本变的极低,沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态,多数互联网应用只要做到了一定规模,一定会有自身IM的需求,而不是单纯地仅仅依托第三方(例如微信、云信等)。

PS:关于什么是IM,您也可详读专题文章《零基础IM开发入门(一):什么是IM系统?》。

4、 携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求,这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展,也逐渐不适合日益增长的办公需求和用户体验。

2017年左右,使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生,该项目的主要目标是在采用自研IM的基础上,实现IM与办公的结合。在完善IM服务的基础上,支持了一些常规的办公场景,如电话、假单、考勤、OA等,通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入,最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目,在结合公司国际化战略的基础上,倾力打造小程序平台,服务号等基础服务。在梳理、优化原有服务的同时,打造了诸多衍生服务。

2020年中开始,在继续推进企业内办公一站式平台的基础上,我们需要支持更多的外部场景,实际需求促使我们向开放式平台转型,这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

5、携程TripPal开放平台总体架构

5.1Gateway网关层

这一层是所有请求调用流量的入口,主要功能如下:

  • 1)服务路由;
  • 2)集中式限流、风控、日志监控等功能;
  • 3)调用IDS (Identity Service) 验证请求的合法性。

第 3)步中验证通过后,可以将用户ID、Token等基本信息,通过 HttpHeader 的方式向后端服务透传,后端服务可以直接使用UserID,也可以再次对Token进行认证

5.2IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权,同时还负责令牌的颁发,以及RBAC+模块级别的接口控权。

另外,针对开放小程序,TripPal提供两种认证方式:

1)常规的Oauth第三方模式接入:

2)另一种是基于Oauth+开放平台签名的第三方认证,对于接入方相对简单:

5.3微服务层

这一层是整个系统的业务层,具体包含三种类型的微服务:

  • 1)TripPal开放平台内部系统微服务:只有在特定用户认证和权限验证通过之后,外部才能访问;
  • 2)开放平台对外提供的OpenAPI:采用Oauth+RBAC的方式控制权限;
  • 3)自研小程序后端服务:根据安全需要,所有使用Oauth+模块权限的第一方小程序服务端。

目前TripPal自身的核心微服务应用达到28个,提供全集团的多端(C端、B端)基础服务能力,服务全公司超过500个业务应用,在线C端用户均值超过2万,日访问量超过亿。

6、 TripPal的IM服务

目前TripPal使用完全自研的基于Java实现的类ejabberd架构,底层采用的XMPP协议进行通讯。

Tips:

XMPP全称是ExtensibleMessageing and Presence Protocol,可扩展消息与存在协议。是目前网络上开源,最灵活,应用最广泛的一种即时消息通信协议。

1999年Jeremie Miller,首先提出了Jabber,一种为实现即时消息和存在的开放技术,后续基于这个协议,开发了一个开源的服务实现jabberd。后续,IETF国际标准组织介入,成立Extensible Messageing and Presence Protocol(XMPP)工作组,并开始标准化工作。

2000年,jabberd服务器1.0版本发布,那时Jabber协议的基本特点(基于XML的流,消息,存在,联系人列表等)都被固定下来。

2004年,IETF出版了RFC 3902和RFC3921,定义了XMPP的核心功能,成为推荐标准。

后续在2011年,IETF出版了RFC6120和RFC 6121,更新了XMPP的核心定义,替代了之前的RFC 3920和3921。

目前XMPP协议被XMPP Standards Foundation负责管理运作,集中于在IETF定义的基础XMPP规范之上,如何开发开放的协议扩展。

IM服务端做了大量的系统性的优化,从底层的数据库调优、底层通讯服务升级,到上层消息、群、群成员等核心功能的大幅改造。

底层通讯服务由之前的erlang完整迁移至java技术栈,服务可靠性、弹性伸缩、安全性和性能获得了提升。同时对上层偏业务的服务进行了改造,极大地提升了接口响应,服务稳定性也得到了提升,为整个产品的研发提供了重要支撑。

目前这套自研的IM 3.0服务在生产环境稳定运行,整体资源消耗比2.0时期有较大下降。

7、 TripPal办公衍生服务

7.1概述

在实际的企业办公场景下,尤其是大型企业复杂组织架构和管理模式的场景下,TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用,如搜索中台,消息卡片,智能审批中台,角色服务,工作流引擎等。

本文简单介绍其中3个服务。

7.2智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务,该服务支持用户自定义整个审批单及审批流的全部细节。

 

7.3角色服务

角色服务在灵活定义角色范围及基础角色的基础上,支持用户灵活调整,动态管理,且自动接入审批中台,同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念:

7.4在线文档

在线文档服务主要提供文档的在线协作能力,支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上,在线文档是采用CRDT算法实现的无冲突merge(LastWrite Wins)、多端最终一致的分布式方案,同时兼具高可用、可容错的特性,在服务器发生故障时,允许Shift至另一台机器上继续执行,即使服务端完全宕机,客户端依然能够离线工作。

8、 TripPal高可用的实践

目前TripPal部署在3个机房,分为公有云1个机房及私有云2个机房。

总体架构在应用多机房部署、数据层跨机房DRC的基础上,采用就近访问的原则进行服务访问,其中一旦发生任意2个机房全挂的情况,都能保证系统内的核心应用仍能提供服务。

其中公有云机房的一期部署方案已经完成,二期部署方案和测试计划预计于7月完成,届时可以和大家分享一下混合云方案的一些细节和历程。

9、 开放平台的未来架构及演进方向

9.1概述

开放平台主要面向两类群体,开发者和用户。

所以主要有两个方向:

1)一是便捷开发,主要围绕降低开发者门槛、较低研发成本,打通不同开发者、应用之间的壁垒,实现生态共享。

2)另一方面,针对实际用户,在提高用户体验、数据安全的同时,实现用户服务能力整合和主动发现。

9.2开发者

在这方面,目前主流开放平台已经对开发者提供了强大的支持。

主要形式分为以下3种。

1)前端信任:

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式,来降低开发者接入门槛,减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2)低代码(Low-Code):

由于大量的互联网业务属于简单交互或模型化交互,以此为出发点,基于构建合理模型、简单业务函数等形式,可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口,可以大幅度降低开发者的研发门槛和成本,打破用户和开发者界线,提高开放平台整体生态的活力。

3)ServerLess:

基于云原生的ServerLess结合低代码,开放开发者的云端编程入口,同时提供云端基础组件,允许开发者无需部署实际的后端应用服务,极大降低的开发者的运营维护门槛。

9.3用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上,投入的都比较少,也没有比较成熟的实践,我们认为在这方面可以围绕两个点展开。

一方面:第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广,基本是应用方独立管理和推广,但是随着应用数量的大幅度增加,以及应用方单方面推广难度较大等原因,亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈,实现开放平台应用生态的可持续性和能力共享。同时,在特定场景下,结合用户分析、大数据及AI,提高用户主动或被动的应用发现能力。

另一方面:构建符合应用间开放协议的软件联盟,打破应用壁垒,围绕服务集成、开放应用的核心原则,使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下,一个复杂互联网业务通常由多个异构子业务/子应用构成,这样,通过应用拆分、开放共享等形式,在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。

9.4开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台,用于提供各种各样的信息服务,在可以预见的未来,各个平台之间会有一个整合、标准化、互通的可能性。

那么构建标准开放协议,使得开放平台向底层沉淀的过程则至关重要。

10、 本文小结

通过实现基本IM开放平台架构,以及各种衍生服务,我们总结出了IM开放平台的一些核心能力。

主要是:

  • 1)服务集成:根据不同的业务场景集成并提供相应场景下的基础服务能力;
  • 2)开放应用:提供第三方接入能力;
  • 3)高性能、高可用。

11、参考资料

[1] 零基础IM开发入门(一):什么是IM系统?

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

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

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

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

[6] 浅谈IM系统的架构设计

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

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

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

[10] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[11] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[12] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[13] 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路

[14] 基于实践:一套百万消息量小规模IM系统技术要点总结

[15] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] 直播系统聊天技术(八):vivo直播系统中IM消息模块的架构实践

[18] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[19] 得物从0到1自研客服IM系统的技术实践之路

[20] 一套分布式IM即时通讯系统的技术选型和架构设计

[21] 微信团队分享:来看看微信十年前的IM消息收发架构,你做到了吗


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

posted @ 2024-08-29 15:45 Jack Jiang 阅读(69) | 评论 (0)编辑 收藏

     摘要: 【来源申明】本文引用了微信公众号“网优雇佣军”的《是谁偷走了我家的手机信号?》文章内容。为了更好的内容呈现,下文在引用和收录时内容有改动,转载时请注明原文来源信息,尊重原作者的劳动。1、系列文章引言1.1适合谁来阅读?本系列文章尽量使用最浅显易懂的文字、图片来组织内容,力求通信技术零基础的人群也能看懂。但个人建议,至少稍微了解过网络通信方面的知识后再看,会更有收获。如果您大...  阅读全文

posted @ 2024-08-21 17:53 Jack Jiang 阅读(74) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术厉飞雨分享,原题“得物App弱网诊断探索之路”,下文进行了排版和内容优化。1、引言随着得物用户规模和业务复杂度不断提升,端上网络体验优化已逐步进入深水区。为了更好地保障处于弱网状态下得物App用户的使用体验,我们在已有的网络体验大盘、网络诊断工具的基础上研发了弱网诊断能力。该工具能够高效实时诊断用户真实网络环境,同时给出精确网络质量分级,为后续App各业务场景...  阅读全文

posted @ 2024-08-15 11:08 Jack Jiang 阅读(88) | 评论 (0)编辑 收藏

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