【移動應用開發技術】android中對截圖事件進行監聽的原理是什么

這篇文章給大家介紹android中對截圖事件進行監聽的原理是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。1.監聽截屏圖片所在目錄變化（FileObserver）2.監聽媒體庫的變化（ContentObserver）

上面兩種方法均不是萬能的，需要結合使用才能達到良好的效果，首先看看如何監控目錄在android中，我們可以通過FileObserver來監聽目錄變化，先來看看如何使用private

static

final

File

DIRECTORY_PICTURES

=

new

File(Environment.getExternalStorageDirectory(),

Environment.DIRECTORY_PICTURES);

private

static

final

File

DIRECTORY_DCIM

=

new

File(Environment.getExternalStorageDirectory(),

Environment.DIRECTORY_DCIM);

if

(manufacturer.equalsIgnoreCase("xiaomi"))

{

DIRECTORY_SCREENSHOT

=

new

File(DIRECTORY_DCIM,

"Screenshots");

}

else

{

DIRECTORY_SCREENSHOT

=

new

File(DIRECTORY_PICTURES,

"Screenshots");

}

FILE_OBSERVER

=

new

FileObserver(DIRECTORY_SCREENSHOT.getPath(),

FileObserver.ALL_EVENTS)

{

@Override

public

void

onEvent(int

event,

String

path)

{

if

(event

==

FileObserver.CREATE)

{

String

newPath

=

new

File(DIRECTORY_SCREENSHOT,

path).getAbsolutePath();

Log.d(TAG,

"path:

"

+

newPath);

}

}

};我們對指定目錄的指定事件監聽即可，當事件被觸發時onEvent會回調。這里我們只關心目錄中有沒有新的文件生成。坑1：在實踐中發現，并不是所有手機都允許如此監聽或者說都能收到回調。有的手機上面無法收到CREATE事件，但是可以收到其他事件。我還發現，有的時候收到的事件并沒有在FileObserver中定義，比如32768！下面是Linux中相應event對應的含義，32768=IN_IGNORED，但是為什么會ignore，并不清楚。/lxr/http/source/include/linux/inotify.h?a=m68k#L45還遇到過1073741856（1073741856=0x40000000|0x20，即IN_OPEN|IN_ISDIR）和1073741840（1073741840=0x40000000|0x10，即IN_CLOSE_NOWRITE|IN_ISDIR）。坑2：不同手機，監聽的目錄并不一致。小米需要監聽Environment.DIRECTORY_DCIM，其他監聽Environment.DIRECTORY_PICTURES即可。關于FileObserver這里再多說兩句，FileObserver無法進行遞歸監聽，也就是說，我們監聽的文件夾中如果有子文件夾，并且我們想知道其中變化，這種方式是不可行的。需要手動對子文件進行操作。另外，當我們監聽的目錄/文件被刪除后又重新建立了一個同名的目錄/文件，之前的FileObserver不會繼續工作，需要重新設置監聽才行。還要注意，FileObserver回調并不在主線程中，而是在FileObserver線程中。鑒于上述原因，我們還要使用方法2，監聽媒體庫變化。這個方法使用ContentObserver即可。private

static

final

ContentObserver

CONTENT_OBSERVER

=

new

ContentObserver(HANDLER)

{

@Override

public

void

onChange(boolean

selfChange,

Uri

uri)

{

//記得先檢查讀文件的權限

ContentResolver

resolver

=

GeneralInfoHelper.getContext().getContentResolver();

if

(uri.toString().matches(MediaStore.Images.Media.EXTERNAL_CONTENT_URI

+

"(/\\d+)?"))

{

Cursor

cursor

=

resolver.query(uri,

PROJECTION,

null,

null,

MediaStore.MediaColumns.DATE_ADDED

+

"

DESC");

if

(cursor

!=

null

&&

cursor.moveToFirst())

{

//完整路徑

String

newPath

=

cursor.getString(cursor.getColumnIndex(MediaStore.MediaColumns.DATA));

File

file

=

new

File(newPath);

//file.exists()

判斷文件是否存在

}

if

(cursor

!=

null)

{

cursor.close();

}

}

}

};

getContentResolver().registerContentObserver(MediaStore.Images.Media.EXTERNAL_CONTENT_URI,

true,

CONTENT_OBSERVER);坑3：實踐中發現，并不是所有手機都是監聽相同的Uri，有的帶數字，有的不帶。坑4：查詢數據庫時記得按MediaStore.MediaColumns.DATE_ADDED字段排序，注意，這個時間單位是秒，不是毫秒坑5：即使排了序，你拿到的仍然有可能不是正確的，在魅族E2上面出現了這個問題。但是當我刪除了魅族E2截圖文件夾之后，一切又恢復正常了……這里我做了一個簡單的判斷，如何DATE_ADDED和當前時間相差兩秒以內，那么從數據庫查出的這條數據我視為有效坑6：當用戶刪除了截圖文件夾的時候，媒體庫此時會更新，所以此時onChange會收到大量回調，所以這里需要判斷判斷文件是否存在。可能有人會問，為什么不直接用第二種方法？原因有2，首先從坑5可以看出第二種方法也并非100%有效，其次，這種方法速度很慢，通常會有2-3秒的延遲。而第一種方法如果有效，通常都會比后者快很多。好了，障礙基本掃清，下面開始融合兩種方法首先使用成員變量記錄截圖文件路徑private

static

String

sScreenshotPath;當方法1或者方法2收到結果時，用收到的結果與sScreenshotPath對比，如果是同一個文件，那么就無需再次通知了，否則則進行通知。邏輯太簡單，代碼就不寫了。但是實際情況是不會這么樂觀的。坑7：在實踐中發現，有的系統不直接保存截圖，而是先生成一個隱藏文件，比如叫.截圖.jpg，然后再修改文件名（去掉“.”）。這種情況下，我們可能就會收到兩次用戶截圖事件的回調（方法1和方法2都可能收到回調），但實際用戶只截了一次。這里我做了一個特殊處理，在判斷是否是同一個文件時，只判斷文件名，而不去管文件的完整路徑也不管文件是否隱藏（也就是不比較文件名前面的“.”）//僅靠文件名而不是全路徑判斷是否為同一個截圖文件，因為有些系統對截圖有move操作

private

static

boolean

isSameFile(String

newPath)

{

if

(TextUtils.isEmpty(sScreenshotPath))

{

return

false;

}

return

TextUtils.equals(removePrefixDot(new

File(sScreenshotPath).getName()),

removePrefixDot(new

File(newPath).getName()));

}

private

static

String

removePrefixDot(@NonNull

St