@omysho #18 😂获得了安慰，原来不是我一个人这样...

😓最后我的解决方案如一楼所说，换回了 File 。白瞎我写好了一套 File Uri 兼容的接口。

我在最开始做兼容时，想着是遵循规范，所以尽管可以开 `requestLegacyExternalStorage` 凑合一下，我也没有选择这个。然后自己弄好了所有对 Uri 的支持，并且一部分自己的私有文件还是得用 File，也做好了相关的处理。

然后就遇到了主楼所说的各种兼容性问题。我知道 Android 11 恢复了 File API，但是在我的测试机（ Android 10 ）上还是不行，这是显而易见的因为我测试机还是 10 嘛，而我不可能不对 10 做兼容。

=。=然后我发现我傻逼了，还有 `requestLegacyExternalStorage` 啊，这个 API 只在 Android 10 生效。

所以，解决这个破问题的完美方案就是，继续用 File 那套，开启 `requestLegacyExternalStorage`。target SDK 用 29，30 都可以。去 TM 的 Uri，去 TM 的 FileDescriptor，一堆问题还让我用。

我本将心照明月，奈何...

ps：我本来想去验证一下 `openFileDescriptor` 阻塞这个问题真不是我的锅的。用完 FileDescriotor 我就 close 了，MediaMetadataRetriever 用完我也 release 了，我还要干啥啊。不过马上就要赶下一个需求了，先鸽了吧。

@Jirajine #9 谢谢您的意见。我们这个场景并不是通过 文件选择器 UI （ SAF ）获得的 Uri，而是通过系统的 MediaStore 扫描公开多媒体库得到的，比如 DCIM 、Pictures 这些文件夹里的。按我的理解，这些 Uri 是没有权限问题的（或者说我申请了 Read Video 权限，就一直拥有了）。
内存泄漏和正确释放的这些问题，我觉得我没有，但的确我还没靠数据验证过，我到时候尝试写个最小复现 Demo 来验证下这个问题。
GIF 我之所以为啥不看 MIME，可能是之前处理视频，被各种奇怪的错误信息坑怕了，有分辨率错的，有帧率不准的，也有啥都没有的，所以对于 GIF，我之前就想着反正我是用这个库解析，它能解出来就是 GIF，不能解出来就当不是吧=。= 不然遇到我认定是 GIF 的但是它解析不出来，还要处理额外的兼容问题。

@dingwen07 #10

@yujiang #11

@NSAgold #13

我们是剪辑 App，用户需要能预览，多选，预裁剪他们的素材，所以有一个内置的资源选择器是必然的。包括上面一直在提的，也不是选择器的内容啊，而是处理 Android 10 返回的 Uri 遇到的问题，这个靠 Documents UI 也是解决不了的。

@ho121 #6 我开始也是这样以为的，但其实并不是。而且在 `openFileDescriptor` 的注释中也提到了 "If at all possible,you should use {@link #openAssetFileDescriptor(Uri, String)}."虽然本质上它只是封了一层。

我们还没支持通过 SAF 获取文件，目前是通过 MediaStore 获得的，然后视频播放我用到的 `MediaExtractor` 和 `MediaMetadataRetriever` 的 `setDataSource` 是不支持流的方式，只有 File 和 FileDescriptor 两套。
当然，迫不得已，我也是可以通过 Uri 开个流把用户选择的音视频保存在自己私有目录。但这样就太怪了，而且显得仿佛偷用户隐私一样...不过如果要做 SAF 支持，应该只能这样做了吧...

