移动端推送服务主要指通过特定的服务器把实时信息及时的发送给客户端。而在实现该功能的同时会伴随着红点机制或是相应的类似弹出框形式的信息展现。
推送在好的产品设计中是一个有效提高用户活跃的功能，也是对用户进行精准营销的有效手段。
首先我们看下iOS的具体实现原理（以下两种图估计被用烂了）：
第二步，应用所在的iOS操作系统向苹果的APNS服务器请求device token，APNS根据对应的证书以及设备信息生成device token，并把该device token返回给相应的应用进行存储；
第三步，应用把APNS返回的device token发送给具体的推送服务器。
通过以上三步具有推送功能的应用、APNS服务器、推送服务器便都具有了device token这一个标识，而具体的发送推送的过程，在可以看下图：
Provider(推送服务器)首先把推送消息发送给APNS，APNS通过获得推送服务器提供的device token匹配自己保持的device token列表，找到对应的能够接受推送的手机设备，并把消息发送到对应的iOS操作系统，操作系统接受到推送消息后再在系统内通过相应的机制送达我们的APP 。
以上是iOS的整个推送流程，这部分在网上已经有许多的介绍文章，对应的我把相关的文章链接贴出来，有兴趣的可以在仔细看下这两篇文章：
ios推送消息的基本原理
iPhone的UDID与push中使用的device token的关系
在具体的项目中主要基于第三方推SDK 实现了广播推送、自定义定时推送、按设备标签推送这三个功能，其中的波折只能用欲哭无泪来形容（技术人员的实力在此处有了很好的体现）。
广播推送：一般的主流第三方推送都会提供的简单内容推送，通过设置推送源的相关属性，可以使得所有保持连接的用户无差别接收推送消息，并且在点击通知栏信息时可以进行直接跳转。
自定义定时推送：借助第三方推送SDK进行二次开发，实现在后台编辑内容并设置推送时间后，用户可以在特定时候接收到推送消息，并且在设定时间内打开应用可以直接弹出推送信息的入口弹窗。
按设备标签推送：简单的精准推送，可以在用户的某些行为下产生用户标签并进行记录，然后再通过在发送推送时设置不同的标签实现对不同的用户推送不同的消息。
通过以上两篇文章，相信你一定可以详细的了解推送功能的机制。我也不再累赘，以下主要说下我遇到的一些坑（很多都是泪啊）：
推送只会到达应用外层，不会对应用内的功能进行控制（除非已经做了一些特定推送功能的开发）。如果光有推送功能，会在用户的手机的通知栏产生相应的提示信息；用户若是直接点击通知栏提示信息，那么可以通过设置推送内容直接进行跳转。
但大量的事实告诉我们用户很多时候不会通过点击通知栏进入应用，而是直接点击应用图标进入应用（推送会触发应用icon产生红点，而红点的用户习惯已经被普遍培养起来了）；此时在用户在进入用户的首页时，并不知道你刚刚推送的消息具体是那个模块的。如此推送的作用便由于没有引导物而不能产生价值。
2、在以上分析原理的文章中，一再提到一个叫做device token的东西，可能很多人会问这是个什么东西（这个东西只在iOS中存在）？
简单的说就是APNS识别iOS操作系统的唯一标识符，通过这个东西APNS才能找到对应APP所在的手机。而这个东西又会和应用的证书有一定的关联性，而这个证书在具体的应用开发中让我这个产品经理踩了好多坑。
一次是技术人员由于证书要到期的原因，重新生成了证书，但是由于我们在线上的证书还是老版本，所以造成推送功能没法使用。另外证书在iOS的开发中一般是存在两个的，一个测试证书一个正式环境的证书，而如果对这两个证书的使用稍有不当不单单是对推送功能会产生影响，还会在具体的测试中造成不必要的麻烦。
3、上面第二点主要是在iOS中遇到的坑，在说说在安卓中遇到的。
安卓的推送和iOS稍微有点不同，在国内一般不存在像APNS这种官方的中间服务器，所以一般都是通过推送服务器和客户端保持长链接而实现推送的。但一般情况下系统因为本身机制的问题，会不断的杀死长链接（续航、内存管理等机制）；从而导致很多的情况下推送是不能送达客户端的；而这种能够维持稳定长链接的问题还是很有技术难度的，故我们在费了很多精力去设计并实现推送功能时，往往因为到达率过低而让你沮丧。
而不同厂商改造后的安卓系统对推送功能的支持也是不一样的，最大的区别在于推送在应用icon上产生红点的机制，很多厂商的操作系统是不会因为推送触发应用icon上的红点。而解决这类问题只有提升技术实力，但是作为一个产品汪，我也是无力杀敌啊，最后对于安卓的具体实现情况我只能妥协，只祈祷着技术实力的提升。
4、安卓中另一个问题就是测试了。由于在安卓中是没有所谓的推送测试环境的，所以一定要注意在设计之初就想好测试推送功能的方式。
我想到的有两种：把测试和正式环境一开始就区分开。
如果是用第三方最好是有一个测试账号还有一个正式账号，如果是自己开发则一定要预先便把两个环境都搭好，千万别让两个环境互相干扰。
第二种就是在代码中设置测试标签，一般的推送都是支持按特定的标签推送的只要预先在代码中写死测试系统的标签即可，再通过设置测试标签区分正式和测试环境。
不过推荐使用第一中方式，会安全很多。
5、关于精准推送。
现在大部分的主流第三方推送都可以做到定向推送按设备标签、按设备号等。而在设计这种功能时一定要预先想好标签的获取方式，以及不同标签的组合方式，在第三方推送的后台中只会支持标签之间的“或”关系；如果想要通过不同的标签组合缩小推送用户范围是没办法实现的，最好的方式就是自己进行二次开发。而这种精准推送在测试时也是很困难的，标签的不同组合的效果都要测试，而设备获得标签的时机又是比较特定的所以测试用例也是相当考验测试人员专业性的。
以上就是我在基于第三方推送设计推送功能时遇到的若干个坑，有些是自己在设计之初对推送原理认识不够造成的，而有些就是在项目进展中被其他的相关人员埋了坑。总结这些也是希望自己在后续的产品设计中可以预先想好相应的应对方案，使自己对项目掌控的更好，减少不必要的麻烦。
同时希望自己把遇到的坑，以及填坑的过程讲出来，可以和大家一起讨论！
