注意以下基于 7.0 源码讨论
1. startActivityForResult 使用场景是什么? requestCode、 resultCode 含义是什么?
1.1 使用场景
用户开始新的活动,并且希望在新活动结束时收到某些信息。比如选择照片、选择联系人、选择收货地址、进行某块数据编辑工作等。
1.2 requestCode
- 解决的是「区分多个异步任务」的问题。与其他异步 API 的设计类似,如果没有这个信息,那么 Activity 在收到响应时会进入混乱的状态。比如他不知道自己得到的是选择照片还是选择联系人的结果。
- 该信息会发送到 AMS 那边的 ActivityRecord.requestCode 变量进行记录,Client 端新 Activity 并不知道这个信息。
- 为什么 requestCode < 0 时收不到结果?
- ActivityStarter 收到 startActivityLocked 时,写入 ActivityRecord.resultTo 变量为空,源码
- 在 ActivityStack 收到 finishActivityResultsLocked 时,读取 ActivityRecord.resultTo 变量为空,结果数据不会添加到源 ActivityRecord.results 变量,源码
- 在 ActivityStack 收到 resumeTopActivityInnerLocked 时,读取 ActivityRecord.results 数组为空,不会分发结果数据,这样源 Activity 也就没有结果回调,源码
1.3 resultCode
- 异步调用结果码,告诉调用者成功/失败/其它信息
- 该信息由被调用 Activity / framework 写入,并经过 AMS 传递给源 Activity
2. A 启动 B ,B 中何时执行 setResult ? setResult 是否可以位于 finish 之后?
2.1 setResult 在 finish 之前执行,只是把数据记录在 Activity.mResultCode 和 Activity.mResultData 变量中
- 最早 Activity 构造器阶段
- 最晚 Activity.finalize 内存回收阶段
// Home 键 + 不保留后台 Activity 可触发 onDestroy
protected void onDestroy() {
super.onDestroy();
Log.d(TAG, "onDestroy() called");
new ReqGC().start();
}
@Override
protected void finalize() throws Throwable {
Log.d(TAG, "finalize() called");
finish();
super.finalize();
}
@Override
public void finish() {
Log.d(TAG, "finish() called");
setResult(RESULT_OK, new Intent().putExtra("key", "resultData"));
super.finish();
}
// 不泄漏 Activity 对象
static class ReqGC {
public void start() {
final Handler handler = new Handler();
handler.postDelayed(new Runnable() {
@Override
public void run() {
System.gc();
handler.postDelayed(this, 10);
}
}, 10);
}
}
2.2 否
- 如果位于 finish 之后执行,那信息无法传递给源 Activity
- 从代码可以看出 setResult 和 finish 类似生产者/消费者模型,setResult 负责写入数据,finish 负责读取数据
2.3 线程安全问题
- Activity.mResultCode 和 Activity.mResultData 变量由 Activity 对象的锁进行保护
- 支持后台线程和 UI 线程分别进行 setResult 和 finish
- 但是为什么需要加锁保护这两个信息?需要「解决什么问题」?
2.4 API 设计/数据组装问题
- 底层 AMS 提供的接口的参数是 setResult 和 finish 的参数的组合形式,但是为什么 Activity 为什么把一个接口拆分成两个接口给开发者使用?
- 使用方便。很多情况下上层调用者只关心 finish ,不需要理解太多的信息。
3. Activity.finish 数据处理流程
关键节点:
- Client 端通过 AMP 把数据发送给 Server 端 AMS
- AMS 把数据包装成 ActivityResult 并保存在源 ActivityRecord 的 results 变量中
- AMS 向 Client 端发送 pause 信息让栈顶 Activity 进入 paused 状态,并等待 Client 端回复或超时
- AMS 接收 Client 端已 paused 信息,恢复下一个获取焦点的 Activity ,读取之前保存在 ActivityRecord.results 变量的数据派发给 Client 端对应的 Activity
- Client 端数据经过 ApplicationThread 对象、ActivityThread 对象的分发最后到达 Activity
4. startActivityForResult 和 singleTask 导致源 Activity 收不到正确结果问题
- 基本原则:源 Activity 和目标 Activity 无法在跨 Task 情况下通过 onActivityResult 传递数据
ActivityStarter.sendNewTaskResultRequestIfNeeded
private void sendNewTaskResultRequestIfNeeded() {
if (mStartActivity.resultTo != null && (mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) != 0
&& mStartActivity.resultTo.task.stack != null) {
// For whatever reason this activity is being launched into a new task...
// yet the caller has requested a result back. Well, that is pretty messed up,
// so instead immediately send back a cancel and let the new task continue launched
// as normal without a dependency on its originator.
Slog.w(TAG, "Activity is launching as a new task, so cancelling activity result.");
mStartActivity.resultTo.task.stack.sendActivityResultLocked(-1, mStartActivity.resultTo,
mStartActivity.resultWho, mStartActivity.requestCode, RESULT_CANCELED, null);
mStartActivity.resultTo = null;
}
}
- Android 5.0 以上 AMS 在处理 requestCode >= 0 情况且 launchMode 为 singleTask 和 singleInstance 信息时「不会」创建新的 Task,因此可以收到正常回调
ActivityStarter.startActivityUnchecked
// Should this be considered a new task?
// 因为新启动 ActivityRecord.resultTo 变量不为空,所以不创建新 Task
if (mStartActivity.resultTo == null && mInTask == null && !mAddingToTask
&& (mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) != 0) {
newTask = true;
setTaskFromReuseOrCreateNewTask(taskToAffiliate);
//...
} else if (mSourceRecord != null) {
// 复用源 ActivityRecord 所属的 Task
final int result = setTaskFromSourceRecord();
//...
} else if (mInTask != null) {
...
} else {
...
}
- Android 4.4.4 以下 AMS 在处理 requestCode >= 0 情况且 launchMode 为 singleTask 和 singleInstance 信息时「会」创建新的 Task,因此在 startActivity 之后立即收到取消的回调
if (sourceRecord == null) {
// This activity is not being started from another... in this
// case we -always- start a new task.
if ((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
Slog.w(TAG, "startActivity called from non-Activity context; forcing " +
"Intent.FLAG_ACTIVITY_NEW_TASK for: " + intent);
launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
}
} else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
// The original activity who is starting us is running as a single
// instance... this new activity it is starting must go on its
// own task.
// 源 Activity 独占一个 Task
launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
} else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
// The activity being started is a single instance... it always
// gets launched into its own task.
// 新 Activity 需要在新 Task
launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
}
if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
// For whatever reason this activity is being launched into a new
// task... yet the caller has requested a result back. Well, that
// is pretty messed up, so instead immediately send back a cancel
// and let the new task continue launched as normal without a
// dependency on its originator.
Slog.w(TAG, "Activity is launching as a new task, so cancelling activity result.");
r.resultTo.task.stack.sendActivityResultLocked(-1,
r.resultTo, r.resultWho, r.requestCode,
Activity.RESULT_CANCELED, null);
// 这里清空需要接收结果的 Activity 的引用
r.resultTo = null;
}
// Should this be considered a new task?
// 因为 r.resultTo 已经被清空,所以会创建新的 Task
if (r.resultTo == null && !addingToTask
&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
...
r.setTask(targetStack.createTaskRecord(getNextTaskId(),
newTaskInfo != null ? newTaskInfo : r.info,
newTaskIntent != null ? newTaskIntent : intent,
true), null, true);
if (DEBUG_TASKS) Slog.v(TAG, "Starting new activity " + r + " in new task " +
r.task);
newTask = true;
...
} else if (sourceRecord != null) {
...
- 通过 dumpsys activity activities 命令查看 AMS 状态,验证两个 Activity 是否属于不同的 Task
- 通过 debug AMS 源码的方式验证以上假设
总结
以上就是该 API 的使用场景、内部原理、注意事项