@Jirajine #5 我访问的资源都是在公共目录的，不需要用户手动授权，所以应该是不存在失效问题的吧？我之前怀疑的是频繁读取释放后，可能哪里出错了导致文件处于被占用状态，然后我再访问就一直在等解除占用了。一个体现是在阻塞的时候如果等个两三分钟，那还是能正常加载出来的。我本来还是想 debug 一步一步看是内部具体哪个函数卡住了，但是又被其他事情拖住了。
Gif 这个的确有我一部分问题，之前我担心自己判断类型不准确，或者用户某些杂七杂八的 Gif 格式不对，就 try catch 了这个框架的构造方法，如果没出错且获取帧数大于 1 则认定是 Gif 。之前这样做是没问题的。换成了 fd，在大部分手机上也是没问题的，但是一部分手机就会 Native Crash 了，我也没法捕获。

@secretman #2 一般的第三方框架还好，但我这次有问题的很多是涉及到 JNI 的，我试过了没改动_(:з)∠)_我至今仍不知道 `FFmpegMediaMetadataRetriever` 的作者代码是哪里写错了...

@omysho #1 我看文档的说法是 Android 11 开始就会忽略了 `android:requestLegacyExternalStorage` 属性，所以我是打算最后不行了才开这个凑合一下。
然后 Android 11 恢复了 File API 这事，这个就是我傻逼了。这个说法我是之前就知道的，然后，当时我正在解决上面说的 `FFmpegMediaMetadataRetriever` 的 Crash 问题，这期间我尝试了各种做法，包括把 targetSdkVersion 升级到了 30，再给它传 filePath，依然不行。就给我留下了 File API 对我依旧不好使的印象。
刚刚看到你的回帖，对我描述的第二个问题 `MediaExtractor`，换回 filePath 了，目前没有复现用 fileDescriptor 的阻塞 bug，真是喜大普奔。Android 这也真是的 Orz

以前高中的时候，遇到大雨都是直接淋回去，也不担心什么。

现在就不一样了，会想万一感冒了发烧了怎么办，只能自己照顾自己了。不像小时候，喊一句妈我头有点晕就好了。

简而言之，Android 10 之后采用了分区存储，不让垃圾 App 在 SD 卡里乱拉屎。

但是媒体资源的文件夹是允许操作的，于是这些垃圾 App 改在 DCIM 文件夹里乱拉屎了。

挺好的，需要 Android App 的话我可以帮忙，虽说我觉得网页和小程序就够了。

我一直都是只填基本信息，其他的跟人事讲涉及我隐私，你真要那等我入职了再补充。

我今天为了买书，领了一堆优惠券。

然后，京东选需要的书添加到购物车，下单。184 ；当当选同样的书下单，160 。果断用当当了。

你可以瞎扯一句 “不过 HashMap 在最新的 JDK 17 的加载因子改为了 0.8，不知道您对此怎么看”，然后观察一下他的反应。

如果他打个哈哈过去，或者瞎扯一些解释，说明他不过如此，自己也是个只会背面试题的逼。

如果他当场查证，或者自信地跟你讲一下泊松分布的原理，论证 0.75 是个较为合适的值，不应该随便改。那的确是人家牛，态度也没问题，我们也可以服气。

=。=如果给我一个排除中文的排行榜，我可能还更喜欢点。中文项目很多水分太大了

倒了好，之前去盒马付款必须下 App 就一生黑了，而且那次甚至还不能用现金付款。希望垃圾盒马早点倒闭，希望垃圾阿里早点倒闭。

这样一看我还是太年轻。当时一次我在某连锁店吃到了钢丝，投诉后店家表示是姜丝，当时我就很火大。

而那时候我的诉求是，我希望店家能进行检查、优化流程，来避免以后再发生这样的事。我不图钱，就希望能减少这种事发生。

然后美团客服倒是态度很好地应允了，但是他们说他们也只能靠降低排名之类的方式限制。我心想这好歹也是食品安全的问题啊，不过他都这样说了我也不知道说啥，然后我表示一下我希望得到他们改进流程的反馈，他说他尽量，最后也没回音了。

后来朋友跟我聊了这事，他说我应该要钱，这样才能真正地迫使他们改进。我感觉也挺对的，自己还是太天真_(:з)∠)_