learnframework的博客

可以采用Windowless图层，让Windowless图层需要挂载在Task的父亲，而不是Task哈，因为Task本身被设置了WindowCrop，会裁剪掉面积大小，导致显示异常，所以这里要挂载到Task的显示区域大的父亲上。然后在GPU绘制时候，可以考虑使用skia绘制一个阴影图层，这个在SurfaceFlinger中gpu合成绘制时候是可以使用skia相关的api绘制阴影，具体skia代码如何绘制实现可以参考原来。2、阴影View正常要比Task区域显示要大一些，这样才可以有外阴影的效果。

因为Winscope是一个动态的过程，属于数据是不断变化的而上面只是开始抓取时候有往mBuffer中添加，那么是什么地方可以触发这个WindowTracing源源不断的打入log，即添加到mBuffer中？可以看出来这里会有一个很重要的 mRoot.dumpDebug，mRoot就是RootWindowContainer，它会迭代dump出来整个wms层级结构的所有数据的详细信息，这样也是浏览器上可以绘制层级结构详细信息的关键。然后主要看看WindowManagerShellCommand的相关的方法。

首先这个service call就是直接调用到SurfaceFlinger这个service的onTransact方法，1041代表是code，i32代表是data的int类型，1和0代表就是值。那么选着Transaction选项后抓取Winscope，看看winscope_proxy.py程序的相关输出，看看有没有线索可以查到是如何获取系统的相关Transaction数据。在使用Winscope过程经常会有如下的一些选项供我们进行选择，不同的选项最后就会展示不同的数据项出来。具体这些数据是哪里来的呢？

时候，有给大家讲解过一个实战项目是针对某个app进行单图层进行截图方案，是不是和这个很类似，大家可以考虑一下是否可以进行简单的修改就可以实现对这个单app录屏功能。新版本的单独app进行录制视频功能的交互大概就是上面的，整个过程就是让用户可以选择一个app，然后启动这个app到前台，在进行单独录屏处理。这里针对aosp上实现单app录屏的进行一些代码的剖析，本篇不进行详细的源码分析，主要把核心原理给大家讲解清楚。如果针对单app进行录屏的功能要我们完全自己实现会如何实现呢？大家是否有相关的方案呢？

近期有学员朋友求助一个给安卓设备的左右两边要加入侧边栏的需求，这个需求其实还和平时的系统自带的Navigationbar，或者StatusBar等窗口不一样。因为无论是Navigationbar，或者StatusBar都是属于和手机屏幕画面是一起的，而这个左右侧边栏的需求是想把主屏幕画面和侧边栏画面是独立的，二者互不干扰的情况。3、侧边栏的画面不会因为正常手机画面的页面跳转而被覆盖，侧边栏点击相关按钮可以让正常手机画面有页面跳转等操作交互。1、input相关的触摸知识部分。2、wms相关的知识。

针对这个问题，其实就是说window结构树顺序依赖关系和sf的Layer结构树依赖关系居然不同，大家也知道正常情况下肯定要一模一样，因为Layer虽然可以新加入，但是不能说原来的window对应的Layer结构树顺序都乱了，这样可能会造成显示类的bug。基于上面这个2个面试题，其实本质上是对wms还有surfaceflinger相关知识的深入考察，而且问题属于难度等级层次分明，慢慢变大的情况，所以要完全可以拿捏对这问题，基本上wms部分的知识考察就可以得到面试官的高度认可打高分。

但是近来有学员提到一个疑问，那就是如果是存在多屏的情况下，而且多屏都在刷新的情况下，那么帧率显示起来就比较乱，因为原来方案基本上都是有layer显示就会累计，根本不管到底是哪个屏幕的。在SurfaceFlinger课程专题有做了一个帧率显示的工具，大部分在当时的代码大部分在SurfaceFlinger层面实现的。4、在computFps时候，针对拿layer的dispkayID和prop获取的displayID进行比较，相等则可以统计。1、针对layer需要获取每个layer的对应的displayID。

