Jack Jiang

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

置顶随笔

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2023年3月30日

     摘要: 本文由得物技术团队Uni分享,即时通讯网收录时有内容修订和排版优化。一、引言本文要分享的是得物技术团队基于Electron开发客服IM桌面端的技术实践过程,内容包括桌面技术选型、Electron的基础概念、具体的实施技术方案、遇到的棘手问题等。Electron社区虽然很活跃,但是不一样的场景遇到的技术问题,几乎找不到对应的解决方案,我们很多都是在探索过程中不断的去完善,希望本文能带给你一些启发。学...  阅读全文

posted @ 2023-03-30 13:38 Jack Jiang 阅读(23) | 评论 (0)编辑 收藏

2023年3月23日

     摘要: 一、本文内容概述WiFi对于现在的家庭来说,属于司空见惯的上网方式,但很多情况下,家里房间多、空间大、杂物乱的情况下,WiFi的信号就受影响。为什么WiFi信号会受影响?什么情况下该使用何种方式组网?如何改善WiFi信号差的问题?等等,本文将通俗易懂地为你找到这些问题的答案。学习交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》- 开源IM框架源码:https://gith...  阅读全文

posted @ 2023-03-23 14:53 Jack Jiang 阅读(30) | 评论 (0)编辑 收藏

为了更好地分类阅读52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第10 期。

[-1-] 简述传输层协议TCP和UDP的区别

