企业官网建设流程全解析

其实做App推送这件事，我刚入行的时候觉得特别简单：不就是调个接口发个通知嘛。直到自己完整做过几个带推送功能的上线项目，才明白这玩意儿水有多深。光是一个"消息送达率"，就能让开发、运营、产品吵一整轮。这篇内容不搞花架子，把我这些年踩过的坑、摸清楚的逻辑，一次讲明白。无论你是刚接手推送模块的客户端开发，还是要做推送运营后台的产品经理，或者是想搞清楚推送原理的测试同学，照着这篇梳理，能省下不少弯路。

先说清楚一个最容易被混淆的概念：推送到底是什么。简单来说，推送是服务端主动向用户设备发起消息传递的机制，不需要用户主动打开App，也不需要客户端反复轮询。它和"拉取"是两种相反的通信模式。没有推送之前，App想知道服务端有没有新数据，只能定时去问，这不仅费电、费流量，而且不实时。推送解决了这个问题：服务端有话说的时候，直接找到用户手机，把话说出去。但这件事在移动端做起来，远比想象中麻烦，尤其是Android生态，简直是大坑套小坑。

1. 推送的本质和它解决的现实问题

1.1 推送的本质：服务端主动找上门

在技术层面，推送依赖于一条常驻的系统级长连接。iOS和Android系统各自维护着这样的连接通道，应用服务商把消息交给系统通道，系统再转发到具体设备上。这意味着真正负责消息下发的不是App自己，而是操作系统。这带来一个非常关键的隔离效果：即使App进程被用户滑掉、系统杀了进程，只要系统通道还在，通知依然能到达。

这里有个很生活化的类比。App像你家里装的对讲机，系统通道像小区的门卫室。你有事联系住户，不需要跑到每栋楼下喊，直接告诉门卫室，门卫室再用内部广播通知。即便住户正在睡觉，没接对讲机，门卫的广播依然能把他叫醒。推送就是这个"门卫广播"。

搞清楚这个本质，你就能理解很多现象：为什么Android手机关掉App后台后还能收到通知？因为通知是系统转发的，不是App发的。为什么用户强行"卸载"或者彻底关闭通知权限后收不到了？因为门卫室被住户下了"拒收"指令。

1.2 为什么短信和站内信替代不了推送

不少业务方一开始会问：我有短信通道，也有站内信，为什么还要接推送？

这三种触达方式解决的是完全不同的问题。短信的优点是覆盖面广、不需要App存在、穿透力强，但成本高、限制多、用户反感度高。站内信本质是"用户来你家时才能看到门口贴的条"，适合承载需要用户主动查看的历史记录，比如账单明细、系统公告。推送的定位则是"实时提醒+低成本触达"，适合高频、即时、轻量的消息场景。

我做过一个运动类App，它的业务形态就很典型：用户设置了每日锻炼提醒、好友发起了运动挑战、教练安排了训练计划，这些都需要实时通知。用短信提醒显然会把成本拉到天上，用站内信又完全起不到提醒作用。推送是唯一合理的选择。这也是为什么社交、电商、工具、运动、网约车这类App全都重度依赖推送——它是产品与用户保持连接的生命线。

1.3 推送的核心指标：按消息类型分开看

很多团队一上来就谈"送达率要100%"，这其实是个伪命题。推送消息至少要分成三类，每一类的目标完全不同：

• 营销类消息：比如电商大促、优惠券到期，这类消息天然容易被用户屏蔽，送达率能到80%以上就算不错。
• 服务类消息：比如订单状态变化、物流轨迹、验证码，这类消息用户是"期待收到"的，送达率应该目标逼近100%。
• 系统类消息：比如账号异地登录提醒、版本强制升级，这类消息即使部分Android机型有厂商限制，也必须有兜底方案。

理解了分类，你才能正确看待技术方案选型。如果所有消息都要求最高可靠性，那技术成本会成倍增加，比如需要同时接入厂商通道+自建长连接+短信兜底。但大多数产品根本不需要这么重的方案。

2. 国内App推送的生态与选型：为什么Android这么乱

2.1 iOS的APNs与Android海外的FCM：两条标准路线

在iOS平台上，推送几乎是唯一解：APNs（Apple Push Notification service）。所有iOS设备的通知都走苹果的统一通道。优点是极其稳定、省电、体验统一；缺点是所有消息都要经过苹果审核机制，且无法像Android那样随意发"透传消息"（静默消息），限制较多。