一些vip学员朋友也纷纷求助马哥的实现patch代码，想用于公司的实战项目实现。但是在公司需求实现要求和马哥这边的实现还是会有一些需求上的变更和设备环境差异，所以使用过程中学员朋友们也提出了一些额外的问题。这个问题其实在马哥自己设备上从来没有发现过，但是有的vip学员朋友和我反馈有这种黑屏不显示情况，针对这个问题第一时间进行了分析，主要通过提供的dumpsys SurfaceFlinger来查看。2、因为上下结构已经实现，如果左右结构，针对触摸部分，如果左右结构需要更改触摸区域的宽度变宽。

这个项目我说过不给提供答案哈，让各位学员朋友自己独立思考完成哈，因为尽量想让大家慢慢的要脱离每次可以抄袭马哥课程作业的习惯，这样才可以在以后framework工作中独立自主完成。上面就我们学员的成果和代码，让其他学员可以参考评估，在这基础上做出更好的相框手机和电视。明显在分屏情况等情况下会有画面显示异常，和正常屏幕显示画面有残缺部分。基本上看效果看着有相框的感觉了，功能应该算实现了80%本文章更多详细代码和资料

到这里就完美解释清楚了ActivityRecordInputSink巨大区域是哪里来的，本质还是因为replaceTouchableRegionWithCrop设置成了true

这里面主屏幕的Layer都会在虚拟屏幕有一个对应的Mirror Layer即直接对主屏幕的每一个layer进行了Mirror

VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR设置1、会在DisplayContent的mApplySurfaceChangesTransaction中对Display是否有内容进行确定2、一旦涉及了Display的上有内容到无内容的变化会调用setDisplayLayerStack来重新设置layerStack3、在sf中layer会对layerStack进行匹配然后决定显示哪个Display本文章更多详细代码和资料需要购买课程获取。

所以这里其实就是最核心的transform，有了它就可以把自定义的屏幕size和屏幕本身size进行统一，让1440x2960大小屏幕可以显示1080x1920屏幕大小内容。从上面一系列的dumpsys可以得出结论，一旦wm size成了新的屏幕size后，整个系统的大小确实变化了，连displayContent也是变化的。明显看到差异就是屏幕上下有黑边了，那么下面就来调研这个wm size是怎么做的的display大小修改的。

前面文章和视频课程都是直接从SurfaceFlinger层面开始讲解Vsync部分的，当然vsync的主要核心逻辑也确实在SurfaceFlinger，但是一般vsync都是由app层面发起请求的，这一部分也还是有必要带大家了解清楚。createDisplayEventConnection方法,这个方法app发起跨进程调用后会到服务端BnSurfaceComposer，这个SurfaceFlinger是继承这个BnSurfaceComposer的。

1、利用FrameTimeLine来获取实时fps的数据2、直接使用SurfaceFlinger中的RefreshRateOverlay这个图层类来负责显示这个实时fps数据

学员朋友们拿到后也进行了认真的实战开发，而且针对马哥提供方案也做了一些改进，下面就分享一下两个学员朋友等改进建议。

是不是可以认为这里RefBase在incStrong of后面打印的this肯定和上面的LayerHandle打印的this一样？

dumpsys input可以看到一个ActivityRecordInputSink在Activity的下面

到这里，就把学员提出的录屏时候Mirror问题前后版本出现与不出现的原因搞清楚了，整体其实探索出来了结果后并不是很复杂，但是如果要自己去探索还是有一定的难度的。虽然有难度，马哥还是希望大家平时遇到相关的技术疑问时候不要轻易放弃或者完全不管，应该努力用自己学习知识应用起来，结合起来，去分析实际开发中遇到一些问题。只有这样不断探索，技术才会不断成长，成长到有一天你发现你对这个模块理解深入程度基本上也不输给任何人的时候，你就是这方面的顶级专家。本文章更多详细代码和资料需要购买课程获取。

今天来给大家分享一下如何实现单独获取某个Layer的图片，而不是整个屏幕的图片。

截图分享可以选定某个特定窗口进行，这个和上面的录屏其实基本上类似一个场景，就是截图时候有会存在只需要截图固定窗口window的，不需要其他window的情况，同样游戏主播进行直播这个情况，截图时候希望只有游戏画面就可以，游戏画面上面的其他app的窗口不希望在截图中。经常分析一些显示问题时候，会想要dumpsys各个图层，但是dumpsys SurfaceFlinger命令一般来说只是有相关的图层信息，是文本类的信息，所以有时候黑屏或者显示 异常情况就比较难看出来是不是自己图层本身上帧有问题。

