Android平台截图研究 FrameBuffer(/dev/graphics/fb0) 文件内容研究!(含源码工程)
1. FrameBuffer文件介绍
FrameBuffer 文件是 Linux (Android是基于Linux的) 对显示设备的一种抽象设备,相当于显存。Android 的 SurfaceFlinger 想更新屏幕的时候,就会把相应的改变写入到FrameBuffer里。Android 2.x 的时代,显示开机画面的功能也是通过把图像数据写入到FrameBuffer实现的。所以,你可以认为,FrameBuffer里头一定有当前屏幕内容的图像数据。
Android平台上,FrameBuffer 文件的绝对路径一般是: /dev/graphics/fb0 。
所以,如果我们想截图,其中一种方法就是把FrameBuffer里头的图像数据取出来,转换成bitmap,然后存储起来或者给ImageView来显示出来。
2. FrameBuffer文件格式
现在我们知道 FrameBuffer (/dev/graphics/fb0) 文件里头会有当前屏幕的图像数据,取出来就可以了。但是,如果你直接运行这段代码:
public void test() { byte[] fb_data = new byte[5000000]; FileInputStream fis = null; try { fis = new FileInputStream(new File("/dev/graphics/fb0")); DataInputStream dStream = new DataInputStream(fis); dStream.readFully(fb_data); dStream.close(); Bitmap bm = BitmapFactory.decodeByteArray(fb_data, 0, fb_data.length); mImageView.setBackground(new BitmapDrawable(bm)); } catch (Exception e) { e.printStackTrace(); } }
会遇到两个问题:
1. /dev/graphics/fb0 文件会拒绝访问,所以你要让你的程序获取root权限后,才能取到/dev/graphics/fb0里头的数据 ,或者获取 root 权限后把 /dev/graphics/fb0 文件改为所有用户可读 (如何获取root权限,这篇文章暂不讨论)
2. 取到数据后,decode成bitmap,让imageview显示,会花屏,或者索性什么都没显示。
花屏或者什么都不显示,那是因为 FrameBuffer 里头的数据并不是常见的图像数据,直接丢给 BitmapFactory 显示,BitmapFactory 也不知道你这一堆什么玩意儿,所以出来的图像要么花屏,要么什么都不显示。
那我们现在进入正题:FrameBuffer 里头的数据到底是怎么样的?
要弄清这个问题,我们需要在我们的jni代码里执行这段代码:
int fd, ret; struct fb_fix_screeninfo finfo; // 打开Framebuffer设备 fd = open("/dev/graphics/fb0", O_RDONLY); if(fd < 0) { <span style="white-space:pre"> </span>LOGD("======Cannot open /dev/graphics/fb0!"); <span style="white-space:pre"> </span>return -1; } // 获取Framebuffer 的 fixed info 不变信息 ret = ioctl(fd, FBIOGET_FSCREENINFO, &finfo); if(ret < 0 ) { <span style="white-space:pre"> </span>LOGD("Cannot get fixed screen information."); <span style="white-space:pre"> </span>close(fd); <span style="white-space:pre"> </span>return -1; }
通过这段代码,我们获取到了 Framebuffer 设备的 “不变信息” :其实就是一个名叫 fb_fix_screeninfo 的结构体,这个结构体里包含了我们的 Framebuffer 数据的格式。
fb_fix_screeninfo这个结构体定义在 linux/include/linux/fb.h 头 文件里头 ( 虽然这个头文件是linux源码里头找的,但是 fb.h 里头定义的很多东西,Android 都直接沿用了)
定义如下:
struct fb_fix_screeninfo { char id[16]; /* identification string eg "TT Builtin" */ unsigned long smem_start; /* Start of frame buffer mem */ /* (physical address) */ __u32 smem_len; /* Length of frame buffer mem */ __u32 type; /* see FB_TYPE_* */ __u32 type_aux; /* Interleave for interleaved Planes */ __u32 visual; /* see FB_VISUAL_* */ __u16 xpanstep; /* zero if no hardware panning */ __u16 ypanstep; /* zero if no hardware panning */ __u16 ywrapstep; /* zero if no hardware ywrap */ __u32 line_length; /* length of a line in bytes */ unsigned long mmio_start; /* Start of Memory Mapped I/O */ /* (physical address) */ __u32 mmio_len; /* Length of Memory Mapped I/O */ __u32 accel; /* Indicate to driver which */ /* specific chip/card we have */ __u16 reserved[3]; /* Reserved for future compatibility */ };里面有一个 __u32 type 成员,就是这个成员会告诉我们,我们的FrameBuffer里头的数据的格式。
这个 __ur32 type 可能的取值有5个,分别如下:
#define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels */ #define FB_TYPE_PLANES 1 /* Non interleaved planes */ #define FB_TYPE_INTERLEAVED_PLANES 2 /* Interleaved planes */ #define FB_TYPE_TEXT 3 /* Text/attributes */ #define FB_TYPE_VGA_PLANES 4 /* EGA/VGA planes */
于是我们回到刚刚那段 jni 代码,最后加一句打印:
LOGD("====== type : %d", finfo.type);
D/termExec(21787): ====== type : 0
但是既然存的是每个像素点的 ARGB 信息,为何 BitmapFactory 会解析出花屏图像出来呢? 这是因为 Framebuffer 里头每个像素点的 ARGB 信息是按照 little endian 方式存储的 也就是说,假如屏幕中一个像素点的格式的 ARGB 颜色值是 #FFBBCCDD 的话,存到 Framebuffer 的时候,是存成这样的:DDCCBBFF。所以现在你明白为何你把 Framebuffer 的数据直接丢给
BitmapFactory 的时候会花屏了吧? 因为每个像素点的 ARGB 信息都倒过来了啊,变成 BGRA 了。
那是如果确定每个像素点存的时候存的是 BGRA 的呢?要确定每个像素点的存储格式,需要再运行一段 jni 代码,如下:
int fd, ret; static struct fb_var_screeninfo vinfo; // 打开Framebuffer设备 fd = open("/dev/graphics/fb0", O_RDONLY); if(fd < 0) { LOGD("======Cannot open /dev/graphics/fb0!"); return -1; } // 获取FrameBuffer 的 variable info 可变信息 ret = ioctl(fd, FBIOGET_VSCREENINFO, &vinfo); if(ret < 0 ) { LOGD("======Cannot get variable screen information."); close(fd); return -1; }
这是获取到的是一个叫做 fb_var_screeninfo 的结构体的实例,这个结构体同样定义在 linux/include/linux/fb.h 里头,定义如下:
struct fb_var_screeninfo { __u32 xres; /* visible resolution */ __u32 yres; __u32 xres_virtual; /* virtual resolution */ __u32 yres_virtual; __u32 xoffset; /* offset from virtual to visible */ __u32 yoffset; /* resolution */ __u32 bits_per_pixel; /* guess what */ __u32 grayscale; /* != 0 Graylevels instead of colors */ struct fb_bitfield red; /* bitfield in fb mem if true color, */ struct fb_bitfield green; /* else only length is significant */ struct fb_bitfield blue; struct fb_bitfield transp; /* transparency */ __u32 nonstd; /* != 0 Non standard pixel format */ __u32 activate; /* see FB_ACTIVATE_* */ __u32 height; /* height of picture in mm */ __u32 width; /* width of picture in mm */ __u32 accel_flags; /* (OBSOLETE) see fb_info.flags */ /* Timing: All values in pixclocks, except pixclock (of course) */ __u32 pixclock; /* pixel clock in ps (pico seconds) */ __u32 left_margin; /* time from sync to picture */ __u32 right_margin; /* time from picture to sync */ __u32 upper_margin; /* time from sync to picture */ __u32 lower_margin; __u32 hsync_len; /* length of horizontal sync */ __u32 vsync_len; /* length of vertical sync */ __u32 sync; /* see FB_SYNC_* */ __u32 vmode; /* see FB_VMODE_* */ __u32 rotate; /* angle we rotate counter clockwise */ __u32 reserved[5]; /* Reserved for future compatibility */ };
注意到 这个结构体里面的四个结构体成员了么? red、green、blue 和 transp 这四个成员。它们的类型是 fb_bitfield,这个fb_bitfield 就是用来告诉我们每个像素点的格式的。
fb_bitfield 也是定义在 linux/include/linux/fb.h 里头,定义如下:
struct fb_bitfield { __u32 offset; /* beginning of bitfield */ __u32 length; /* length of bitfield */ __u32 msb_right; /* != 0 : Most significant bit is */ /* right */ };
这个结构体里头:
offset ------ 颜色值的在整个ARGB二进制数据中的偏移量
length ------ 颜色值二进制位数
msb_right ------ 0 代表Big endian
现在我们在刚刚那段获取 fb_var_screeninfo 结构体实例的 jni 代码的末尾,加上这几句打印:
// 下面这一段是每个像素点的格式 LOGD("====== fb_bitfield red.offset : %d", vinfo.red.offset); LOGD("====== fb_bitfield red.length : %d", vinfo.red.length); // 如果 == 0,就是Big endian LOGD("====== fb_bitfield red.msb_right : %d", vinfo.red.msb_right); LOGD("====== fb_bitfield green.offset : %d", vinfo.green.offset); LOGD("====== fb_bitfield green.length : %d", vinfo.green.length); LOGD("====== fb_bitfield green.msb_right : %d", vinfo.green.msb_right); LOGD("====== fb_bitfield blue.offset : %d", vinfo.blue.offset); LOGD("====== fb_bitfield blue.length : %d", vinfo.blue.length); LOGD("====== fb_bitfield blue.msb_right : %d", vinfo.blue.msb_right); LOGD("====== fb_bitfield transp.offset : %d", vinfo.transp.offset); LOGD("====== fb_bitfield transp.length : %d", vinfo.transp.length); LOGD("====== fb_bitfield transp.msb_right : %d", vinfo.transp.msb_right);
看看我的 i9300 的运行结果:
D/termExec(21988): ====== fb_bitfield red.offset : 16 D/termExec(21988): ====== fb_bitfield red.length : 8 D/termExec(21988): ====== fb_bitfield red.msb_right : 0 D/termExec(21988): ====== fb_bitfield green.offset : 8 D/termExec(21988): ====== fb_bitfield green.length : 8 D/termExec(21988): ====== fb_bitfield green.msb_right : 0 D/termExec(21988): ====== fb_bitfield blue.offset : 0 D/termExec(21988): ====== fb_bitfield blue.length : 8 D/termExec(21988): ====== fb_bitfield blue.msb_right : 0 D/termExec(21988): ====== fb_bitfield transp.offset : 24 D/termExec(21988): ====== fb_bitfield transp.length : 8 D/termExec(21988): ====== fb_bitfield transp.msb_right : 0
从打印结果我们可以看到:
1. 每个像素点的单个颜色值占8 bits 也就是一个字节,一个像素是 8 * 4 = 32 bits。
2. blue offset 是0 也就是 Framebuffer里头存的每个像素点的 前8 bits 是蓝色值
3. green offset 是 8 ,8 到 15 bits 是绿色值
4. red offset 是 16 ,16 到 23 bits 是红色值
5. transp offset 是 24,24 到 31 bits 是透明度值
综合上面所述,Framebuffer 中的数据肯定是这样的 :
BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA BGRA ...
啊!Framebuffer 的数据格式现在是搞清楚了,但是当你以为你简简单单的把 每个像素的 BGRA 信息 转换成 ARGB 后,丢给BitmapFactory就能得到屏幕截图了么?
其实还不够。
首先,回头再看看 fb_var_screeninfo 的定义,我们注意到里头有六个这样的成员:
__u32 xres; /* visible resolution */ __u32 yres; __u32 xres_virtual; /* virtual resolution */ __u32 yres_virtual; __u32 xoffset; /* offset from virtual to visible */ __u32 yoffset;
前两个个的的含义如下:
1. xres -------------- 你可以认为这个就是屏幕的宽(单位:像素)
2.yres --------------- 你可以认为这个就是屏幕的高(单位:像素)
前两个很好理解,后面四个就麻烦一点点。稍微查下资料我们就能知道,Android 的 Framebuffer 一般是“双缓冲”的,就是说 Framebuffer里头不止缓存了一个屏幕的像素点数据,而是缓存了两个屏幕的像素点数据。而且两屏数据,是上下摆放的,假设我们的手机屏幕横向有 720 个像素,纵向有 1280 个像素,那 fb0 的实际格式将会是如下所示:
第一列是 fb0 文件的相对地址(十进制表示) 720个像素点 * 每个像素点占用4字节 = 2880 0 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... 2880 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... 2880*2 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... . . 缓冲的第一屏 . 2880*1279 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... 2880*1280 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... 2880*1281 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... 2880*1282 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ... . . 缓冲的第二屏 . 2880*2559 BGRA BGRA BGRA BGRA BGRA BGRA BGRA ...
把这两屏数据当成一副图,那横向像素点个数 就是 xres_virtual,纵向像素点个数就是 yres_virtual。由于Android一般是“双缓冲”,所以下面这个公式对很多手机都应该成立:
xres == xres_virtual yres * 2 == yres_virtual
既然有两屏数据,那哪一屏才是当前的屏幕内容呢?这就是 xoffset 和 yoffset 会告诉你的,我的 i9300 获取到的这样的:
D/termExec(21988): ====== xres : 720 D/termExec(21988): ====== yres : 1280 D/termExec(21988): ====== xres_virtual : 720 D/termExec(21988): ====== yres_virtual : 2560 D/termExec(21988): ====== xoffset : 0 D/termExec(21988): ====== yoffset : 0
所以我的 i9300 的 Framebuffer 的第一屏就是当前屏幕的内容。 假如我的 i9300 yoffset == 1280 的话,那第二屏才是真正屏幕的当前内容。
fb_fix_screeninfo 里头,另外还有一个需要注意的成员是 line_length。其实我们的 Framebuffer 里头保存的一屏数据并不一定刚好就是我们的屏幕分辨率大小,它的横向像素值有可能比屏幕的横向像素值多!假如你发现你截出来的图片屏幕外有黑边,那原因就在这里了。
Framebuffer里头的图像数据的一行,不应该是 屏幕横向分辨率 * 4,而应该是 line_length (它的单位不是像素点,而是字节)
3. 从Framebuffer中获取图像数据
现在我们已经知道了,Framebuffer 中的数据格式,那到底如何中的屏幕图像数据显示在ImageView中呢?
当然,你已经知道了Framebuffer中的数据格式了,你大可以很自信的自己把一屏的数据截取出来,把BGRA转换成ARGB,然后转换成bitmap,然后丢给ImageView显示出来。比如,下面这段代码:
long stat2 = System.currentTimeMillis(); for (int i = 0; i < pixels.length; i+=4) { row = i / line_length; if (row >= h) break; if ((i - row * line_length) >= widthBytes) continue; // fb0里面存储的BGRA中的A都是FF pixels[offset] = (0xFF << 24) | ((Fb0Bytes[i + 2] & 0xFF) << 16) | ((Fb0Bytes[i + 1] & 0xFF) << 8) | (Fb0Bytes[i] & 0xFF); offset++; } Logger.d("Moce time = " + (System.currentTimeMillis() - stat2));
这段代码你可以不用细看,你只要知道我只读取一屏的数据,然后每次读取4bytes,把BGRA转换成了ARGB。但是这段代码的平均执行时间是 250ms 。这实在是太慢了。为了提速,我第一个想到的是改用C语言来写,但是并没有质的提升。最后经过一番搜索,发现了一个很有名的开源库:turbo-jpeg !turbo-jpeg 会调用Arm cpu 的 Neon 协处理器的 SIMD 指令集,效率非常高!
4. 实例截图功能的完整Android demo项目
我上传了一个通过 jni 实现截图的功能完整demo项目到Github了,地址如下:https://github.com/faip520/AndroidFramebufferScreenshot
我简单描述下实现的过程:
1. 打开 /dev/graphics/fb0 设备
2.把 fb0 设备内容中的一屏数据,通过 mmap 映射到自己的内存区
3.通过 turbo-jpeg 的接口,直接读取 fb0 的信息,生成 jpeg 图片数据
4.把得到的 jpeg 图片数据返回到 java 层
5.通过BitmapFactory.decode 方法把 jpeg 图片数据转换成 bm,然后转换成 BitmapDrawable 给 ImageView 显示。
需要说明的是:我这份代码,肯定不是适配所有机型的,你的机型有可能是 “三缓冲”,有可能不是 32位色,而是 RGB565 或者其他格式,xoffset 和 yoffset 的值也有可能
比较特别,甚至有可能 Framebuffer 都不是 fb0 文件。这些情况下,你就要自己去修改我的代码了。 我这里只是介绍一个解决这种问题的分析模型。
5. 黑边问题的处理 (图像裁剪)
其实如果你的截图出来有黑边,或者只想截取其中一部分。可以看看我源码里头的这个地方:
tjCompress2(handle, framebuffer_memory, // 希望生成的jpeg图片的宽 源数据里头屏幕每行的字节数 300, finfo.line_length, // 希望生成的jpeg图片的高 100, TJPF_BGRA, &jpeg_data, &jpegSize, TJSAMP_444, 10, TJFLAG_NOREALLOC);
其中第三个和第五个参数,就是你希望生成的 jpeg 的宽高。比如 100 100,那就是只截取屏幕左上角的 100 * 100 个像素。配置这里就可以去掉黑边,或者图片裁剪。