[链接http://www.52im.net/thread-580-1-1.html

[摘要] 本文将从应用层的角度,简要的对比TCP和UDP协议的区别,或许能给你些许启发。


[-2-] 为什么QQ用的是UDP协议而不是TCP协议?

[链接http://www.52im.net/thread-279-1-1.html

[摘要] QQ既有UDP也有TCP!不管UDP还是TCP,最终登陆成功之后,QQ都会有一个TCP连接来保持在线状态。这个TCP连接的远程端口一般是80,采用UDP方式登陆的时候,端口是8000。


[-3-]移动端即时通讯协议选择:UDP还是TCP?

[链接http://www.52im.net/thread-33-1-1.html

[摘要]对于有选择困难证的人来说,基于以上因素,加上UDP和TCP协议的本质差异,这样的选择确实很纠结。本文将从作者的实践总结,给出自已的观点,如有异议还请理性回复,不为找喷,仅供参考。


[-4-]快速理解TCP和UDP的差异

[链接http://www.52im.net/thread-1160-1-1.html

[摘要] 本文延续《网络编程懒人入门》系列文章的风格,通过快速对比分析 TCP 和 UDP 的区别,来帮助即时通讯初学者快速了解这些基础的知识点,从而在IM、消息推送等网络通信应用场景中能准确地选择合适的传输层协议。


[-5-] 快速理解为什么说UDP有时比TCP更有优势

[链接http://www.52im.net/thread-1277-1-1.html

[摘要] 随着网络技术飞速发展,网速已不再是传输的瓶颈,UDP协议以其简单、传输快的优势,在越来越多场景下取代了TCP,如网页浏览、流媒体、实时游戏、物联网。本文作为《网络编程懒人入门》系列文章的第5篇,将为您快速梳理UDP协议在某些场景下对比TCP协议所具有的优势。


[-6-] UDP的连接性和负载均衡

[链接http://www.52im.net/thread-1018-1-1.html

[摘要]本文将从实践出发,讨论UDP在实际应用中的连接性和负载均衡问题。


[-7-] 深入地理解UDP协议并用好它

[链接] http://www.52im.net/thread-1024-1-1.html

[摘要] 本文接系列文章的上篇《不为人知的网络编程(五):UDP的连接性和负载均衡》,将从实践出发,讨论如何深入地理解UDP协议并在实践中用好它。


[-8-] 如何让不可靠的UDP变的可靠?

[链接http://www.52im.net/thread-1293-1-1.html

[摘要] 涉及到实时传输我们都会先考虑 RUDP,RUDP 应用在我们APP核心传输体系的各个方面,但不同的系统场景我们设计了不同的 RUDP 方式,所以基于那些激烈的讨论和我们使用的经验,我决定扒一扒 RUDP,来给大家分享如何让UDP变的可靠的实践经验。


[-9-] 从底层入手,深度分析TCP连接耗时的秘密

[链接http://www.52im.net/thread-3265-1-1.html

[摘要] 经过日常工作的思考之后,我更想弄明白的是,TCP的开销到底有多大,能否进行量化。一条TCP连接的建立需要耗时延迟多少,是多少毫秒,还是多少微秒?能不能有一个哪怕是粗略的量化估计?当然影响TCP耗时的因素有很多,比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。


[-10-]彻底搞懂TCP协议层的KeepAlive保活机制

[链接http://www.52im.net/thread-3506-1-1.html

[摘要] 限于篇幅,该篇并没有深入探讨TCP协议本身的KeepAlive机制,所以这次借本文想把TCP协议的KeepAlive保活机制给详细的整理出来,以便大家能深入其中一窥究竟。


[-11-] 拔掉网线再插上,TCP连接还在吗?一文即懂

[链接http://www.52im.net/thread-3846-1-1.html

[摘要] 本篇文章,我们就从系统层面深入地探讨一个有趣的TCP技术问题:拔掉网线后,再插上,原本的这条TCP连接还在吗?或者说它还“好”吗?


[-12-] 单台服务器并发TCP连接数到底可以有多少

[链接http://www.52im.net/thread-561-1-1.html

[摘要] 到底一台服务器能够支持多少TCP并发连接呢?这就是本文要讨论的问题。


👉52im社区本周新文:《得物从0到1自研客服IM系统的技术实践之路》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-03-23 10:42 Jack Jiang 阅读(43) | 评论 (0)编辑 收藏

2023年3月9日

     摘要: 1、前言最近我负责的 LiveChat 客服聊天系统到了自研阶段,任务类似于做一个腾讯云IM这样的通信层SDK。在和后台进行技术选型讨论后,确定了数据传输层协议格式使用 Protobuf。本文基于我对Protobuf在Android端的实际使用心得,手把手教你如何在Android端IM产品中使用Protobuf,希望对你有帮助。学习交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动...  阅读全文

posted @ 2023-03-09 14:30 Jack Jiang 阅读(38) | 评论 (0)编辑 收藏

2023年3月6日

1、项目简介

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

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

2、代码托管同步更新

GitHub.com:

码云gitee:

3、设计目标

让开发者专注于应用逻辑的开发,底层复杂的即时通讯算法交由SDK开发人员,从而解偶即时通讯应用开发的复杂性。

4、框架组成

整套MobileIMSDK框架由以下6部分组成:

  • 1)Android客户端SDK:用于开发Android版即时通讯客户端,支持Android 2.3及以上版本,查看API文档
  • 2)iOS客户端SDK:用于开发iOS版即时通讯客户端,支持iOS 8.0及以上版本,查看API文档
  • 3)Java客户端SDK:用于开发跨平台的PC端即时通讯客户端,支持标准Java 1.6及以上版本,查看API文档
  • 4)H5客户端SDK:暂无开源版,查看精编注释版
  • 5)小程序端SDK:持续开发中,敬请关注;
  • 6)服务端SDK:用于开发即时通讯服务端,支持Java 1.7及以上版本,查看API文档

整套MobileIMSDK框架的架构组成:

5、技术特征

  • 久经考验:历经8年,从Andriod 2.3、iOS 5.0 时代持续升级至今(绝不烂尾);
  • 超轻量级:高度提炼,lib包50KB以内;
  • 多种协议:可能是全网唯一开源可同时支持UDP、TCP、WebSocket三种协议的同类框架;
  • 多种网络:精心优化的TCP、UDP、WebSocket协议实现,可应用于卫星网、移动网、嵌入式物联网等场景;
  • 高效费比:独有的UDP协议实现,无连接特性,同等条件下可实现更高的网络负载和吞吐能力;
  • 消息走向:支持即时通讯技术中消息的所有可能走向,共3种(即C2C、C2S、S2C);
  • 粘包半包:优雅解决各端的TCP经典粘包和半包问题,底层封装,应用层完全无感知;
  • QoS机制:完善的消息送达保证机制(多重保障),不漏过每一条消息;
  • 健壮可靠:实践表明,非常适于在高延迟、跨洲际、不同网络制式环境中稳定、可靠地运行;
  • 断网恢复:拥有网络状况自动检测、断网自动治愈的能力;
  • 原创算法:核心算法和实现均为原创,保证了持续改进和提升的空间;
  • 多种模式:预设多种实时灵敏度模式,可根据不同场景控制即时性、流量和客户端电量消耗;
  • 数据压缩:自有协议实现,未来可自主定制数据压缩,灵活控制客户端的流量、服务端网络吞吐;
  • 高度封装:高度封装的API接口,保证了调用的简易性,也使得可应用于更多的应用场景;
  • Web支持:可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;
  • 扩展性好:服务端基于Netty,继承了Netty的优秀高可扩展性;
  • 性能优异:服务端继承了Netty高性能、高吞吐特性,适用于高性能服务端场景。

MobileIMSDK 所支持的全部3种即时通讯消息走向分别是:

(1) Client to Client (C2C):即由某客户端主动发起,接收者是另一客端;

(2) Client to Server (C2S):即由某客户端主动发起,接收者是服务端;

(3) Server to Client (S2C):即由服务端主动发起,接收者是某客户端。

6、性能测试

压力测试表明,MobileIMSDK用于推送场景时,理论单机负载可接近千万级。用于聊天应用时,单机负载也可达数十万。

当然,每款应用都有各自的特点和差异,请视具体场景具体评估之,测试数据仅供参考。

性能测试报告:点此查看

7、演示程序

8、应用案例

RainbowChat是一款基于MobileIMSDK的产品级聊天APP,更多详情:点击下载体验 或 查看运行截图

① 基于MobileIMSDK的产品级聊天APP:

▶ 详细介绍下载体验 或 查看运行截图

② MobileIMSDK在高网络延迟下的案例:

▶ 某款基于MobileIMSDK的商业商品,曾运营于跨洲际的复杂网络环境下,端到端通信延迟在洲际网络繁忙时可高达600ms以上(与服务端的单向延迟约为300ms左右,而通常大家访问国内主流门户的延迟约为20~50ms),某段时期的非敏感运营数据 点此查看

9、打包下载(all in one)

说明:最新发布版打包内容中,已包含完整的demo源码、sdk源码、api文档、编译后的分发包等。

10、典型应用场景

场景1:聊天APP

  • 应用说明:可用于开发类似于微信、QQ等聊天工具。
  • 消息走向:需使用C2C、C2S、S2C全部类型。

特别说明:MobileIMSDK并未定义聊天应用的应用层逻辑和协议,开发者可自行定义并实现之。

场景2:消息推送

  • 应用说明:可用于需要向客户端实时推送信息的各种类型APP。
  • 消息走向:仅需使用S2C 1种消息走向,属MobileIMSDK的最简单应用场景。

场景3:企业OA

  • 应用说明:可用于实现企业OA的指令、公文、申请等各种消息实时推送,极大提升用户体验,并可延伸至移动设备。
  • 消息走向:仅需使用S2C 1种消息走向,属MobileIMSDK的最简单应用场景。

场景4:企业OA的增强型

  • 应用说明:可用于实现企业OA中各种系统级、用户级消息的实时互动,充分利用即时通讯技术提升传统OA的价值。
  • 消息走向:可使用C2C、C2S、S2C全部类型,这与聊天APP在很多方面已无差别,但企业OA有自已的用户关系管理模型和逻辑,较之全功能聊天APP要简单的多。

11、开发指南

12、关注作者

博客地址:点击入进、Github主页:点击进入

附录1:Demo截图

1)Android和iOS运行效果

>> 安装和使用:进入Android版Demo帮助页进入iOS版Demo帮助页

2)Windows 运行效果

>> 安装和使用:进入Java版Demo帮助页

3)Mac OS X 运行效果

>> 安装和使用:进入Java版Demo帮助页

附录2:基于MobileIMSDK的全功能IM【案例】

>> 关于RainbowChat的更多资料请见:RainbowChat前端APP功能截图网页 。

 

附录3:基于MobileIMSDK-Web的网页端IM系统【案例】

下图为RainbowChat-Web的主界面(更多截图点此进入更多演示视频点此进入):

posted @ 2023-03-06 12:21 Jack Jiang 阅读(38) | 评论 (0)编辑 收藏

2023年3月2日

     摘要: 1、引言我相信大家刚开始学网络编程中socket的时候,都跟我一样对书上所讲的socket概念云里雾里的、似懂非懂,很是困扰。这篇文章我打算从初学者的角度,用通俗易懂的文字,跟大家分享下我所理解的socket是什么,并由浅入深从操作系统内核实现来透视socket的原理。* 推荐阅读:跟本篇类似,《到底什么是Socket?一文即懂!》一文也非常适合初学者。另一篇《我们在读写Socket时,究竟在读写...  阅读全文

posted @ 2023-03-02 14:25 Jack Jiang 阅读(47) | 评论 (0)编辑 收藏

2023年3月1日

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOSAndroidH5标准Java平台,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► iOS端更新记录:http://www.52im.net/thread-2735-1-1.html
► 全部运行截图:iOS端全部运行截图 (另:Android端运行截图 点此查看
► 在线体验下载:App Store安装地址 (另:Android端下载体验 点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架 MobileIMSDK 实现)。

v6.2 版更新内容

此版更新内容更多历史更新日志):

  • 1)[优化] 升级核心通信层库 MobileIMSDK 至 v6.3
  • 2)[优化] 提供了方便的配置用于开/关长连接的SSL/TLS加密传输。

