不错，挺全面的，很适合我这种非专业人士，临时有需求又找不到合适的网站的情况。收藏了。

我觉得这种时候用 if 就是最好的方案，但如果你非要实现形如 let 的调用方式，可以自己写一个 Object? 的拓展函数实现。接收不定长的参数和一个条件为真时执行的函数。

Android 项目，冷启动要 2 分多钟，打一个 release 包要 6 分钟。时常吐槽说等编译的时间已经超过我 debug 的时间了。耗时分析有一半时间是在 kotlin 编译上，为此还看了下别人的优化方案： https://juejin.cn/post/6854573211548385294
看完放弃自己优化的念头了。我需要公司配个更好的 CPU ......

看到你这个问题，昨晚特意没充电测试了一下。手里的小米 11，睡了八小时，电量 72% 到 65%。
睡前没杀进程，Clash 也开着。感觉耗电量能接受。

@sorelion #12 这些我也不了解，就不给选哪个的建议了。不过我说点我自己的想法，供你参考。

首先，我觉得你可以想一下当前你的人生阶段，优先级更高的是什么事？我之前迫于一些焦虑也在想要不要跳，但是最后结果是我当下更希望打理自己的生活，所以暂时放弃了换工作的想法避免进了很忙的公司。
但前两年换工作时，那时我的最高优先级是：我感觉到了我的应用层开发经验已经瓶颈了，我重点应该找适合发展的工作，所以那时候我定下两个方向，一个是底层，一个是音视频，然后尽可能地争取，哪怕换城市也无所谓。

所以我感觉你也可以想想你的规划和你的优先级是什么样。如果更希望注重生活，那就找个双休的不加班的。如果有大厂情节，那再准备准备面一下试试看。如果对技术很执着，希望做有意思有挑战的东西，可能要慎重外包（我不熟悉，只是算人云亦云吧）。如果想转管理，第二个好像也不错。

祝好。

艹，我也五年 Android，工资远比你低...

@cybermonster #10 以前 MIUI 12 的时候是这样，当然我是 2k +120hz 都开了的。那时候每天中午都会打会炉石。然后下午四五点就没电了，而且大部分时候其实我是在用电脑，没咋开手机。
现在 12.5 好挺多，晚上到家还有个 20% 吧，我能接受了。

额，本来不想回帖的，看到了 1 楼...
我手头是小米 11，不是 pro 。广告没多少，bug 也没多少。而且说到广告，起码小米的广告开关是符合用户直觉的，我直接就关了。我手头有台华为测试机，某天突然桌面冒出一个啥精品推荐，我绞尽脑汁都不知道怎么删掉，最后还是靠搜索...而且华为自带的视频播放器都有关不掉的视频推荐（关闭内容后也有一个恶心的 icon 在那）。其他厂商这几年的手机我没用过，我是真不明白那些说小米广告多的人怎么看华为的。

然后续航问题，MIUI12 的时候我手头这破手机续航一天一冲都不够，换成 12.5 后倒是一天一冲没啥问题了。相机我不懂用的也不多，个人感受：1 、微信自带的拍照功能渣得一逼，效果远比系统自带的差。要拿其他的比我不说话，拿微信拍照比，呵呵。2 、微距功能挺好玩，但是拍出来后总有点糊。当然，我这是 11 不是 pro 。

个人真实感受。你要不认也没问题。

我关注的一个主播有评测，好像味道还可以：
[在粽子里吃出螺蛳粉？居然还有更离谱的口味？-哔哩哔哩] https://b23.tv/hekvbr

@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

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

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