在Android海外市场，Google的FCM（Firebase Cloud Messaging）扮演着类似APNs的角色。但由于国内设备上没有完整的Google服务依赖，FCM这条路在国内走不通。这就导致了国内Android推送生态进入了一种"分裂"状态。

2.2 国内厂商通道：小米、华为、OPPO、vivo、荣耀

既然没有统一的系统通道，国内头部手机厂商各自建立了自己的推送通道。现在主流的有：小米推送（MIUI）、华为推送（HMS Push）、OPPO推送（ColorOS）、vivo推送、荣耀推送。魅族也有一套，但市场份额小，很多第三方服务商也兼顾。

为什么你必须接厂商通道？因为国内Android手机上，很多用户有清理后台的习惯，App进程随时可能被杀。如果只靠App自己维持长连接，进程一死，推送就断了。厂商通道是系统级的，即使App被杀，系统依然能接收并展示通知。实测下来，应用商店分发的主流型号，厂商通道的实时性和可靠性远好于自建长连接。

这就像一个城市没有统一邮政系统，每个小区（厂商）都有自己的快递柜。你要给全市住户送通知，就得挨个小区谈合作，把包裹放进每个小区的柜子里。这也就是为什么国内推送集成工作比iOS繁琐得多。

2.3 第三方推送服务商：极光、个推、友盟、MobPush

面对这么多厂商通道，逐家对接显然不现实。常见的做法是通过第三方推送服务商，比如极光推送（JPush）、个推、友盟推送、MobPush。这些服务商已经提前把小米、华为、OPPO、vivo等厂商通道全部封装好，你只需要接入一个SDK，就能把消息同时下发到不同厂商通道。

第三方服务商的核心价值有两个：统一接入和智能路由。前者很好理解，后者是指服务商根据设备的厂商类型，自动选择合适的通道下发，不用客户端自己判断。比如同一台小米手机，服务商会自动调用小米通道，而不会走FCM或者自建长连接。

选第三方服务商的时候，我建议重点考察几个点：厂商通道的覆盖度（是否支持最新的荣耀、是否有魅族）、免费额度和商务条款、控制台的运营功能（定时推送、标签分群、A/B测试）、API的扩充能力，以及出问题时的技术支持响应速度。

提示：很多团队一开始为了省钱自己对接厂商通道，结果光是要搞定vivo和OPPO的厂商申请资质就折腾了一个多月。如果你的业务不是特别在乎推送这个环节的差异化能力，用第三方服务商是更理性的选择。

2.4 Android与iOS推送机制对比速查

这张表基本概括了为什么推送这个"小功能"在不同平台上工作量和坑位差距巨大。

3. 一条推送消息的完整生命周期：从点击到展示

3.1 推送下发的完整链路

一条推送从业务服务器到用户手机，大致经过五个环节：

1. 业务服务器调用推送服务商的API，传入推送内容、目标设备标识、过期时间等参数。
2. 推送服务商根据目标设备的类型和在线状态，选择最优通道。
3. 通道服务器（APNs或各厂商推送服务器）将消息推送到目标设备。
4. 设备的系统级进程收到消息，展示通知栏消息（或根据消息类型触发App回调）。
5. App在合适的时机处理消息，比如跳转页面、更新UI、上报点击事件。

这里面任何一个环节都可能出问题。比较常见的坑是第一步传错设备标识，或者第二步通道选择错误导致消息走了低优先级通道，又或者第三步厂商服务器被限流。排查推送问题的时候，要按这个链路逐段定位，而不是只看"为什么收不到"这一个表象。

3.2 通知消息与透传消息：两种完全不同的玩法

在Android生态里，推送消息可以分成两种类型：通知消息和透传消息。这个概念极其重要，很多初期的项目就是因为没搞懂这两者的区别，导致消息展示异常。

通知消息是直接由系统展示的通知栏消息，不需要App进程存活就能展示。用户看到的就是标题+内容。这类消息是App被杀死后依然能提醒用户的关键，但是不能控制消息的展示样式，只能使用系统默认的交互。

透传消息也叫"静默消息"，消息到达设备后，系统不会自动展示，而是回调给App，由App决定接下来做什么。比如App收到透传消息后，可以自行弹一个自定义弹窗、更新数据、触发下载任务。但前提是App进程必须活着，否则压根收不到。所以在实际项目中，透传消息一般用来做"应用在线时"的业务场景，比如IM消息、客服消息、实时价格更新。

