V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  xloger  ›  全部回复第 14 页 / 共 26 页
回复总数  511
1 ... 10  11  12  13  14  15  16  17  18  19 ... 26  
2021-07-05 11:32:17 +08:00
回复了 changwei 创建的主题 Windows Win10 下最好用的看图软件是?
看了一圈果然没人提我用的这个:MassiGra.
六七年前在用 picasa,忘了因为啥原因换掉了,当时就把小众软件推荐的看图软件试了个遍,最后选了 MassiGra 这个很冷门的。当然,至今我也很满意。
而且很多为了面试“看源码”的,大多看的还是网上别人发的源码分析文章。

别人说看 Android 系统源码时我都会问怎么看的,IDE 点进去看的只是一部分源码,完整的是得自己额外下源码的,没说这个过程的,可以想象出他们是怎么“看源码”的了。

我关于 Android 本身的源码,印象比较深的一次是一个 Activity 关闭后没有及时调 onDestory,网上搜索无果,但是看到 Logcat 上看到了一条日志,然后就源码查这个日志,看怎么处罚这个条件,检查到最后知道是 handler 里有消息没处理完,再一验,是其他同事不小心在某些情况下会死循环反复发 Message 。
框架的源码,我一次是用 Glide 解析 Gif,一部分 Gif 用默认的加载方法不会动。我怀疑是 Glide 解析这个文件把它当普通文件识别了,也许是我生成的 Gif 头文件信息不对之类的。也看了一会源码,不过时间紧张最后直接在应用层加了个判断了。

纯粹的程序员看源码,我觉得分为两个情况:
1 、抱着解决某个问题的角度,去阅读分析这个问题是怎么产生的,该怎么解决。
2 、觉得这个功能实现得很棒,很厉害,去研究学习怎么设计怎么实现的。
2021-06-30 11:45:31 +08:00
回复了 hotMan 创建的主题 分享创造 整了个自媒体工具导航
不错,挺全面的,很适合我这种非专业人士,临时有需求又找不到合适的网站的情况。收藏了。
2021-06-24 10:25:14 +08:00
回复了 yazinnnn 创建的主题 Kotlin 关于 kotlin 处理多个可空类型的变量的问题
我觉得这种时候用 if 就是最好的方案,但如果你非要实现形如 let 的调用方式,可以自己写一个 Object? 的拓展函数实现。接收不定长的参数和一个条件为真时执行的函数。
2021-06-22 16:23:59 +08:00
回复了 szq8014 创建的主题 程序员 你们的项目启动时间是几秒?
Android 项目,冷启动要 2 分多钟,打一个 release 包要 6 分钟。时常吐槽说等编译的时间已经超过我 debug 的时间了。耗时分析有一半时间是在 kotlin 编译上,为此还看了下别人的优化方案: https://juejin.cn/post/6854573211548385294
看完放弃自己优化的念头了。我需要公司配个更好的 CPU ......
看到你这个问题,昨晚特意没充电测试了一下。手里的小米 11,睡了八小时,电量 72% 到 65%。
睡前没杀进程,Clash 也开着。感觉耗电量能接受。
@sorelion #12 这些我也不了解,就不给选哪个的建议了。不过我说点我自己的想法,供你参考。

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

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

祝好。
艹,我也五年 Android,工资远比你低...
2021-06-16 11:05:17 +08:00
回复了 cybermonster 创建的主题 Android 想换小米 11pro,有用过的进来说说优缺点
@cybermonster #10 以前 MIUI 12 的时候是这样,当然我是 2k +120hz 都开了的。那时候每天中午都会打会炉石。然后下午四五点就没电了,而且大部分时候其实我是在用电脑,没咋开手机。
现在 12.5 好挺多,晚上到家还有个 20% 吧,我能接受了。
2021-06-16 10:54:25 +08:00
回复了 cybermonster 创建的主题 Android 想换小米 11pro,有用过的进来说说优缺点
额,本来不想回帖的,看到了 1 楼...
我手头是小米 11,不是 pro 。广告没多少,bug 也没多少。而且说到广告,起码小米的广告开关是符合用户直觉的,我直接就关了。我手头有台华为测试机,某天突然桌面冒出一个啥精品推荐,我绞尽脑汁都不知道怎么删掉,最后还是靠搜索...而且华为自带的视频播放器都有关不掉的视频推荐(关闭内容后也有一个恶心的 icon 在那)。其他厂商这几年的手机我没用过,我是真不明白那些说小米广告多的人怎么看华为的。

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

