本文将演示一个iOS客户端程序，通过UDP协议与两个典型的NIO框架服务端，实现跨平台双向通信的完整Demo。服务端将分别用MINA2和Netty4进行实现，而通信时服务端你只需选其一就行了。同时用MINA2和Netty4分别实现服务端的目的，是因为很多人都在纠结到底是用MINA还是Netty来实现高并发的Java网络通信服务端，在此干脆两个都实现了，就看你怎么选择了，够吊吧。
本文演示的是一个Android客户端程序，通过UDP协议与两个典型的NIO框架服务端，实现跨平台双向通信的完整Demo。
由于即时通讯系统的复杂性和对服务器稳定性的很高要求，一般即时通讯系统开发至少需要1年左右的时间，而这还只是测试版，离"稳定"还有一定距离，而这时匆匆上马的不稳定的系统会让你失去用户，您也不可能召集上万台电脑进行测试，那样的成本本身已经相当高，而无论如何测试，也仍然只是测试系统。而我们的系统，是经过几年的正式使用，经受过实际高用户量稳定运行的系统。这是长时间专业积累的经验和成果。所以，需要选择与专业的音视频即时通讯开发公司合作，可以快速获得即时通讯的开发经验和一套稳定的系统。
IM发展至今，已是非常重要的互联网应用形态之一，尤其移动互联网时代，它正以无与论比的优势降低了沟通成本和沟通代价，对各种应用形态产生了深远影响。
IM App 是我做过 App 类型里复杂度最高的一类，里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制（因为我个人对移动客户端的经验积累的比较丰富嘛）。
京东的京麦商家后台2014年构建网关，从HTTP网关发展到TCP网关。在2016年重构完成基于Netty4.x+Protobuf3.x实现对接PC和App上下行通信的高可用、高性能、高稳定的TCP长连接网关。
不做任何开发，就能实现弱网环境下实现实时视频直播零卡顿，听上去是不是天方夜谭？看完这篇文章你就知道，我们是如何做到的。
京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户，以及最终根据消息协议呼起操作页面，京麦实时消息推送是一个完整且健康的生态闭环。下面我会详细的介绍下京麦实时消息推送是如何在演变中不断完善的。
即时通讯应用（包括IM聊天应用、实时消息推送应用等）开发的前期技术选型时，关于数据传输格式的选择，在即时通讯开发者同行的眼里，是个极富争议话题。
本文作者：丁同舟，来自金蝶随手记技术团队。 1、前言 本文接上篇《金蝶随手记团队分享：还在用JSON? Protobuf让数据传输更省更快(原理篇)》，以iOS端的Objective-C代码为例，向您
MobileIMSDK工程始于2013年10月，起初用作某产品的即时通讯底层实现，完全从零开发。
本次更新为次要版本更新，进行了若干优化（更新历史详见：码云 Release Nodes）。可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。
本次更新为主版本更新，更新内容包含了简化了消息发送目标的方式、支持Web版与APP版互通、优化了Protocal协议结构等主要升级，详细更新内容见“版本更新说明”部分。
本次为主要版本更新（本次更新内容见文末“MobileIMSDK v6.0更新内容 ”一节），强势升级，将同时支持TCP、UDP、WebSocket三种协议，精心封装之下，实现同一套API、三种协议同时并存。
对于即时通讯开者新手来说，在开始着手编写IM或消息推送系统的代码前，最头疼的问题莫过于到底该选TCP还是UDP作为传输层协议。本文延续《网络编程懒人入门》系列文章的风格，通过快速对比分析 TCP 和 UDP 的区别，来帮助即时通讯初学者快速了解这些基础的知识点，从而在IM、消息推送等网络通信应用场景中能准确地选择合适的传输层协议。
IM应用从服务端数据的角度来看，它是一种很特殊的应用场景，抛开基础数据、增值业务和附属功能不谈，单从IM聊天工具的立身之本——聊天数据来说，理论上是不需要在服务端存储的（或者说只需要短暂存储——比如离线消息，上线即拉走），这也是为什么微信在前段时间号称绝不存储用户聊天数据的原因（从技术上说这不是没有道理的，但到底有没有存储，这已经超越技术范畴了，不在此文讨论之列 ^_^）。
本次更新为次要版本更新，进行了bug修复和优化升级（更新历史详见：码云 Release Notes、Github Release Notes）。
自从2018年8月20日子弹短信在锤子发布会露面之后（详见《老罗最新发布了“子弹短信”这款IM，主打熟人社交能否对标微信？》），关于它的讨论不绝于耳，7 天融资 1.5 亿的传闻更是将它推到了风口浪尖（请见《[资讯] “子弹短信”发布一周即融得1.5亿资金》）。
这是由一篇我的演讲稿整理出来的文章，目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们，希望把我的经验分享出来，对大家有所帮助。
电商平台最不能缺的就是即时通讯，例如通知类下发，客服聊天等。今天，就来给大家分享一个开源的即时通讯系统。如对文章不感兴趣可直接跳至文章末尾，有获取源码链接的方法。
本文原题“读取文件时，程序经历了什么？”，本次收录已征得作者同意，转载请联系作者。本次有少许改动。
如果QQ是一个人，看似风光，其实从出生到成长，过程饱经错荡，堪算坎坷。它的人生历程确实也够励志的了。
作为即时通讯技术的开发者来说，高性能、高并发相关的技术概念早就了然与胸，什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来，又或许你对具有这些技术特征的技术框架比如：Java的Netty、Php的workman、Go的nget等熟练掌握。但真正到了面视或者技术实践过程中遇到无法释怀的疑惑时，方知自已所掌握的不过是皮毛。
一个安全的信息系统，合法身份检查是必须环节。尤其IM这种以“人”为中心的社交体系，身份认证更是必不可少。
HQ Trivia 号称直播答题的鼻祖，它是一款小知识互动游戏，由短视频社交鼻祖Vine的联合创始人拉斯-尤苏波夫和科林-克罗尔共同开发
对于很多初次接触Web端即时通讯技术的人来说，WebSocket是个很新的概念，但无疑它是当前Web端即时通讯技术中最热门的关键词。随便点开一篇文章，只要说打算开发Web端即时通讯相关的的应用，老司机们推荐的无一例外都是WebSocket。
2012 年 7 月，微信 4.2 版本首次加入了实时音视频聊天功能，如今已发展了 5 年，在面对亿级微信用户复杂多变的网络和设备环境，微信多媒体团队在每个技术细节上不断地深耕细作，为微信用户提供了高质量的视频通话。
Android端的视频相关的开发，大概一直是整个Android生态，以及Android API中，最为分裂以及兼容性问题最为突出的一部分。摄像头，以及视频编码相关的API，Google一直对这方面的控制力非常差，导致不同厂商对这两个API的实现有不少差异，而且从API的设计来看，一直以来优化也相当有限，甚至有人认为这是“Android上最难用的API之一”
实时音视频的开发学习有很多可以参考的开源项目。一个实时音视频应用共包括几个环节：采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节。每一个细分环节，还有更细分的技术模块。比如，前后处理环节有美颜、滤镜、回声消除、噪声抑制等，采集有麦克风阵列等，编解码有VP8、VP9、H.264、H.265等。
最近小妹新做了一款 APP，其中需要使用上高性能、高安全的即时通讯功能。我进行了一轮技术选型，其中包括腾讯 IM 等云服务商提供的 IM 产品。
业界上用来做即时通讯的解决方案有：1. 基于http 的轮询; 2. 基于websocket 长连接; 3. 基于tcp或udp的自定义协议, 这种若在要在Web端使用, 需要套一层websocket 封装. 此外早期还有基于Comet 技术的长连接，基于xmpp 的开源客户端应用等。
一个完善的IM系统中通常充斥着大量的图片内容，包括：用户头像、图片消息、相册、图片表情等等，那么在做服务端架构设计时该如何存储这些图片呢？
黑莓为自家的即时通讯软件BBM推出企业版软件开发工具包（Enterprise SDK），有了这个SDK，企业应用开发者挑选安全信息系统时有了新的选择，可以让开发者将黑莓的信息技术植入iOS或者Andr
即时通讯是端开发工作中常见的需求，本篇文章以作者工作中使用FLutter开发社交软件即时通讯需求为背景，描述一下即时通讯功能设计的要点。
微信小程序自2017年1月9日正式对外公布以来，越来越受到关注和重视，小程序上的各种技术体验也越来越丰富。而音视频作为高速移动网络时代下增长最快的应用形式之一，在微信小程序中也当然不能错过。本文来自腾讯视频云终端技术总监rexchang（常青）的技术分享，讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容，希望能为你的音视频技术实践带来启发。
随着瓜子二手车相关业务的发展，公司有多个业务线都接入了IM系统，IM系统中的Socket长连接的安全问题变得越来越重要。本次分享正是基于此次解决Socket长连接身份安全认证的实践总结而来，方案可能并不完美，但愿能起到抛砖引玉的作用，希望能给您的IM系统开发带来启发。
2017 年 12 月，微信小程序向开发者开放了实时音视频能力，给业内带来广阔的想象空间。连麦互动视频直播技术在 2016 年直播风口中成为视频直播的标配，然而只有在原生的 APP 上才能保障良好的用户体验。
国庆结束，宅在家里的我 通过朋友圈，弹指间游遍全球 斯里兰卡 ▽ 马尔代夫 ▽ 新疆火烧云 ▽ …… 这些照片，主要有2种风格 浮夸型，滤镜、美颜、风格，生成ins网红景点 自然型，iphone自带编辑，朋友圈的一股清流 一些热门拍摄、美图的App 也逐渐增加社交板块 似乎从拍摄剪辑到直播聊天，是顺理成章的事情 那么， 以拍摄录制起家的app， 是如何搞定百万日活用户的并发聊天？ 这里抛出一个问题 即时通讯IM功能会面临哪些挑战？亿万级消息并发？稳定容灾的安全性？ 今天，我们从“百万聊
广州TIT创意园，这里是腾讯在广州的研发团队所在地，LiveVideoStack采访了微信多媒体内核中心音视频算法高级工程师梁俊斌（Denny）。从华为2012实验室到腾讯，过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack：音频技术还有许多难点需要解决，而作为技术人也延展到应用场景，关注用户需求。本文整理了本次访谈的主要内容，仅供参阅。
自从苹果公司在iPhone 4引入了视网膜屏幕的概念以来，手机的分辨率自此开始突飞猛进。当前，1920x1080甚至更高的分辨率已经成为了标配。不过当我们谈到实时音视频聊天的时候，无奈受制于上行带宽，有相当一部分用户还是只能发送码率在250kbps以下的小分辨率视频码流，这就白白浪费了用户的高清手机屏幕。
这是一个云计算的时代。 这是一个互联网的时代。 这是一个分工合作，快速奔跑的时代。 云计算的概念在国内经过多年的造势与推广已经逐渐的落地，随着IaaS、SaaS和PaaS服务模式的不断落地，云计算对于传统的各大软件、硬件服务行业产生了巨大的影响。 云计算的出现打破了地域的概念，打破了传统企业以及互联网开发人员对于资源配置的观点，几乎所有的计算和存储资源都集中到了“云”端，用户端将变得越来越简单。通过虚拟化技术，“云”端的资源将被用户以租用方式使用，用户不再需要自己购置和升级软硬件。 相较于云计算对于软、硬件
没错，分布式IM即时通讯系统已经上线双向视频通话功能，至此，已完全支持发送文本消息、表情消息、图片消息、文件消息、语言消息和双向视频通话。所有的功能从需求、原型、设计、架构、编码，到测试、部署、运维，冰河都为你安排的妥妥的。
以现在主流的即时通讯应用形态来讲，一个完整的即时通讯IM应用其实是即时通信（英文简写：IM=Instant messaging）和实时通信（英文简写：RTC=Real-time communication）2种技术组合在一起的一整套网络通信系统。之所以以IM这个简写代称整个即时通讯软件，其实是历史原因了（因为早期的诸如ICQ这样的即时通讯工具，也就是文字聊天，并没有加入实时音视频这样的实时通信技术），对这个话题有兴趣的可以到网上查一查IM的发展历史。
在安卓（Android）和苹果（iOS）设备之间实现短信发送技术主要包括两种方式：RCS (Rich Communication Services) 和 IM (Instant Messaging) 服务。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
