Android Service完整实现流程分析

目录
  • 前言
  • 一.APP侧启动Service
    • 1.1 前台和后台启动
    • 1.2startServiceCommon
  • 二.系统侧分发处理Service的启动逻辑
    • 2.1 AMS接受启动service的通知
    • 2.2realStartServiceLocked流程
  • 三.系统侧通知APP启动Service
  • 四.总结

前言

一开始的目标是解决各种各样的ANR问题的,我们知道,ANR总体上分有四种类型,这四种类型有三种是和四大组件相对应的,所以,如果想了解ANR发生的根因,对安卓四大组件的实现流程是必须要了解的,都不明白ANR如何触发的,怎么能完美的解决ANR的问题呢?

所以会写一系列的文章,来分析四大组建的实现原理,同时也顺带讲解四种类型的ANR是如何发生的。

本篇主要介绍service的完整实现流程,下一篇文章介绍Service中的ANR是如何产生的。

一.APP侧启动Service

其实启动service和启动Activity是很相似的,都是APP通知系统侧,由系统侧完成的整个流程。

1.1 前台和后台启动

无论是Activity,还是service,还是Application,都继承自Context的抽象类,所以可以使用Context的各种功能,就比如这了要介绍的启动前台/后台service。

Context在安卓中,使用了一种典型的代理模式,我们调用的startService或者startForegroundService方法,最终都会委托给ContextImpl中的startService和startForegroundService来处理的。我们就来看下ContextImpl中的这两个方法:

@Override
    public ComponentName startService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, false, mUser);
    }
    @Override
    public ComponentName startForegroundService(Intent service) {
        warnIfCallingFromSystemProcess();
        return startServiceCommon(service, true, mUser);
    }

果然和我猜测的差不多,无论前台还是后台启动,其实最终都会走到一个方法中,只是配置参数的区别而已。最终都会走执行startServiceCommon方法。

1.2startServiceCommon

该方法中,通过binder通知系统的AMS完成对应的service的启动操作:

 ComponentName cn = ActivityManager.getService().startService(
                    mMainThread.getApplicationThread(), service,
                    service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
                    getOpPackageName(), getAttributionTag(), user.getIdentifier());

接下来,我们就看下系统侧是如何处理Service启动流程的。

二.系统侧分发处理Service的启动逻辑

系统侧的处理我主要分为3块来讲:

1.系统接受APP侧的通知并转发

2.系统侧委托ActiveServices负责完成的处理流程

3.收到APP侧执行完成的回调,进行收尾操作

2.1 AMS接受启动service的通知

APP侧持有system_server进程的binder,上面讲到,它会通过binder方法startService完成对系统侧的通知。所以AMS的startService会收到这个通知。

我们看下代码,发现AMS会把整个service的逻辑全部交由ActiveServices来处理,代码如下:

 try {
                res = mServices.startServiceLocked(caller, service,
                        resolvedType, callingPid, callingUid,
                        requireForeground, callingPackage, callingFeatureId, userId);
            } finally {
                Binder.restoreCallingIdentity(origId);
            }

系统代码startServiceLocked方法中,代码虽然很长,但是却遵循着一个不变的宗旨:位语句,即前面处理各种异常的分支逻辑,把核心流程留到方法的最终来处理。

所以我们直接看startServiceLocked方法的最后一部分即可:

final ComponentName realResult =
                startServiceInnerLocked(r, service, callingUid, callingPid, fgRequired, callerFg,
                allowBackgroundActivityStarts, backgroundActivityStartsToken);

startServiceInnerLocked方法中,处理逻辑也是比较简单的,最终会交给bringUpServiceLocked方法来进行处理。而bringUpServiceLocked方法中则最终会交给realStartServiceLocked完成整个流程。好像系统代码都喜喜欢用realStart,Activity启动的流程中也有一个方法叫realStartActivity。

2.2realStartServiceLocked流程

realStartServiceLocked方法中,我们总结为三个流程:

