1。前言前两天发了一篇文章，讲解如何整合多种SDK推送方式，共享系统推送通道，提高推送的送达率。但是在实际操作中，还是有一些地方需要注意和延伸思考。本文是对之前多推送SDK方案的补充，希望能让大家全面了解自己在做什么，需要思考什么？如果不知道什么是多推送SDK下发方案，可以看看上一篇文章：《来自悦跑圈的多推送 SDK 方案 — MixPush》2。什么是多SDK推送方案？首先需要了解什么是多SDK推送方案。在Android推送服务市场中，有很多提供推送解决方案的服务商。例如：极光、个推、小米、魅族、华为等。在众多的推送方案中，可以分为两类：1、厂商系统级推送有自己的硬件设备和配套的定制系统。这类系统级推送，优点是一般使用系统推送服务，可以达到更高的投放率，更稳定，基本无视你的app是否在运行。类似于iOS下提供的系统推送服务。但是，缺点也很明显。在没有这个系统的设备上，交付率不高。比较有代表性的有：小米（MIUI）、魅族（Flyme）（出货率可达90%）。据我所知，华为自己的系统推送服务存在问题，所以不建议在解决方案中使用。2、第三方推送纯粹以第三方服务的形式存在。因为没有系统推送渠道支持，本身没有那么多优势，所以为了提高投放率，会做更多的努力，也会在不同的系统上做不同的支持和适配。这是优点也是缺点。因为不依赖系统推送服务渠道，所以不同系统的投放率不会有太大差异。比较有代表性的有：格推和极光（到货率可达25%）。这样，一个更有优势的多SDK推送方案就诞生了。项目中集成了多个推送SDK。在有系统级推送服务的设备上，注册使用系统级推送SDK，在没有系统级推送服务的设备上，直接使用第三方推送（一般选择第三方推送，这里选择的那个）文章的解决方案）。这样可以保证有系统级推送服务的设备下达率更高，没有系统级推送服务的设备下达率不会太低。需要注意的是，虽然项目中集成了多个App推送服务，但是根据机型和系统只会注册一个推送服务，即同时只会注册一个推送服务有效。服务端不需要区分机型，可以直接发布推送所有推送服务商的服务。如下图所示：3、请问有缺陷吗？3.1Apk大小根据现有厂商（小米、魅族）+第三方（推推）的组合会比较大，一般至少需要集成3个推送SDK。通常，一个家庭的SDK在400KB左右。当然，如果是正常打包的话，应该会少一些。不过，即使更少，也会增加大约1MB左右。如果Apk本身达到了20~30MB，其实影响不大。但如果App本身只有几MB，增加1MB其实是需要权衡的。我维护过一个总体积不到1MB的App。基本上，任何增加大小的SDK都是被禁止的。3.2仍需注册各项服务。虽然在代码层面，会根据不同的机型注册不同的推送服务。但是那些没有注册的推送SDK还是需要在AndroidManifest.xml中注册组件。以push为例，它需要在AndroidManifest.xml中注册一个push核心Service，标记为android:exported=true，这就是为什么说push服务会互相唤醒。从另一个角度来看，对于第三方推送服务来说，市场占有率决定了投放率。这样我们就可以不使用推送服务了，而是拉活了，在后台运行。例如，在小米设备上，主动注册是使用小米推送，但获取推服务仍然可能被其他集成获取获取的应用程序唤醒，这是我们无法控制的。好在国内一些定制系统和6.0以上的原生系统已经禁止了相互唤醒，应该可以缓解相互唤醒的问题。4、可以做得更好吗？由于有些系统级的推送服务主要依赖对应的系统，比如小米的推送就需要依赖MIUI。这样我们就可以简单的理解为使用小米应用市场的设备都是运行MIUI的。那么我们也可以使用Gradle播放只集成不同市场渠道推送SDK的Apk，只集成小米市场渠道包的小米推送SDK，不集成其他。这样一来，不仅Apk的体积会变小，而且不会出现其他推送服务相互拉扯的情况。当然，对于第三方应用市场的一些渠道包，还是需要集成多个推送SDK的。但是这也会带来一些其他的问题。比如有些热更新算法需要一个benchmarkpackage来计算difference来生成热更新的differencepackage。如果使用Gradle针对不同的推送制作不同渠道的Apk，它们的代码本身是不同的，所以如果需要热更新，就会有多个benchmarkpackage，复杂度会增加，维护成本自然会增加。五、总结以上是我对多推SDK集成的一些思考。其实最简单的方法还是上一篇介绍的方案，直接集成多推SDK，无需分包。最简单的解法也是最稳定的解法，但这并不更影响我们的思考。【本文为专栏作家“张扬”原创稿件，转载请微信公众号联系作者获取授权】点此查看该作者更多好文
