引用：http://baike.baidu.com/view/3250601.htm IP Push基于HTTP协议。邮箱客户端会保持一个固定的IP地址，当邮箱客户端需要收到新邮件通知时，向服务器发出HTTP请求；服务器则将一直保持这个连接。当服务器有新邮件到来时，服务器会在第一时间将新邮件推送给客户端，从而实现Push Mail的一种方式。   目录 简介 什么是PUSH？ Push Mail的特点 实现原理 邮件服务商提供的IP PUSH服务 展开   编辑本段简介 IP push的弊端： 　　需要保持网络在线。无论使用手机还是电脑，设备必须保持互联网在线。 常见疑问： 　　1、耗电量。保持时刻的在线，即便是不刷新数据和传递数据，也会有50%以上的（待机对比）耗电量消耗，这显然不符合目前的低碳生活；   　　解决办法：合理安排工作时间，减少在非工作时间或处于PC前工作时的GPRS连接；   　　2、关机重启则失效。   　　一般的移动设备需要通过第三方软件实现IP Push的功能，而Windows、Android和Symbian等手机系统已包含相关功能，因此可以无需安装其他客户端。   　　但是通过第三方软件实现的IP Push功能的移动设备，重启后会失效，无法正常实现邮件的接收。   　　解决办法：设置第三方软件为开机自动重启，并允许其自行访问网络注册。   　　弊端：降低了一定的开机速度。   　　3、辐射问题。(有争议，目前并无充足科学研究证据手机辐射对人体有影响)   　　通过GPRS访问网络会带来一定的辐射，此种辐射对于心脏病人和孕妇会有较大的影响，而未连接GPRS的移动设备辐射值明显要低于保持在线的移动设备。   　　解决办法：照顾自己的身体和家人的健康，切记不要在老人、孩子和孕妇身边常保持GPRS在线。可以设置一定的时间访问网络查找邮件的更新（第三方软件一般带有此功能，Windows、Android和Symbian的客户端支持此设置。）   编辑本段什么是PUSH？ 　　这里的PUSH是特指push mail。   　　PushMail指的是利用推送技术，将电子邮件直接传送到移动终端。简单的说，就是系统直接将电子邮箱中刚刚收到的邮件即时发送到用户手中，不像传统移动邮件系统那样必须依赖移动终端定期接/收邮件或用户主动检查邮箱，所以客户终端上时刻都能够与所指定的信箱维持同步的资料。 当你有新邮件时，服务器会在第一时间将这个消息“推”给你。相比传统的定时收信（即所谓的“拉”技术），Push的好处是可以让你更快地收到邮件。比如用foxmail客户端，设置了5分钟自动收信，当一封信在一个随机的时间发出之后，需要平均等待2.5分钟才可以得到通知，而如果服务器可以Push给你，就只需等待一个网络延时。而遗憾的是，在广泛使用的pop3或imap协议中，并没有考虑到Push机制，因此Push功能需要额外的开发和协议规定。   编辑本段Push Mail的特点 　　Push Mail是将邮件主动推送到手机终端的移动邮件解决方案，能随时将企业邮件推送到用户手机终端上，实现关键信息随时、随地、随身获得。   　　1、主动将新邮件推送到手机终端，用户不用任何操作   　　2、可直接在手机上查看附件   　　3、可国际漫游，GPRS网络覆盖的地方都能使用   　　4、支持采用高可靠性的SSL安全加密措施   　　5、流量少、费用低   编辑本段实现原理 　　SP服务商提供的EMN PUSH（即SMS Push）服务（这里以中国移动为例）   　　中国移动加密Push Mail平台，完整结构如下：   　　中国移动安装有一套邮件推送网关（GEGW：GPRS Email Gateway），负责向手机发送EMN短信，建立和维护CEF和手机之间的加密传输通道；在企业端安装邮件代理网关（CEF：Corporation Email Forward），负责从企业邮件服务器收取邮件缓存在本地，负责对邮件附件进行压缩和转换；在用户手机上安装Push Mail客户端软件，在手机上提供一个完整的邮箱功能，负责接收、存储、转发、回复、新建邮件。   　　当有新邮件到达时，CEF通过GEGW发送EMN短信到手机终端，触发用户手机Push Mail客户端，通过GPRS网络连接GEGW，与CEF建立一条端到端的SSL加密通道连接，取得邮件。   编辑本段邮件服务商提供的IP PUSH服务 　　只有运营商可以提供Push，而他们又盯上了邮箱这个领域，其他邮箱运营的公司要想和移动竞争，似乎已经输在了起跑线上，然而事情并非如此。与传统稳重的大国企相比，新兴IT公司的优势就是具有不断的创新精神和强大的开发团队。其实Push不一定非要通过SMS实现，用Internet也可以。通过网络，手机客户端可以发送一个HTTP请求到服务器，告知服务器客户端需要这个用户的新邮件通知，当服务器收到一封新邮件时，就会回复这个HTTP请求；客户端通知用户收到了新邮件，并同时再次与服务器建立连接，等待下一封信。有些人觉得只有“SMS Push”才是真Push，IP Push是伪Push。他们为什么会这么想呢？因为他们觉得IP Push需要保持连接，浪费了流量、电量、网络资源。那事实是这样吗？其实并非如此。我们首先思考这样一个问题，你打电话给你的朋友，为什么基站在很短几秒钟之内就可以通知到对方的手机有一个来电呢？那是因为其实基站时刻都在跟你的手机保持着连接。所以SMS path也需要“保持连接”，再进一步思考，其实只要能够保持和基站的连接，其实就已经可以保持网络连接了，而其实等待一个HTTP的响应（reponse）或者说维持一个TCP连接，额外开销并不大。用“网易掌上邮”、尚邮push mail等IP Push邮件的实测结果是，打开Push和关闭Push，电量并没有明显消耗，一天消耗的流量大概是50-60KB，也就相当于打开一个不太复杂的web页面所产生的流量。 IP PUSH的特点 　　1、需要保持网络在线。无论使用手机还是电脑，设备必须保持互联网在线。   　　2、IP PUSH在保持互联网在线时基本不产生流量。   　　3、相比SMS PUSH，IP PUSH不需要SP支持，支持更灵活。 IMAP IDLE Push 　　IMAPIDLE 模式是 IMAP 协议的一项高级功能，在这种模式下，客端登录连接服务器后并无主动查询新邮件的动作，而是停留在 IDLE（空闲） 状态，当服务器接收到新邮件后通知客端，客端再开始查询新邮件的动作，此动作完成后，客端重新回到空闲状态。所以也可以算是一种push的方式。目前gmail实现了这个功能。 什么是“伪Push” 　　通过上面的分析，我们可以得出这样一个结论：所谓真正的Push，就是要求一封邮件服务器收到后，可以在一个非常短的时间（数秒）内通知客户端，而且不能产生明显的流量和电量消耗。那么非Push或者说“伪Push”的定义，就是通过定时查询的方式由客户端主动收信的，那么这种方式必将产生一定的延时。我们可能会想，如果缩短查询的时间间隔呢？比如每分钟或者每半分钟查询一次？如果这样做，必然消耗手机很多的电量和流量。 cmwap在部分地区不能实现IP Push 　　cmwap是中国移动提供的一种接入点。可以访问wap站点、收发短信和通过10.0.0.172代理接入Internet。就是说，使用cmwap接入，你的网络访问是需要通过移动提供的代理完成。而这个代理在部分地区设置了严格HTTP请求超时（新疆3分钟，上海40分钟，其他地区未知，也有说超时1分钟的），可以简单的理解为一个TCP连接在没有数据传输的时候，有最长时间限制。要想在cmwap下实现IP Push，就必须在每次HTTP请求超时后重新发起一个请求来保持网络连接，这个动作使得每次HTTP请求超时后都会进行重新连接服务器，增加了流量，消耗电量。   　　因此，在中国部分地区，通过WAP网络并不能实现真正的IP PUSH。   　　下面罗列一些目前已知的，可以通过WAP网络实现IP PUSH的地区：   　　1、浙江   　　2、北京   　　3、广东   　　4、吉林   　　5、广西   　　其他未知。

