#前言

还有20天就要过年了，心情非常的激动，感觉自己已经要膨胀了，所以今天来讨论一下两个比较常见的问题，相信很多朋友都已经研究过了，不过年底了就当是复习了吧。

现在我们开始讨论今天的话题

（PS：请注意，我用的kotlin，并不是Java，但是我相信Java同学肯定看的懂）

#Fragment的onActivityResult方法

最近新项目里有这样一个使用场景：

在Activity里，嵌套了一个Fragment，这个Fragment用来从手机中选择照片。

val intent = Intent(Intent.ACTION_PICK, MediaStore.Images.Media.EXTERNAL_CONTENT_URI)
startActivityForResult(Intent.createChooser(intent, resources.getString(R.string.please_select_pic)), REQUEST_PICK)

写法还是很简单的，很幸运，我发现Fragment也是有onActivityResult方法，于是按照平时的套路写完了代码，结果非常成功。

紧接着，出现了另一个需求：

编辑用户昵称，跳转到一个编辑Activity，返回显示新的用户昵称。

于是我满怀希望的按照刚才的套路写了一遍代码：

val intent = Intent(activity, EditShortInfoActivity::class.java)
intent.putExtra("title", title)
intent.putExtra("content", content)
intent.putExtra("length", length)
activity.startActivityForResult(intent, requestCode)

最终在编辑结束后，返回新的昵称：

val intent = Intent()
intent.putExtra("content", message)
setResult(Activity.RESULT_OK, intent)
finish()

赶紧运行测试一下，咦咦咦？为什么onActivityResult方法没有回调呢？

这不是再搞我吗？我十分气愤的吐槽中，首先打开了Fragment的onActivityResult方法：

public void onActivityResult(int requestCode, int resultCode, Intent data) {
}

空方法，说明Fragment内部没有做任何处理，不过问题应该不在这，Fragment被嵌套在Activity中，那么Activity调用了Fragment的可能性肯定是最大的，啥也别说了，看一下FragmentActivity的onActivity方法：

@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) {
mFragments.noteStateNotSaved();
int requestIndex = requestCode>>16;
if (requestIndex != 0) {
requestIndex--; String who = mPendingFragmentActivityResults.get(requestIndex);
mPendingFragmentActivityResults.remove(requestIndex);
if (who == null) {
Log.w(TAG, "Activity result delivered for unknown Fragment.");
return; }
Fragment targetFragment = mFragments.findFragmentByWho(who);
if (targetFragment == null) {
Log.w(TAG, "Activity result no fragment exists for who: " + who);
} else {
targetFragment.onActivityResult(requestCode & 0xffff, resultCode, data);
}
return;
}
super.onActivityResult(requestCode, resultCode, data);
}

果然看到了我们期待的Fragment对象，那八成问题就在这了，我们先来分析一下代码：

我们的请求码右移了16位（相当于除了2的16次方，也就是65526），得到了一个索引值，这让我想到了之前我们研究过的哈西算法，然后得到对应的Fragment，如果你Fragment不等于空，就再把请求码再处理一次，然后回调onActivityResult方法。

我们先来断点看看在我第一次获取系统照片的时候都发生了什么？

image

首先我要告诉大家，我自己传的requestCode是101，但是在FragmentActivity的onActivityResult中竟然显示的是327781，那肯定是在调用相册的时候，系统把的请求码处理了，最终走到了Fragment的onActivityResult方法，

image

在我的EditUserInfoDetailsFragment得到的是101。

通过上面的研究，我们得出了结论，当我们在调用系统相册的时候，系统会把我们原来的请求码进行处理，然后再最终把处理过的请求码恢复，我们就可以通过判断我们原本的请求码，知道我们要进行的操作什么。

现在再来试试第二种情况，因为篇幅的缘故我就不贴图了，直接说出结果（其实是我懒，大家都懂的）：

如果是app内部的startActivityForResult，是不会对请求码进行处理的，也就是说我们传的requestCode是什么，在FragmentActivity中得到也是什么，但是我们的值除以65536，那是肯定是等于0的，所以就什么也不执行了。

有些朋友说了，那我直接把我的请求码设置到65536以上不就得了？

我就说为什么你这么机智呢，我就赶紧实验了一下：

image

结果很凄凉，只能使用小于16位的requestCode，那就是说不可能大于65536，看来google比我们还机智。

那有什么办法解决这个问题呢？其实非常的简单，既然系统忽略了我们的请求码，那我们就自己分发请求码就好了：

/** * 重写此方法，子fragment才能出发回调onActivityResult */ @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
if (resultCode != RESULT_OK) {
return;
}
FragmentManager fm = getSupportFragmentManager();
List<Fragment> fragments = fm.getFragments();
if (fragments != null && fragments.size() > 0) {
for (Fragment f : fragments) {
f.onActivityResult(requestCode, resultCode, data);
}
}
}

我这里把resultCode不是ok的屏蔽了，当时你可以按照你自己的需求删掉就可以了，代码就不用解释了。

#总结

为什么android系统对我们的第三方app的请求码处理了呢？

我猜测可能有两点：

1、是为了系统安全，就好像7.0以上把文件的uri封装了是一样的道理。

2、可能是为了区别不同app请求了同一个app，这个值能靠猜了。

本来我今天是想讨论两个问题，没想到一写就这么长了，所以今天就结束了，如果大家对android为什么这么设计有更深入的了解，可以留言讨论，大家一起学习进步。

那就这样，祝大家生活愉快。