笔者从信息分类出发，对数据传输进行了分析并总结了三种主要的现象级方案，供大家参考与学习。

信息传输好比产品的血液流动。

产品经理有必要大致了解数据传输的边界、场景、基本方案，以参与项目的排期、控时、选型。

信息传输的方式，决定了可实现场景的边界。目前的传输方式主要如下：

1. 在线直传：不经过服务器，进行直传；
2. 在线代理：消息经过服务器 中转 到达目标账号；
3. 离线代理：消息经过服务器 中转 到达目标账号 对方不在线 消息暂存服务器的数据库,在其上线再传发；
4. 离线扩展：将暂存消息以邮件，短信等方式转发给目标账号。

这些传输方式有不同的实现方案。为了更概括抽象，笔者从信息分类角度出发，总结了三种主要的现象级方案。

一、实时且高频的信息传递——IM

一些功能，对信息响应的及时性和频率要求高，比如App中的实时聊天（就像陌陌的聊天）、匹配交友（类似SOUL的语音匹配），对战游戏（如王者荣耀）等。

这些场景往往是“在线等”的态势，毫秒级别的误差就可能会导致产品的坍塌。

那么通常是使用什么信息交互技术实现的呢？

通常会使用IM机制（Instant Messaging）。即时通讯，就是识别在线用户，并与他们实时交换消息。

IM是一个成熟的机制，该体系中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步、存储和检索。

IM工作流程：

这样就无需每次信息发出，都要从客户端到服务器进行“握手”访问，减少了大量的延迟和丢失数据风险。

打比方，IM无需每次都拿钥匙开门了，而是门就给你开着，进出不限次数。避免了丢钥匙的风险和开门的时间浪费。

IM通常是配合“长链接”（后面还会提到）技术实现的。可以公司自己研发，多数时是使用第三方IM的SDK，比如云信。

以IM为内核的产品，比如钉钉、微信、QQ等。

非以IM系统为核心的应用，最典型的如一些在线游戏、社交应用等。

二、及时性要求不太高的信息传递——接口

作品评论、点赞、收藏这样的功能，对时效要求低于上面提到的实时聊天。

这种功能一般是通过常规的HTTP接口请求方式实现的。也就是信息源头发起请求，服务器收到请求进行处理，再返回给目标服务器。

这种信息传递机制在产品中使用的最普遍，研发成本小。比如双击【抖音】的底部【首页】菜单，视频刷新。

其流程就是：客户端触发——发起消息——刷新数据。

当然用户不请求，也能自动刷新呢？可以通过定时任务，或死循环等方式实现。

原理就是按照设定的频率，自动请求服务器。好像每隔一会打开一次朋友圈，看有没有人点赞一样。

关于HTTP请求的扩展

（1）短轮询和长轮询

轮询：就是户端定期去向服务端询问是否有新的消息；服务端见到客户端来询问，就告诉它。

这种方案最简单，但是却不适用于即时通讯产品，因为即时通讯软件的消息传递机制与一般的消息推送的区别就在即时这点，如果采用轮询的方式，客户端每几秒就连一次服务器，对于手机电量与流量的消耗是很大的。

• 短轮询（short-polling）：是指服务端收到请求后，无论是否有数据都立即返回。
• 长轮询（long-polling）：指服务端收到请求后若有数据立即返回，若无数据则保持到有数据时返回，或一段时间后超时才结束。

（2）短连接和长连接

• 短连接（short connection）：就是请求一次，建立一次连接，任务结束就中断，不再复活。
• 长连接（long connection）：执行握手链接后，不断开链接，保持客户端和服务端通信，直到服务器超时自动断开链接，或者客户端主动断开链接。

适用于操作频繁、点对点通讯，且连接次数不是太多。

三、退出应用或后台状态下的信息发送——推送

比如App退出之后，还会有顶部横幅提醒。

这通常是通过服务器的推送机制实现的。该推送技术叫做Serverpush：客户端是否在线都可以被唤起。

简单地说，就是不管你要不要消息（在用户手机系统设置为同意接收来自应用的消息推送通知情况下），都可以把消息推到你手机的通知栏，或者app右上角有角标。

推送可以第一时间把想要传达给用户的消息发出去，因为很多用户其实也不知道自己需要怎么样的信息。

推送方案的公认评价采取4s标准：Safe(安全)、Stable（稳定）、Save（省电省流量省成本）、Slim（体积小）。

目前国内主要使用第三方的推送功能，比如个推、腾讯的信鸽。

（1）为什么要推送

每个月用户手机里都装有几十款应用，而现在生活节奏快，即便是很不错的应用也可能几天不用就忘掉了，因此为了提醒用户应用的存在性，同时给用户带来一些价值，比如手游类应用送道具，电商类应用送优惠券等。

归根结底，推送的目的是提升应用的活跃度和留存率。

（2）为什么要用第三方推送

自建通道尤其是创业团队，会耗费一定的人力，同时在推送的关键指标如抵达率、精准推送等方便是个很大挑战。

总结

由于数据量、及时性、容错、硬件性能、生态集群、技术发展等方面的差别，导致移动产品的数据传输方案，不同于后台类产品的数据传输（参考文章《系统间数据对接的逻辑和机制》）。

本文粗浅的总结，源自于实际工作的积累总结。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议