3. 活跃阶段活跃阶段的用户增长可以看做推荐的一部分。其中最重要的手段就是 Push。Push 的意义不仅仅在于提供个性化推荐，它更增加了 APP 的入口，因此 Push 是用户增长最重要的手段之一。Push 的内容很多，值得单独写一写。简单地说，Push 可以看做一个 top-1 的推荐系统，在推什么的部分，和推荐算法是基本一样的。除了推什么的部分，Push 还需要考虑：什么时候推每天推几条个性化和非个性化的推送怎么安排配比如何提升时效性要不要给用户个性化条数 quota 和发送时间Push 内容的 landing page 承接Push 的点击能否带来转化，即在 APP 内更多地消费内容，从而给 APP 带来一个 DAU 以外的真金白银的收益…等等等等，不一而足。其他地，根据业务不同，也包括发券等促销相关的算法等。这一阶段，主要关注用户的拉活率、长期留存和长期卸载，我们的拉活手段希望用户能从一周三次到每天一次，但是同时也希望用户不因我们的拉活手段感到反感，进而卸载 APP。4. 沉默 & 流失阶段当用户不再使用 APP，甚至卸载 APP 时，我们对用户的触达能力就收到了极大限制。倘若用户还没有卸载，可以通过 Push 来进行极限拉活；倘若用户已经卸载了，还剩下一些盘外招可用，比如：根据用户的注册手机和邮箱，给用户发送短信和邮件：由于短信和邮件也是有成本的，每天发给哪些用户，什么时候发，发什么内容，都可以由算法决定。广告重投放：当一个用户卸载了APP，悲观主义者将他看做流失用户，乐观主义者将他看做新的种子用户，因此，可以对卸载用户重新投放广告，一般地转化率都比普通广告要高。随地都能看到产品焦虑感溢出屏幕的拉活短信但是要注意，一个活跃用户流失的原因一般是因为 APP 不能给用户提供可持续的价值了，此时通过各种方式挽留用户，只能说是亡羊补牢。长期留存主要取决于 APP 的价值，想要更好的用户增长，需要把精力更多放到前面，思考如何给用户提供更多价值，延长用户的生命周期，才是正经道理。总结从业务角度，DAU是最核心的指标，对应的用户增长是一个相当核心的方向。但从实际工作角度，又有些麻烦。一方面，用户增长是一个十分广泛的领域，各方向应用的可能完全不一样，如，做优惠券分发算法和做新用户 deeplink 承接，是完全不同的思路；此外，部分方向做的内容和其他组可能存在重叠，如，在 Feed 中优化新用户留存/提升分享率，和 Feed 流推荐的同学做的事情又有重叠。对这个问题，不同企业有不同的方案，一些企业选择把用户增长作为推荐算法下面的子方向。一些企业则会把用户增长中和推荐算法重叠的部分放入推荐组，其他部分整合成用户增长算法组，与推荐组架构上并列，此时推荐组和用户增长不完全解耦，也会背一部分用户增长的指标，如留存、DAU等。现有的资料，有一些非技术岗总结的方法论如“AARRR”/"RARRA"之流，有兴趣可以学习了解一下，学习下如何创造黑话，可能对写晋升 PPT 大有裨益。

　　微博很热，于是就产生了研究一下的想法，在体验了新浪微博和嘀咕等之后，有了以下几点看法，欢迎大家补充： 　　1. 微博源于手机短信，这也是为何微博要限制140个字符的原因，正好是两个短信的长度。如果说QQ/OICQ是互联网上的寻呼机，那微博就是互联网上的短信。 　　手机短信是点对点，而微博是点对面，关注你的人的多少决定了传播的范围，当然微博是免费的。短信必须延伸到免费的互联网上。  　　2. 别看现在微博百家齐放，能发展壮大的只能是新浪这样的，道理很简单，名人是稀缺资源，名人基本上都被新浪等大鳄圈走了，剩下的嘀咕之类只能是小众。 　　为什么名人这么重要，不是说他们文彩有多好，利用名人效应来快速聚集人气是非常有必要的，相比较而言，非名人在微博上都属于接听的受众。 　　3. 微博更应该看作是一个工具，一种功能，而不是一个产品，好比短信是一种通信方式，微博也是；所以微博很快就会成为各个综合网站的一个必备，心情更新也算微博。 　　4. 其实两年前就玩过一阵子Twitter，但是在上面写英文交老外朋友实在是费劲，就搁置了，可见文化背景的重要。  　　5. 微博的运作模式是：订阅+PUSH；用户订阅（关注）各个名人或者商业用途的微博；接受广告或非广告内容的PUSH； 主要的挑战是微博的黏度很低。 　　如果圈子足够大，利用微博进行推广的成本就很低了，很有效。  　　6. 用户选择关注的对象十分自由，如果选择关注的太多，信息就过载了，需要更智能的过滤技术，可以从微博海洋中提取自己感兴趣的内容。 　　7. 微博更像是关注“人”，而非“事”，要找自己感兴趣的内容，就是查找话题。  　　8. 微博的优势在于：简约-降低写作门槛，提升写作热情；方便-短信/彩信/WAP/手机客户端/Web/MSN/QQ，快速实时同步。  　　9. 微博由于长度的限制，无法承载太多的信息，因此微博注定无法替代博客。 　　近期韩寒也宣称退出新浪微博，毕竟微博只能用来记载琐事，要想利用微博来发表文学作品不太现实，哪怕是连载。 　　把微博比做短信，就能解释很多关于微博以及怎么利用微博来赚钱的问题了。 

