Framework 源码解析知识梳理(5) startService 源码分析
1、前言
最近在看关于插件化的知识，遇到了如何实现Service插件化的问题，所以，先学习一下Service内部的实现原理，这里面会涉及到应用进程和ActivityManagerService的通讯，建议你们先阅读一下以前的这篇文章 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通讯实现，整个Service的启动过程离不开和AMS的通讯，从整个宏观上来看，它的模型以下，是否是和咱们以前分析的通讯过程如出一辙： java
2、源码分析
当咱们在Activity/Service/Application中，经过下面这个方法启动Service时：缓存
public ComponentName startService(Intent service)
复制代码
与以前分析过的不少源码相似，最终会调用到ContextImpl的同名方法当中，而该方法又会调用内部的startServiceCommon(Intent, UserHandle)： bash
- 校验
Intent的合法性，对于Android 5.0之后，咱们要求Intent中须要制定Package和Component中至少一个，不然会抛出异常。 - 经过
Binder通讯调用到ActivityManagerService的对应方法，关于调用的详细过程能够参考 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通讯实现 中对于应用进程到ActivityManagerService的通讯部分分析。
ActivityManagerService中的实现为： 数据结构
mServices变量来去实现
Service的启动，而
mServices的类型为
ActiveServices，它是
ActivityManagerService中负责处理
Service相关业务的类，不管咱们是经过
start仍是
bind方式启动的
Service，都是经过它来实现的，它也被称为“应用服务”的管理类。
从经过ActiveServices调用startServiceLocked，到Service真正被启动的过程以下图所示，下面，咱们就来一一分析每个阶段究竟作了什么： app
咱们首先来看入口函数startServiceLocked的内部实现：ide
ComponentName startServiceLocked(IApplicationThread caller, Intent service, String resolvedType,
int callingPid, int callingUid, String callingPackage, final int userId)
throws TransactionTooLargeException {
final boolean callerFg;
//caller是调用者进程在AMS的远程代理对象，类型为ApplicationThreadProxy。
if (caller != null) {
//得到调用者的进程信息。
final ProcessRecord callerApp = mAm.getRecordForAppLocked(caller);
if (callerApp == null) {
throw new SecurityException(
"Unable to find app for caller " + caller
+ " (pid=" + Binder.getCallingPid()
+ ") when starting service " + service);
}
callerFg = callerApp.setSchedGroup != ProcessList.SCHED_GROUP_BACKGROUND;
} else {
callerFg = true;
}
//经过传递的信息，解析出要启动的Service，封装在ServiceLookupResult中。
ServiceLookupResult res =
retrieveServiceLocked(service, resolvedType, callingPackage,
callingPid, callingUid, userId, true, callerFg, false);
if (res == null) {
return null;
}
if (res.record == null) {
return new ComponentName("!", res.permission != null
? res.permission : "private to package");
}
//对于每一个被启动的Service，它们在AMS端的数据结构为ServiceRecord。
ServiceRecord r = res.record;
if (!mAm.mUserController.exists(r.userId)) {
Slog.w(TAG, "Trying to start service with non-existent user! " + r.userId);
return null;
}
//判断是否容许启动该服务。
if (!r.startRequested) {
final long token = Binder.clearCallingIdentity();
try {
final int allowed = mAm.checkAllowBackgroundLocked(
r.appInfo.uid, r.packageName, callingPid, true);
if (allowed != ActivityManager.APP_START_MODE_NORMAL) {
Slog.w(TAG, "Background start not allowed: service "
+ service + " to " + r.name.flattenToShortString()
+ " from pid=" + callingPid + " uid=" + callingUid
+ " pkg=" + callingPackage);
return null;
}
} finally {
Binder.restoreCallingIdentity(token);
}
}
//是否须要配置相应的权限。
NeededUriGrants neededGrants = mAm.checkGrantUriPermissionFromIntentLocked(
callingUid, r.packageName, service, service.getFlags(), null, r.userId);
if (Build.PERMISSIONS_REVIEW_REQUIRED) {
if (!requestStartTargetPermissionsReviewIfNeededLocked(r, callingPackage,
callingUid, service, callerFg, userId)) {
return null;
}
}
//若是该Service正在等待被从新启动，那么移除它。
if (unscheduleServiceRestartLocked(r, callingUid, false)) {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "START SERVICE WHILE RESTART PENDING: " + r);
}
//给ServiceRecord添加必要的信息。
r.lastActivity = SystemClock.uptimeMillis();
r.startRequested = true;
r.delayedStop = false;
r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
service, neededGrants));
//其它的一些逻辑，与第一次启动无关，就先不分析了。
return startServiceInnerLocked(smap, service, r, callerFg, addToStarting);
}
复制代码
简单地来讲，就是根据Intent查找须要启动的Service，封装成ServiceRecord对象，初始化其中的关键变量，在这一过程当中，加入了一些必要的逻辑判断，最终调用了startServiceInnerLocked方法。函数
ComponentName startServiceInnerLocked(ServiceMap smap, Intent service, ServiceRecord r,
boolean callerFg, boolean addToStarting) throws TransactionTooLargeException {
//...
String error = bringUpServiceLocked(r, service.getFlags(), callerFg, false, false);
//...
return r.name;
}
复制代码
这里面的逻辑咱们先忽略掉一部分，只须要知道在正常状况下它会去调用bringUpServiceLocked来启动Service：源码分析
private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
boolean whileRestarting) throws TransactionTooLargeException {
//若是该Service已经启动。
if (r.app != null && r.app.thread != null) {
sendServiceArgsLocked(r, execInFg, false);
return null;
}
//若是正在等待被从新启动，那么什么也不作。
if (!whileRestarting && r.restartDelay > 0) {
return null;
}
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Bringing up " + r + " " + r.intent);
//清除等待被从新启动的状态。
if (mRestartingServices.remove(r)) {
r.resetRestartCounter();
clearRestartingIfNeededLocked(r);
}
//由于咱们立刻就要启动该Service，所以去掉它的延时属性。
if (r.delayed) {
if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (bring up): " + r);
getServiceMap(r.userId).mDelayedStartList.remove(r);
r.delayed = false;
}
//若是该Service所属的用户没有启动，那么调用 bringDownServiceLocked 方法。
if (mAm.mStartedUsers.get(r.userId) == null) {
String msg = "Unable to launch app "
+ r.appInfo.packageName + "/"
+ r.appInfo.uid + " for service "
+ r.intent.getIntent() + ": user " + r.userId + " is stopped";
Slog.w(TAG, msg);
bringDownServiceLocked(r);
return msg;
}
try {
AppGlobals.getPackageManager().setPackageStoppedState(
r.packageName, false, r.userId);
} catch (RemoteException e) {
} catch (IllegalArgumentException e) {
Slog.w(TAG, "Failed trying to unstop package "
+ r.packageName + ": " + e);
}
final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
final String procName = r.processName;
ProcessRecord app;
//若是不是运行在独立的进程。
if (!isolated) {
app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
+ " app=" + app);
//若是该进程已经启动，那么调用realStartServiceLocked方法。
if (app != null && app.thread != null) {
try {
app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
//在Service所属进程已经启动的状况下调用的方法。
realStartServiceLocked(r, app, execInFg);
return null;
} catch (TransactionTooLargeException e) {
throw e;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting service " + r.shortName, e);
}
}
} else {
app = r.isolatedProc;
}
//若是该Service所对应的进程没有启动，那么首先启动该进程。
if (app == null) {
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
"service", r.name, false, isolated, false)) == null) {
String msg = "Unable to launch app "
+ r.appInfo.packageName + "/"
+ r.appInfo.uid + " for service "
+ r.intent.getIntent() + ": process is bad";
Slog.w(TAG, msg);
bringDownServiceLocked(r);
return msg;
}
if (isolated) {
r.isolatedProc = app;
}
}
//将该ServiceRecord加入到等待的集合当中，等到新的进程启动以后，再去启动它。
if (!mPendingServices.contains(r)) {
mPendingServices.add(r);
}
if (r.delayedStop) {
r.delayedStop = false;
if (r.startRequested) {
if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
"Applying delayed stop (in bring up): " + r);
stopServiceLocked(r);
}
}
return null;
}
复制代码
bringUpServiceLocked的逻辑就比较复杂了，它会根据目标Service及其所属进程的状态，走向不一样的分支：post
- 进程已经存在，而且目标
Service已经启动：sendServiceArgsLocked - 进程已经存在，可是目标
Service没有启动：realStartServiceLocked - 进程不存在：
startProcessLocked，而且将ServiceRecord加入到mPendingServices中，等待进程启动以后再去启动该Service。
下面，咱们就来一块儿分析一下这三种状况。学习
2.1 进程已经存在，而且目标 Service 已经启动
首先来当进程已经存在，且目标Service已经启动时所调用的sendServiceArgsLocked方法：
private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
boolean oomAdjusted) throws TransactionTooLargeException {
final int N = r.pendingStarts.size();
if (N == 0) {
return;
}
while (r.pendingStarts.size() > 0) {
Exception caughtException = null;
ServiceRecord.StartItem si;
try {
si = r.pendingStarts.remove(0);
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Sending arguments to: "
+ r + " " + r.intent + " args=" + si.intent);
if (si.intent == null && N > 1) {
// If somehow we got a dummy null intent in the middle,
// then skip it. DO NOT skip a null intent when it is
// the only one in the list -- this is to support the
// onStartCommand(null) case.
continue;
}
si.deliveredTime = SystemClock.uptimeMillis();
r.deliveredStarts.add(si);
si.deliveryCount++;
if (si.neededGrants != null) {
mAm.grantUriPermissionUncheckedFromIntentLocked(si.neededGrants,
si.getUriPermissionsLocked());
}
bumpServiceExecutingLocked(r, execInFg, "start");
if (!oomAdjusted) {
oomAdjusted = true;
mAm.updateOomAdjLocked(r.app);
}
int flags = 0;
if (si.deliveryCount > 1) {
flags |= Service.START_FLAG_RETRY;
}
if (si.doneExecutingCount > 0) {
flags |= Service.START_FLAG_REDELIVERY;
}
r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
} catch (TransactionTooLargeException e) {
if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Transaction too large: intent="
+ si.intent);
caughtException = e;
} catch (RemoteException e) {
// Remote process gone... we'll let the normal cleanup take care of this. if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Crashed while sending args: " + r); caughtException = e; } catch (Exception e) { Slog.w(TAG, "Unexpected exception", e); caughtException = e; } if (caughtException != null) { // Keep nesting count correct final boolean inDestroying = mDestroyingServices.contains(r); serviceDoneExecutingLocked(r, inDestroying, inDestroying); if (caughtException instanceof TransactionTooLargeException) { throw (TransactionTooLargeException)caughtException; } break; } } } 复制代码
这里面最关键的就是调用了r.app.thread的scheduleServiceArgs方法，它其实就是Service所属进程的ApplicationThread对象在AMS端的一个远程代理对象，也就是ApplicationThreadProxy，经过binder通讯，它最终会回调到Service所属进程的ApplicationThread的scheduleServiceArgs中：
private class ApplicationThread extends ApplicationThreadNative {
public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
int flags ,Intent args) {
ServiceArgsData s = new ServiceArgsData();
s.token = token;
s.taskRemoved = taskRemoved;
s.startId = startId;
s.flags = flags;
s.args = args;
sendMessage(H.SERVICE_ARGS, s);
}
}
复制代码
sendMessage函数会经过ActivityThread内部的mH对象发送消息到主线程当中，mH其实是一个Handler的子类，在它的handleMessage回调中，处理H.SERVICE_ARGS这条消息：
handleServiceArgs方法，就会从
mServices去查找对应的
Service，调用咱们熟悉的
onStartCommand方法，至于
Service对象是如何被加入到
mServices中的，咱们在
2.2节中进行分析。
private void handleServiceArgs(ServiceArgsData data) {
Service s = mServices.get(data.token);
if (s != null) {
try {
if (data.args != null) {
data.args.setExtrasClassLoader(s.getClassLoader());
data.args.prepareToEnterProcess();
}
int res;
if (!data.taskRemoved) {
//调用 onStartCommand 方法。
res = s.onStartCommand(data.args, data.flags, data.startId);
} else {
s.onTaskRemoved(data.args);
res = Service.START_TASK_REMOVED_COMPLETE;
}
QueuedWork.waitToFinish();
try {
//通知AMS启动完成。
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
} catch (RemoteException e) {
// nothing to do.
}
ensureJitEnabled();
} catch (Exception e) {
if (!mInstrumentation.onException(s, e)) {
throw new RuntimeException(
"Unable to start service " + s
+ " with " + data.args + ": " + e.toString(), e);
}
}
}
}
复制代码
这里面，咱们会取得onStartCommand的返回值，再经过Binder将该返回值传回到AMS端，在AMS的mServices的serviceDoneExecutingLocked中，会根据该返回值来修改ServiceRecord的属性，这也就是咱们常说的onStartCommand方法的返回值，会影响到该Services以后的一些行为的缘由，关于这些返回值之间的差异，能够查看Service.java的注释，也能够查看网上的一些教程：
2.2 进程已经存在，可是 Service 没有启动
下面，咱们来看Service没有启动的状况，这里会调用realStartServiceLocked方法：
private final void realStartServiceLocked(ServiceRecord r,
ProcessRecord app, boolean execInFg) throws RemoteException {
if (app.thread == null) {
throw new RemoteException();
}
if (DEBUG_MU)
Slog.v(TAG_MU, "realStartServiceLocked, ServiceRecord.uid = " + r.appInfo.uid
+ ", ProcessRecord.uid = " + app.uid);
r.app = app;
r.restartTime = r.lastActivity = SystemClock.uptimeMillis();
final boolean newService = app.services.add(r);
bumpServiceExecutingLocked(r, execInFg, "create");
//更新Service所在进程的oom_adj值。
mAm.updateLruProcessLocked(app, false, null);
mAm.updateOomAdjLocked();
boolean created = false;
try {
if (LOG_SERVICE_START_STOP) {
String nameTerm;
int lastPeriod = r.shortName.lastIndexOf('.');
nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
EventLogTags.writeAmCreateService(
r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
}
synchronized (r.stats.getBatteryStats()) {
r.stats.startLaunchedLocked();
}
mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
//通知应用端建立Service对象。
app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
app.repProcState);
r.postNotification();
created = true;
} catch (DeadObjectException e) {
Slog.w(TAG, "Application dead when creating service " + r);
mAm.appDiedLocked(app);
throw e;
} finally {
if (!created) {
final boolean inDestroying = mDestroyingServices.contains(r);
serviceDoneExecutingLocked(r, inDestroying, inDestroying);
if (newService) {
app.services.remove(r);
r.app = null;
}
if (!inDestroying) {
scheduleServiceRestartLocked(r, false);
}
}
}
//这里面会遍历 ServiceRecord.bindings 列表，由于咱们这里是用startService方式启动的，所以该列表为空，什么也不会调用。
requestServiceBindingsLocked(r, execInFg);
updateServiceClientActivitiesLocked(app, null, true);
if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
null, null));
}
//这个在第一种状况中分析过了，会调用 onStartCommand 方法。
sendServiceArgsLocked(r, execInFg, true);
if (r.delayed) {
if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (new proc): " + r);
getServiceMap(r.userId).mDelayedStartList.remove(r);
r.delayed = false;
}
if (r.delayedStop) {
// Oh and hey we've already been asked to stop! r.delayedStop = false; if (r.startRequested) { if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "Applying delayed stop (from start): " + r); stopServiceLocked(r); } } } 复制代码
这段逻辑，有三个地方须要注意：
app.thread.scheduleCreateService：经过这里会在应用进程建立Service对象requestServiceBindingsLocked：若是是经过bindService方式启动的，那么会去调用它的onBind方法。sendServiceArgsLocked：正如2.1节中所分析，这里最终会触发应用进程的Service的onStartCommand方法被调用。
第二点因为咱们今天分析的是startService的方式，因此不用在乎，而第三点咱们以前已经分析过了。因此咱们主要关注app.thread.scheduleCreateService这一句，和2.1中的过程相似，它会回调到H中的下面这个消息处理分支当中：
handleCreateService的处理逻辑以下图所示：
private void handleCreateService(CreateServiceData data) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
unscheduleGcIdler();
LoadedApk packageInfo = getPackageInfoNoCheck(
data.info.applicationInfo, data.compatInfo);
Service service = null;
try {
//根据Service的名字，动态的加载该Service类。
java.lang.ClassLoader cl = packageInfo.getClassLoader();
service = (Service) cl.loadClass(data.info.name).newInstance();
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to instantiate service " + data.info.name
+ ": " + e.toString(), e);
}
}
try {
if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);
//1.建立ContextImpl对象。
ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
//2.将 Service 做为它的成员变量 mOuterContext 。
context.setOuterContext(service);
//3.建立Application对象，若是已经建立那么直接返回，不然先调用Application的onCreate方法。
Application app = packageInfo.makeApplication(false, mInstrumentation);
//4.调用attach方法，将ContextImpl做为它的成员变量mBase。
service.attach(context, this, data.info.name, data.token, app,
ActivityManagerNative.getDefault());
//5.调用Service的onCreate方法。
service.onCreate();
//6.将该Service对象缓存起来。
mServices.put(data.token, service);
try {
ActivityManagerNative.getDefault().serviceDoneExecuting(
data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
} catch (RemoteException e) {
// nothing to do.
}
} catch (Exception e) {
if (!mInstrumentation.onException(service, e)) {
throw new RuntimeException(
"Unable to create service " + data.info.name
+ ": " + e.toString(), e);
}
}
}
复制代码
以上的逻辑分为如下几个部分：
- 根据
Service的名字，经过ClassLoader加载该类，并生成一个Service实例。 - 建立一个新的
ContextImpl对象，并将第一步中建立的Service实例做为它的mOuterContext变量。 - 建立
Application对象，这里会先判断当前进程所对应的Application对象是否已经建立，若是已经建立，那么就直接返回，不然会先建立它，并依次调用它的attachBaseContext(Context context)和onCreate()方法。 - 调用
Service的attach方法，初始化成员变量。
- 调用
Service的onCreate()方法。 - 将该
Service经过token做为key，缓存在mServices列表当中，以后Service生命周期的回调，都依赖于该列表。
2.3 进程不存在的状况
在这种状况下，Service天然也不会存在，咱们会走到mAm.startProcessLocked的逻辑，这里会去启动Service所在的进程，它到底是怎么启动的咱们先不去细看，只须要知道它是这个目的就能够了，此外，还须要注意的是它将该ServiceRecord加入到了mPendingServices中。
对于Service所在的进程，它的入口函数为ActivityThread的main()方法，在main方法中，会建立一个ApplicationThread对象，并调用它的attach方法：
attach方法中，会调用到
AMS的
attachApplication方法：
attachApplication方法中，又会去调用内部的
attachApplicationLocked：
mServices对象：
ActiveServices中的该方法中，就会去遍历前面谈到的
mPendingServices列表，再依次调用
realStartServiceLocked方法，至于这个方法作了什么，你们能够回到前面的
2.2节去看，这里就再也不重复分析了。
3、小结
以上就是startService的整个流程，bindService也是相似一个调用过程，其过程并不复杂，本质上仍是 Framework 源码解析知识梳理(1) - 应用进程与 AMS 的通讯实现 所谈到的通讯过程，咱们所须要学习的是AMS端和Service所在的应用进程对于Service是如何管理的。
系统当中的全部Service都是经过AMS的mServices变量，也就是ActiveServices类来进行管理的，而且每个应用进程中的Service都会在AMS端会对应一个ServiceRecord对象，ServiceRecord中维护了应用进程中的Service对象所须要的状态信息。
而且，不管咱们调用多少次startService方法，在应用进程侧都会只存在一个Service的实例，它被存储到ActivityThread的ArrayMap类型的mServices变量当中。
更多文章，欢迎访问个人 Android 知识梳理系列：
- Android 知识梳理目录：www.jianshu.com/p/fd82d1899…
- 我的主页：lizejun.cn
- 我的知识总结目录：lizejun.cn/categories/
相关文章
- 1. Framework 源码解析知识梳理(6) ContentProvider 源码解析
- 2. Glide 知识梳理(6) - Glide 源码解析之流程剖析
- 3. TP5源码分析前置知识-【源码分析顺序】
- 4. Tornado1.0源码分析-Web Framework
- 5. Android 异步任务知识梳理(1) AsyncTask 源码解析
- 6. View 绘制体系知识梳理(2) setContentView 源码解析
- 7. Android 数据存储知识梳理(3) SharedPreference 源码解析
- 8. Android 数据存储知识梳理(1) SQLiteOpenHelper 源码解析
- 9. Android 异步任务知识梳理(3) AsyncQueryHandler 源码解析
- 10. View 绘制体系知识梳理(1) LayoutInflater#inflate 源码解析
- 更多相关文章...
- • XML DOM 解析器 - XML DOM 教程
- • TCP报文格式解析 - TCP/IP教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • Java Agent入门实战（二）-Instrumentation源码概述
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
欢迎关注本站公众号,获取更多信息
相关文章
- 1. Framework 源码解析知识梳理(6) ContentProvider 源码解析
- 2. Glide 知识梳理(6) - Glide 源码解析之流程剖析
- 3. TP5源码分析前置知识-【源码分析顺序】
- 4. Tornado1.0源码分析-Web Framework
- 5. Android 异步任务知识梳理(1) AsyncTask 源码解析
- 6. View 绘制体系知识梳理(2) setContentView 源码解析
- 7. Android 数据存储知识梳理(3) SharedPreference 源码解析
- 8. Android 数据存储知识梳理(1) SQLiteOpenHelper 源码解析
- 9. Android 异步任务知识梳理(3) AsyncQueryHandler 源码解析
- 10. View 绘制体系知识梳理(1) LayoutInflater#inflate 源码解析