1.bumpServiceExecutingLocked,启动超时检查。

2.thread.scheduleCreateService通知APP一侧去创建Service。

3.sendServiceArgsLocked通知APP执行Service的生命流程。

private void realStartServiceLocked(ServiceRecord r, ProcessRecord app,
            IApplicationThread thread, int pid, UidRecord uidRecord, boolean execInFg,
            boolean enqueueOomAdj) throws RemoteException {
        //1.启动超时检查
        bumpServiceExecutingLocked(r, execInFg, "create", null /* oomAdjReason */);
        ...
        //2.通知APP创建service
            thread.scheduleCreateService(r, r.serviceInfo,
                    mAm.compatibilityInfoForPackage(r.serviceInfo.applicationInfo),
                    app.mState.getReportedProcState());
            r.postNotification();
            created = true;
        ...
        //3.通知执行service生命流程
        sendServiceArgsLocked(r, execInFg, true);
       ...
    }

三.系统侧通知APP启动Service

一般情况下,APP侧会收到系统侧发过来两种类型的通知,

第一种:创建Service的任务通知

第二种:执行Service生命流程的通知,通知Service执行onStartCommand方法。

ApplicationThread接受通知并创建Service

系统侧持有APP侧的binder,会通过scheduleCreateService这个binder方法通知APP一侧进行相应的操作。而APP侧,完成这个工作接收的就是ApplicationThread中的scheduleCreateService方法。该方法收到通知后,通过handler切换到主线程处理:

 public final void scheduleCreateService(IBinder token,
                ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
            updateProcessState(processState, false);
            CreateServiceData s = new CreateServiceData();
            s.token = token;
            s.info = info;
            s.compatInfo = compatInfo;
            sendMessage(H.CREATE_SERVICE, s);
        }

handle中,会切换到主线程执行ActivityThread的handleCreateService方法。

主要执行了如下的几段逻辑:

1.如果是首次创建App进程的话,则需要重新创建Application;

2.创建Service对象;

3.调用service的attach方法进行关联;

4.调用service的onCreate生命周期方法;

5.创建完成后,通过serviceDoneExecuting通知系统侧创建完成。

try {
            if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
            Application app = packageInfo.makeApplication(false, mInstrumentation);
            final java.lang.ClassLoader cl;
            if (data.info.splitName != null) {
                cl = packageInfo.getSplitClassLoader(data.info.splitName);
            } else {
                cl = packageInfo.getClassLoader();
            }
            service = packageInfo.getAppFactory()
                    .instantiateService(cl, data.info.name, data.intent);
            ContextImpl context = ContextImpl.getImpl(service
                    .createServiceBaseContext(this, packageInfo));
            if (data.info.splitName != null) {
                context = (ContextImpl) context.createContextForSplit(data.info.splitName);
            }
            if (data.info.attributionTags != null && data.info.attributionTags.length > 0) {
                final String attributionTag = data.info.attributionTags[0];
                context = (ContextImpl) context.createAttributionContext(attributionTag);
            }
            // Service resources must be initialized with the same loaders as the application
            // context.
            context.getResources().addLoaders(
                    app.getResources().getLoaders().toArray(new ResourcesLoader[0]));
            context.setOuterContext(service);
            service.attach(context, this, data.info.name, data.token, app,
                    ActivityManager.getService());
            service.onCreate();
            mServicesData.put(data.token, data);
            mServices.put(data.token, service);
            try {
                ActivityManager.getService().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
            } catch (RemoteException e) {
                throw e.rethrowFromSystemServer();
            }
        }

ApplicationThread接受通知并执行Service的生命流程

同样的,这里完成接受的是,仍然是ApplicationThread中的方法。这个流程中的接受方法是scheduleServiceArgs方法。

