Android R Activity启动流程:逆向代码参数化的信息到客户需求

Android R Activity启动流程:逆向代码参数化的信息到客户需求

1. client客户端:

ActivityTaskManager.getService().startActivity(whoThread,
                    who.getBasePackageName(), who.getAttributionTag(), intent,
                    intent.resolveTypeIfNeeded(who.getContentResolver()), token,
                    target != null ? target.mEmbeddedID : null, requestCode, 0, null, options);

2. server服务端:

ActivityTaskManagerService.java
public final int startActivity(IApplicationThread caller, String callingPackage,
        String callingFeatureId, Intent intent, String resolvedType, IBinder resultTo,
        String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo,
        Bundle bOptions) {

参数理解：
客户端->请求->服务端
1，客户端要有能表明客户的具体信息)
2，请求的意图也有明确具体
3，服务端有各种服务，返回请求的结果。

概念：需要哪种服务就要到哪种服务的接口端进行请求服务并等待返回的结果。
比如，我要启动一个Activity，就到ActivityTaskManagerService服务的接口端startActivity进行登记告知自己请求，等待服务返回请求结果。

3. 逆向代码参数化的信息到客户需求

之前记得UML用例图是：客户的需求->逐步拆解分析->程序代码中的参数。
所以，程序员为了更好的理解代码逻辑，也要学会逆向代码中的参数化信息到客户的需求。

例如：startActivity参数化的信息->逆向转化为->客户需求
The caller, whose calling package is callingPackage and calling feature ID is callingFeatureId,
is executing the intent of resolving type as resolvedType,
and needs to return the result to resultTo and resultWho,
and it carries the request code requestcode, the start flag startflags, the profiler info profilerInfo and a bundle of bOptions

调用者caller其调用包为callingPackage且调用特征id为callingFeatureId，
正在执行解析类型为resolvedType的intent意图，
需要将结果返回给resultTo和resultWho，
并且其携带着请求代码requestCode，启动标志startFlags,分析器信息profilerInfo和一捆可选项。

caller 是 IApplicationThread 类型，即App客户端的IBinder服务接口，系统通过该接口回调App客户端

resultTo 是 IBinder类型， 是调用者caller在系统服务端的IBinder，

参数具有：唯一性，便捷性，标识性，等等。
例如 为什么会有requestCode？
因为requestCode标识具体调用者的某一次的具体请求，方便逻辑处理。

Android 系统是client/server架构 (大局观)
client端       请求            server端

caller    ->    intent   ->    server根据收到的intent请求进行服务

            <- 返回结果