我见过有团队把所有消息都用透传发，结果用户一杀进程就收不到关键通知，被运营追着骂。正确做法是：需要保证100%展示的消息走通知消息，需要App处理逻辑的消息在App存活时走透传。更稳的方案是"通知消息和透传消息同时发"，通知保证触达，透传保证业务逻辑。

3.3 离线消息：用户关机、断网了怎么办

推送服务商通常都有"离线消息"机制，也就是当设备不在线时，先把消息存下来，等设备上线后再补发。这里有一个需要仔细设计的参数：离线消息的有效时间。

比如在离线时间默认是1天，那用户断网一天后打开手机，会瞬间收到一大堆过时通知，体验非常糟糕。比较好的做法是区分消息类型：服务类消息可以设置几小时的有效期；营销类消息设置更短，比如1小时；有些时效性极强的验证码消息，甚至可以直接不做离线补发。推送服务商的后台一般都有这个参数配置，不要用默认值。

3.4 打开发送的payload长什么样

不管走哪个通道，推送消息最终都会有一个标准化的payload结构。以iOS APNs为例，核心字段如下：

{ "aps": { "alert": { "title": "运动提醒", "body": "你今天还有3公里目标未完成" }, "badge": 1, "sound": "default" }, "custom_key": "custom_value" }

Android厂商通道的payload结构虽然各不相同，但核心概念一致：包含通知的标题、内容、是否响铃震动、消息ID，以及自定义的extra字段。开发中常见的坑是iOS端自定义字段如果放在aps外层，App在后台时framework层能收到，但如果App被杀，点击通知启动App时只能从delegate回调里取出launchOptions，这里面的数据解析特别容易出错，需要认真测试。

4. 接入推送的实操细节：从App到服务端的必备功课

4.1 申请各厂商通道的资质和密钥

不管你是直接对接厂商还是用第三方服务商，申请厂商通道都需要一些基本资质。通常你需要准备：App在应用商店的上架信息或应用签名、企业资质或个人开发者信息。华为、小米、OPPO、vivo都有自己的开放平台，申请流程相似：注册开发者账号、创建应用、开通推送服务、获取AppID和AppKey/AppSecret。

实操中容易卡壳的几个环节：

• OPPO和vivo的推送申请对非上架应用审核较严，有时要求提供软著或上架截图。建议在项目立项初期就同步申请，不要等开发完了再补。
• 华为的推送服务支持"Debug模式"，但要注意区分调试和生产的ClientID。
• 荣耀推送目前基本沿用了华为的推送接口，但要在荣耀开发者平台单独创建应用。

注意：厂商通道的密钥是一对一的，一个App对应一家厂商的一套Key。如果同一个App包名在多个渠道申请了不同的签名，一定要确认屏蔽逻辑，否则消息推送会互相串。

4.2 第三方SDK的接入与初始化

这里以常见的第三方服务商为例，大致流程是：在服务商后台创建应用、获取AppKey，然后在客户端进行初始化。

Android端在Application的onCreate里初始化：

JPushInterface.setDebugMode(true); JPushInterface.init(this);

iOS端在AppDelegate的didFinishLaunchingWithOptions里注册：

[JPUSHService setupWithOption:launchOptions appKey:@"your_app_key" channel:@"App Store" apsForProduction:isProduction];

初始化完成之后，需要获取设备的registrationId并上报给服务端。服务端后续推送时靠这个ID定位设备。这里的常见问题是一个用户多台设备的情况：设计注册信息时，建议一张表里维护userId与多个deviceToken的映射关系，并在登录态变化时及时解绑。否则用户换设备之后，消息很容易发到旧设备上。

4.3 Android 13通知权限：绕不开的硬门槛

Android 13（API级别33）开始，通知权限变成了运行时权限，需要像请求定位权限一样向用户申请。这一步被很多老项目忽略，导致升级到Android 13后推送突然失效。

申请核心代码如下：

if (Build.VERSION.SDK_INT >= 33) { val manager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager if (!manager.areNotificationsEnabled()) { requestPermissions(arrayOf("android.permission.POST_NOTIFICATIONS"), 100) } }

