欢迎来到皮皮网网首页

【源码哥 后门】【源码加网络验证】【绝对底源码公式】节点测试源码_节点测试是什么意思

来源:c语言sprintf源码 时间:2024-11-25 10:12:21

1.go test 测试代码
2.element-plus源码学习日志-03
3.UGUI源码阅读之Mask
4.深入理解 Lustre 系列二:测试
5.UE4-Slate源码学习(六)slate渲染Part2-Paint控件绘制
6.vue/compiler-dom源码分析学习--day4: 字符串化hoist节点

节点测试源码_节点测试是节点节点什么意思

go test 测试代码

       在开发过程中,确保代码的测试测试稳定性和性能至关重要。Go语言提供了内置的源码testing包,用于执行单元测试和性能测试,什意思通过命令go test实现。节点节点这个命令会自动扫描源码目录下名为*_test.go的测试测试源码哥 后门文件,生成测试可执行文件,源码并输出测试结果。什意思

       无需额外参数时,节点节点go test会遍历整个包下的测试测试测试文件。但你也可以通过查阅go help testflag了解更多参数选项。源码例如,什意思编写测试用例时,节点节点如对NewTestFlightItem函数的测试测试测试,可在CIHFeedback.go同目录下创建CIHFeedback_test.go,源码并执行go test。

       性能测试同样重要,可以通过在测试文件中添加BenchmarkNewTestflight()和BenchmarkNewTestflightTimeConsuming()函数来实现。执行压力测试时,使用go test -test.bench=".*"命令,如测试结果耗时,可能表明涉及数据库操作,需关注性能优化。

       查看性能表现,可以使用go tool pprof命令,如cpu.profile,通过topN命令分析profile文件,查看函数调用时间和占比。同时,可以借助graphviz生成函数调用关系图,以图形化方式理解代码执行情况。

       go test还提供了cover工具来检查测试覆盖率,通过-go test -coverprofile=cover.out运行测试并统计,使用go tool cover -func=cover.out分析未覆盖的代码部分。因此,在开发过程中,养成编写全面单元测试的习惯是必不可少的。

       通过上述步骤,Go语言的源码加网络验证testing包为代码测试提供了全面的支持,有助于确保代码的健壮性和性能。

element-plus源码学习日志-

       每日学习进阶,承上启下

       昨日探讨了input组件的使用及编码准则,今日深入剖析element-plus源码,探索新知识。

       文件定位至element-plus\packages\dialog\src\index.vue

       先看模板代码片段,引入了teleport组件,这是新增的内置组件。

       没有使用teleport时,元素作为app组件的子节点;而使用teleport后,元素变为app组件的同级节点,统一挂载于body下,to属性可指定具体id的DOM节点。

       前端展示层级对最终显示结果影响重大。在Vue 2时代,使用Vue.extend创建新实例,挂载于app同级节点,解决全局弹层的层级问题。新自定义组件简化了开发流程,优化代码。

       引入了Vue 3自定义指令,与之前版本有所调整,需进一步学习。

       注意到Vue 3支持fragments,组件不再受限于单一节点,引入新问题,需深入研究官方文档,理解其用法。

       JS代码段回顾了之前讨论过的基础知识,简要审视,复习要点。

       今日总结:学习了Vue的新内置组件teleport,具备将包含的节点挂载至指定DOM节点的功能。并了解了新版本自定义指令的调整。

       下一步规划:基于Jest为组件编写单元测试,学习Jest的基本用法、报告生成等操作,深入框架测试领域。绝对底源码公式

