[讨论]Android端消息推送服务是否需要多开进程

当前保活(包括腾讯)在MIUI上基本都是失效的，且绿色守护、黑域等越来越普及，工信部也在推行统一推送标准，保活这一流氓手段最后都会得到根治。
而在实际开发中，我给推送服务单独放在一个进程运行，并没发现有多大优势，反而在进程通信上有极大的不便。从而给开发带来了很大的麻烦，想请问下各位是怎么处理这个问题的呢？

我个人认为，在像小米、华为这些需要用户强制使用它的统一推送通道的ROOM，除非你是微信这样可以进入白名单，否则最好的方式就是接入它们的推送SDK（就像ios里用苹果官方的APNS推送服务一样），其它手机目前还是可以考虑继续使用保活黑科技。

不过，后台保活应该会是越来越难，android官方已经注意到各种黑科技保活带来的害处，所以非主流的招只会越用越难，所以建议如果要偷懒的话，可以使用腾讯的信鸽这样的推送服务（当然我不是做广告，没收好处费），毕竟信鸽号称可以借助手机qq的互拉（这招无人能敌，必竟qq是不可能被各厂商封杀的）。要怎么用，需要自已去权衡了，推送就是推送，别把它看的太复杂，自已做不好的话那就用别的人，一家不好就就换一家呗。

引用：JackJiang 发表于 2017-07-28 09:53
我个人认为，在像小米、华为这些需要用户强制使用它的统一推送通道的ROOM，除非你是微信这样可以进入白名单 ...

额Orz
我这里重点想了解下各位对多开进程实现消息推送这个方式的观点
都说在新进程里运行推送服务稳定(理论上也确实这样)，但实际上没感觉到比单进程稳定在哪

引用：pye52 发表于 2017-07-28 14:43
额Orz
我这里重点想了解下各位对多开进程实现消息推送这个方式的观点
都说在新进程里运行推送服务稳定( ...

这种东西没有标准的实现，适合自已的就是最好的，不用跟风

感谢JackJiang的意见，终于不再纠结于是否需要多开进程了。
项目从sqlite换成了realm，又改为greendao(sqlite)。这里说一下踩过的坑。原本将推送服务放到新的进程运行，是为了稳定性与保活，但实现之后发现在不少国产Rom上，这个保活并不靠谱，子进程会和主进程一起被干掉，大部分主流手段也无法自启。
由于设计上的一些问题(想请教各位是否有更好的实现方式)，推送进程跟主进程都需要对数据库进行读写操作，一直未能找到一个很好的方案，下面说一下我所踩过的坑。

realm：
优点：
1、读写速度极快，可以直接在ui线程操作，没遇到过卡顿2、数据实时更新
3、官方提供了封装好的recyclerview adapter，使用方便
缺点：
1、不支持多进程(3.5.0已支持)
2、线程间操作非常麻烦，配合rxjava需要多写很多无谓的代码


greendao：
优点：
1、使用简单，自带缓存，读写性能也较好
缺点：
1、多进程的话缓存就是个拖油瓶，每次query都得先清缓存，否则数据可能不同步2、greendao的relations比较坑，contentprovider中query方法返回的是cursor，导致获取的对象是没有daosession的

总的来说上面提到的2种orm在多进程读都不是问题，写是比较大的问题，但理论上多进程操作sqlite会存在问题，因此最后还是采取了contentprovider的方式实现，并通过取巧的方式来弥补了relations的问题。
若是用户量不大，数据量不大的话，用realm + 单进程的模式就足够了，而且这样的组合开发效率也会大幅度提高。