只有在拿到权限后，App才能展示通知栏消息。这个弹窗的时机设计很有讲究：太早弹用户会拒绝，太晚弹用户可能根本不知道这个App是干嘛的。我通常的做法是，在用户完成一个关键操作后弹出，并在弹窗前先展示一个自定义引导浮层，说清楚"开启通知可以收到订单状态、活动优惠等重要提醒"，能显著提升授权率。

4.4 iOS端的证书与Key配置：两个必须注意的环境

iOS推送依赖APNs证书或Token Key。如果使用旧式证书，需要注意p12证书会区分开发环境（sandbox）和生产环境（production）。开发阶段用开发证书，发布后用生产证书，如果环境配错，推送在某种情况下可能静默失败。

如果使用Token Key（.p8文件），则没有环境和证书有效期的问题（Key有效期最长可达一年），而且一个Key可以同时用于多个App，是目前推荐的方式。无论哪种方式，在交给服务端之后，一定要在服务端保留好环境参数，在推送接口里明确指定目标环境。

4.5 服务端推送接口设计要点

服务端是整个推送链路的发起方，接口设计直接决定后续的可靠性。我总结的几个关键点：

• 消息队列解耦：推送请求先进入MQ，由消费者异步调用推送服务商接口，防止业务接口因为推送超时被拖垮。
• 幂等设计：每个推送任务都要有全局唯一的任务ID，服务商接口支持根据消息ID去重，业务端也要做去重。
• 回调上报：必须接收并存储推送服务商的下发回执（送达、点击、过期等状态），这是排查问题的数据基础。
• 内容审核：对推送内容做敏感词过滤、链接检测，尤其是营销类内容，避免被封禁推送权限。
• 限流控制：每家服务商都有接口QPS限制，高峰期需要做限流，否则会有部分消息被丢弃。

5. 推送运营后台：内容、频控与用户分群

5.1 推送文案怎么不招人烦

推送是一个强打扰产品，文案写得好不好直接影响卸载率。我自己看数据发现，用户最容易点击的文案有两个特征：一是明确表达了"这条消息对他有什么好处"，二是没有营销轰炸感。比如：

• 差标题："限时优惠，全场5折！"
• 好标题："你收藏的跑步鞋降价了，直降80元"

好的推送文案往往会在开头就交代清楚"你是谁"，避免用户看到通知时皱眉回想半天。对于服务类消息，直接把核心信息放标题里，比如"您的订单已到达，请到前台领取"，用户不打开App也知道发生了什么，这会极大地提升用户对App的好感。

5.2 频率控制是底线工程

推送频控如果做不好，后面所有运营动作都会塌方。比较常见的做法是：单个用户每日推送条数上限（比如3条）、同一类型的消息N小时内不重复发、营销类消息只在特定时间段发送（比如10:00-12:00和19:00-21:00）。这些控制既可以在服务端代码里做，也可以在推送服务商的后台配置。

更精细的做法是给用户打标签，比如"营销敏感用户"、"重度睡眠用户"，针对不同标签执行不同的频控策略。这个需求在项目初期可能没有，但如果推送体量上来，迟早要做。

5.3 推送的A/B测试：不要靠感觉

推送文案、推送时间、推送人群都是可以A/B测试的。很多服务商后台已经提供了简单的A/B实验功能。实操中，一次实验的样本量不要太小（每个分组建议至少几万人），否则结果没有统计意义。同时，要区分核心指标：营销推送看点击率和转化率，服务推送看送达率和用户满意度。

我做过一个电商类的实验：同一批用户，A组推送文案强调价格优惠，B组强调库存紧张，结果是B组点击率高出37%。这个结果如果靠直觉，很难猜对。所以，推送内容生产也应该是"数据驱动"的，而不是"灵感驱动"。

6. 常见问题与排障技巧：收不到推送时别慌

6.1 收不到推送的排查顺序

收不到推送是出现频率最高的问题。我的排查顺序固定是：通知权限 -> 设备标识 -> 进程状态 -> 厂商通道 -> 服务端日志。

先看手机设置里App通知是否开启。Android用户很容易误关通知权限，到时候怎么测都收不到。再看registrationId是否和服务端保存的一致，App重装后registrationId会变化，很多人忘记更新。再看测试机型：有些厂商对"自启动管理"、省电策略有独立的开关，即使用户打开了通知权限，后台限制仍然能卡掉推送，需要在系统设置里把App加入白名单。