UGUI源码阅读之Mask

       Mask主要基于模版测试来进行裁剪,因此先来了解一下unity中的模版测试。

       Unity Shader中的模版测试配置代码大致如上

       模版测试的伪代码大概如上

       传统的渲染管线中,模版测试和深度测试一般发生在片元着色器(Fragment Shader)之后,但是现在又出现了Early Fragment Test,可以在片元着色器之前进行。

       Mask直接继承了UIBehaviour类,同时继承了ICanvasRaycastFilter和IMaterialModifier接口。

       Mask主要通过GetModifiedMaterial修改graphic的Material。大致流程:

       1.获取当前Mask的层stencilDepth

       2.StencilMaterial.Add修改baseMaterial的模板测试相关配置,并将其缓存

       3.StencilMaterial.Add设置一个unmaskMaterial,用于最后将模板值还原

       MaskableGraphic通过MaskUtilities.GetStencilDepth计算父节点的Mask层数,然后StencilMaterial.Add修改模板测试的配置。

       通过Frame Debugger看看具体每个batch都做了什么。先看第一个,是Mask1的m_MaskMaterial,关注Stencil相关的数值,白色圆内的stencil buffer的值设置为1

       这个是Mask2的m_MaskMaterial,根据stencil的计算公式,Ref & ReadMask=1,Comp=Equal,只有stencil buffer & ReadMask=1的像素可以通过模板测试,即第一个白色圆内的像素,然后Pass=Replace,会将通过的像素写入模板值(Ref & WriteMask=3),即两圆相交部分模板值为3

       这个是RawImage的Material,只有模板值等于3的像素可以通过模板测试,所以只有两个圆相交的部分可以写入buffer,其他部分舍弃,通过或者失败都不改变模板值

       这是Mask2的unmaskMaterial,将两个圆相交部分的模板值设置为1,也就是还原Mask2之前的stencil buffer

       这是Mask1的unmaskMaterial,将第一个圆内的模板值设置为0,还有成最初的stencil buffer

       可以看到Mask会产生比较严重的overdraw。

       2.drawcall和合批

       每添加一个mask,一般会增加2个drawcall(加上mask会阻断mask外和mask内的合批造成的额外drawcall),一个用于设置遮罩用的stencil buffer,一个用于还原stencil buffer。视频app源码购买

       如图,同一个Mask下放置两个使用相同的RawImage,通过Profiler可以看到两个RawImage可以进行合批

       如图,两个RawImage使用相同的,它们处于不同的Mask之下,但是只要m_StencilValue相等,两个RawImage还是可以进行合批。同时可以看到Mask1和Mask1 (1),Mask2和Mask2 (1)也进行了合批,说明stencilDepth相等的Mask符合合批规则也可以进行合批。

       StencilMaterial.Add会将修改后的材质球缓存在m_List中,因此调用StencilMaterial.Add在相同参数情况下将获得同一个材质球。

深入理解 Lustre 系列二:测试

       Lustre 测试框架

       Lustre 的功能和性能测试通过一套完整的测试集进行,即Lustre测试套件集(LTS)。LTS由超过个测试组成,涵盖了从bash脚本、C程序到外部应用的多种测试类型。LTS提供了自动化执行测试流程的工具,允许用户选择性地执行测试或分组执行,同时支持对特定配置、特性如ldiskfs、ZFS、DNE、HSM的验证。LTS测试代码位于源码树的/lustre/tests目录下,主要组件见下表。

       Lustre测试术语

       LTS包括被集成到lustre-tests-*.rpm和lustre-io-kit-*.rpm中的所有脚本和应用。在目录/usr/lib/lustre/tests下的一个集合称为测试套件,如sanity.sh。独立测试,如large-lun.sh中的test 4,属于特定的测试套件。测试套件可以组合执行,例如回归测试。LTS包括回归测试、特定特性的测试、配置验证、恢复测试和错误测试。抽奖源码下载地址下表列出了一些活跃的单元、特性和回归测试及其简要描述。

       Lustre代码测试

       在Lustre编码时,推荐在开发周期早期进行持续的测试。开发者在提交代码前,应确保通过小型验收测试(acceptance-small)套件。若引入新测试用例,先查找并重现bug,修复后验证代码。新测试用例若未覆盖新bug,则需专门添加,用于测试该bug。

       错误规避

       在测试时,若执行失败是由于与bug无关的问题,且问题已被修复,可通过配置规避选项参数。例如,规避sanity.sh中的“g”和“”子测试,或所有insanity.sh测试,设置环境变量即可。在运行acceptance-small测试时,也可使用命令规避测试。

       Lustre测试框架选项

       下面的例子展示了运行完整acceptance-small测试或其子测试的方法。Lustre测试脚本可方便灵活地添加新的测试用例。

       Lustre小型验收测试

       小型验收测试(acceptance small,acc-sm)是Lustre在开发早期阶段捕获bug的测试。acc-sm测试脚本位于目录/lustre/tests中,包括三个分支:b1_6( tests)、b1_8_gate( tests)和HEAD( tests)。下表列出了一些通用acc-sm测试。在acceptance-small.sh和每个测试脚本中定义了执行命令。

       Lustre测试中的环境变量

       本节介绍用于测试的环境变量,通常在/lustre/tests/cfg/$NAME.sh配置脚本中定义。通过NAME=name访问环境变量。默认单节点测试配置是NAME=local,在/lustre/tests/cfg/local.sh中访问。下表列出了一些重要环境变量及其用途。

