多推送 SDK 的方案中，我们还需要思考什么？

发布时间：2025-11-05 09:08:51 来源：技术快报 作者：IT科技

一、多推的方前言

前两天推送了一篇文章，案中讲解的需思如何集成多 SDK 推送的方式，共享系统推送通道，多推的方来提高推送的案中送达率。但是需思在实际操作的时候，还是多推的方有一些地方需要被注意到，并延伸思考。案中

本文就对之前的需思多推送 SDK 的方案，做一个补充，多推的方希望让你跟全面的案中了解到你在做什么，需要思考什么?需思

还不了解什么是多推 SDK 送方案的，可以先看看之前的多推的方文章：《来自悦跑圈的多推送 SDK 方案 — MixPush》

二、什么是案中多 SDK 推送方案

首先需要了解到，什么是亿华云计算需思多 SDK 推送方案。在 Android 的推送服务的市场中，存在多家提供推送解决方案的服务商。例如：极光、个推、小米、魅族、华为 等。

而这众多的推送方案中，又可以被分为两类：

1、厂商系统级推送

有自己的硬件设备以及与之匹配的定制系统。对于这类系统级的推送，优势在于，一般是走的系统推送服务，可以做到送达率更高，更稳定，基本上可以无视你的 App 是否运行。类似于 iOS 下，提供的系统推送服务。但是劣势也非常的站群服务器明显，在非该系统的设备上，送达率并不高。比较有代表的就是：小米(MIUI)、魅族(Flyme)(送达率可以到 90% )。华为据我了解到的情况，本身系统推送服务有问题，所以方案里也不推荐使用。

2、第三方推送

纯粹的以第三方服务的形式存在。因为没有系统推送通道的支持，本身没有那么多优势，所以它为了提高送达率，会做更多的努力，在不同的系统上也会做不同的支持和适配，这个是优势也是劣势。因为不依赖系统推送服务通道，这样在不同的系统中，送达率并不会差别太多。比较有代表就是IT技术网：个推、极光(送到率可以到 25%)。

这样比较有优势的多 SDK 推送的方案诞生了，在项目内集成多家推送 SDK，在存在系统级推送服务的设备上，注册使用系统级的推送 SDK ，而在不存在系统级推送服务的设备上，直接使用第三方推送(一般选一个第三方推送即可，本文方案里选的 个推 )。这样能保证存在系统级推送服务的设备送达率较高，而不存在系统级推送服务的设备上，送达率也不至于太低。

需要注意的是，虽然在项目内，集成了多个 App 推送的服务，但是会根据机型和系统，只对一个推送服务进行注册，也就是同时只保持一个推送服务的有效注册。这服务端就无需区分机型，直接对所有推送服务商的服务，发布推送即可。

如下图：

三、那么有什么缺陷吗?

3.1 Apk 体积会大

按现有厂商(小米、魅族)+ 第三方(个推)的这种组合方案，一般也需要集成 至少 3 家推送 SDK 。正常来说，一家的 SDK 大概在 400KB 左右，当然正常打包下来，应该会更少一些。

不过哪怕就算是少一些，也会增加大约 1MB 左右。如果对于 Apk 本身已经达到二三十 MB 的 App 而言，其实影响并不大。但是如果本身只有几 MB 的 App ，增加 1MB 其实就需要掂量一下了。

本身维护过一个总体积不到 1MB 的 App ，基本上任何增大体积的 SDK ，都是被禁止的。

3.2 依然需要注册各种服务

虽然在代码层面，会根据不同的机型，注册不同的推送服务。但是哪些不被注册的推送 SDK 依然是需要在 AndroidManifest.xml 注册组件的。

就以个推为例，它会需要在 AndroidManifest.xml 中注册一个推送核心的 Service ，被标记为 android:exported=true ，这也是为什么有说法，推送服务会相互唤醒。也从一个侧面来说，对于第三方推送服务，市场占用率决定了送达率。

这样，可能会导致我们并没有用到该推送服务，但是它却被拉活运行在后台。例如在小米设备上，本身主动注册的是使用小米推送，但是个推的服务，依然可能会被其他集成了个推的 App 唤醒，这些都是不受我们控制的。

不过好在现在一些国产定制系统和原生 6.0 以上的系统中，相互唤醒已经被禁止掉了，所以这样相互唤醒的问题，应该会有所缓解。

四、能不能做的更好一点

既然一些系统级的推送服务中，主要是依赖对应的系统，例如小米推送就需要依赖 MIUI 。这样我们就可以简单的理解为，使用小米应用市场的设备，都是运行的 MIUI 。那么，我们也可以对不同的市场渠道，利用 Gradle 打出只集成了该推送 SDK 的 Apk ，对小米市场的渠道包，只集成小米推送SDK ，其他都不集成。这样不光 Apk 的体积会有说减少，并且也不存在被其他推送服务相互拉活的情况。

当然，对于一些第三方应用市场的渠道包，还是需要集成多个推送 SDK 的。

但是这样也会引发一些其他的问题，例如，一些热更新的算法需要有基准包，来计算差量生成差量包，用于热更新，如果使用 Gradle 对不同的推送打出不同的渠道 Apk ，他们本身的代码已经不一样了，就会导致如果需要使用热更新的话，基准包就会有多个，复杂度也就提高了，维护成本自然增大了。

五、小结

以上就是我对多推送 SDK 集成的一些思考。实际上最简单的方式，依然是之前文章中，介绍的方案，直接集成多推送 SDK ，不需要分包。

最简单的方案也是最稳定的方案，但是这并不影响我们思考的跟多一些。

【本文为专栏作者“张旸”的原创稿件，转载请通过微信公众号联系作者获取授权】

戳这里，看该作者更多好文

相关文章