如果以上都没问题，再看服务端推送日志，确认消息是否已经推送到服务商、服务商返回的响应code是什么。第三方服务商的后台一般都有"查询推送明细"的功能，能看到每条消息的送达状态，排查效率会高很多。

6.2 推送到达率低：先看是不是用户自己关了

推送到达率低，很多时候不是技术问题，而是用户主动"用脚投票"。当用户发现一个App总是发无用的广告，他大概率会关掉通知。如果你发现自己App的推送送达率在持续下滑，优先去检查用户对推送消息的点击率，以及通知权限的开启率。这些数据在第三方服务商后台都有。

如果确认技术链路正常，那么问题很可能出在内容端。此时应该做的是重新梳理推送内容的价值感，而不是继续加码推送次数。推送次数越多，用户的授权率越低，这是产品运营层面的恶性循环。

6.3 App抓包看推送请求

排查推送问题时，抓包定位非常有帮助。尤其是服务端推送接口传参错误导致的静默失败，光看服务端日志很难快速定位。可以抓两种包：服务端HTTP请求抓包、客户端SDK与厂商服务的网络请求抓包。

抓包工具方面，常见的方案有Charles、Fiddler、Wireshark，以及一些移动端抓包工具。需要注意，很多厂商推送SDK默认不走系统代理，需要额外安装证书并做SSL解绑。另外，抓包时手机和电脑要在同一局域网，部分厂商通道强制使用HTTPS证书校验，抓包时可能会出现"SSL握手失败"之类的提示，这并不一定是推送问题，可能是抓包工具的证书没有被信任。

6.4 测试阶段最容易忽略的机型兼容问题

推送的兼容问题，往往出现在测试覆盖不到的长尾机型上。比如某款手机的系统在后台对推送通道有特殊优化，导致厂商通道连接被延迟；又比如某款手机的通知设置里有个"通知分类管理"，默认把App的通知静音。这些极度细碎的问题，在真机测试时很难全部覆盖。

我的建议是测试用例里至少要覆盖三类设备：iOS设备一台、搭载最新Android系统的主流大厂机一台、一台国产老机型（低版本系统）。同时，安排一轮"清后台测试"和"重启手机测试"，确认App进程被清理、手机重启之后，推送是否还能正常收到。这些场景是线上故障高发区。

6.5 服务端推送返回成功但客户端没收到

这类问题通常是推送服务商已经把消息下发给了厂商通道，但厂商通道因为设备不在线、消息过期、通道被限流等原因没有送达。第三方服务商后台通常会有"厂商回执"数据，能看到厂商通道最终是否接收了消息以及错误码。如果没有回执数据，可以直接找厂商技术支持查。

还有一个容易忽略的点：推送消息的"厂商类别"是否与设备匹配。比如设备是一台小米手机，但推送时由于registrationId被错误解析，消息发到了华为通道，结果直接被丢弃。这类问题在Android多渠道环境下不算罕见，究其原因还是设备标识管理混乱。

7. 我的一点实用建议和踩坑心得

做了这么多推送相关的项目，最大的体会是：推送不是一个"集成完就结束"的模块，它是一个持续运营、持续优化的系统。技术上它涉及客户端、服务端、厂商通道、第三方服务商多段协作；产品上它涉及文案、频控、用户分群、数据监测。任何一个环节掉链子，最终用户感知的都是"这App总给我瞎发通知"或者"这App通知总收不到"，两种评价都会让产品受损。

有一个小建议值得单独提出来：所有推送消息，无论是营销类还是服务类，都建议做"用户可控制"设置。比如在App内增加一个"消息通知设置中心"，让用户自己选择接收哪些类型的推送。表面上看似多了一步操作，实际上反而会提高用户对推送的信任度，整体授权率和点击率都会更好。这是我自己做一个运动App时验证过的经验：开放消息偏好设置后，通知权限的整体开启率比之前提高了将近20%。

最后再分享一个排查技巧：线上推送出问题时，先别急着动代码。登录推送服务商后台，查一下目标消息的单条明细，基本能定位到是服务端没发出去、服务商没转发，还是厂商通道拒收。很多团队花半天查代码，最后发现只是测试环境下推送服务商的白名单域名没有配置完整。这类问题看起来低级，但确实是实战中最高频的。希望这篇内容能帮你少踩几个坑。