此版主要功能运行截图更多截图点此查看):

posted @ 2023-03-01 12:05 Jack Jiang 阅读(28) | 评论 (0)编辑 收藏

2023年2月23日

     摘要: 1、引言对于IM聊天应用来说,为了提升安全性,对聊天消息加密是常规操作。众所周之,Netty是高性能的Java NIO网络通信框架,因而用Netty来写IM是再正常不过了。网上关于为Netty生成、以及使用SSL/TLS证书的文章有很多,但由于各种原因,生成的证书要么是Netty中无法读取和使用,要么是代码不全或不具体导致根本配不通SSL/TLS加密。正好这段时间专门为 MobileIM...  阅读全文

posted @ 2023-02-23 14:18 Jack Jiang 阅读(56) | 评论 (0)编辑 收藏

2023年2月16日

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、标准Java平台,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► 版本更新记录:http://www.52im.net/thread-1217-1-1.html
► 全部运行截图:Android端iOS端
► 在线体验下载:专业版(TCP协议)专业版(UDP协议)      (关于 iOS 端,请:点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

* RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。

v8.4 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容通信核心层优化!】:

  • 1)[优化] 可根据http接口的url自动判断并启用https加密;
  • 2)[优化] 升级核心长连接通信层库 MobileIMSDK 至 v6.3
  • 3)[优化] 提供了灵活的接口定制和开启长连接的SSL/TLS加密传输。

