@忆_析风 onActivityResult之所以设计的如此难用，本质是向安卓恢复机制的妥协。
因为恢复时activity是新的对象，回调式的写法对于这种场景其实天然的无法支持，回调回来的操作必然是对原对象的操作。导致:
1.内存泄露（回调中持有已经ondestory的原activity对象，导致无法回收）；
2.回调更新的是原activity对象的数据，重建的activity并得不到这个回调。
所以安卓源码在设计的时候，是给activity、fragment加了一个统一的onActivityResult的方法，在activity重建的时候，将这个数据回调给新的activity对象，以此达到重建activity场景onActivityResult也能无感知的正常表现。
个人感觉ResultApi解决的主要问题:原来的onActivityResult导致跳转和接收信息两个阶段完全割裂，跳转的地方完全感知不到接收信息的地方，只能通过一个固定的code关联，这对功能的内聚是个极大的破坏，而借助ResultApi，可以将两者关联起来，也能隐藏其中做映射又毫无意义的requestCode。同时也统一了权限申请这种处于一样窘境的场景。
由于重建导致无法借助简单回调的情况有很多，比如直接给fragment(或本质是fragment的dialogfragment)设置回调这类场景，在页面重建，dialogfragment自动恢复的场景，由于设置监听的方法的逻辑并没有重新走到，导致监听没赋值而无法回调出去，我们常见但是很不优雅的解决方案也就是给activity继承这个回调接口，直接在dialogfragment中获取当时依附的activity然后强转成这个接口调用对应方法，本质上和onActivityResult的设计方案是一样的。
目前看起来，只要安卓的重建恢复机制在，这个问题就没有完美的解
Android Result Api不能在生命周期onStart及之后注册的解决办法现在Activity的startActivityForResult废弃了,Google建议我们使用Activity Result Api. 然而这个Activity Resu...