UE4-Slate源码学习(六)slate渲染Part2-Paint控件绘制

       上一篇文章介绍了绘制一个SWindow的初期步骤,即计算整个UI树的控件大小,为绘制做准备。文章随后深入探讨了绘制流程的第二步,即执行FSlateApplication::PrivateDrawWindows()后,开始调用SWidget::Paint()函数,每个控件随后实现其虚函数OnPaint()。

       在这一过程中,绘制参数被封装在FPaintArgs中,作为Paint和OnPaint过程中的关键引用参数。FSlateRHIRenderer与FSlateDrawBuffer是继承自FSlateRenderer的类,作为FSlateApplicationBase的全局变量,在构造时创建。在绘制过程中,通过GetDrawBuffer()函数可获取到FSlateDrawBuffer对象。

       FSlateDrawBuffer实现了Slate的绘制缓冲区,内部封装了FSlateWindowElementList数组,用于存储多个SWindow下的绘制元素列表。每个SWindow通过AddWindowElementList()返回一个元素列表。

       FSlateWindowElementList负载了SWindow内的所有图元信息,内部封装了FSlateDrawElement的数组,包含Cached和Uncached元素,以及SWindow的指针和用于渲染的批处理数据FSlateBatchData。

       FSlateDrawElement是构建Slate渲染界面的基本块,封装了UI树节点控件需要渲染的相关信息,如渲染变换、位置、大小、层级ID、绘制效果等,以及后续渲染阶段需要的相关数据。

       在Paint流程中,处理当前传入的SWindow和ChildWindows,首先判断窗口是否可见和是否最小化,然后从参数封装的OutDrawBuffer中获取WindowElementList。调用SWindow的PaintWindow()函数开始绘制窗口,并最终返回所有子控件计算完的最大层级。接着,子窗口递归绘制。

       PaintWindow()函数在绘制窗口时,首先调用SetHittestArea()设置点击区域,HittestGrid会判断窗口大小是否改变,若不变则仅更新窗口在屏幕中的位置。构造FPaintArgs参数后,将其封装到FSlateInvalidationContext中。

       FSlateInvalidationRoot类的PaintInvalidationRoot()函数可以作为控件树的根节点或叶子节点(SInvalidationPanel),构建快速路径避免每次绘制都计算大小和Paint函数,有利于优化。本篇文章主要分析正常慢速路径调用流程,优化相关将另文分析。

       PaintSlowPath()函数从SWindow开始调用Paint()函数,并定义LayerId从0开始作为参数,进行实际的绘制相关计算。

       Paint()函数首先处理裁剪、透明度混合、坐标转换等代码。若SWidget包含NeedsTick掩码,则调用Tick函数,我们在日常开发中通过蓝图或lua使用Tick函数时即调用到这里,通过SObjectWidget::Tick调用到UUserWidget::NativeTick供实现Tick。构造FSlateWidgetPersistentState PersistentState作为SWidget的变量,表示Paint时的状态。

       PersistentState.CachedElementHandle将当前SWidget存储到FSlateWindowElementList中的WidgetDrawStack数组中。

       更新FPaintArgs中的父节点参数和继承可点击测试参数,判断点击测试状态,然后将当前SWidget添加到点击测试中。调用虚函数OnPaint,由控件自己实现。

       OnPaint()函数参数包括绘制参数引用、几何体、裁剪矩形、缓冲元素列表、层级、控件风格、父节点状态等。最后处理重绘标签、延迟绘制相关内容、UpdateWidgetProxy()根据缓存句柄更新快速路径中需要处理标记设置为Volatile不稳定状态的SWidget。

       虚函数OnPaint()由子类自己实现,本文列举了SImage、SButton、SCompoundWidget和SConstraintCanvas的OnPaint()示例代码学习。

       在SImage中,简单判断Brush是否存在以及BrushDrawType的类型,然后调用FSlateDrawElement::MakeBox将控件添加到缓冲区元素列表中。

       SButton继承自SCompoundWidget,GetBorder()根据当前按钮状态返回ui中设置的Enabled、Press、Hover、Disabled等状态的Brush。

       SCompoundWidget作为合成节点,有且只能有一个子节点,且在Paint时强制将子节点的LayerId+1,同时SCompoundWidget可以单独设置混合颜色和透明度,影响子节点。

       SConstraintCanvas作为SWidget的基类对应UMG中常用的UCanvasPanel,通过ArrangeLayeredChildren()对孩子进行层级排序,并根据孩子的层级是否相同存储bool值在ChildLayers中。遍历所有孩子,判断是否开启新层级,递归调用Paint函数,最后返回最大层级。

       SConstraintCanvas::ArrangeLayeredChildren函数中,获取设置bExplicitChildZOrder,表示可以将同层一次渲染,有利于提高渲染器批处理。对所有孩子排序,排序规则为FSortSlotsByZOrder。遍历所有孩子,判断可见性掩码、计算偏移、锚点、位置、拉伸缩放等,封装成FArrangedWidget存储到ArrangedChildren中,用于OnPaint时有序遍历。判断每个孩子ZOrder是否相同,相同则bNewLayer为false,大于LastZOrder则将bNewLayer设置为true,最终存储到ArrangedChildLayers中,用于OnPaint函数判断是否将layerId+1。

       FSlateDrawElement::MakeBox()函数在OnPaint之后调用,将绘制控件的相关信息通过创建FSlateDrawElement绘制元素对象,添加到SWindow管理的FSlateWindowElementList元素列表中。创建Payload用于存储贴图等相关信息,根据控件Paint过程中的参数调用Element.Init初始化绘制元素,得到为该控件绘制创建的FSlateDrawElement对象。

       总结整个Slate绘制流程的第二步,我们没有分析快速处理和优化细节,而是按照正常绘制流程分析代码。通过从PaintWindow开始遍历整个控件树,处理每个空间节点的Paint、OnPaint函数,最终目的是给每个控件创建一个FSlateDrawElement对象,存储渲染线程绘制所需的相关信息,并添加到FSlateWindowElementList中。理解了整个调用流程,整个过程较为清晰,本文基于UE4版本4..2。

