關於拼多多被曝刪除用戶本機照片的一點想法

本文章首發於公衆號 Android丨Kotlin，歡迎搜索 AndroidKotlin 關注我～

相信你們最近都看到了這條新聞《網友稱被拼多多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 的官方文檔，總會找到一些你過去忽略或理解有錯的知識。

感謝閱讀，咱們下期再見。