手机推送服务

标签：android   style   io   os   使用   ar   数据   sp   问题   

设计一个长连接手机云推送服务。

要求：

1. 稳定包括两个部分一个是服务器端的稳定性，一个是手机端的稳定性。

服务端稳定性，因为使用长连接方案，对服务器的开销和要求很大，推送方案对服务器开发要求很高，海量线程连接下的服务器稳定性是非常具有挑战性的。一般的评判标准包括：

• 同时在线时峰值 （一般按照百万并发连接时服务器稳定性评测）
• 高并发时消息平均延迟时间（一般按照1分钟处理1百万条信息评测）
• 服务稳定性 （一般要求全年99.9%以上可用，有备份，有负载均衡等）
• 鉴于服务器稳定的开发难度很大，小团队不建议自己开发，建议使用稳定的第三方推送方案，如个推，蝴蝶等。

手机端的稳定性，主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难，所以稳定性非常重要，一般的评判标准包括：

• -每日联网23.5小时以上用户比例 （表征联网稳定性）
• 消息发送后9小时内收到率 （表征到达率）
• 一般来说，推送方案要做网络的分运营商，分省，分机型适配，自己开发工作量较大

2. 耗电

手机客户端都是TCP长连接。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。

3. 共享连接

如果一台手机上装了2个利用JPush的App，那他们会有多个后台服务在后台运行吗？会有多少个长连接呢？

4. 负载均衡

F5？

5. 链接中断

大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。

6. 单机的吞吐量

业界：

iOS 的推送：就是 Apple 官方的 APNs （Apple Push Notification service）。

Android 的推送：Google 官方的是 GCM (Google Cloud Messaging）。

本质上，APNs 与 GCM 是类似的技术实现原理：即系统层有一个常驻的 TCP 长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。

JPush：

为了不让 NAT 表失效，我们需要定时的发心跳，以刷新 NAT 表项，避免被淘汰。

Android 上定时运行任务常用的方法有2种，一种方法用 Timer，另一种是AlarmManager。

• Android 的 Timer 类可以用来计划需要循环执行的任务，Timer 的问题是它需要用 WakeLock 让 CPU 保持唤醒状态，这样会大量消耗手机电量，大大减短手机待机时间。这种方式不能满足我们的需求。
• AlarmManager 是 Android 系统封装的用于管理 RTC 的模块，RTC (Real Time Clock) 是一个独立的硬件时钟，可以在 CPU 休眠时正常运行，在预设的时间到达时，通过中断唤醒 CPU。这意味着，如果我们用 AlarmManager 来定时执行任务，CPU 可以正常的休眠，只有在需要运行任务时醒来一段很短的时间。

手机推送服务

标签：android   style   io   os   使用   ar   数据   sp   问题   

原文地址：http://www.cnblogs.com/linyx/p/4019190.html