相信大家最近都看到了这条新闻《网友称被拼多多APP远程删除照片》。
简单描述一下事件的过程,一位网友从拼多多的 App 里,得知邀请一名新用户,可以直接提现100元,当成功邀请后,发现给予的是随机金额,并没有100元提现这件事情,之后与客服聊天,发送了邀请一名新用户,可以直接提现100元的截图,然后在发送之后,收到了 vivo 手机系统通知,提示相机内的照片被删除,所以他怀疑拼多多远程操控手机,删除了那张图片。
作为一名 Android 工程师,看到这个问题的时候,发现挺有意思的,所以决定去测试一下,到底拼多多是否真的存在删除用户照片的这个行为。
首先我们都知道,Android 的 App 几乎所有的都会向用户获取了存储空间的读写权限,用于保存和读取相关的数据,所以从技术的角度来说,只要获取了这个权限,位于公共存储空间的任何文件,都是可以被删除的。
作为开发人员,我们都知道,随意删除用户公共存储空间的任意数据,这绝对是不合理的行为,但有一个需要注意的点是,我们开发 App 的时候,也会在某些时候把用户在本 App 中产生的数据保存到公共存储空间,例如图片、文档,或者其他的媒体资源文件。
在通过观察拼多多的聊天页面,我们可以知道,是存在两种发送图片的方式
1. 点击照片发送(也就是说点击照片按钮,选择手机本地的图片发送)
2. 点击拍摄发送(通过拼多多自己的拍照功能,拍摄一张照片发送)
所以这个事件中,有一个问题我们要搞清楚
被删除的截图是原本就存在于这部手机上,还是那名网友在和客服聊天的时候,通过拍摄这个功能,拍了存在于另一部手机上的截图?
如果是按照第一种方式发送的图片,那么这张图片被删除了,拼多多这么做显然是有问题的。
又去翻了视频,我发现发送的图片并不是原本的截图,而是拍摄的照片,当然这也不能绝对说就是用户使用的拼多多聊天内的拍照功能拍的,也可能是用手机拍了另一部手机的截图,然后发送的图片,当然这就和第一种发送方式一样了。
不过这个问题,也就只要当事人知道是怎么回事了。
我们在这里讨论一下第二种方式,如果用户使用的是聊天页面的拍摄按钮,拍了一张截图,发送过去,那么这张图片会不会被删除呢?
我用拼多多聊天页面自带的拍照功能,拍了一张照片,但这时还没有点完成按钮发送,去检查手机存储空间的时候,发现这张照片已经被保存到了 DCIM/Pindd/image/16 这个文件目录下面。
当点击发送后,这照片还是存在的,没有被删除。
那么根据 vivo 手机的系统通知,确实有张图片被删除了,这到底是怎么回事呢?
然后再次去看了遍视频,我发现发送的这张图上面👆有一个很明显的红色标记,再结合上面我拍完的张照片的页面,我们可以发现,拼多多在拍完照片之后是提供图片编辑功能的。
所以我猜测,应该是在应用的聊天页面拍摄的截图,然后通过拍摄后的编辑操作划了红线,然后发送的。
按照正常的逻辑,从拍摄到发送,应该只保留一张图片,这是没问题的。
根据我上面猜测的操作逻辑,其实是拍摄原图并保存,编辑原图生成新的编辑后的图片,然后发送的是编辑后的图片,那么这里的原图其实属于一张临时图片,所以删掉原图保留编辑后的图片,这也是没问题的。
看到这里,做开发的同学应该对这个操作非常熟悉,在大多数有拍照编辑的业务场景中,我们都是这样处理的,因为拍摄的原图相当于一个临时文件,最终编辑后的文件才是最终的文件,这个临时文件对用户来说是无感知且无意义的,所以删掉是正常的行为。
那么哪里有问题?
问题出现在,拼多多删除原图的时候,vivo 手机检测到了图片被删除。为什么 vivo 手机会检测到了图片被删除?
还记得拼多多保存图片的地址吗?DCIM/Pindd/image/16 是在 DCIM 下,DCIM 相当于系统公共的相册目录,在这个目录下做任何图片的保存,删除操作,系统都会得到相册被改动的通知,所以当拼多多删除那张临时文件时,vivo 出现了图片被删除的通知。
真正有问题的地方是,拼多多不应该在 DCIM 保存临时的图片文件,我相信这个问题不止拼多多一个 App 有,很多 App 都可能存在这个问题,归根结底,是对 Android 文件目录使用不规范的问题,应用内的临时文件,应该保存在 App 的私有缓存目录下,Android 的开发文档有明确说明。👇
根据拼多多官方微博最新的声明,也验证了我的猜想是正确的。
正确的做法其实也很简单,这种临时文件放在内部存储 getCacheDir() 或外部存储 getExternalCacheDir() 这两个缓存文件目录里面就可以了,当真正完成所有的逻辑之后,再将图片同步到公共的相册文件夹中。
相比拼多多,微信的聊天页面也有拍照编辑发送这一场景,反观微信,只有在最后一步发送点击之后,该图片才会被保存到手机里用户可见的图片文件夹中,至于中间的临时文件,用户是无法感知的。
当我写这篇文章的时候,发现拼多多的 App 里在编辑图片之后,已经不会删掉原图了,大概是通过热修复的方法,把这里的逻辑做了暂时性的处理。
看似解决了问题,不过根本上,还是对 Android 文件目录使用不规范的问题,热修复也是治标不治本的解决方案,希望拼多多之后可以彻底的解决这个问题吧。
况且 Android 10 Google 已经推出了新的 Scoped Storage 规范,虽然在 Android 10 上没有严格执行,但在 Android 11 上是必须适配的,所以看到这篇文章的同学,也希望大家可以检查一下这部分的代码,尽早做适配。
现在再回看这个问题,你说这个问题严重吗?
从技术的角度来说,确实是一个小问题,但从事件发酵的角度来说,它是一个大问题,任何一个小问题都有可能带来严重的后果,所以说写代码是需要时刻保持严谨的,不只是简单的完成需求,更要仔细想想,它真的没问题了吗?
再次推荐大家,无论你的技术如何,时不时的去翻阅一下 Android 的官方文档,总会找到一些你过去忽略或理解有错的知识。
作者:wanbo
链接:https://juejin.cn/post/6917417541195268104