如果你要换一部手机或升级你的系统，备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信，不管是感情价值还是实用价值，备份它们是很有用的。 然而，不像照片、视频或音频文件可以相对容易地传输和备份，备份短信/彩信比较复杂，通常需要使用第三方 app 或服务。 为什么要手动备份 尽管现在有很多不同的 app 能够帮你备份短信/彩信，你可能因为以下原因，考虑自己动手备份它们： app 可能不能在所有的设备和安卓版本上都工作。 app 可能把你的备份数据上传到云端， 有破坏你的内容安全的风险。 通过手动备份，你可以完全掌握你的数据通过哪里，走向哪里，备份过程中减少被间谍软件窥视的危险。 手动备份相比其他方法更省时，更省力，更直接。 怎么手动备份短信/彩信？ 要手动备份你的短信/彩信，你需要在你的电脑上安装一个叫做 adb 的安卓工具。 现在，需要重点知道的是，安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。 因为在不同设备上这个数据库的位置可能不相同，而且，其他短信 app 会创建它们自己的数据库，比如 GO SMS 会创建 gommssms.db 数据库， 所以你需要做的第一件事是搜索这些数据库。 打开命令行工具（我使用了 Linux Terminal， 你也可以使用 Windows CMD 或 PowerShell ）并运行以下命令： 注意： 以下是完成该任务的一系列命令，再后面是每个命令用途的解释。 adb root adb shell find / -name "*mmssms*" exit adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER 解释 一开始我们使用 adb root 命令来以 root 模式启动 adb － 这样我们就有了读取系统保护文件的权限。 adb shell 用来进入设备的 shell。 然后， find 命令用来搜索数据库。（在我的例子中，我发现数据库在 /data/data/com.android.providers.telephony/databases/mmssms.db) 建议：如果你的终端输出了太多无关的结果，可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下) 安卓短信/彩信数据库 然后我们使用 exit 命令回退到我们的本地系统目录。 最后，使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。 现在，当你想要还原短信/彩信时，不管是还原到新的设备还是新的系统版本， 只要再次搜索新系统中短信/彩信的具体位置，并用我们备份的数据库替换它即可。 使用 adb push 来替换它，例如： adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db 文章转载自 开源中国社区 [http://www.oschina.net]

如果你要换一部手机或升级你的系统，备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信，不管是感情价值还是实用价值，备份它们是很有用的。 然而，不像照片、视频或音频文件可以相对容易地传输和备份，备份短信/彩信比较复杂，通常需要使用第三方 app 或服务。 为什么要手动备份 尽管现在有很多不同的 app 能够帮你备份短信/彩信，你可能因为以下原因，考虑自己动手备份它们： app 可能不能在所有的设备和安卓版本上都工作。 app 可能把你的备份数据上传到云端， 有破坏你的内容安全的风险。 通过手动备份，你可以完全掌握你的数据通过哪里，走向哪里，备份过程中减少被间谍软件窥视的危险。 手动备份相比其他方法更省时，更省力，更直接。 怎么手动备份短信/彩信? 要手动备份你的短信/彩信，你需要在你的电脑上安装一个叫做 adb 的安卓工具。 现在，需要重点知道的是，安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。 因为在不同设备上这个数据库的位置可能不相同，而且，其他短信 app 会创建它们自己的数据库，比如 GO SMS 会创建 gommssms.db 数据库， 所以你需要做的第一件事是搜索这些数据库。 打开命令行工具(我使用了 Linux Terminal， 你也可以使用 Windows CMD 或 PowerShell )并运行以下命令： 注意： 以下是完成该任务的一系列命令，再后面是每个命令用途的解释。 adb root   adb shell   find / -name "*mmssms*"   exit   adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER  解释 一开始我们使用 adb root 命令来以 root 模式启动 adb - 这样我们就有了读取系统保护文件的权限。 adb shell 用来进入设备的 shell。 然后， find 命令用来搜索数据库。(在我的例子中，我发现数据库在 /data/data/com.android.providers.telephony/databases/mmssms.db) 建议：如果你的终端输出了太多无关的结果，可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下) 安卓短信/彩信数据库 然后我们使用 exit 命令回退到我们的本地系统目录。 最后，使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。 现在，当你想要还原短信/彩信时，不管是还原到新的设备还是新的系统版本， 只要再次搜索新系统中短信/彩信的具体位置，并用我们备份的数据库替换它即可。 使用 adb push 来替换它，例如： adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db  作者：Liron 来源：51CTO

如果你要换一部手机或升级你的系统，备份你的数据就变得至关重要。我们存储重要数据的位置之一就是我们的短信/彩信，不管是感情价值还是实用价值，备份它们是很有用的。 然而，不像照片、视频或音频文件可以相对容易地传输和备份，备份短信/彩信比较复杂，通常需要使用第三方 app 或服务。 为什么要手动备份 尽管现在有很多不同的 app 能够帮你备份短信/彩信，你可能因为以下原因，考虑自己动手备份它们： app 可能不能在所有的设备和安卓版本上都工作。 app 可能把你的备份数据上传到云端， 有破坏你的内容安全的风险。 通过手动备份，你可以完全掌握你的数据通过哪里，走向哪里，备份过程中减少被间谍软件窥视的危险。 手动备份相比其他方法更省时，更省力，更直接。 怎么手动备份短信/彩信？ 要手动备份你的短信/彩信，你需要在你的电脑上安装一个叫做  adb 的安卓工具。 现在，需要重点知道的是，安卓把短信/彩信通常存储在一个叫做 mmssms.db 的数据库里。 因为在不同设备上这个数据库的位置可能不相同，而且，其他短信 app 会创建它们自己的数据库，比如 GO SMS 会创建 gommssms.db 数据库， 所以你需要做的第一件事是搜索这些数据库。 打开命令行工具（我使用了 Linux Terminal， 你也可以使用 Windows CMD 或 PowerShell ）并运行以下命令： 注意： 以下是完成该任务的一系列命令，再后面是每个命令用途的解释。 adb root adb shell find / -name "*mmssms*" exit adb pull /PATH/TO/mmssms.db /PATH/TO/DESTINATION/FOLDER 解释 一开始我们使用 adb root 命令来以 root 模式启动 adb － 这样我们就有了读取系统保护文件的权限。 adb shell 用来进入设备的 shell。 然后， find 命令用来搜索数据库。（在我的例子中，我发现数据库在/data/data/com.android.providers.telephony/databases/mmssms.db) 建议：如果你的终端输出了太多无关的结果，可以试试使用 find 的参数来精简结果。(具体参数可以搜索引擎查下) 安卓短信/彩信数据库 然后我们使用 exit 命令回退到我们的本地系统目录。 最后，使用 adb pull 把数据库文件复制到我们电脑的一个文件夹里。 现在，当你想要还原短信/彩信时，不管是还原到新的设备还是新的系统版本， 只要再次搜索新系统中短信/彩信的具体位置，并用我们备份的数据库替换它即可。 使用 adb push 来替换它，例如： adb push ~/Downloads/mmssms.db /data/data/com.android.providers.telephony/databases/mmssms.db 原文发布时间为：2017-12-22 本文来自云栖社区合作伙伴“Linux中国”

