UML图

内部处理request请求

分析和设计模块时，首要的是要有分层概念，切记不要把业务层和sdk层混淆

capture

bmg Render

onSourceUpdate(result)

setRepeatingRender(Request request)

RenderModel管理者1.根据信息判断是否需要转场2.填充转场相关的result

屏幕

OnNewClip

渲染PipeLine

commit()

客户端处理转场业务

sourceUpdate帧

renderSession

中间状态回调（渲染前）

onBeforeRender

快拍录屏业务实现者2.通过onRenderCompleted 的result获取sample，这个Sample的时间戳写入可以内聚在ScreenRecordFilter中3.将sample put给录制模块

OnTransform

问题：1.请求端每新增一个业务，比如改变SequenceSource的queueMode、snapshot等行为就必须在session中新增接口，不符合开闭原则2.我们设计接口，应该只设计必要的接口，因为接口的增加一旦不可控，第一说明整个系统的行为抽象没做好，第二，严重影响代码的可读性和稳定性。比如，维护过一段时间的代码，因为考虑不周增加了许多不必要成员变量，而这个具有类中全局属性的成员变量可能出现在好些接口当中，要他们一起进行各种判断和逻辑组合来完成任务。相当于所有接口又同时依赖在一起了（他们都依赖成员变量，成员变量一旦改变将影响任何接口可能的行为），导致极难维护。为什么他们要被依赖在一起才能完成任务？这是一个非常有深意的问题。其实出现这个问题的根源在于，我们原本不需要这么多的接口，它们本来就应该在更高的维度上抽象出来成为一个新的整体，这个过程中，我们可以消灭许多不必要的成员变量我们这个系统。3.同样的，回调端的接口，一旦出现新增一个需要监听渲染PipeLine的结果的业务，我们又必须新增一个对应的回调。究其根源是我们的系统不具备一个把核心元数据统一抽象，并且统一地根据系统定义的几个核心节点（即回调方法）来转发统一的结果的机制。4.回调结果的过多对于代码阅读者，特别是业务不熟悉的代码阅读者是一个灾难。他将必须时时刻刻担心、小心这个回调的线程来源以及时序安排。

Filter业务1.根据request查找设置的filter2.实例化filter3.设置filter

onSourceUpdate()

onSourceUpdate

客户端监听者

客户端

onError

onBeforeRender()

时间戳记录

onRenderCompleted

Animation时间戳监听需求

onTrackerResult

Tracker业务监听者1.根据result读取tracker结果信息2.post出去完成其他业务

时间戳回调

回归到渲染本质，渲染是一个大的状态机，其内部PipeLine时对用户封闭的，只暴露片段着色和顶点着色2大过程作为可编程的节点。对应的，我们的基于渲染的业务行为必然会与之具有相似性，且必须设计地具有相似性才合理。就像人的表皮纹理，在显微镜下同样将呈现类似的纹理特征。

ScreenRecordFilter

onSourceUpdate{更新时间戳}//start()//stop()

otherTraget

帧数据就像果子慢慢成熟的过程

HybridRender处理

ScreenRecordFilter1.实现DrawTexture渲染完成回调结果

ScreenRecordFilter1.实现DrawTexture2.把结果写入result

MediaSession

PutAudio

请求客户端操作

录屏等依赖时间戳的业务

Tracker1.实现source监听函数2.完成自己的tracker业务3.获得结果，把结果写入result

执行Session内部客户端请求的request队列

RenderStateListener

onRenderCompleted(result)

转场业务实现者1.根据result读取转场信息2.填充参数3.即时设置新参数

onRenderCompleted回调

1.如何请求2.如何获取结果3.如何拓展   a)新增requestKey，ResultKey   b)根据requestKey执行相应的逻辑，   c)根据结果，填充相应的result

平面追踪Tracker结果

SuperRecord

start()stop()

录屏帧

Tracker1.实现source监听函数2.完成自己的tracker业务3.获得结果

RecordCallback

+onSample(MediaSample)

注入request、result及等资源

onSourceUpdate回调

session创建

clearColor

recordBuffer

SequenceSourceSource

全景追踪Tracker结果

解码的帧

FilterObject

Draw()

1.客户端业务这边做成广播模式以监听session的2个重要接口实现业务隔离和分发2.由于现在存在一个result对象，此前快拍必须监听sourceUpdate才能获取时间戳，但是，现在实际上客户端无需再监听sourceUpdate了，只需要在渲染完成后即可以通过result获取时间戳。

Render

客户端容错业务

SampleUpdateListener

tracker处理记录结果

onSample()

Tracker业务1.构建对应的Tracker2.加入内部source'监听列表

setQueueMode()

Tracker的回调

能力查询

优势：1.一次渲染过程的所有元数据都有一个统一的记录者和输出节点，把此前散发的监听业务集中统一地归并输出，无须每个业务注册一个单独的回调，统一由onSourceUpdate、onRenderCompleted带着result给出2.最大限度的屏蔽内部的细节，客户端只需下发相应命令 统一获取相应结果即可3.减少依赖的接口，比如录屏功能，原本需要依赖sourceUpdate、ScreenRecordFilter的结果，现在只需要通过onRenderCompleted获取结果即可。4.实现层业务相互隔离，每个实现层模块可以抽象成PipelineNode，每个node的任务就是根据requuest参数，完成自己的业务，最后把结果填充到result（大部分业务基本都是更新RenderModel内部的参数，少数业务是直接改HybridRender接口，不过这些都可以封装到node中处理）5.把零散的功能抽象成一个个的可以单独部署的能力，实现层形成node或PipeLine概念可以按需拆装，后期可支持能力配置化（基于不同项目、平台，对外暴露不同的能力集合）6.TODO：建立一个request对应一个或多个target的概念，这种概念下，可以随意取一个copy的帧，未来的业务如果需要帧数据，可以灵活地通过下发request得到对应的buffer。渲染sdk只focus在数据的渲染和抓取上。

Tracker1.实现source监听函数2.完成自己的tracker业务3.获得结果，回调

需要新增Completed接口

客户端处理UploadFrame业务

request请求

我们现在的代码，缺乏能力查询、以及最终渲染结果帧回给客户端的闭环能力

执行

用户指定的其他target

客户端处理新的clip业务

其他处理，记录结果

onUploadFrame

request