|
|
|
|
移动端
创建专栏

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

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

作者:佚名|2017-08-21 08:00

有奖调研 | 1TB硬盘等你拿 AI+区块链的发展趋势及应用调研


 

一、前言

前两天推送了一篇文章,讲解的如何集成多 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专栏作者“张旸”的原创稿件,转载请通过微信公众号联系作者获取授权】

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

【编辑推荐】

  1. 【访谈】某知名旅游企业CIO:旅游业复杂业态下的IT构建之思考
  2. 外媒速递:关于云数据仓库的几项关键思考
  3. 使用Docker网络解决方案weave遇到的那些坑
  4. AWS IOT解决方案分析
  5. Azure IoT解决方案
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多