(2)服务端主要更新内容:

  • 1)[优化] 升级核心长连接通信层库MobileIMSDK 至 v6.3
  • 2)[优化] 开放了灵活的接口定制和开启长连接的SSL/TLS加密传输。

此版主要功能运行截图更多截图点此查看):

posted @ 2023-02-16 10:42 Jack Jiang 阅读(51) | 评论 (0)编辑 收藏

2023年2月14日

本文作者:丁同舟,来自金蝶随手记技术团队。

1、引言

接上篇《金蝶随手记团队的Protobuf应用实践(原理篇)》,本文将以iOS端的Objective-C代码为例,图文并茂地向您菔救绾卧趇OS工程中快速使用Protobuf,希望对你有帮助。

 

学习交流:

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

2、系列文章

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

另外:如果您还打算系统地学习IM开发,建议阅读《新手入门一篇就够:从零开发移动端IM》。

3、基本介绍

 

Protobuf(全称 Protocol buffers) 是 Google 提出的一种跨平台、多语言支持且开源的序列化数据格式。相对于类似的 XML 和 JSON,Protobuf 更为小巧、快速和简单。相对于传统的 XML 和 JSON, Protobuf 的优势主要在于:更加小、更加快,其语法目前分为proto2和proto3两种格式。

如果你没不了解Protobuf是什么,建议先阅读本系列的前几篇《Protobuf从入门到精通,一篇就够!》、《快速理解Protobuf的背景、原理、使用、优缺点》、《金蝶随手记团队的Protobuf应用实践(原理篇)》,本篇就不再重复介绍了。

目前 Google 官方的 Protobuf最新 release 版本为3.21.12,但本文写作时用的是3.5.1,以下截图都是基于此版本的环境搭建,如果你使用最新版本,差异并不大,因为只是小版本更新。

关于 Protobuf的使用可以查阅官方文档:https://developers.google.com/protocol-buffers/docs/overview,建议养成阅读文档的习惯。

4、准备工作

4.1环境要求

最低开发环境要求:

  • 1)Objective-C 2.0 Runtime (32bit & 64bit iOS, 64bit OS X)
  • 2)Xcode 7.0 以上版本

注意:Protobuf 出于性能考虑没有使用 ARC,但在 ARC 下是可以使用的。

4.2下载安装