个人真实感受。你要不认也没问题。
2021-06-15 15:05:56 +08:00
回复了 EEEcho 创建的主题 美酒与美食 螺蛳粉味的粽子好吃吗?
我关注的一个主播有评测,好像味道还可以:
[在粽子里吃出螺蛳粉?居然还有更离谱的口味?-哔哩哔哩] https://b23.tv/hekvbr
2021-06-15 15:01:35 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@omysho #18 😂获得了安慰,原来不是我一个人这样...
2021-06-15 11:40:21 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
😓最后我的解决方案如一楼所说,换回了 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 了,我还要干啥啊。不过马上就要赶下一个需求了,先鸽了吧。
2021-06-12 14:13:10 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@Jirajine #9 谢谢您的意见。我们这个场景并不是通过 文件选择器 UI ( SAF )获得的 Uri,而是通过系统的 MediaStore 扫描公开多媒体库得到的,比如 DCIM 、Pictures 这些文件夹里的。按我的理解,这些 Uri 是没有权限问题的(或者说我申请了 Read Video 权限,就一直拥有了)。
内存泄漏和正确释放的这些问题,我觉得我没有,但的确我还没靠数据验证过,我到时候尝试写个最小复现 Demo 来验证下这个问题。
GIF 我之所以为啥不看 MIME,可能是之前处理视频,被各种奇怪的错误信息坑怕了,有分辨率错的,有帧率不准的,也有啥都没有的,所以对于 GIF,我之前就想着反正我是用这个库解析,它能解出来就是 GIF,不能解出来就当不是吧=。= 不然遇到我认定是 GIF 的但是它解析不出来,还要处理额外的兼容问题。
2021-06-12 13:01:00 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@dingwen07 #10

@yujiang #11

@NSAgold #13

我们是剪辑 App,用户需要能预览,多选,预裁剪他们的素材,所以有一个内置的资源选择器是必然的。包括上面一直在提的,也不是选择器的内容啊,而是处理 Android 10 返回的 Uri 遇到的问题,这个靠 Documents UI 也是解决不了的。
2021-06-11 18:50:08 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@ho121 #6 我开始也是这样以为的,但其实并不是。而且在 `openFileDescriptor` 的注释中也提到了 "If at all possible,you should use {@link #openAssetFileDescriptor(Uri, String)}."虽然本质上它只是封了一层。

我们还没支持通过 SAF 获取文件,目前是通过 MediaStore 获得的,然后视频播放我用到的 `MediaExtractor` 和 `MediaMetadataRetriever` 的 `setDataSource` 是不支持流的方式,只有 File 和 FileDescriptor 两套。
当然,迫不得已,我也是可以通过 Uri 开个流把用户选择的音视频保存在自己私有目录。但这样就太怪了,而且显得仿佛偷用户隐私一样...不过如果要做 SAF 支持,应该只能这样做了吧...
2021-06-11 18:38:19 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@Jirajine #5 我访问的资源都是在公共目录的,不需要用户手动授权,所以应该是不存在失效问题的吧?我之前怀疑的是频繁读取释放后,可能哪里出错了导致文件处于被占用状态,然后我再访问就一直在等解除占用了。一个体现是在阻塞的时候如果等个两三分钟,那还是能正常加载出来的。我本来还是想 debug 一步一步看是内部具体哪个函数卡住了,但是又被其他事情拖住了。
Gif 这个的确有我一部分问题,之前我担心自己判断类型不准确,或者用户某些杂七杂八的 Gif 格式不对,就 try catch 了这个框架的构造方法,如果没出错且获取帧数大于 1 则认定是 Gif 。之前这样做是没问题的。换成了 fd,在大部分手机上也是没问题的,但是一部分手机就会 Native Crash 了,我也没法捕获。
2021-06-11 17:02:07 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@secretman #2 一般的第三方框架还好,但我这次有问题的很多是涉及到 JNI 的,我试过了没改动_(:з)∠)_我至今仍不知道 `FFmpegMediaMetadataRetriever` 的作者代码是哪里写错了...
2021-06-11 16:59:15 +08:00
回复了 xloger 创建的主题 程序员 不是我不想支持 Android 10 的分区存储啊 Orz
@omysho #1 我看文档的说法是 Android 11 开始就会忽略了 `android:requestLegacyExternalStorage` 属性,所以我是打算最后不行了才开这个凑合一下。
然后 Android 11 恢复了 File API 这事,这个就是我傻逼了。这个说法我是之前就知道的,然后,当时我正在解决上面说的 `FFmpegMediaMetadataRetriever` 的 Crash 问题,这期间我尝试了各种做法,包括把 targetSdkVersion 升级到了 30,再给它传 filePath,依然不行。就给我留下了 File API 对我依旧不好使的印象。
刚刚看到你的回帖,对我描述的第二个问题 `MediaExtractor`,换回 filePath 了,目前没有复现用 fileDescriptor 的阻塞 bug,真是喜大普奔。Android 这也真是的 Orz
1 ... 10  11  12  13  14  15  16  17  18  19 ... 26  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2423 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 15:57 · PVG 23:57 · LAX 07:57 · JFK 10:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.