android截图事件监听的原理与实现

android系统没有对用户截屏行为提供回调的api，所以我们只能走野路子来获取用户是否截屏了。一般大家都会采用如下两种方法

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，并不清楚。

http://rswiki.csie.org/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 string filename) { 
  if (filename.startswith(".")) { 
    return filename.substring(1); 
  } 
  return filename; 
} 

至此，android截图事件监听基本结束，由于测试机器有限，故无法保证上述方法万无一失。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。