为何onActivityResult传递的数据非类型安全？Activity Result API如何实现类型安全？

• 核心问题首先来自回调方法的签名设计没有任何类型绑定：
  旧机制下onActivityResult的固定签名是onActivityResult(int requestCode, int resultCode, @Nullable Intent data)，所有返回的业务数据全部被塞进通用的Intent容器里，从方法定义层面就没有和你预期要接收的具体数据类型做关联。
  最常见的坑就是：你发起跳转时预期目标页面会返回String类型的用户名，存在key为"username"的extra中。但如果目标页面开发时写错了，把这个key对应的value存成了Boolean类型，你在回调里直接用data.getStringExtra("username")取值时，系统不会在编译阶段提示你类型不匹配，只有运行到这段逻辑时才会出现取值为空、甚至类型转换崩溃的问题。
• 其次是请求标识和数据类型的映射没有校验机制：
  旧机制要区分不同的跳转请求，完全靠开发者手动定义int类型的requestCode做标识，再在onActivityResult里通过多分支判断匹配对应逻辑、取对应类型的数据。整个映射关系完全靠开发者的主观记忆维护，没有任何强制约束：比如你不小心把本来用于“选择照片”的requestCode = 101，复用到了“填写收货地址”的跳转逻辑里，那回调分支匹配成功后，你按照选照片的逻辑把Intent里的地址字符串强行转成图片Uri，就会直接出现类型不匹配的崩溃，这类问题只有在实际运行触发对应分支时才能暴露。
• 最后是数据解析逻辑和发起动作完全脱节：
  旧机制中所有请求的结果解析逻辑，全部集中堆在同一个公共回调方法里，和发起跳转的位置完全分离。你在调用startActivityForResult发起跳转时，没有任何机制能约束、告知后续的解析逻辑要取什么类型的值，甚至随着代码迭代，开发者自己都可能记错某一个requestCode对应的返回值类型，进一步放大了类型不匹配的风险。

对比来看，Activity Result API之所以能实现类型安全，本质是通过ActivityResultContract把启动动作、输入类型、返回结果类型、解析逻辑全部做了强绑定，在注册启动器的阶段就明确了请求与响应的类型对应关系，能在编译阶段就拦截类型不匹配的问题。

内容的提问来源于stack exchange，提问作者SilentKnight