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;
-
-
-
- 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;
- }
-
-
-
- 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];
- unsigned long smem_start;
-
- __u32 smem_len;
- __u32 type;
- __u32 type_aux;
- __u32 visual;
- __u16 xpanstep;
- __u16 ypanstep;
- __u16 ywrapstep;
- __u32 line_length;
- unsigned long mmio_start;
-
- __u32 mmio_len;
- __u32 accel;
-
- __u16 reserved[3];
- };
里面有一个 __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);
运行下,会看到我的三星 i9300 运行的结果是:
- D/termExec(21787): ====== type : 0
其实,大多数 Android 设备的 fb0 都应该是 type == 0 的,type 为0 意思说 Framebuffer 里头存的是每个像素点的 ARGB 信息。
但是既然存的是每个像素点的 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;
-
-
- fd = open("/dev/graphics/fb0", O_RDONLY);
-
- if(fd < 0)
- {
- LOGD("======Cannot open /dev/graphics/fb0!");
- return -1;
- }
-
-
- 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;
- __u32 yres;
- __u32 xres_virtual;
- __u32 yres_virtual;
- __u32 xoffset;
- __u32 yoffset;
-
- __u32 bits_per_pixel;
- __u32 grayscale;
-
- struct fb_bitfield red;
- struct fb_bitfield green;
- struct fb_bitfield blue;
- struct fb_bitfield transp;
-
- __u32 nonstd;
-
- __u32 activate;
-
- __u32 height;
- __u32 width;
-
- __u32 accel_flags;
-
-
- __u32 pixclock;
- __u32 left_margin;
- __u32 right_margin;
- __u32 upper_margin;
- __u32 lower_margin;
- __u32 hsync_len;
- __u32 vsync_len;
- __u32 sync;
- __u32 vmode;
- __u32 rotate;
- __u32 reserved[5];
- };
注意到 这个结构体里面的四个结构体成员了么? red、green、blue 和 transp 这四个成员。它们的类型是 fb_bitfield,这个fb_bitfield 就是用来告诉我们每个像素点的格式的。
fb_bitfield 也是定义在 linux/include/linux/fb.h 里头,定义如下:
- struct fb_bitfield {
- __u32 offset;
- __u32 length;
- __u32 msb_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);
-
- 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;
- __u32 yres;
- __u32 xres_virtual;
- __u32 yres_virtual;
- __u32 xoffset;
- __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;
-
- 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,
-
- 300, finfo.line_length,
-
- 100, TJPF_BGRA,
- &jpeg_data, &jpegSize,
- TJSAMP_444, 10,
- TJFLAG_NOREALLOC);
其中第三个和第五个参数,就是你希望生成的 jpeg 的宽高。比如 100 100,那就是只截取屏幕左上角的 100 * 100 个像素。配置这里就可以去掉黑边,或者图片裁剪。
转自:http://blog.csdn.net/a1w0n/article/details/37727971