vue/compiler-dom源码分析学习--day4: 字符串化hoist节点

       vue/compiler-dom源码解析继续:深入理解字符串化hoist节点

       前言:在处理内置指令后,我们今日关注的是@vue/compiler-dom包中的字符串化hoist节点操作。这部分代码在baseCompile方法中找到调用入口,且hoistStatic选项默认为true,尽管没有直接传入参数。

       在vue/compiler-sfc/__tests__/compileTemplate.spec.ts的测试用例中,我们发现参数来源。接着,我们追踪到hoistStatic.ts和`walk`函数,这是实现静态提升(static hoisting)的关键,用于优化性能,避免在render function中重复生成和比较不会变化的静态节点。

       静态提升允许将不变的元素和文本节点抽离到render函数外,提高渲染效率。例如,一个只包含动态部分的,其静态部分会被提升,渲染时会直接使用字符串拼接,而不是每次都重新创建。

       现在,我们来看下stringifyStatic方法。该方法在确定节点会被提升到哪个阶段后执行,确保只处理适合的普通元素和文本节点。在transforms/stringifyStatic.ts中,代码负责识别可stringify的子节点,比如v-slot组件是不支持的,但可以hoist。

       在`analyzeNode`方法中,逐层递归检查节点,确保所有子节点满足stringify条件。文本节点则有特殊的处理方式,其他情况下,如遇到table元素,可能存在浏览器兼容性问题,导致不能使用innerHTML。

       总结`stringifyCurrentChunk`方法,它将识别到的静态块转换为字符串调用节点,替换原始hoist元素。整个过程旨在优化性能,通过字符串化hoist节点,减少不必要的DOM创建和比较。

       尽管代码逻辑相对直观,但众多小方法间的跳转可能影响阅读。核心是找到可stringify的最大静态块,并进行替换。关于内置指令和style的处理,也有相应的优化策略,如transformStyle处理静态style为bind类型。