关于Context.startForegroundService() did not then call Service.startForeground()的解决办法

废话不多说，关于前台服务方面的知识请自行百度，我要说的是在启动service调用了startFroregroundService，并且在service里的onCreate和onStartCommand里也调用了startFraground的情况下，在崩溃统计里依然出现了Context.startForegroundService() did not then call Service.startForeground()这个异常。

首先要了解这个异常出现的原因，startFroregroundService调用了之后会启动一个计时器，如果5s内没有在对应的service里调用startForeground的话，就会抛出这个异常。但是我明明在service里调用了，这是怎么回事呢？答案是调用了startFroregroundService之后，5秒内service都没有启动起来 ，所以就没有onCrate，自然也没法调用startForeground。

为什么会出现这个情况？而且测试测不出来，我看了一下代码，我们的service是在Application 的onCreate里创建的，同时这个onCreate里还有一堆别的初始化代码。根据我的猜测，测试的情况就相当于用户直接点击图标启动应用，这个情况下cpu肯定优先处理本app的任务，所以创建一个服务不会耗费多少时间，也不会出现异常。但是在用户手机里的时候，会有后台拉活的情况，即被别的推送拉活，或者被alarmmanager唤醒等等各种拉活手段，这个时候应用其实是处于后台的，cpu优先级也比较低，所以面对application里一堆的初始化任务可能会执行很长时间，包括创建service也会超过5s,这样就会导致异常。

大体上分析了原因，解决起来就不会毫无方向。首先缩减onCrate里的各种初始化代码是不太现实了，毕竟牵扯太大，我的做法是延迟启动Service

  ICMTimer timer = CMLibFactory.getInstance().createInstance(ICMTimer.class);
            timer.start(5000,0,lRepeatTime -> {
                DaemonEnv.startServiceSafely(context, AbsWorkService.class);
                RemoteWork.start(context);
            });

timer是我们项目框架里的一个延迟器，这里可以直接用new Handler(Looper.getMainLooper()).postDelay()这个方法去做。5秒的时间可以根据自己的情况去设置，这样就避开了application刚创建的时候任务最多的时间，理论上来说这个时间越大，那么发生异常的可能性越低。经过修改，我们项目的这个崩溃率从百分之2-3,降低到了百分之0.2左右，减少了十倍，由此可证明我的猜测应该是没错的。

这样崩溃率减少到了可以接受的范围内，后续的优化可以从缩减application繁重的初始化入手，这样也可以减少启动时间。