Android O适配

来源:互联网 发布:数据库中的存储过程 编辑:程序博客网 时间:2024/05/22 13:58

官方文档:https://developer.android.com/preview/features/background.html#migration

一、从Android O针对服务以及广播这两个组件做了如下的限制

1、前台服务不受影响,但后台服务会被限制。首先需要确定应用是前台应用还是后台应用,只要满足以下任意一个都认为是前台App:
(1)App有一个可见的Activiy
(2)App有一个前台是service
(3)App与其他前台App有交互,比如远程服务绑定、数据库监听等
          总之,前台App的service使用可以随心所欲,但是当应用退入后台进入idle状态时,系统会停止这个应用的service,停止方式与Service.stopSelf()方法等效。可惜还没固件,不然可以验证这个特性。App从前台刚转变成后台状态时,在有限的数分钟内还是可以启动后台服务的,这么做的原因主要是为了给App一个机会去处理任务。对于后台服务的受限,Android推荐使用JobScheduler jobs来替代曾经的后台服务。另外,提供了新的Context.startForegroundService()的方法来启动服务。

2、广播接收组件的限制

    其实从Android7.0已经对广播的做了限制,详情请看点击打开链接。主要是对CONNECTIVITY_ACTION等三个广播做了限制。AndroidO则做了加强,有如下的几点:

(1)静态注册的receiver将不能接收implicit广播。Android提供的替代方案是使用registerReceiver方法来动态注册。这个相当于对通过监听系统各种广播事件达到拉起应用来干坏事的方式进行了封杀。当然还提供另外的JobScheduler job方案来解决这个问题。
(2)静态注册的receiver依然能接收explicit广播。
(3)系统应用不受这个限制。这个就有点坑爹啊。

3、如何确定implicit广播?

按照google的说法是绝大部分可以静态注册的广播都是implicit的,简单理解就是为系统服务的广播,不面向于App。google考虑到如此削弱广播的力量带来的改动太多,为此对一些广播加入了白名单,处于白名单中的广播的不受限制,对于其他广播都需要寻求替代方案。

二、JobScheduler

1、从Api21引入JobScheduler之后google就一直强推,不难想象JobScheduler将从AndroidO逐渐开始大展身手。JobScheduler简单的理解就是一个作业调度框架,应用每提交一个作业就会进入一个作业队列,调度框架不断的从队列中取出作业进行调度。

2、JobScheduler主要分为两种

(1)一次性job调度,示例代码如下:

public void scheduleJob() {        JobInfo.Builder builder = new JobInfo.Builder(mJobId++, mServiceComponent);        builder.setMinimumLatency(10 * 1000);        builder.setOverrideDeadline(20 * 1000);        builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY);        JobScheduler tm = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);        tm.schedule(builder.build());}
(2)重复性job调度,示例代码如下:

public void scheduleJob() {        JobInfo.Builder builder = new JobInfo.Builder(mJobId++, mServiceComponent);        builder.setPeriodic(3000);        builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY);        JobScheduler tm = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);        tm.schedule(builder.build());}

(3)JobService,示例代码如下:

public class MyJobService extends JobService {    private static final String TAG = MyJobService.class.getSimpleName();    @Override    public void onCreate() {        super.onCreate();        Log.i(TAG, "Service created");    }    @Override    public void onDestroy() {        super.onDestroy();        Log.i(TAG, "Service destroyed");    }    @Override    public int onStartCommand(Intent intent, int flags, int startId) {        return START_NOT_STICKY;    }    @Override    public boolean onStartJob(final JobParameters params) {        Log.i(TAG,"JobId=" + params.getJobId());        long duration = params.getExtras().getLong(WORK_DURATION_KEY);        // Uses a handler to delay the execution of jobFinished().        Handler handler = new Handler();        handler.postDelayed(new Runnable() {            @Override            public void run() {                jobFinished(params, false);            }        }, duration);        Log.i(TAG, "on start job: " + params.getJobId());        // Return true as there's more work to be done with this job.        return true;    }    @Override    public boolean onStopJob(JobParameters params) {        // Stop tracking these job parameters, as we've 'finished' executing.        Log.i(TAG, "on stop job: " + params.getJobId());        // Return false to drop the job.        return false;    }}
3、使用限制:

(1)JobScheduler是api21引入,不过还好有FirebaseJobDispatcher这个兼容方案

(2)应用进程被kill掉,job也会被取消掉