多推送 SDK 的方案中，我們還需要思考什么？
一、前言
前兩天推送了一篇文章，講解的如何集成多 SDK 推送的方式，共享系統(tǒng)推送通道，來(lái)提高推送的送達(dá)率。但是在實(shí)際操作的時(shí)候，還是有一些地方需要被注意到，并延伸思考。
本文就對(duì)之前的多推送 SDK 的方案，做一個(gè)補(bǔ)充，希望讓你跟全面的了解到你在做什么，需要思考什么?
還不了解什么是多推 SDK 送方案的，可以先看看之前的文章：《來(lái)自悅跑圈的多推送 SDK 方案 — MixPush》
二、什么是多 SDK 推送方案
首先需要了解到，什么是多 SDK 推送方案。在 Android 的推送服務(wù)的市場(chǎng)中，存在多家提供推送解決方案的服務(wù)商。例如：極光、個(gè)推、小米、魅族、華為 等。
而這眾多的推送方案中，又可以被分為兩類：
1、廠商系統(tǒng)級(jí)推送
有自己的硬件設(shè)備以及與之匹配的定制系統(tǒng)。對(duì)于這類系統(tǒng)級(jí)的推送，優(yōu)勢(shì)在于，一般是走的系統(tǒng)推送服務(wù)，可以做到送達(dá)率更高，更穩(wěn)定，基本上可以無(wú)視你的 App 是否運(yùn)行。類似于 iOS 下，提供的系統(tǒng)推送服務(wù)。但是劣勢(shì)也非常的明顯，在非該系統(tǒng)的設(shè)備上，送達(dá)率并不高。比較有代表的就是：小米(MIUI)、魅族(Flyme)(送達(dá)率可以到 90% )。華為據(jù)我了解到的情況，本身系統(tǒng)推送服務(wù)有問(wèn)題，所以方案里也不推薦使用。
2、第三方推送
純粹的以第三方服務(wù)的形式存在。因?yàn)闆]有系統(tǒng)推送通道的支持，本身沒有那么多優(yōu)勢(shì)，所以它為了提高送達(dá)率，會(huì)做更多的努力，在不同的系統(tǒng)上也會(huì)做不同的支持和適配，這個(gè)是優(yōu)勢(shì)也是劣勢(shì)。因?yàn)椴灰蕾囅到y(tǒng)推送服務(wù)通道，這樣在不同的系統(tǒng)中，送達(dá)率并不會(huì)差別太多。比較有代表就是：個(gè)推、極光(送到率可以到 25%)。
這樣比較有優(yōu)勢(shì)的多 SDK 推送的方案誕生了，在項(xiàng)目?jī)?nèi)集成多家推送 SDK，在存在系統(tǒng)級(jí)推送服務(wù)的設(shè)備上，注冊(cè)使用系統(tǒng)級(jí)的推送 SDK ，而在不存在系統(tǒng)級(jí)推送服務(wù)的設(shè)備上，直接使用第三方推送(一般選一個(gè)第三方推送即可，本文方案里選的 個(gè)推 )。這樣能保證存在系統(tǒng)級(jí)推送服務(wù)的設(shè)備送達(dá)率較高，而不存在系統(tǒng)級(jí)推送服務(wù)的設(shè)備上，送達(dá)率也不至于太低。
需要注意的是，雖然在項(xiàng)目?jī)?nèi)，集成了多個(gè) App 推送的服務(wù)，但是會(huì)根據(jù)機(jī)型和系統(tǒng)，只對(duì)一個(gè)推送服務(wù)進(jìn)行注冊(cè)，也就是同時(shí)只保持一個(gè)推送服務(wù)的有效注冊(cè)。這服務(wù)端就無(wú)需區(qū)分機(jī)型，直接對(duì)所有推送服務(wù)商的服務(wù)，發(fā)布推送即可。
如下圖：
三、那么有什么缺陷嗎?
3.1 Apk 體積會(huì)大
按現(xiàn)有廠商(小米、魅族)+ 第三方(個(gè)推)的這種組合方案，一般也需要集成 至少 3 家推送 SDK 。正常來(lái)說(shuō)，一家的 SDK 大概在 400KB 左右，當(dāng)然正常打包下來(lái)，應(yīng)該會(huì)更少一些。
不過(guò)哪怕就算是少一些，也會(huì)增加大約 1MB 左右。如果對(duì)于 Apk 本身已經(jīng)達(dá)到二三十 MB 的 App 而言，其實(shí)影響并不大。但是如果本身只有幾 MB 的 App ，增加 1MB 其實(shí)就需要掂量一下了。
本身維護(hù)過(guò)一個(gè)總體積不到 1MB 的 App ，基本上任何增大體積的 SDK ，都是被禁止的。
3.2 依然需要注冊(cè)各種服務(wù)
雖然在代碼層面，會(huì)根據(jù)不同的機(jī)型，注冊(cè)不同的推送服務(wù)。但是哪些不被注冊(cè)的推送 SDK 依然是需要在 AndroidManifest.xml 注冊(cè)組件的。
就以個(gè)推為例，它會(huì)需要在 AndroidManifest.xml 中注冊(cè)一個(gè)推送核心的 Service ，被標(biāo)記為 android:exported=true ，這也是為什么有說(shuō)法，推送服務(wù)會(huì)相互喚醒。也從一個(gè)側(cè)面來(lái)說(shuō)，對(duì)于第三方推送服務(wù)，市場(chǎng)占用率決定了送達(dá)率。
這樣，可能會(huì)導(dǎo)致我們并沒有用到該推送服務(wù)，但是它卻被拉活運(yùn)行在后臺(tái)。例如在小米設(shè)備上，本身主動(dòng)注冊(cè)的是使用小米推送，但是個(gè)推的服務(wù)，依然可能會(huì)被其他集成了個(gè)推的 App 喚醒，這些都是不受我們控制的。
不過(guò)好在現(xiàn)在一些國(guó)產(chǎn)定制系統(tǒng)和原生 6.0 以上的系統(tǒng)中，相互喚醒已經(jīng)被禁止掉了，所以這樣相互喚醒的問(wèn)題，應(yīng)該會(huì)有所緩解。
四、能不能做的更好一點(diǎn)
既然一些系統(tǒng)級(jí)的推送服務(wù)中，主要是依賴對(duì)應(yīng)的系統(tǒng)，例如小米推送就需要依賴 MIUI 。這樣我們就可以簡(jiǎn)單的理解為，使用小米應(yīng)用市場(chǎng)的設(shè)備，都是運(yùn)行的 MIUI 。那么，我們也可以對(duì)不同的市場(chǎng)渠道，利用 Gradle 打出只集成了該推送 SDK 的 Apk ，對(duì)小米市場(chǎng)的渠道包，只集成小米推送SDK ，其他都不集成。這樣不光 Apk 的體積會(huì)有說(shuō)減少，并且也不存在被其他推送服務(wù)相互拉活的情況。
當(dāng)然，對(duì)于一些第三方應(yīng)用市場(chǎng)的渠道包，還是需要集成多個(gè)推送 SDK 的。
但是這樣也會(huì)引發(fā)一些其他的問(wèn)題，例如，一些熱更新的算法需要有基準(zhǔn)包，來(lái)計(jì)算差量生成差量包，用于熱更新，如果使用 Gradle 對(duì)不同的推送打出不同的渠道 Apk ，他們本身的代碼已經(jīng)不一樣了，就會(huì)導(dǎo)致如果需要使用熱更新的話，基準(zhǔn)包就會(huì)有多個(gè)，復(fù)雜度也就提高了，維護(hù)成本自然增大了。
五、小結(jié)
以上就是我對(duì)多推送 SDK 集成的一些思考。實(shí)際上最簡(jiǎn)單的方式，依然是之前文章中，介紹的方案，直接集成多推送 SDK ，不需要分包。
最簡(jiǎn)單的方案也是最穩(wěn)定的方案，但是這并不影響我們思考的跟多一些。
【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)聯(lián)系作者獲取授權(quán)】