本文作者：友盟+技术专家 刘章军 业务背景 友盟+消息推送U-Push日均消息下发量百亿级，其中筛选任务日均数十万，筛选设备每分钟峰值可达7亿+，本文将分享友盟+技术架构团队在长期生产实践中沉淀的筛选架构解决方案。**如何保证百亿级的下发量？** 友盟+U-Push筛选是Push产品的核心功能，其中实时筛选是面向推送要求较高的付费Pro用户提供的核心能力之一，实现了用户实时打标、筛选、分发、触达的功能。友盟+U-Push的设备识别以device_token为基准，为保证尽可能的触达我们留存了近期所有可能触达客户的device_token，以10亿真实设备为例，每个设备安装10个集成友盟+SDK的应用可以产生10个device_token，牵扯到硬件环境变动导致的device_token漂移问题，可能产生更多device_token。 （ 图1.1.1 友盟+U-Push业务数据流简图） 图1.1.2 友盟+U-Push功能清单 U-Push筛选架构概览 2.1 上下行两个核心链路 U-Push服务由两个关键链路组成，下行链路保证客户消息的触达，上行链路承载终端采数和与客户服务端的数据同步。其中下行链路主要分为任务调度、筛选中心，上行链路主要服务是多种收数通道（为兼容历史问题）和设备中心，上行通过设备中心实现跟下行桥接。 图2.1.1 友盟+U-Push筛选业务场景 在U-Push服务中，依照业务场景不同定义了多种任务类型，其中除单播、列播直接下发外组播、广播、自定义播、自定义文件播均需要通过筛选服务处理后才可执行下发，下行链路中（如图2.1.2）优先级最高是的任务受理和任务发送流程（红色链路），即无论发生什么情况都要保证客户消息的正确下发，是U-Push服务稳定性的底线。出于融灾考虑，筛选服务在架构上与主链路解耦。 图2.1.2 筛选和核心链路隔离 2.2 数据架构目标和设计 提到筛选，其本质是通过建立合理的标签索引系统实现数据的快速定位。筛选的目标是U-Push核心设备库，但是为避免筛选请求影响到核心库稳定需要将待筛选集合分库冗余存储，与一般OLAP，OLTP场景不同，U-Push筛选的应用场景更加苛刻。 不俗的在线任务并发能力 筛选本质还是在线场景，具有一定的并发能力，并发压力主要在于压榨系统IO上，通过合理的中间件使用、严谨的服务调度、针对性场景的差异化设计降低单次筛选的执行时间，提高并发。 实时海量数据分析和传输能力 筛选提供了多种分析维度（图2.2.2），支持灵活的语法组合。筛选服务不仅要满足对海量数据的实时查询分析，还要支持对单次可能破亿的结果集做低成本传输。 图2.2.2 筛选支持的字段类型 成本可控 一切问题都是成本问题，从行业看全民上云后服务架构的成本问题更是备受关注，尤其在友盟+庞大的业务量下成本问题更加重要。 为下游任务并行发送创造条件 友盟+U-Push的发送层集群用于大量的发送节点，最理想的设计就是在任务筛选阶段即完成数据切片、分发、调度，下游直接并行发送以达到最高效率。 U-Push筛选在持续的技术迭代中，和多领域专业团队深度合作，充分利用不同组件的特性，通过整合Tair、AnalyticDB for MySQL(ADS)、OSS、MaxCompute(ODPS)、Lindorm、HBase、SchedulerX等产出了一套兼顾稳定、性能、和成本的均衡解决方案。 筛选分为离线和实时两部分，离线通过ODPS生成设备主库快照，导入ADS。实时通过消费数据上行服务的设备信息更新事件，实时更新ADS或者RDB库。在执行筛选时候，对于较大结果集通过upload或者dump到OSS的方式输出多个小文件，传输给发送链路下游执行并行发送。 图2.2.4 筛选服务数据流向 上述业务链路和数据结构介绍了筛选目前的整体设计，但是要应付复杂的客情和多变的业务场景还需要做更多细节设计。 设计细节 3.1 筛选库的场景设计 从上面的概览可以看出，筛选架构中的主要矛盾就是消息下行链路中海量数据的读和上行链路中设备属性更新的高频写的矛盾，解决这个矛盾需要大量的资源来保证数据一致性和性能，在常规的设计思路中在目前的成本资源下几乎是不可行。大数据三大宝，冷热分离分库分表，通过业务分析调研，U-Push将业务分成若干场景，基于客户的不同生命周期的业务诉求和服务能力将客户指向不同场景，尽量优化客户体验。 图3.1.1 筛选库的场景设计 组播和广播筛选我们主要围绕ADS来建设，ADS提供了实时和离线两种更新方式，在产品形态上只对Pro客户开放实时筛选能力，在架构设计上通过分库的方式隔离不同层客户的数据，提供差异化服务，提高稳定性。 离线部分：通过离线主库保证了所有客户的T+1筛选能力。在实际业务中离线主库只有读请求作为所有极端场景下的兜底，离线主库以device_token分区，可以实现完全打散但是聚合查询的时候性能稍差。为了提高部分客户尤其是新客户的体验我们设计了新客户离线库，修改为客户分区，提高了单客户聚合查询的效率。但是新客户离线库因客户间的规模差异容易引发分区倾斜，生产中这个表需要持续关注，及时清理和转移，否则在跑ads_loader的时候可能破线。 图3.1.2 离线主库的分区状态 图3.1.3 以客户为分区的分区倾斜情况 实时部分：保证实时筛选服务体验是整个系统的重点，将实时筛选再细分为VIP实时库、测试设备库（方便客户接入阶段实时获取测试效果）、新客户实时库（新增客户一般设备量很小，U-Push会免费提供一段时间的实时筛选服务）。与离线分区类似，在分区设计上同样对大规模场景数据和较少规模场景的数据分表，特别的测试设备库可能产生大量脏数据，整体隔离出来。 图3.1.2 客户场景迁移 新客户接入伊始基于客户规模区分，在不同的生命周期节点会被引入特定的场景，在保证大盘能力的前提下尽量输出更优质的客户体验。 3.2 利用OSS传输和切分文件 在上述设计中通过离线和实时的区分，降低了高频写可能对设备库造成的影响。但是始终绕不过海量数据的传输问题，为规避这个问题U-Push采用差异化的设计思路，以结果集规模做区分，对大结果集直接通过ADS dump到OSS，基于不同客户的并行度做远程切分，在OSS完成upload和split操作后返回文件路径集合，后续链路只保留文件路径集，直至进入发送层执行并行发送。对小结果集通过select拉取到内存整合消息报文传输，后续链路直接发送设备ID。通过OSS做中间存储，极大的降低冗余的IO损耗。 ADS3.0由于整体架构改动改为通过外部表的方式dump到OSS，与2.0可以dump出单个文件不同3.0在dump后会产生一系列小文件直接导致原有的方案不可行，在通过和ADS团队沟通后ADS特地在3.0版本完善了dump单个文件的功能，致谢ADS的同学。 图3.2.1 筛选查询中的性能瓶颈风险 3.3 查询缓存和预筛选 谈到查询场景，必然会有缓存的一席之地，与一般设计思路不同，U-Push直接放弃了针对实时筛选能力的查询缓存，因为在这样的设备量级下随时的设备更新是必然。U-Push的实时筛选库是一个高频写低频读的场景，但是对单次读的要求比较苛刻，首先对未开启实时功能的离线客户，因为设备库是快照形式，一天内的多次读拿到的结果必然相同这时候设置缓存就很有意义，比如新闻、气象、工具类客户的习惯，一天内发送多次广播，就不必每次再去重新生成筛选集文件。 图3.3.1 查询缓存逻辑流程图 预筛选功能的开发是个小插曲，前面讲到U-Push放弃了对实时的查询缓存，导致客户的每次消息发送都要重新去生成文件，在保证数据实时性的角度考虑无可非议，但是遇到“较真”的客户就很有压力。比如新闻类客户极度关注消息下发的时效性，通过开发者控制台可以查看每个任务的筛选时间，有时候同类消息2s的差异也会引发客户在DING群的"客诉"。客户的诉求可以理解但是这也耗费了团队大量的精力。通过和个别客户沟通U-Push开发了预筛选功能，在客户习惯性发送消息的前一段时间预先调度执行筛选逻辑生成设备ID集合，通过损失少量的数据时效性来压缩消息下发时间，争取消息发送速度。 图3.3.1 友盟+U-Push消息轨迹 3.4 Alias筛选的优化 筛选请求可以归类为两种场景： Alias功能依赖的ID Mapping场景，NvN的设备ID和Alias映射。 tag组播和iOS广播功能的select场景，条件查询，基于ADS实现。 Alias功能简介：Alias允许开发者为设备绑定别名，别名由alias_type，alias两个属性组成，譬如开发者可以标识设备A，为他增加alias_type=telephone_number, alias=13900000000以此来给设备A增加手机号的属性。在发送消息时候可以绕开device_token，直接通过服务端指定alias实现触达，alias是一个典型的NVN ID Mapping场景，一个设备在同一个alias_type下面同时只能拥有一个alias。这也是符合一般业务场景的，比如上例一般一个设备只有一个手机号，设置新手机号后会覆盖原alias。如果需要满足双卡双待的功能，需要设置两个alias_type，即alias_type=telephone_number_main，alias_type=telephone_number_secondary。alias的一般使用场景是开发者通过自定义文件播上传一批文件，文件内容为某个alias_type下若干设备alias的集合（百万千万级）。筛选服务扫描文件后依次找出alias值mapping的device_token。 3.4.1 Alias的早期设计 说到Mapping，轮询，高吞吐查询，首当其冲选Redis，早期的U-Push也是如此。 图3.5.1 alias早期数据结构设计 alias利用Redis的Set和Hash结构实现正查和反差的功能，为什么反差用hash，前面讲到1个设备在1个alias_type下只保存最新的alias。这也是出于保护用户的目的，如果1个设备同时存在多个alias下，在开发者执行圈选的时候可能会多次选出这个设备造成多次无效触达。 这个设计平淡无奇，的确也可以满足绝大部分客户的筛选场景，但是随着业务量的增加有几个问题逐渐暴露 轮询成为海量设备查询的瓶颈，且不可突破。 Redis数据持久化难的问题凸显，数据分析难上加难。 Alias无法很好的满足数据返还链路的需求。 3.4.2 研究Alias的解法 分库的确是很好的思路但是仍然无法满足性能问题和持久化问题，而且随着行业对大数据的关注，数据返还也成为更多开发者的诉求。打通数据返还链路做好客户数据的存、取、管、用已经是一个重要的行业方向。为了解决这个问题U-Push通过离线和实时相结合制定措施 分库，增加KA级别客户独享库，压缩横向扩容空间。 分层，基于Lindorm做持久化分层存储。 离线留存，通过日志系统留存下行筛选结果，一方面完善统计需求，一方面通过回执返还客户。 3.4.3 基于Lindorm宽表的分层设计 用宽表代替Redis的Set设计做正查，用普通表基于设备ID的联合主键做反查，在查询时候通过将单次轮询改为多次mget尽量压缩IO损耗寻找响应性能和服务稳定的中间值，Lindorm的磁盘存储可以满足业务需求的同时通过exporter的配置实现lindorm数据T+1同步至ODPS。 图3.5.2 基于Lindorm款表的分层设计 3.4.4 数据迁移的尝试和思考 数据迁移是在很多业务架构中都是痛中之痛，如何保证稳定、平滑、安全的迁移需要付出大量的成本。U-Push在Alias的数据迁移中做了多种方案的研究和思考。 Tair整体dump迁移，dump方案理论上可行但是有较大的业务风险，出于稳定性的考虑放弃。 写请求增量更新，通过客户的写请求逐key迁移，会有漫长的灰度时间，且无法执行彻底清理，胜在稳定性强。 扫描设备主库，分客户批次灰度迁移。在U-Push的功能中，提供了appkey下alias_type的功能，客户可以在开发者控制台查询appkey下的alias_type列表，为实现这个功能对appkey和alias_type做了集合索引，这个索引成为数据迁移的关键。通过扫描设备库获取appkey和device_token，结合alias_type去反查库查找alias，再拿appkey+alias_type+alias去正查库查询device_token列表完成迁移。 第三种方法可以实现存量数据的完美迁移，对线上服务几乎没影响，但是在百亿级设备下，以1wTPS计算仍然需要10天的时间，好在该方案可以实现单个客户的灰度与回滚。 结语 U-Push筛选服务只是U-Push众多服务中的一环，在友盟+巨大的业务量下，为满足形形色色的各行业需求输出了大量精致的设计，本文列出的只是冰山一角，日均消息下发量百亿级做到游刃有余离不开其他技术架构团队在筛选服务迭代中的共同协作。 目前U-Push已经以Push通道为基础，整合了微信、短信、隐私短信升级为多通道触达服务，为众多知名的App如：今日头条、澎湃新闻、作业帮、易车等提供了触达能力，后续持续接入支付宝小程序、头条号等更多运营场景通道，持续为客户提供稳定、高性能、低成本的触达能力保证。 友盟+，国内领先的第三方全域数据智能服务商，截至2020年6月已累计为200万移动应用和890万家网站提供十年的专业数据服务。

    推送并不是什么新技术，这种技术在互联网时代就已经很流行了。只是随着进入移动互联网时代，推送技术显得更加重要。因为在智能手机中，推送从某种程度上，可以取代使用多年的短信，而且与短信相比，还可以向用户展示更多的信息（如图像、表格、声音等）。推送技术的实现通常会使用服务端向客户端推送消息的方式。也就是说客户端通过用户名、Key等ID注册到服务端后，在服务端就可以将消息向所有活动的客户端发送。 实际上，在很多移动操作系统中，官方都为其提供了推送方案，例如，Google的云推送、IOS、Windows Phone7/8也都提供了类似的推送方案。不过这些推送方案的服务器都在国外，有一些推送服务（如Google的云推送）在国内由于某些原因不太稳定，所以国内近几年涌现出了很多专门为国人打造的推送服务。 本文将从各种流行移动操作系统入手介绍推送技术的各种实现方式。当然，我们的主要目的是讨论Android的推送技术。 一、iOS的推送技术 Apple为IOS提供了很完美的推送方案，其基本原理是Apple提供了自己的推送服务器，叫APNS（Apple Push Notification Service，苹果推送通知服务器）。而客户端设备（IPhone、IPad等）直接与APNS建立长连接。不过向客户端设备发送的消息并不是由APNS产生的，而是在需要发送消息的用户自己提供的服务器（称为Provider）中产生的，然后Provider将消息传送给APNS，最后由APNS将消息传送给客户端设备。也就是说，消息最开始由Provider产生，然后Provider将消息传送给APNS，最后再由APNS传送给客户端设备。消息传递的过程如图1所示。                      图1       在发送消息到客户端设备接收到消息的过程中，始终伴随这一个令牌的传送（device token）。要想使用APNS提供消息服务，应用程序需要先向IOS注册需要提供的一个必要的信息就是与当前设备有关的device token，IOS在接收到devicetoken后，会向APNS查询这个device token是否在APNS上注册了（所有的IOS设备在第一次使用时都需要向苹果服务器注册一个账号，否则无法从AppleStore下载应用，当然更无法使用推送服务了），如果已经注册，APNS会直接向应用程序返回这个devicetoken。应用程序获得这个devicetoken后，表示APNS已经允许向自己推送消息了，接着还需要将该device token发送给推送服务器（Provider）。到这里应用程序已经成功将自己注册到APNS中了。现在就可以通过Provider产生要推送的消息，然后Provider会将消息发送给APNS服务器，最后APNS服务器会直接向应用程序发送消息。这个过程比较复杂，不过看一下图2的描述就会对这一过程更加了解了。每一个流程描述前面的数字表示发送的时间先后顺序。 图2 二、Windows Phone的推送技术 微软为Window Phone提供的推送方案与IOS类似，也需要自己准备推送服务器（可以称为Cloud Service）。只是表示设备的ID变成了Uri。在Window Phone中有一个Push Client Service（PCS）。所有需要推送服务的应用程序都需要与Push Client Service通信。下面是Window Phone推送的基本步骤，读者可以与图3对照来看这一过程。 第1步：应用程序会向Push Client Service请求一个Push Notification URI（①）。 第2步：如果当前Window Phone设备已经在微软服务器注册了，Push Client Service会从MPNS（Microsoft Push Notification Service ，微软推送通知服务）获取Push Notification URI，并返回给应用程序，表示推送服务可用（②和③）。 第3步：应用程序需要将Push Notification URI发送给自己的推送服务器（Cloud Service）（④）。 第4步：如果需要推送消息，Cloud Service会将消息发送到MPNS，然后MPNS会将消息发送给Push Client Service，最后由Push Client Service将消息传送给应用程序（⑤、⑥和③）。                                                           图3 三、Android的推送方案 Android的推送方案就比较多了，也比较乱。例如，有Google官方提供的C2DM（Android Cloud to Device Messaging）；第三方的推送服务（如极光推送）；还有通过各种协议实现的推送服务端程序（如AndroidPN），用户通过这些服务端程序可以搭建自己的推送服务器。这些推送技术会在本节后面的部分详细介绍，本节先来介绍一下Android中经常使用的各种推送技术。当然，这些推送技术也能用于其它的移动设备，但由于Android的官方推送服务（C2DM）在国内使用上有一些问题，所以基于Android的第三方推送服务较其它系统多，因此这里主要针对Android来介绍。 通常推送技术会使用如下两种方式实现。 1. 轮询（Pull）方式 2. 持久连接方式（服务端Push方式） 轮询方式就是客户端以一定的时间间隔不断查询服务端是否有新的消息。这种方式必须自己实现与服务器之间的通信机制，例如消息队列等。而且还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。所以大多数推送服务都不会使用轮询方式。 持久连接方式也就是Push方式，对于客户端来说，是一种被动的方式，而主动权在服务端，当有消息时，服务端会向所有注册到推送服务器的客户端推送消息。这种推送方式的好处是可以保证实时性，而且客户端实现简单。当然，也会有不足，例如，如果大量的客户端与服务端保持长连接时，会消耗服务器的资源。不过在未推送消息时，这些长连接就成了空闲连接，通常这种连接主要消耗的是内存资源。例如，200万用户可能会消耗数十GB的内存。因此搭建这种推送机制时要使用性能好的服务器。 持久连接的实现有很多方式，例如，可以使用XMPP作为通信协议。XMPP的主要优势是协议成熟、强大，可扩展性强。XMPP更多地用于IM系统中，后面要介绍的AndroidPN也是用了XMPP协议。 XMPP也有明显的缺点，例如，协议很复杂，如果吃透XMPP协议可能需要很长时间，还有就是由于XMPP是基于XML的，从而造成了数据冗余、这样会造成移动设备费流量、耗电等弊病。 除了XMPP，还可以使用MQTT协议，这种协议的主要优势是简洁、小巧、可扩展性强，从而带来了省流量、省电等优点，而且有C++版的服务端组件rsmb。缺点是协议不够成熟，而且实现较复杂，而且rsmb不开源，部署硬件的成本较高。 尽管C2DM服务在国内可能不太稳定或有一些地区不可用，但还是有必要介绍一下C2DM的原理。不过对于在国内使用的应用最好使用第三方的推送服务，或自己假设推送服务器。 C2DM和IOS的APNS以及Window Phone的MPNS大同小异。还需要自己准备一台推送服务器，并通过如下步骤实现消息的推送。 第1步：移动设备上的C2DM服务需要与Google官方的C2DM服务器交互，验证当前设备是否在C2DM服务器上注册了，如果已经注册，C2DM服务器会返回一个注册ID给客户端的C2DM服务。（①和②） 第2步：客户端的C2DM服务会与自己的推送服务器交互，将账号和C2DM服务器返回的注册ID传给推送服务器。（③） 第3步：如果要推送消息，推送服务器会将注册ID和要推送的消息先发送到C2DM服务器，然后C2DM服务器会直接将消息推送给客户端（手机、平板电脑的设备）（④和⑤）。 读者可以对照图4来理解这3个步骤。                                          图4 除了使用官方的推送方案外，现在国内涌现出多个第三方的推送方案，例如，极光推送（JPush）、百度推送等。读者也可以用一下，这些同时通常是免费的（可能推送多媒体数据需要收费）。

 Android、iOS和Windows Phone中的推送技术    推送并不是什么新技术，这种技术在互联网时代就已经很流行了。只是随着进入移动互联网时代，推送技术显得更加重要。因为在智能手机中，推送从某种程度上，可以取代使用多年的短信，而且与短信相比，还可以向用户展示更多的信息（如图像、表格、声音等）。 推送技术的实现通常会使用服务端向客户端推送消息的方式。也就是说客户端通过用户名、Key等ID注册到服务端后，在服务端就可以将消息向所有活动的客户端发送。 实际上，在很多移动操作系统中，官方都为其提供了推送方案，例如，Google的云推送、IOS、Windows Phone7/8也都提供了类似的推送方案。不过这些推送方案的服务器都在国外，有一些推送服务（如Google的云推送）在国内由于某些原因不太稳定，所以国内近几年涌现出了很多专门为国人打造的推送服务。 本文将从各种流行移动操作系统入手介绍推送技术的各种实现方式。当然，我们的主要目的是讨论Android的推送技术。 一、iOS的推送技术 Apple为IOS提供了很完美的推送方案，其基本原理是Apple提供了自己的推送服务器，叫APNS（Apple Push Notification Service，苹果推送通知服务器）。而客户端设备（IPhone、IPad等）直接与APNS建立长连接。不过向客户端设备发送的消息并不是由APNS产生的，而是在需要发送消息的用户自己提供的服务器（称为Provider）中产生的，然后Provider将消息传送给APNS，最后由APNS将消息传送给客户端设备。也就是说，消息最开始由Provider产生，然后Provider将消息传送给APNS，最后再由APNS传送给客户端设备。消息传递的过程如图1所示。 图1 在发送消息到客户端设备接收到消息的过程中，始终伴随这一个令牌的传送（device token）。要想使用APNS提供消息服务，应用程序需要先向IOS注册需要提供的一个必要的信息就是与当前设备有关的device token，IOS在接收到devicetoken后，会向APNS查询这个device token是否在APNS上注册了（所有的IOS设备在第一次使用时都需要向苹果服务器注册一个账号，否则无法从AppleStore下载应用，当然更无法使用推送服务了），如果已经注册，APNS会直接向应用程序返回这个devicetoken。应用程序获得这个devicetoken后，表示APNS已经允许向自己推送消息了，接着还需要将该device token发送给推送服务器（Provider）。到这里应用程序已经成功将自己注册到APNS中了。现在就可以通过Provider产生要推送的消息，然后Provider会将消息发送给APNS服务器，最后APNS服务器会直接向应用程序发送消息。这个过程比较复杂，不过看一下图2的描述就会对这一过程更加了解了。每一个流程描述前面的数字表示发送的时间先后顺序。 图2 二、Windows Phone的推送技术 微软为Window Phone提供的推送方案与IOS类似，也需要自己准备推送服务器（可以称为Cloud Service）。只是表示设备的ID变成了Uri。在Window Phone中有一个Push Client Service（PCS）。所有需要推送服务的应用程序都需要与Push Client Service通信。下面是Window Phone推送的基本步骤，读者可以与图3对照来看这一过程。 第1步：应用程序会向Push Client Service请求一个Push Notification URI（①）。 第2步：如果当前Window Phone设备已经在微软服务器注册了，Push Client Service会从MPNS（Microsoft Push Notification Service ，微软推送通知服务）获取Push Notification URI，并返回给应用程序，表示推送服务可用（②和③）。 第3步：应用程序需要将Push Notification URI发送给自己的推送服务器（Cloud Service）（④）。 第4步：如果需要推送消息，Cloud Service会将消息发送到MPNS，然后MPNS会将消息发送给Push Client Service，最后由Push Client Service将消息传送给应用程序（⑤、⑥和③）。 图3 三、Android的推送方案 Android的推送方案就比较多了，也比较乱。例如，有Google官方提供的C2DM（Android Cloud to Device Messaging）；第三方的推送服务（如极光推送）；还有通过各种协议实现的推送服务端程序（如AndroidPN），用户通过这些服务端程序可以搭建自己的推送服务器。这些推送技术会在本节后面的部分详细介绍，本节先来介绍一下Android中经常使用的各种推送技术。当然，这些推送技术也能用于其它的移动设备，但由于Android的官方推送服务（C2DM）在国内使用上有一些问题，所以基于Android的第三方推送服务较其它系统多，因此这里主要针对Android来介绍。 通常推送技术会使用如下两种方式实现。 1. 轮询（Pull）方式 2. 持久连接方式（服务端Push方式） 轮询方式就是客户端以一定的时间间隔不断查询服务端是否有新的消息。这种方式必须自己实现与服务器之间的通信机制，例如消息队列等。而且还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。所以大多数推送服务都不会使用轮询方式。 持久连接方式也就是Push方式，对于客户端来说，是一种被动的方式，而主动权在服务端，当有消息时，服务端会向所有注册到推送服务器的客户端推送消息。这种推送方式的好处是可以保证实时性，而且客户端实现简单。当然，也会有不足，例如，如果大量的客户端与服务端保持长连接时，会消耗服务器的资源。不过在未推送消息时，这些长连接就成了空闲连接，通常这种连接主要消耗的是内存资源。例如，200万用户可能会消耗数十GB的内存。因此搭建这种推送机制时要使用性能好的服务器。 持久连接的实现有很多方式，例如，可以使用XMPP作为通信协议。XMPP的主要优势是协议成熟、强大，可扩展性强。XMPP更多地用于IM系统中，后面要介绍的AndroidPN也是用了XMPP协议。 XMPP也有明显的缺点，例如，协议很复杂，如果吃透XMPP协议可能需要很长时间，还有就是由于XMPP是基于XML的，从而造成了数据冗余、这样会造成移动设备费流量、耗电等弊病。 除了XMPP，还可以使用MQTT协议，这种协议的主要优势是简洁、小巧、可扩展性强，从而带来了省流量、省电等优点，而且有C++版的服务端组件rsmb。缺点是协议不够成熟，而且实现较复杂，而且rsmb不开源，部署硬件的成本较高。 尽管C2DM服务在国内可能不太稳定或有一些地区不可用，但还是有必要介绍一下C2DM的原理。不过对于在国内使用的应用最好使用第三方的推送服务，或自己假设推送服务器。 C2DM和IOS的APNS以及Window Phone的MPNS大同小异。还需要自己准备一台推送服务器，并通过如下步骤实现消息的推送。 第1步：移动设备上的C2DM服务需要与Google官方的C2DM服务器交互，验证当前设备是否在C2DM服务器上注册了，如果已经注册，C2DM服务器会返回一个注册ID给客户端的C2DM服务。（①和②） 第2步：客户端的C2DM服务会与自己的推送服务器交互，将账号和C2DM服务器返回的注册ID传给推送服务器。（③） 第3步：如果要推送消息，推送服务器会将注册ID和要推送的消息先发送到C2DM服务器，然后C2DM服务器会直接将消息推送给客户端（手机、平板电脑的设备）（④和⑤）。 读者可以对照图4来理解这3个步骤。 图4 除了使用官方的推送方案外，现在国内涌现出多个第三方的推送方案，例如，极光推送（JPush）、百度推送等。读者也可以用一下，这些同时通常是免费的（可能推送多媒体数据需要收费）。