function是一个通用的函数对象容器，可以存储任意可调用对象（函数、函数指针、成员函数、成员变量、lambda表达式，任何function对象，比如一个类，定义了operator()），并提供了一致的接口来调用这些对象。通过function，可以将一个函数或函数对象作为参数传递给其他函数或存储在容器中，大大提高了灵活性。参数解释：Ret:代表调用function的返回结果的类型Args：代表是参数的类型。demo展示：1、function存储函数指针方式return a*2;

1、使用vi、gedit等代码编辑工具进行编辑，然后使用命令gcc或者Makefile等进行编译，即编写代码和编译是分开的，一般编写代码也没啥代码错误提示等，只有命令编译时候才可以发现错误，这种方式相对来说适合少量修改代码，不适合大量写代码的情况。aosp相关native模块，比如input，SurfaceFlinger等，经常阅读会遇到一些陌生库函数或者类，可能这个时候想要查询这个库函数相关的详情进行学习，类似课程讲解linux库函数有个man手册一样东西。选着第一个GDB既可以，选着后又弹出如下。

std::promise用来包装一个值将数据和future绑定起来，为获取线程函数中的某个值提供便利，取值是间接通过promise内部提供的future来获取的，也就是说promise的层次比future高。这个问题回答其实可以考虑一下future的获取，future都是需要几个固定的异步线程调用方式，比如async这种，但是很多时候不喜欢用这种异步方式，那么自然也就没办法获取future，所以为了future的获取更加灵活方便，就需要有这个promise对象。

在多屏互动时候有一个屏幕的画面是一个MirrorLayer，另一个屏幕画面是真实的，即2个屏幕上有一个是MirrorLayer，这个时候疑问就来了，经过在aosp13上体验发现，两个屏幕画面都可以正常接受触摸事件进行正常的事件响应。到这里就可以理解为啥两个屏幕各自的mirrorlayer和正常layer都可以正常接受触摸事件的原因，因为在input派发选择窗口，遍历window时候，都对应是同一个windowinfo。这里的inputInfo就是最为关键的信息，也就是最后传递给input端的关键点。

大家好！因为前面一直忙于讲解surfaceflinger层面到的原理和源码分析部分，一直没有一个系统的项目来给大家练手实现，今天来实现一个sf层面的一个小项目。具体项目背景信息如下

hal/surfaceflinger/perfetto专题，马哥经过若干天的努力，终于把sf最重要合成部分搞定

看到了finalizePendingOutputLayers明显好像没啥啊，没看到有调用destroyLayer啊，但是Trace中确实有展示对应destroyLayer，这个是为啥？赋值时候就会导致mCurrentOutputLayersOrderedByZ析构，从而一系列的析构方法回调。执行collectVisibleLayers时候具体还会触发destroyLayer操作，还是个跨进程的。明显属于在finalizePendingOutputLayers触发的调用。堆栈打印出来就很明显啦，那就是在。

hi，粉丝朋友们：大家好！本节我们来讲解一下SurfaceFlinger主要合成工作的第一个阶段任务commit一般SurfaceFlinger端的合成工作主要有两个1.commit主要就是处理app端发起的一系列transaction的事务请求，需要对这些请求进行识别是否当前帧处理，处理过程就是把事务中的属性取出，然后更新到Layer中，偶buffer更新的还需要进行相关的latchbuffer操作。

进行queue动作完成后，紧接着就是runInSync执行，这个方法参数非常关键，代表是一个同步事务等待同步后进行回调执行的部分，而且这个时候会有一个Transaction的参数，里面就包含了相关WindowContainer的绘制相关事务。注意对于prepareSync属于WindowContainer的基类方法，Task没有实现那就是默认WindowContainer实现的，所以一直会调用到有自己实现的WindowState的。

updateActiveBuffer方法会对mPreviousReleaseCallbackId这个变量进行赋值，大家注意这里的为啥叫做前一帧的CallbackId，因为下面这个updateActiveBuffer就是赋值是先进行的mPreviousReleaseCallbackId赋值，然后才进行的新buffer的赋值，所以这个mPreviousReleaseCallbackId其实上一个的buffer的Id，不是当前这次的。这里的mPreviousReleaseCallbackId是哪里来的呢？

