第1个回答 2017-09-09
1、首先要保证你的程序一直在于后台运行,也就是所谓和守护程序一样,而且在任何认为kill和系统内存回收kill后,保证重启。
2、获取系统内部资源。
3、上报策略,间隔时间上报还是按月按天上报。
4、监测网络,当网络开启的时候第一时间上报数据。
5、服务器连接。
对于以上问题的解决:
1、利用广播BroadcastReceiver监听,当系统启动时启动服务service,监听的action是
android.intent.action.BOOT_COMPLETED,当服务被kill时在onDestroy()再次启动服务,在
onStartCommand()中 设置 flags = START_STICKY;return
super.onStartCommand(intent, flags, startId),保证服务重启。
2、利用getPackageManager(),getInstalledPackages(),getApplicationInfo()来获取系统安装数据。
3、上报策略可以每天(时间间隔24小时),但是不是很准确,一般按日上报不做时间间隔这样个人认为比较准确。
4、检测开启网络上报数据,还是利用广播BroadcastReceiver监听,监听action为android.net.conn.CONNECTIVITY_CHANGE,当发现网络开启时就触发数据上报。
5、服务器连接,如果你了解java熟悉java企业级开发,那么你对httpclient并不陌生,很幸运的是android sdk已经集成了httpclient,那我们服务器连接首选它了。
以上是我做的解决方案,你是否有更好的替代品,希望我只是抛了块砖头,后面你继续。。。。
service被系统异常kill掉后回重启。有以下值:
onStartCommand有三种返回值:
START_STICKY:sticky的意思是“粘性的”。使用这个返回值时,我们启动的服务跟应用程序”粘”在一起,如果在执行完onStartCommand后,服务被异常kill掉,系统会自动重启该服务。当再次启动服务时,传入的第一个参数将为null;
START_NOT_STICKY:“非粘性的”。使用这个返回值时,如果在执行完onStartCommand后,服务被异常kill掉,系统不会自动重启该服务。
START_REDELIVER_INTENT:重传Intent。使用这个返回值时,如果在执行完onStartCommand后,服务被异常kill掉,系统会自动重启该服务,并将Intent的值传入。