推送并不是什么新技术，这种技术在互联网时代就已经很流行了。只是随着进入移动互联网时代，推送技术显得更加重要。因为在智能手机中，推送从某种程度上，可以取代使用多年的短信，而且与短信相比，还可以向用户展示更多的信息（如图像、表格、声音等）。 　　推送技术的实现通常会使用服务端向客户端推送消息的方式。也就是说客户端通过用户名、Key等ID注册到服务端后，在服务端就可以将消息向所有活动的客户端发送。 　　实际上，在很多移动操作系统中，官方都为其提供了推送方案，例如，Google的云推送、IOS、Windows Phone7/8也都提供了类似的推送方案。不过这些推送方案的服务器都在国外，有一些推送服务（如Google的云推送）在国内由于某些原因不太稳定，所以国内近几年涌现出了很多专门为国人打造的推送服务。 　　本文将从各种流行移动操作系统入手介绍推送技术的各种实现方式。当然，我们的主要目的是讨论Android的推送技术。 　　一、iOS的推送技术 　　Apple为IOS提供了很完美的推送方案，其基本原理是Apple提供了自己的推送服务器，叫APNS（Apple Push Notification Service，苹果推送通知服务器）。而客户端设备（IPhone、IPad等）直接与APNS建立长连接。不过向客户端设备发送的消息并不是由APNS产生的，而是在需要发送消息的用户自己提供的服务器（称为Provider）中产生的，然后Provider将消息传送给APNS，最后由APNS将消息传送给客户端设备。也就是说，消息最开始由Provider产生，然后Provider将消息传送给APNS，最后再由APNS传送给客户端设备。消息传递的过程如图1所示。 　　 　　在发送消息到客户端设备接收到消息的过程中，始终伴随这一个令牌的传送（device token）。要想使用APNS提供消息服务，应用程序需要先向IOS注册需要提供的一个必要的信息就是与当前设备有关的device token，IOS在接收到devicetoken后，会向APNS查询这个device token是否在APNS上注册了（所有的IOS设备在第一次使用时都需要向苹果服务器注册一个账号，否则无法从AppleStore下载应用，当然更无法使用推送服务了），如果已经注册，APNS会直接向应用程序返回这个devicetoken。应用程序获得这个devicetoken后，表示APNS已经允许向自己推送消息了，接着还需要将该device token发送给推送服务器（Provider）。到这里应用程序已经成功将自己注册到APNS中了。现在就可以通过Provider产生要推送的消息，然后Provider会将消息发送给APNS服务器，最后APNS服务器会直接向应用程序发送消息。这个过程比较复杂，不过看一下图2的描述就会对这一过程更加了解了。每一个流程描述前面的数字表示发送的时间先后顺序。 　　 　　二、Windows Phone的推送技术 　　微软为Window Phone提供的推送方案与IOS类似，也需要自己准备推送服务器（可以称为Cloud Service）。只是表示设备的ID变成了Uri。在Window Phone中有一个Push Client Service（PCS）。所有需要推送服务的应用程序都需要与Push Client Service通信。下面是Window Phone推送的基本步骤，读者可以与图3对照来看这一过程。 　　第1步：应用程序会向Push Client Service请求一个Push Notification URI（①）。 　　第2步：如果当前Window Phone设备已经在微软服务器注册了，Push Client Service会从MPNS（Microsoft Push Notification Service ，微软推送通知服务）获取Push Notification URI，并返回给应用程序，表示推送服务可用（②和③）。 　　第3步：应用程序需要将Push Notification URI发送给自己的推送服务器（Cloud Service）（④）。 　　第4步：如果需要推送消息，Cloud Service会将消息发送到MPNS，然后MPNS会将消息发送给Push Client Service，最后由Push Client Service将消息传送给应用程序（⑤、⑥和③）。 　　三、Android的推送方案 　　Android的推送方案就比较多了，也比较乱。例如，有Google官方提供的C2DM（Android Cloud to Device Messaging）；第三方的推送服务（如极光推送）；还有通过各种协议实现的推送服务端程序（如AndroidPN），用户通过这些服务端程序可以搭建自己的推送服务器。这些推送技术会在本节后面的部分详细介绍，本节先来介绍一下Android中经常使用的各种推送技术。当然，这些推送技术也能用于其它的移动设备，但由于Android的官方推送服务（C2DM）在国内使用上有一些问题，所以基于Android的第三方推送服务较其它系统多，因此这里主要针对Android来介绍。 　　通常推送技术会使用如下两种方式实现。 　　1. 轮询（Pull）方式 　　2. 持久连接方式（服务端Push方式） 　　轮询方式就是客户端以一定的时间间隔不断查询服务端是否有新的消息。这种方式必须自己实现与服务器之间的通信机制，例如消息队列等。而且还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。所以大多数推送服务都不会使用轮询方式。 　　持久连接方式也就是Push方式，对于客户端来说，是一种被动的方式，而主动权在服务端，当有消息时，服务端会向所有注册到推送服务器的客户端推送消息。这种推送方式的好处是可以保证实时性，而且客户端实现简单。当然，也会有不足，例如，如果大量的客户端与服务端保持长连接时，会消耗服务器的资源。不过在未推送消息时，这些长连接就成了空闲连接，通常这种连接主要消耗的是内存资源。例如，200万用户可能会消耗数十GB的内存。因此搭建这种推送机制时要使用性能好的服务器。 　　持久连接的实现有很多方式，例如，可以使用XMPP作为通信协议。XMPP的主要优势是协议成熟、强大，可扩展性强。XMPP更多地用于IM系统中，后面要介绍的AndroidPN也是用了XMPP协议。 　　XMPP也有明显的缺点，例如，协议很复杂，如果吃透XMPP协议可能需要很长时间，还有就是由于XMPP是基于XML的，从而造成了数据冗余、这样会造成移动设备费流量、耗电等弊病。 　　除了XMPP，还可以使用MQTT协议，这种协议的主要优势是简洁、小巧、可扩展性强，从而带来了省流量、省电等优点，而且有C++版的服务端组件rsmb。缺点是协议不够成熟，而且实现较复杂，而且rsmb不开源，部署硬件的成本较高。 　　尽管C2DM服务在国内可能不太稳定或有一些地区不可用，但还是有必要介绍一下C2DM的原理。不过对于在国内使用的应用最好使用第三方的推送服务，或自己假设推送服务器。 　　C2DM和IOS的APNS以及Window Phone的MPNS大同小异。还需要自己准备一台推送服务器，并通过如下步骤实现消息的推送。 　　第1步：移动设备上的C2DM服务需要与Google官方的C2DM服务器交互，验证当前设备是否在C2DM服务器上注册了，如果已经注册，C2DM服务器会返回一个注册ID给客户端的C2DM服务。（①和②） 　　第2步：客户端的C2DM服务会与自己的推送服务器交互，将账号和C2DM服务器返回的注册ID传给推送服务器。（③） 　　第3步：如果要推送消息，推送服务器会将注册ID和要推送的消息先发送到C2DM服务器，然后C2DM服务器会直接将消息推送给客户端（手机、平板电脑的设备）（④和⑤）。 　　读者可以对照图4来理解这3个步骤。 　　 　　除了使用官方的推送方案外，现在国内涌现出多个第三方的推送方案，例如，极光推送（JPush）、百度推送等。读者也可以用一下，这些同时通常是免费的（可能推送多媒体数据需要收费）。 最新内容请见作者的GitHub页：http://qaseven.github.io/