比如surfaceflingre模块深入分析需要用到hal相关的模块，比如mapper，hwc等，所以说去分析surfaceflinger就必须要有一定hal基础比较好，还有就是perfetto,大家可能会以为他只是个性能优化工具。核心思路就是讲解清楚perfetto相关的基础知识，学会怎么看perfetto的trace，及怎么自己加和打印tag和trace等，有了这些知识后再会结合相关的业务来练习怎么看perfetto，比如surfaceflinger就是一个学习实战看perfetto的很好案例。

layer_state_t结构体用来代表Layer图层的的相关信息，SurfaceControl与sf的Layer共用这个layer_state_t结构体，layer_state_t包括layer所有属性主要成员如下：可以看到常见的主要属性：坐标，长宽，变换矩阵，变化值what，flags，mask等，一般是一个图层就有一个layer_state_t结构体。

其实Client本质是一个Binder对象的BpBinder即跨进程的代理，远端的BnBinder在SurfaceFlinger的Client.cpp。看下SurfaceComposerClient构造时候会与sf进行跨进程createConnection创建链接，返回的对象就是Client对象。SurfaceComposerClient对象是在哪里创建的呢?这里的SurfaceSession是在哪里创建的呢？sf端就是简单创建了一个Client对象，这里来看看。这里的mClient是谁呢？

hi，粉丝朋友们：本节将使用perfetto的trace来巩固Vsync的源码分析的部分的流程。具体抓取trace方法及相关操作建议：a.抓取trace期间需要主要不能让画面一直刷新，因为这样一直刷新不方便看vsync的结束和开始b.建议选着桌面，滑动桌面一下后停止1左右，再继续滑动，尽量让抓取的trace可以有如下图的间隔效果c.需要在surfaceflinger中额外补充自己加的一些ATRACE代码方便追踪流程。

上面代码有注释，大家是不是看到熟悉的poll，是不是学了马哥跨进程专题后，这个都不是事分分钟可以看的懂这个逻辑，核心的就是观察相关的vsync的fd，有数据变化了，读取，属于vsync了就触发相关的，vsync回调，这个就是hal的vsync回调。学过或者你看过surfaceflinger相关文章同学都知道，vsync其实都是由surfaceflinger软件层面进行模拟的，但是软件模拟有可能会有误差或偏差，这个时候就需要有个硬件vsync帮忙校准。但是问题又来了，请问是谁触发了这个fd有数据的啊？

所以说mValue = (mValue + 1) % 2的这个赋值操作就是打印trace了，也就是说系统执行到了 DispSyncSource::onVsyncCallback就代表有vsync到来，上升和下降那种理论就说的过去了，因为上升下降代表mValue确实有变化了。那么结合我们上面的代码结论我们知道，第一次有value的trace打印了，说明肯定是有vsync的回调了，至于之前脉冲图没有打印，那一般是因为抓取时候就没有触发这个onVsyncCallback回调，所以自然不会打印出来啦。

简单说就是吧以前的sf的EventTread功能中，自己唤醒触发vsync的部分移除EventTread，让VSyncDispatch直接进行（后面有机会讲解vsync再深入分析），不在使用EventThread来搞对于的sf的vsync了。sf这个，也就是app端可以指定vsync是跟随surfaceflinger的合成vsync的，所以这里也就是被叫做Choreographer clients ，这里大家就可以理解了吧，具体有没有谁使用呢？以前不是说了只是来产生sf的vsync么？

正因为有了系统中各个地方埋下的这些tag，才让我们可以根据这些方法tag分析出整个系统的运行情况。但是大家有没有想过，请问这些tag是怎么打上去的？如果我们自己要打印自己方法的tag应该怎么搞？

主要就是以上几个，虽然场景不一样，但是他们最后调用的截图接口其实都是同一个，都是最后会调用到surfaceflinger中的截图方法，下面就以adb shell命令行方式screencap案例分析,因为他的接口调用最为简单，这次分析方式主要是使用perfetto的trace分析方式。截图是一种开发过程中经常遇到的功能，但是这个功能底层是怎么实现的？这里显示发起了一个跨进程调用，目标段是surfaceflinger进程。2、主导surfaceflinger需要相关的layer预处理。