手机推送系统的未来编辑本段回目录
推送和消息提醒已经是智能手机的重要功能。虽然它们可以帮助我们及时获取各种信息，但有时也会分散我们的精力、降低办事效率。比如你可能在办公时收到Draw Something的邀请而打乱工作节奏，或者在睡觉时被微博新增僵尸粉的提醒声吵醒。实际上在这两种情景中，这些推送提醒对你来说是完全没有价值的。
那么智能手机等设备应该如何根据用户需求定制更个性化的推送系统呢？至少可以从地点、情景模式和对象这三个不同的手段寻求突破。
人们几乎会一直携带着他们的智能设备，但是在不同的地点对推送有着不同需求。比如工作中人们可能只需要和工作有关的提醒消息，而回家则需要关注更多的休闲与居家类的轻松话题。依据地点而推出差异化的推送服务并不难实现。手机可以依靠GPS功能定位，再将位置信息反馈给相关应用，应用依靠收到的信息可以进一步优化推送服务。Gmail现在已经可以依据算法决定邮件的优先级。那么依据位置信息算出哪些邮件与工作有关，再做出与地点相匹配的推送服务，这也并不是天方夜谭。
仅仅依靠地点来定制推送服务还远远不够。如果我们在家办公，这种基于地点的推送服务反而会适得其反。这个时候我们需要情景模式的帮助。手机本身已经内置一些情景模式，比如睡眠、静音、办公等。如果这些情景模式可以和各个应用无缝整合，依据用户习惯推出一套与情景模式相适应的推送系统，用户只需简单的切换便能达到自己想要的效果。比如加班办公时，用户只用将模式切换到工作模式即可。
消息来源的对象也很重要。你当然不想在深夜被僵尸粉的评论给惊喜，同样你在任何时刻也不想错过你深度关注的人所发出的消息和信息。因此，社交类应用依据用户交往和互动信息，对高频对象建立过滤器，使用户可以时刻得到对方的一手信息也是需要重点考虑的问题。
当然，深层次的定制个性化的推送服务需要用户本身的行为习惯和私人信息的支持，这对应用的隐私保护问题又是一个挑战。但是在信息大爆炸的今天，通过智能推送使用户及时掌握有价值的信息，是有效过滤信息，解决信息超载的重要前提。
图片来源：nexgagdet 文章部分观点参考来源：thenextweb
浅析手机消息推送设计 编辑本段回目录
消息是提醒用户有更新的内容，可能短信、邮件、好友申请和日程安排。消息的作用在于主动提醒用户，不需要主动刷新程序或者网页去检查更新，比如Android的sina微博，必须手动刷新程序才能更新微博或者查看好友申请。这种做法可以节省流量，对于手机包月用户而言非常有必要的。用户专注于当前任务时，可以接收到其他应用程序推送的消息，用户可以及时处理多任务。
推送机制
最基础的方法是程序实时联网获取消息，但是程序会占用内存，频繁联网耗费电量，程序各自链接自有服务器还会占用很多进程。以轮询（poll）的方式实现时需要程序不定地询问服务器是否有更新，推送（push）的好处在于有消息时由服务器告知手机客户端，手机此时再发起更新，省电省流量，所以智能手机平台都会有推送服务。
iPhone自3.0之后推出消息推送机制，原理是消息由服务器统一处理：
- 应用服务器Provider将消息和目标发送给APNs
- APNs查找目标iPhone并发送消息
- iPhone将消息传递给应用程序，再弹出Push通知
APNs和iPhone保持15分钟的心跳式长连接，维护手机和服务器的联系正常，否则手机会不停发起连接，直到连接到服务器为止。程序不必实时开启和主动检查更新，当收到APNs消息时，iPhone会弹出对话框Push消息并伴随着声音，用户可以选择“view”或者“close”。即使用户当前处在离线状态，用户收到消息之后激活程序，再通过程序链接应用服务器下载邮件或者录音。
WP7的也有相应的推送服务，无论程序是否开启都可以界面顶部推送Toast Notification，并显示10秒。WP7的Push Client负责于服务器交互，接受到消息时再传送给相应的应用程序，而不需要应用程序各自维护一个进程。如果程序被钉在首页，服务器推送瓦片通知（Tile Notification），改变瓦片的背景图片、数字和标题属性。而弹出框式的原生推送（Raw Notification）只能应用在程序开启时，容许实时更新界面。
除了iPhone的长连接心跳查询，PushMail的IMAP可以支持IDLE特性，邮件客户端登录连接服务器后不会主动检查更新，而是停留在空闲状态，当服务器接收到新邮件再通知邮件客户端，此时客户端会再查询收邮件。或者依靠短信触发，以看不见的短信方式触发程序发起更新，但是短信方式的实现成本较高。（非技术人员，相关技术描述可能有误）
推送形式
iPhone的消息弹出框如果点击“view”会影响当前操作，但是如果点击“close”就再也查看不到消息。由于弹出框形式的限制，没法像Android状态栏那样同时显示多条消息。分散在各个屏幕的badge难以管理，多数badge并没有实际意义，比如花了很长时间更新可能发现某个应用程序只是改了个程序名称。
iPhone的消息缺乏统一的管理，虽然比Android容易推送消息，但在终端没有将消息聚合起来统一管理，所以有设计师对其加以改进，设计了Notifications App。解锁界面显示消息，滑动某条消息可以立即查看具体内容。对现有iPhone的界面操作的基础上加以利用了解锁界面。
双击Home键可以从底部调出消息，而越狱APP Notified Pro和Android一样利用状态栏，两者目的都是为了全局操作。考虑到很多游戏会覆盖状态栏，Notifications的方式较好，同时对用户现有操作系统影响较小。进入该程序中可以对所有消息统一编辑或者清除。
之所以需要统一管理的另外一个原因在于程序越来越多，消息也越多，个别应用程序为了吸引用户注意力，会频繁推送消息，导致消息泛滥和影响用户对重要消息的关注程度。
终端推送设计
除了要了解OS对消息的处理机制和展现形式，消息自身的众多属性可以在设计中加以利用，比如消息的元数据、状态、优先级和同步方式等等。
时效性强的短信、微博私信和邮件处理的优先级更高，可以优先显示在解锁界面。好友申请、系统消息和好友评论等优先级稍低，只以数字提醒并且不带声音，甚至只能在程序开启时提醒。未来情景式消息推送会在手机端发挥作用，优先级会依照信息对用户的有效性有所提升，比如到了某了商店附近触发折扣信息的推送。
服务器在推送消息时，如果可以附带更多样的处理方式、比如查看完整的140字微博、回复、忽略、已读和拒绝，不进入其他程序（如Facebook和短消息）就能操作会提高处理的效率，正如MIUI在主页收到短信时可以立即回复。
程序应该智能识别处理状态，比如已读带处理的消息标记为badge不再重复声音提醒，好友申请可以分为同意、拒绝和忽略，对于在各种手机端被用户忽略的消息可以设定为垃圾消息。
多台设备的消息可以同步处理，如iPhone端的消息未读，切换到PC端时，查阅了更新的内容之后，iPhone端的消息可以取消推送。
未来的消息推送很有可能会向WP7那样往集成化的方向发展，其重要性将越来越高。
参考资料：