下载 Protobuf 代码包(https://github.com/protocolbuffers/protobuf/releases/tag/v21.12),因文章截图时用的是v3.5.1,所以我这里的为了保持一致选择的是 protobuf-objectivec-3.5.1.tar.gz,版本区别不大,建议依此类推。

4.3解压代码包

编译 Protobuf,这里可能需要安装部分工具:

$ brew install autoconf

$ brew install automake

$ brew install libtool

运行下面脚本进行编译:

$ ./autogen.sh

$ ./configure

$ make

$ makeinstall

检查protobuf是否安装成功:

$ protoc --version

如果成功打印版本号则安装成功:

libprotoc 3.5.1

5、在 iOS 中使用 Protobuf

5.1创建.proto文件

这里使用官方文档上的一份示例数据结构创建Person.proto:

syntax = "proto3";

 

message Person {

  string name = 1;

  int32 id = 2;

  string email = 3;

 

  enumPhoneType {

    MOBILE = 0;

    HOME = 1;

    WORK = 2;

  }

 

  message PhoneNumber {

    string number = 1;

    PhoneType type = 2;

  }

 

  repeated PhoneNumber phone = 4;

}

使用命令行编译Person.proto为objective-c的文件,编译出来的文件为Person.pbobjc.h和Person.pbobjc.m:

protoc Person.proto --objc_out=./

5.2引入 Protobuf 运行时资源

Google 官方的文档提供了两种引入方式,但使用第一种的时候编译不能通过,所以这里选择了第二种。

具体就是:复制protobuf目录下的:objectivec/*.h, objectivec/google/protobuf/*.pbobjc.h, objectivec/google/protobuf/*.pbobjc.m, 以及除去 objectivec/GPBProtocolBuffers.m 后的objectivec/*.m。

这里直接用命令行操作。

首先进入protobuf下objectivec的目录:

$ cdprotobuf-3.5.1/objectivec

然后复制符合规则的文件到指定的工程目录下:

$mkdir~/ProtobufDemo/ProtocolBuffers~/ProtobufDemo/ProtocolBuffers/google~/ProtobufDemo/ProtocolBuffers/google/protobuf

$ cp*.h *.m ~/ProtobufDemo/ProtocolBuffers

$ cpgoogle/protobuf/*.pbobjc.h google/protobuf/*.pbobjc.m ~/ProtobufDemo/ProtocolBuffers/google/protobuf

注意:上面的命令并没有排除 GPBProtocolBuffers.m 文件,引入时需要手动排除。

现在把ProtocolBuffers目录下所有文件以及上面编译出来的 Person.pbobjc.h 和 Person.pbobjc.m 都引入到工程中。

现在工程目录结构大概是长这样:

 

注意:由于protobuf没有使用 ARC,因此需要为所有.m文件加上-fno-objc-arc来关闭 ARC。

结果如下:

提示:需要留意工程中的 Header Search Paths 要增加 $(PROJECT_DIR)/ProtocolBuffers(具体的路径视情况而定)

5.3直接引入 ProtocolBuffers 工程

如果觉得手动引入文件的方式过于复杂,可以直接引入ProtocolBuffers工程作为依赖项。

1)进入解压后的protobuf目录下,复制objective目录下的所有文件到ProtobufDemo/ProtocolBuffers目录下。

2)在ProtobufDemo工程中引入ProtocolBuffers_iOS工程:

3)在Build Phases中加入依赖关系并链接库:

 

4)引入Person.pbobjc.hPerson.pbobjc.m文件并为.m加上-fno-objc-arc

5)修改工程配置中部分路径为 $(PROJECT_DIR)/ProtocolBuffers

5.4运行测试

首先引入头文件:

#import "Person.pbobjc.h"

生成Person对象并进行编码和解码:

Person *p = [[Person alloc] init];

p.id_p = 1;

p.name = @"person1";

p.email = @"123@qq.com";

 

//encode

NSData*data = [p data];

NSLog(@"Protocol Buffers:\n%@\nData: %@\nData Length: %lu", p, data, data.length);

 

//decode

Person *newP = [[Person alloc] initWithData:data error:nil];

NSLog(@"Decoded: %@", newP);

运行程序,打印日志如下:

Protocol Buffers:

<;Person 0x60c0000da2b0>: {

    name: "person1"

    id: 1

    email: "123@qq.com"

}

Data: <0a077065 72736f6e 3110011a 0a313233 4071712e 636f6d>

Data Length: 23

Decoded: <;Person 0x6040000d9c90>: {

    name: "person1"

    id: 1

    email: "123@qq.com"

}

6、参考资料

[1] Protobuf 官方开发者指南(中文译版)

[2] Protobuf官方手册

[3] Protobuf从入门到精通,一篇就够!

[4] 如何选择即时通讯应用的数据传输格式

[5] 强列建议将Protobuf作为你的即时通讯应用数据传输格式

[6] APP与后台通信数据格式的演进:从文本协议到二进制协议

[7] 面试必考,史上最通俗大小端字节序详解

[8] 移动端IM开发需要面对的技术问题(含通信协议选择)

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

[10] 理论联系实际:一套典型的IM通信协议设计详解

[11] 58到家实时消息系统的协议设计等技术实践分享

[12] 金蝶随手记团队的Protobuf应用实践(原理篇)

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

Coffee time!

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

posted @ 2023-02-14 12:52 Jack Jiang 阅读(31) | 评论 (0)编辑 收藏

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