摘要:綜述所有內容的訪問變化見下圖外部媒體文件的掃描,讀取和寫入最容易被踩坑的應該是,對外部媒體文件,照片,視頻,圖片的讀取或寫入。一句話介紹,就是系統中的一個多媒體數據庫。這里需要注意是無法獲取到文件的。強烈呼吁的正式版能修正這個設計缺陷。
綜述
所有內容的訪問變化見下圖:
外部媒體文件的掃描,讀取和寫入最容易被踩坑的應該是,對外部媒體文件,照片,視頻,圖片的讀取或寫入。
掃描首先是掃描。掃描依然是使用 query MediaStore 的方式。一句話介紹 MediaStore,MediaStore 就是Android系統中的一個多媒體數據庫。代碼如下圖所示,以搜索本地視頻為例子:
protected ListdoInBackground(Void... params) { mContentResolver = context.getContentResolver(); String[] mediaColumns = { MediaStore.Video.Media._ID, MediaStore.Video.Media.DATA, MediaStore.Video.Media.TITLE, MediaStore.Video.Media.MIME_TYPE, MediaStore.Video.Media.DISPLAY_NAME, MediaStore.Video.Media.SIZE, MediaStore.Video.Media.DATE_ADDED, MediaStore.Video.Media.DURATION, MediaStore.Video.Media.WIDTH, MediaStore.Video.Media.HEIGHT }; Cursor mCursor = mContentResolver.query(MediaStore.Video.Media.EXTERNAL_CONTENT_URI, mediaColumns, null, null, MediaStore.Video.Media.DATE_ADDED); if (mCursor == null) { return null; } // 注意,DATA 數據在 Android Q 以前代表了文件的路徑,但在 Android Q上該路徑無法被訪問,因此沒有意義。 ixData = mCursor.getColumnIndexOrThrow(MediaStore.Video.Media.DATA); ixMime = mCursor.getColumnIndexOrThrow(MediaStore.Video.Media.MIME_TYPE); // ID 是在 Android Q 上讀取文件的關鍵字段 ixId = mCursor.getColumnIndexOrThrow(MediaStore.Video.Media._ID); ixSize = mCursor.getColumnIndexOrThrow(MediaStore.Video.Media.SIZE); ixTitle = mCursor.getColumnIndexOrThrow(MediaStore.Video.Media.TITLE); allImages = new ArrayList (); mTotalVideoCount = 0; mCursor.moveToLast(); while (mCursor.moveToPrevious()) { if (addVideo(mCursor) == 0) { continue; } else if (addVideo(mCursor) == 1) { break; } } mCursor.close(); return allImages; }
既然 data 不可用,就需要知曉 id 的使用方式,首先是使用 id 拼裝出 content uri ,如下所示:
public getRealPath(String id) { return MediaStore.Video.Media.EXTERNAL_CONTENT_URI.buildUpon().appendPath(String.valueOf(id)).build().toString(); }
Image 同理換成 MediaStore.Images。
讀取和寫入其次,是讀取 content uri。這里需要注意 File file = new File(contentUri); 是無法獲取到文件的。file.exist() 為 false。
那么就產生兩個問題:1. 如何確定 ContentUri 形式的文件存在 2. 如何讀取或寫入文件。
首先,對于 Content Uri 的讀取,必須借助于 ContentResolver。
其次,對于 1,沒有找到 Google 文檔中提供比較容易的API,只能采用打開 FileDescriptor 是否成功的形式,代碼如下所示:
public boolean isContentUriExists(Context context, Uri uri) { if (null == context) { return false; } ContentResolver cr = context.getContentResolver(); try { AssetFileDescriptor afd = cr.openAssetFileDescriptor(uri, "r"); if (null == afd) { iterator.remove(); } else { try { afd.close(); } catch (IOException e) { } } } catch (FileNotFoundException e) { return false; } return true; }
這種方法最大的問題即是,對應于一個同步 I/O 調用,易造成線程等待。因此,目前對于 MediaStore 中掃描出來的文件可能不存在的情況,沒有直接的好方法可以解決過濾。
對于問題 2,如 1 所示,可以借助 Content Uri 從 ContentResolver 里面拿到 AssetFileDescriptor,然后就可以拿到 InputSteam 或 OutputStream,那么接下來的讀取和寫入就非常自然,如下所示:
public static void copy(File src, ParcelFileDescriptor parcelFileDescriptor) throws IOException { FileInputStream istream = new FileInputStream(src); try { FileOutputStream ostream = new FileOutputStream(parcelFileDescriptor.getFileDescriptor()); try { IOUtil.copy(istream, ostream); } finally { ostream.close(); } } finally { istream.close(); } } public static void copy(ParcelFileDescriptor parcelFileDescriptor, File dst) throws IOException { FileInputStream istream = new FileInputStream(parcelFileDescriptor.getFileDescriptor()); try { FileOutputStream ostream = new FileOutputStream(dst); try { IOUtil.copy(istream, ostream); } finally { ostream.close(); } } finally { istream.close(); } } public static void copy(InputStream ist, OutputStream ost) throws IOException { byte[] buffer = new byte[4096]; int byteCount = 0; while ((byteCount = ist.read(buffer)) != -1) { // 循環從輸入流讀取 buffer字節 ost.write(buffer, 0, byteCount); // 將讀取的輸入流寫入到輸出流 } }保存媒體文件到公共區域
這里僅以 Video 示例,Image、Downloads 基本類似:
public static Uri insertVideoIntoMediaStore(Context context, String fileName) { ContentValues contentValues = new ContentValues(); contentValues.put(MediaStore.Video.Media.DISPLAY_NAME, fileName); contentValues.put(MediaStore.Video.Media.DATE_TAKEN, System.currentTimeMillis()); contentValues.put(MediaStore.Video.Media.MIME_TYPE, "video/mp4"); Uri uri = context.getContentResolver().insert(MediaStore.Video.Media.EXTERNAL_CONTENT_URI, contentValues); return uri; }
這里所做的,只是往 MediaStore 里面插入一條新的記錄,MediaStore 會返回給我們一個空的 Content Uri,接下來問題就轉化為往這個 Content Uri 里面寫入,那么應用上一節所述的代碼即可實現。
Video 的 Thumbnail 問題在 Android Q 上已經拿不到 Video 的 Thumbnail 路徑了,又由于沒有暴露 Video 的 Thumbnail 的 id ,導致了 Video 的 Thumbnail 只能使用實時獲取 Bitmap 的方法,如下所示:
private Bitmap getThumbnail(ContentResolver cr, long videoId) throws Throwable { return MediaStore.Video.Thumbnails.getThumbnail(cr, videoId, MediaStore.Video.Thumbnails.MINI_KIND, null); }
可以進去看 Android SDK 的實現,其中最關鍵的部分是:
String column = isVideo ? "video_id=" : "image_id="; c = cr.query(baseUri, PROJECTION, column + origId, null, null); if (c != null && c.moveToFirst()) { bitmap = getMiniThumbFromFile(c, baseUri, cr, options); if (bitmap != null) { return bitmap; } }
進一步再進去看,可以發現直接就把 Video/Image 文件打開計算 Thumbnail。
private static Bitmap getMiniThumbFromFile( Cursor c, Uri baseUri, ContentResolver cr, BitmapFactory.Options options) { Bitmap bitmap = null; Uri thumbUri = null; try { long thumbId = c.getLong(0); String filePath = c.getString(1); thumbUri = ContentUris.withAppendedId(baseUri, thumbId); ParcelFileDescriptor pfdInput = cr.openFileDescriptor(thumbUri, "r"); bitmap = BitmapFactory.decodeFileDescriptor( pfdInput.getFileDescriptor(), null, options); pfdInput.close(); } catch (FileNotFoundException ex) { Log.e(TAG, "couldn"t open thumbnail " + thumbUri + "; " + ex); } catch (IOException ex) { Log.e(TAG, "couldn"t open thumbnail " + thumbUri + "; " + ex); } catch (OutOfMemoryError ex) { Log.e(TAG, "failed to allocate memory for thumbnail " + thumbUri + "; " + ex); } return bitmap; }
這個 API 毫無疑問設計的非常不合理,沒有暴露 Thumbnail 的系統緩存給開發者,造成了每次都要重新I/O 計算的極大耗時。強烈呼吁 Android Q 的正式版能修正這個 API 設計缺陷。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/74550.html
摘要:隱私更改相關介紹存儲范圍變更改變了應用程序訪問設備外部存儲上文件的方式。只有應用程序預期啟動的特定廣播才免除。此更改意味著將僅接受系統生成的文件。使用全屏通知的應用必須在其應用的文件中請求權限,這是正常權限,因此系統會自動授予。 Android Q 隱私更改相關介紹 存儲范圍變更 Android Q 改變了應用程序訪問設備外部存儲上文件的方式。 通過使用更細粒度的媒體特定權限替換以前的...
摘要:隱私更改相關介紹存儲范圍變更改變了應用程序訪問設備外部存儲上文件的方式。只有應用程序預期啟動的特定廣播才免除。此更改意味著將僅接受系統生成的文件。使用全屏通知的應用必須在其應用的文件中請求權限,這是正常權限,因此系統會自動授予。 Android Q 隱私更改相關介紹 存儲范圍變更 Android Q 改變了應用程序訪問設備外部存儲上文件的方式。 通過使用更細粒度的媒體特定權限替換以前的...
摘要:安裝與測試的流程也是用了的機制而不會受到影響。其他提供自定義類加載器的公有,是不是意味著對于熱修復或者插件化將有官方的支持我們按照開發者的反饋,將部分合理的常用非接口以新的取代。而熱修復或者插件化皆違反政策,是不容許的。showImg(https://user-gold-cdn.xitu.io/2019/5/17/16ac450a4b6e13b5); Device ID Q: 預裝應用可以獲...
閱讀 3011·2021-10-12 10:12
閱讀 3065·2021-09-22 16:04
閱讀 3297·2019-08-30 15:54
閱讀 2609·2019-08-29 16:59
閱讀 2921·2019-08-29 16:08
閱讀 874·2019-08-29 11:20
閱讀 3500·2019-08-28 18:08
閱讀 656·2019-08-26 13:43