从surfaceflinger历史变更谈截屏
众所周知，有一个程序screencap可以截屏，这个程序十分简单，只是使用了surfaceflinger服务的截屏功能。
所以要了解截屏，看surfaceflinger服务的代码是不二首选。但是surfaceflinger也随android系统显示子系统的变更而变更，网上最容易搜到的android资料都在11-14年的文章，都是4.x时代甚至2.x时代的技术，而android代代变化，有不少文章已经不再适用。
2.3.6之前，surfaceflinger放于base目录。这时候的surfaceflinger使用FramebufferNativeWindow。
4.0.x开始，suffaceflinger放于native目录。但仍旧使用FramebufferNativeWindow。
4.2 开始，DisplayHardware类废除（注意DisplayHardware目录或者说组件没有废除，因为显示系统变更了，不再只有一个Display，取而代之的是DisplayDevice类，这个类不在与DisplayHardware目录同级。换句话说，以前surfaceflinger拥有一个DisplayHardware，现在开始就拥有一组DisplayDevice，这些DisplayDevice只代表某一GL上下文，并且不直接访问Hardware层的fbDev，fbDev由HWComposer管理，DisplayDevice只能通过FramebufferSurface去访问Hardware层），不再使用FramebufferNativeWindow，替而引入了FramebufferSurface。
4.3 开始，DisplaySurface，VirutalDisplaySurface。并且废除了libgui中的SurfaceTextureClient。
在4.1.x之前，我称为FramebufferNativeWindow时代，surface是直接从FramebufferNativeWindow创建的。
可以看到这是很常规的egl初始化。
在4.2 开始 FramebufferNativeWindow不再使用，因为在以前单一Display的时代，直接将fbDev和ANativeWindow偶合在一起。现在ANativeWindow和fbDev分离开。SurfaceTextureClient替代了FramebufferNativeWindow，并且不与fbDev偶合（，fbDev由HWComposer接管）。这里必须区分好，android显示系统有一个Surface，而egl也有一个EGLSurface，它们的连结点就是ANavtiveWindow，其定义路径在/system/core/include/system/window.h 。
SurfaceTexture之前是直接继承于BnSurfaceTexture，4.2 开始它与BnSurfaceTexture解偶，转而继承ComsumerBase。ComsumerBase拥有的BufferQueue才是继承于BnSurfaceTexture（，定义在/frameworks/native/include/gui/ISurfaceTexture.h）。SurfaceTexture 与 BnSurfaceTexture生产消费者模式，并只作为消费者。
与此同时，在SurfaceTexture.h同一目录添加了Surface（，定义在/frameworks/native/include/gui ，也就是 libgui.so）， 相应地在surfaceflinger目录有另一个对应的FramebufferSurface，是surfaceflinger服务私有的类，它是面向DisplayDevice的，是SurfaceTextureClient与HWComposer的结合点（Framebuffer就是指HWComposer，Surface则是SurfaceTextureClient一侧，以及用于它的ConsumerBase）。这里要注意，Surface继承于（，isa）ANativeWindow，而FramebufferSurface却继承于（，isa）ConsumerBase。SurfaceTextureClient 作为ANativeWindow 依赖 ISurfaceTexture 服务器，去实现 ANativeWindow的hook接口queueBuffer以及dequeueBuffer。
下面是surfaceflinger初始化DisplayDevice数组：
以及DisplayDevice初始化：
每个DisplayDevice使用SurfaceTextureClient这个ANativeWIndow去创建EGLSurface，而且这里的SurfaceTextureClient使用的是FramebufferSurface的BufferQueue。
在 FramebufferNativeWindow时代，截屏直接使用FBO（，Frame Buffer Object）。
然后每一个layer都绘制一次到framebuffer：
最后GL读出像素：
在4.2开始，发生这些变化，首先实现的函数参数变化了
可以看到display不再以整型来作为标识，而是通过binder来标识。回看上面surfaceflinger在初始化DisplayDevice过程，只是简单地 new BBinder() 来作为一个新的DisplayDevice的token，这个token只在binder驱动设备上建立了一个唯一的路径，作用就是用来系统范围内唯一标识。
所以在4.1.x及以前，screencap的代码是：
从4.2开始，screencap的代码是：
虽然上面说了一大堆的4.2变化，但是在截屏实现没有变化，然而接下来的4.3就完全变化了。
4.2，Surface继承于SurfaceTextureClient，但是4.3后，Surface脱离SurfaceTextureClient继承树，实现成另一个ANativeWindow，依赖 producer。记得上面吗，4.2时，SurfaceTextureClient是一个依赖 FramebufferSurface这个consumer的ANativeWinodw。
下面是surfaceflinger对DisplayDevice的初始化：
跟着是DisplayDevice的初始化：
我们来回顾一下，4.1.x以前使用FramebufferNativeWindow来创建EGLSurface，4.2时候使用SurfaceTextureClient（它使用FramebufferSurface），4.3开始，使用Surface。FramebufferNativeWindow， SurfaceTextureClient， Surface都是ANativeWindow。
4.3开始Surface也另外继承DisplaySurface。（...有时间再补充写）。
最重要是captureScreen接口改了
实现上也就使用了BufferQueue，而不是IMemory来接收数据。
最最重要是没有放出screencap的最新代码，只停留在4.2时候的版本，也就是你不可能通过参照screencap.cpp去使用这个功能 。
可参考Transaction_test.cpp
这里勘误一下，screencap的代码路径在 /frameworks/base/cmds/screencap 目录下，虽然这份代码使用的是ScreenshotClient::update，但是其实质还是在使用ISurfaceComposer::captureScreen，然后使用CpuConsumer去lockNextBuffer（，原理就是SurfaceFlinger作为生产者从BufferQueue填充了一帧Buffer，我们用消费者去访问BufferQueue的帧Buffer），以上面Transaction_test.cpp为例过程是一样的。
我们可以直接将这两份代码搬到native项目去尝试一下，当然是在解决了权限和selinux的环境下。不要高兴得太早，ScreenshotClient::update总是返回-22(BAD_VALUE）。而用Transaction_test.cpp的例子代码，则可以清楚SurfaceFlinger服务执行captureScreen没有报错，却是CpuConsumer::lockNextBuffer返回了-22。
现在我们以4.3(分水岭)后的6.0.1系统为例。CpuConsumer执行在本进程，是libgui.so的一部分，可以反汇编结合源代码去跟踪调试。
下面是CpuConsumer::lockNextBuffer的反汇编：
<+68>调用了pthread_mutex_lock，<+84>调用了一个函数，然后<+88>将结果与0比较，<+90>将结果与2比较。
这可以分析对应的源代码
执行的结果是从<+90>跳到了<+574>
也就是说代码从acquireBufferLocked返回结果是NO_BUFFER_AVAIABLE，接着就是退出调用，先将AutoLock析构。
?! captureScreen返回0真的就意味成功了，不是的，logcat日志上报错了，这真让人郁闷一阵子为何不返回直接错误呢。
看到这uid就知道我是在app进程中使用SurfaceFlinger服务，虽然我将selinux设置可访问SurfaceFlinger的binder，并且访问FrameBuffer设备的进程是SurfaceFlinger，但还是逃不出权限的检测，因为作为binder的client同时表明了自己的进程id。
这里就只能去破解（，修改二进制文件分支跳转指令）surfaceflinger。
从整个过程来看，截屏最终还是在访问FrameBuffer设备，并且对它封锁得更严。即使你是超级用户也不可能对FrameBuffer进行读操作。必须经由SurfaceFlinger服务接受有权限的进程的请求，才可以让SurfaceFlinger服务去访问FrameBuffer设备。这样一来，使用ffmpeg通过输入/dev/fb0的录屏方法也就给抹杀了。当然了，所有帧在递交到SurfaceFlinger之前，也就获取当前Window（当前Activity也就对应Window），自己将所有的buffer进行合成render也达到截屏的效果。这一思路分支没有去研究，因为获取当前活动Activity的api早就被禁用了，要么你就只能截自己应用的屏。
下面我们来看Screenshot::getPixels返回的是什么，当然环境是root权限进程，代码是screencap片段。用gdb远程调试：
返回了像素空间地址在 0xf5ccf000，我们来看这地内存的映射：
（暂时不清楚是什么设备的，dma也就是直接内存访问相关，以后再补充，这块内存存在在某个匿名inode）
（暂时不清楚为什么访问不了）
上面不能访问，只限于gdb调试，程序里面是可以访问的。
我们来看两组数据，第一组数据是两部低端机启用screencap进程截屏的性能： （测试项目分别写/dev/null，共享内存，以及sdcard）
手机A
手机B
再来第二组数据，同样是上面两部低端手机，测试项目为ScreenshotClient，以及SurfaceComposerClient，CpuConsumer截屏后写堆内存。
手机A
手机B
这里说明一下，手机A屏是800M像，手机B屏是300M像，8核。
从上面的数据看，进程创建和切换消耗很大。截屏服务实际消耗在0.02到0.04秒之间，但是spawn进程损耗就增加到100ms~200ms上下。手机B的图形处理能力低于手机A，手机B的sdcard好于手机A的sdcard，但内存访问则是手机A更优，多进程却是手机B损耗更高。
下面是SurfaceComposerClient：：captureScreen，然后CpuConsumer：：lockNextBuffer，其实就是ScreenshotClient：：update的步骤展开。
这里要提一下BufferQueue的生产者-消费者模式，IGraphicsBufferProducer生产者接口，IGraphicsBufferConsumer消费者接口。生产者-(enqueue)->BufferQueue-(dequeu)->消费者，一般来说是这样的，但是它的接口有些特别，生产者同时有接口方法enqueueBuffer和dequeueBuffer，还有一个requestBuffer。如果不仔细参考一下头文件的注释，就会被搞头晕。dequeueBuffer是生产者从BufferQueue取出一块空闲Buffer，然后操作这块空闲Buffer，enqueueBuffer则是入队让消费者可见。而消费者读消费队列的接口方法不是dequeue而是acquireBuffer。
下是一帧 Buffer 的流向图。
生产者 <-(dequeueBuffer)- BufferQueue
生产者在buffer上进行读写操作
生产者 -(enqueueBuffer)-> BufferQueue -(acquireBuffer)-> 消费者
20180309 补充：
这里的buffer，并非大小为 width * height * bytesPerPixel， 而是 stride * height * bytesPerPixel 且 stride >= width。在做处理时扫描行就要注意了。
下面是SuffaceFlinger服务处理captureScreen过程，必然进行BufferQueue的连接。
只要 native_window_api_connect 不返回 NO_ERROR，都不会执行并且返回 BAD_VALUE，所有原因都被这个值抹去，无从分析。
native_window_api_connect函数的作用是将producer与native_window连接起来。
这里的native_window是SurfaceFlinger进程在执行函数时创建的Surface（从4.3之后继承于ANativeWindow）。
