资料库

Android Framework 高频面试题总结.pdf

第1页 / 共58页
第2页 / 共58页
第3页 / 共58页
第4页 / 共58页
第5页 / 共58页
第6页 / 共58页
第7页 / 共58页
第8页 / 共58页
资料共58页,剩余部分请下载后查看
1.AMS 、PMS
1.AMS概述
2.AMS的启动流程
3.AMS与进程启动
4.AMS家族
PMS之前言
1. PMS之SyetemServer处理部分
2. PMS构造方法
2.1 开始阶段
2.2 扫描系统阶段
2.3 扫描Data分区阶段
2.4 扫描结束阶段
2.5 准备阶段
2.Activity 启动流程,App 启动流程
Activity的启动模式
1.什么是Zygote进程
1.1 简单介绍
1.2 各个进程的先后顺序
1.3 进程作用说明
2.Zygote进程的启动流程
2.1 源码位置
2.2 ZygoteInit类的main方法
2.3 registerZygoteSocket(socketName)分析
2.4 preLoad()方法分析
2.5 startSystemServer()启动进程
3.SystemServer进程启动流程
3.1 SystemServer进程简介
3.2 SystemServer的main方法
3.3 查看run方法
3.4 run方法中createSystemContext()解析
3.5 mSystemServiceManager的创建
4.启动服务
4.1 启动哪些服务
4.2 启动服务流程源码分析
4.3 启动部分服务
总结:
3. Binder 机制(IPC、AIDL 的使用)
1、什么是AIDL以及如何使用(★★★★)
2、AIDL的全称是什么?如何工作?能处理哪些类型的数据?(★★★)
3.android的IPC通信方式,线程(进程间)通信机制有哪些
4.为什么使用 Parcelable,好处是什么?
实现机制
5.Android 图像显示相关流程,Vsync 信号等
2019Android Framework 高频面试题总结 1. AMS 、PMS 1.AMS 概述 AMS 是系统的引导服务,应用进程的启动、切换和调度、四大组件的启动和管 理都需要 AMS 的支持。从这里可以看出 AMS 的功能会十分的繁多,当然它并不 是一个类承担这个重责,它有一些关联类,这在文章后面会讲到。AMS 的涉及 的知识点非常多,这篇文章主要会讲解 AMS 的以下几个知识点:    AMS 的启动流程。 AMS 与进程启动。 AMS 家族。 2.AMS 的启动流程 AMS 的启动是在 SyetemServer 进程中启动的,在 Android 系统启动流程(三)解 析 SyetemServer 进程启动过程这篇文章中提及过,这里从 SyetemServer 的 main 方法开始讲起: frameworks/base/services/java/com/android/server/SystemServer.java public static void main(String[] args) { new SystemServer().run(); } main 方法中只调用了 SystemServer 的 run 方法,如下所示。 frameworks/base/services/java/com/android/server/SystemServer.java private void run() { ... ... System.loadLibrary("android_servers");//1 mSystemServiceManager = new SystemServiceManager(mSystemContext);//2 LocalServices.addService(SystemServiceManager.class, mSystemServiceManager); ... try { Trace.traceBegin(Trace.TRACE_TAG_SYSTEM_SERVER, "StartServices");
startBootstrapServices();//3 startCoreServices();//4 startOtherServices();//5 } catch (Throwable ex) { Slog.e("System", "******************************************"); Slog.e("System", "************ Failure starting system services", ex); throw ex; } finally { Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER); } ... } 在注释 1 处加载了动态库 libandroid_servers.so。接下来在注释 2 处创建 SystemServiceManager,它会对系统的服务进行创建、启动和生命周期管理。在 注释 3 中的 startBootstrapServices 方法中用 SystemServiceManager 启动了 ActivityManagerService、PowerManagerService、PackageManagerService 等服务。 在注释 4 处的 startCoreServices 方法中则启动了 BatteryService、UsageStatsService 和 WebViewUpdateService。注释 5 处的 startOtherServices 方法中启动了 CameraService、AlarmManagerService、VrManagerService 等服务。这些服务的父 类均为 SystemService。从注释 3、4、5 的方法可以看出,官方把系统服务分为 了三种类型,分别是引导服务、核心服务和其他服务,其中其他服务是一些非紧 要和一些不需要立即启动的服务。系统服务总共大约有 80 多个,我们主要来查 看引导服务 AMS 是如何启动的,注释 3 处的 startBootstrapServices 方法如下所示。 frameworks/base/services/java/com/android/server/SystemServer.java private void startBootstrapServices() { Installer installer = mSystemServiceManager.startService(Installer.class); // Activity manager runs the show. mActivityManagerService = mSystemServiceManager.startService( ActivityManagerService.Lifecycle.class).getService();//1 mActivityManagerService.setSystemServiceManager(mSystemServiceManager) ; mActivityManagerService.setInstaller(installer); ... } 在注释 1 处调用了 SystemServiceManager 的 startService 方法,方法的参数是 ActivityManagerService.Lifecycle.class:
frameworks/base/services/core/java/com/android/server/SystemServiceManager. java @SuppressWarnings("unchecked") public T startService(Class serviceClass) { try { ... final T service; try { Constructor constructor = serviceClass.getConstructor(Context.class);//1 service = constructor.newInstance(mContext);//2 } catch (InstantiationException ex) { ... } // Register it. mServices.add(service);//3 // Start it. try { service.onStart();//4 } catch (RuntimeException ex) { throw new RuntimeException("Failed to start service " + name + ": onStart threw an exception", ex); } return service; } finally { Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER); } } startService 方法传入的参数是 Lifecycle.class,Lifecycle 继承自 SystemService。首 先,通过反射来创建 Lifecycle 实例,注释 1 处得到传进来的 Lifecycle 的构造器 constructor,在注释 2 处调用 constructor 的 newInstance 方法来创建 Lifecycle 类 型的 service 对象。接着在注释 3 处将刚创建的 service 添加到 ArrayList 类型的 mServices 对象中来完成注册。最后在注释 4 处调用 service 的 onStart 方法来启 动 service,并返回该 service。Lifecycle 是 AMS 的内部类,代码如下所示。 frameworks/base/services/core/java/com/android/server/am/ActivityManagerSe rvice.java public static final class Lifecycle extends SystemService { private final ActivityManagerService mService; public Lifecycle(Context context) { super(context); mService = new ActivityManagerService(context);//1
} @Override public void onStart() { mService.start();//2 } public ActivityManagerService getService() { return mService;//3 } } 上面的代码结合 SystemServiceManager 的 startService 方法来分析,当通过反射 来创建 Lifecycle 实例时,会调用注释 1 处的方法创建 AMS 实例,当调用 Lifecycle 类型的 service 的 onStart 方法时,实际上是调用了注释 2 处 AMS 的 start 方法。 在 SystemServer 的 startBootstrapServices 方法的注释 1 处,调用了如下代码: mActivityManagerService = mSystemServiceManager.startService( ActivityManagerService.Lifecycle.class).getService(); 我们知道 SystemServiceManager 的 startService 方法最终会返回 Lifecycle 类型的 对象,紧接着又调用了 Lifecycle 的 getService 方法,这个方法会返回 AMS 类型的 mService 对象,见注释 3 处,这样 AMS 实例就会被创建并且返回。 3.AMS 与进程启动 在 Android 系统启动流程(二)解析 Zygote 进程启动过程这篇文章中,我提到了 Zygote 的 Java 框架层中,会创建一个 Server 端的 Socket,这个 Socket 用来等待 AMS 来请求 Zygote 来创建新的应用程序进程。要启动一个应用程序,首先要保 证这个应用程序所需要的应用程序进程已经被启动。AMS 在启动应用程序时会 检查这个应用程序需要的应用程序进程是否存在,不存在就会请求 Zygote 进程 将需要的应用程序进程启动。Service 的启动过程中会调用 ActiveServices 的 bringUpServiceLocked 方法,如下所示。 frameworks/base/services/core/java/com/android/server/am/ActiveServices.java private String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg, boolean whileRestarting, boolean permissionsReviewRequired) throws TransactionTooLargeException { ... final String procName = r.processName;//1 ProcessRecord app; if (!isolated) { app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);//2
if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid + " app=" + app); if (app != null && app.thread != null) {//3 try { app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats); realStartServiceLocked(r, app, execInFg);//4 return null; } catch (TransactionTooLargeException e) { ... } } else { app = r.isolatedProc; } if (app == null && !permissionsReviewRequired) {//5 if ((app=mAm.startProcessLocked(procName, r.appInfo, true, "service", r.name, false, isolated, false)) == null) intentFlags, {//6 ... } if (isolated) { r.isolatedProc = app; } } } ... 在注释 1 处得到 ServiceRecord 的 processName 的值赋值给 procName ,其中 ServiceRecord 用来描述 Service 的 android:process 属性。注释 2 处将 procName 和 Service 的 uid 传入到 AMS 的 getProcessRecordLocked 方法中,来查询是否存 在一个与 Service 对应的 ProcessRecord 类型的对象 app,ProcessRecord 主要用来 记录运行的应用程序进程的信息。注释 5 处判断 Service 对应的 app 为 null 则说 明用来运行 Service 的应用程序进程不存在,则调用注释 6 处的 AMS 的 startProcessLocked 方法来创建对应的应用程序进程, 具体的过程请查看 Android 应用程序进程启动过程(前篇)。 4.AMS 家族 ActivityManager 是一个和 AMS 相关联的类,它主要对运行中的 Activity 进行管理, 这些管理工作并不是由 ActivityManager 来处理的,而是交由 AMS 来处理, ActivityManager 中的方法会通过 ActivityManagerNative(以后简称 AMN)的 getDefault 方法来得到 ActivityManagerProxy(以后简称 AMP),通过 AMP 就可以和
AMN 进行通信,而 AMN 是一个抽象类,它会将功能交由它的子类 AMS 来处理, 因此,AMP 就是 AMS 的代理类。AMS 作为系统核心服务,很多 API 是不会暴露 给 ActivityManager 的,因此 ActivityManager 并不算是 AMS 家族一份子。 为了讲解 AMS 家族,这里拿 Activity 的启动过程举例,Activity 的启动过程中会 调用 Instrumentation 的 execStartActivity 方法,如下所示。 frameworks/base/core/java/android/app/Instrumentation.java public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity Intent intent, int requestCode, Bundle options) { target, ... try { intent.migrateExtraStreamToClipData(); intent.prepareToLeaveProcess(who); int result = ActivityManagerNative.getDefault() .startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null ? target.mEmbeddedID : null, requestCode, 0, null, options); checkStartActivityResult(result, intent); } catch (RemoteException e) { throw new RuntimeException("Failure from system", e); } return null; } execStartActivity 方法中会调用 AMN 的 getDefault 来获取 AMS 的代理类 AMP。接 着调用了 AMP 的 startActivity 方法,先来查看 AMN 的 getDefault 方法做了什么, 如下所示。 frameworks/base/core/java/android/app/ActivityManagerNative.java static public IActivityManager getDefault() { return gDefault.get(); } private static final Singleton gDefault = new Singleton() { protected IActivityManager create() { IBinder b = ServiceManager.getService("activity");//1 if (false) { Log.v("ActivityManager", "default service binder = " + b); } IActivityManager am = asInterface(b);//2
if (false) { Log.v("ActivityManager", "default service = " + am); } return am; }+ };} getDefault 方法调用了 gDefault 的 get 方法,我们接着往下看,gDefault 是一个 Singleton 类。注释 1 处得到名为”activity”的 Service 引用,也就是 IBinder 类型的 AMS 的引用。接着在注释 2 处将它封装成 AMP 类型对象,并将它保存到 gDefault 中,此后调用 AMN 的 getDefault 方法就会直接获得 AMS 的代理对象 AMP。注释 2 处的 asInterface 方法如下所示。 frameworks/base/core/java/android/app/ActivityManagerNative.java static public IActivityManager asInterface(IBinder obj) { if (obj == null) { return null; } IActivityManager in = (IActivityManager)obj.queryLocalInterface(descriptor); if (in != null) { return in; } return new ActivityManagerProxy(obj);} asInterface 方法的主要作用就是将 IBinder 类型的 AMS 引用封装成 AMP,AMP 的构造方法如下所示。 frameworks/base/core/java/android/app/ActivityManagerNative.java class ActivityManagerProxy implements IActivityManager{ public ActivityManagerProxy(IBinder remote) { mRemote = remote; }... } AMP 的构造方法中将 AMS 的引用赋值给变量 mRemote ,这样在 AMP 中就可以 使用 AMS 了。 其中 IActivityManager 是一个接口,AMN 和 AMP 都实现了这个接口,用于实现 代理模式和 Binder 通信。 再回到 Instrumentation 的 execStartActivity 方法,来查看 AMP 的 startActivity 方 法,AMP 是 AMN 的内部类,代码如下所示。 frameworks/base/core/java/android/app/ActivityManagerNative.java
public int startActivity(IApplicationThread caller, String callingPackage, Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode, throws RemoteException { int startFlags, ProfilerInfo profilerInfo, Bundle options) ... data.writeInt(requestCode); data.writeInt(startFlags); ... mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);//1 reply.readException();+ int result = reply.readInt(); reply.recycle(); data.recycle(); return result; } 首先会将传入的参数写入到 Parcel 类型的 data 中。在注释 1 处,通过 IBinder 类 型对象 mRemote(AMS 的引用)向服务端的 AMS 发送一个 START_ACTIVITY_TRANSACTION 类型的进程间通信请求。那么服务端 AMS 就会从 Binder 线程池中读取我们客户端发来的数据,最终会调用 AMN 的 onTransact 方 法,如下所示。 frameworks/base/core/java/android/app/ActivityManagerNative.java @Override public boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException { switch (code) { case START_ACTIVITY_TRANSACTION: { ... int result = startActivity(app, callingPackage, intent, resultTo, resultWho, requestCode, startFlags, resolvedType, profilerInfo, options); reply.writeNoException(); reply.writeInt(result); return true; } }
分享到:
收藏