多推送 SDK 的方案中，我們還需要思考什么？
一、前言
前兩天推送了一篇文章，講解的如何集成多 SDK 推送的方式，共享系統推送通道，來提高推送的送達率。但是在實際操作的時候，還是有一些地方需要被注意到，并延伸思考。
本文就對之前的多推送 SDK 的方案，做一個補充，希望讓你跟全面的了解到你在做什么，需要思考什么?
還不了解什么是多推 SDK 送方案的，可以先看看之前的文章：《來自悅跑圈的多推送 SDK 方案 — MixPush》
二、什么是多 SDK 推送方案
首先需要了解到，什么是多 SDK 推送方案。在 Android 的推送服務的市場中，存在多家提供推送解決方案的服務商。例如：極光、個推、小米、魅族、華為 等。
而這眾多的推送方案中，又可以被分為兩類：
1、廠商系統級推送
有自己的硬件設備以及與之匹配的定制系統。對于這類系統級的推送，優勢在于，一般是走的系統推送服務，可以做到送達率更高，更穩定，基本上可以無視你的 App 是否運行。類似于 iOS 下，提供的系統推送服務。但是劣勢也非常的明顯，在非該系統的設備上，送達率并不高。比較有代表的就是：小米(MIUI)、魅族(Flyme)(送達率可以到 90% )。華為據我了解到的情況，本身系統推送服務有問題，所以方案里也不推薦使用。
2、第三方推送
純粹的以第三方服務的形式存在。因為沒有系統推送通道的支持，本身沒有那么多優勢，所以它為了提高送達率，會做更多的努力，在不同的系統上也會做不同的支持和適配，這個是優勢也是劣勢。因為不依賴系統推送服務通道，這樣在不同的系統中，送達率并不會差別太多。比較有代表就是：個推、極光(送到率可以到 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 ，不需要分包。
最簡單的方案也是最穩定的方案，但是這并不影響我們思考的跟多一些。
【本文為51CTO專欄作者“張旸”的原創稿件，轉載請通過微信公眾號聯系作者獲取授權】