ApplicationThread中,收到通知后,通过handler把任务转交到主线程。

 public final void scheduleServiceArgs(IBinder token, ParceledListSlice args) {
            List<ServiceStartArgs> list = args.getList();
            for (int i = 0; i < list.size(); i++) {
                ServiceStartArgs ssa = list.get(i);
                ServiceArgsData s = new ServiceArgsData();
                s.token = token;
                s.taskRemoved = ssa.taskRemoved;
                s.startId = ssa.startId;
                s.flags = ssa.flags;
                s.args = ssa.args;
                sendMessage(H.SERVICE_ARGS, s);
            }
        }

接下来handler中切换到主线程会执行ActivityThread的handleServiceArgs方法。

handleServiceArgs方法主要会完成以下几件事:

1.找到对应的service,调用起onStartCommand方法;

2.通知系统侧回调完成。

private void handleServiceArgs(ServiceArgsData data) {
        CreateServiceData createData = mServicesData.get(data.token);
        Service s = mServices.get(data.token);
        if (s != null) {
            try {
                if (data.args != null) {
                    data.args.setExtrasClassLoader(s.getClassLoader());
                    data.args.prepareToEnterProcess(isProtectedComponent(createData.info),
                            s.getAttributionSource());
                }
                int res;
                if (!data.taskRemoved) {
                    res = s.onStartCommand(data.args, data.flags, data.startId);
                } else {
                    s.onTaskRemoved(data.args);
                    res = Service.START_TASK_REMOVED_COMPLETE;
                }
                QueuedWork.waitToFinish();
                try {
                    ActivityManager.getService().serviceDoneExecuting(
                            data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
                } catch (RemoteException e) {
                    throw e.rethrowFromSystemServer();
                }
            } catch (Exception e) {
                if (!mInstrumentation.onException(s, e)) {
                    throw new RuntimeException(
                            "Unable to start service " + s
                            + " with " + data.args + ": " + e.toString(), e);
                }
            }
        }
    }

发我们发现,不论是创建service,还是通知执行service的生命流程,最终都执行了一个完成的通知,这有何意图呢?是的,这个意图就是和ANR相关的,我们下一章来讲了。

四.总结

前面一一讲了实现的原理,我们最后再来做一个总结,尽量用一张图+几句话的方式来概括。

1.无论前台启动还是后台启动,最终都会走到ContextImpl这个最终实现类中的方法,完成和AMS的交互。

2.AMS中主要是ActiveServices完成的整个流程。其核心方法是realStartServiceLocked。

他首先启动一个延时消息,通过延时消息进行超时的监测。

然后通知APP去生成Service。

通知APP侧去完成Service的生命周期流程onStartCommand。

3.收到APP侧执行完成的通知后,则取消注册延时消息。

到此这篇关于Android Service完整实现流程分析的文章就介绍到这了,更多相关Android Service内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Android Service自启动注意事项分析

    本文实例分析了Android Service自启动注意事项.分享给大家供大家参考,具体如下: @Override public void onStart(Intent intent, int startId) { super.onStart(intent, startId); if(intent == null) return; } @Override public void onDestroy() { super.onDestroy(); Intent intent = new Intent(

  • Android Service启动流程刨析

    强调一下阅读系统源码,起码要对进程间通信要了解,对binder机制非常非常清楚,binder就是指南针,要不然你会晕头转向:强行阅读,就容易睡着. Service启动先来一张图感受一下 这张图能够说明一个大致的流程,但是服务的启动肯定不是这么简单,但是我们先简单的总结一下,逐渐深入.服务的启动形式有两种,startService()和 binderService(),我们看startService()这一种.startService是ContextWrapper里面的方法. ContextWra

  • Android自定义短信倒计时view流程分析

    倒计时实现有三种方式 而这个自定义view是通过handler实现的.为了保证activity销毁的同时倒计时线程依然进行同时重新创建销毁又不会导致内存泄漏,我使用了handler的弱引用将handler和runnable设置成静态,同时通过一系列变量来销毁关闭线程保存状态,话不多说先看效果图: 下面看源码: import android.content.Context; import android.os.Handler; import android.os.Message; import a

  • Android类加载流程分析

    背景 由于前前前阵子写了个壳,得去了解类的加载流程,当时记了一些潦草的笔记.这几天把这些东西简单梳理了一下,本文分析的代码基于Android8.1.0源码. 流程分析 从loadClass开始,我们来看下Android中类加载的流程 /libcore/ojluni/src/main/java/java/lang/ClassLoader.java::loadClass loadClass流程如下: protected Class<?> loadClass(String name, boolean

  • Android Service控件用法实例分析

    本文实例讲述了Android Service控件用法.分享给大家供大家参考,具体如下: 1.Service是一个应用程序的组件 2.Service没有图形化界面 3.用来处理耗时比较长的功能(下载.播放MP3) 4.更新ContentProvider.Intent以及系统的启动 Servcie不是一个单独的进程,不是一个线程 定义一个Service比较简单,只要继承Service类,实现其生命周期的方法即可.一个定义好的Service必须在AndroidManifest.xml文件中通过<ser

  • Android教程之开机流程全面解析

    本文详细讲述了Android的开机流程.分享给大家供大家参考,具体如下: 开机过程中无线模块的初始化过程;如果sim卡锁开启,或者pin被锁住的时候,会要求输入pin或者puk,但是这个解锁动作必须在系统初始化完成以后才能进行.(图形系统都还没有初始化怎么输入密码阿?)当系统初始化完成以后会调用 wm.systemReady()来通知大家.这时候该做什么就做什么. 开机过程中无线模块的初始化过程: rild 调用参考实现 Reference-ril.c (hardware\ril\referen

  • docker-compose镜像发布springboot项目的流程分析

    简介 Docker-Compose项目是Docker官方的开源项目,负责实现对Docker容器集群的快速编排.Compose允许用户通过一个单独的docker-compose.yml模板文件(YAML 格式)来定义一组相关联的应用容器为一个项目(project).Docker-Compose项目由Python编写,调用Docker服务提供的API来对容器进行管理.因此,只要所操作的平台支持Docker API,就可以在其上利用Compose来进行编排管理. Docker-Compose将所管理的

  • 全面解析Android系统指纹启动流程

    本章主要整理Android 指纹启动流程,侧重于hal和framework部分. 一.从Android系统启动流程看指纹启动流程 下图图片出处  → 第一阶段 Boot ROM,Android设备上电后,首先会从处理器片上ROM的启动引导代码开始执行,片上ROM会寻找Bootloader代码,并加载到内存.主要就是上电让系统启动. 第二阶段 Bootloader开始执行,首先负责完成硬件的初始化,然后找到Linux内核代码,并加载到内存. 启动过程中,bootloader(默认是bootable

  • .NetCore使用Swagger+API多版本控制的流程分析

    目录 一.Swagger基本使用 二.Swagger结合版本控制 本文实例环境及版本.NetCore3.1.Swagger6.1 现在的开发大部分都是前后端分离的模式了,后端提供接口,前端调用接口.后端提供了接口,需要对接口进行测试,之前都是使用浏览器开发者工具,或者写单元测试,再或者直接使用Postman,但是现在这些都已经out了.后端提供了接口,如何跟前端配合说明接口的性质,参数等这也是一个问题.有没有一种工具可以根据后端的接口自动生成接口文档,说明接口的性质,参数等信息,又能提供接口调用

  • Android开发Retrofit源码分析

    目录 项目结构 retrofit 使用 Retrofit #create ServiceMethod #parseAnnotations HttpServiceMethod#parseAnnotations 第二种 非Kotlin协程情况 DefaultCallAdapterFactory#get 第一种 Kotlin协程情况 总结 项目结构 把源码 clone 下来 , 可以看到 retrofit 整体结构如下 图 http包目录下就是一些http协议常用接口 , 比如 请求方法 url ,

随机推荐

其他