代码路径为：/frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp 代码版本为android P
此类跟硬件合成Vsync信号有关系。这篇文章主要跟踪下硬件合成Vsync的过程。废话不多说，先看下构造方法。
可以看到构造方法传入一个Composer，然后强转为 mHwcDevice变量。目前这个就是唯一的构造传入参数。
遇到了一个新的类，android::Hwc2::Composer，这个类实现在
/frameworks/native/services/surfaceflinger/DisplayHardware/ComposerHal.cpp 中。
我们的HWComposer的很多操作都委托给了Composer。先来看下HWComposer的几个比较重要的方法。
先来看下Composer怎么构造的。
165Composer::Composer(const std::string& serviceName)
166 : mWriter(kWriterInitialSize),
167 mIsUsingVrComposer(serviceName == std::string("vr"))
168{
//通过binder 调用HAL模块的mComposerService
169 mComposer = V2_1::IComposer::getService(serviceName);
170
171 if (mComposer == nullptr) {
172 LOG_ALWAYS_FATAL("failed to get hwcomposer service");
173 }
174
175 mComposer->createClient(
176 [&](const auto& tmpError, const auto& tmpClient)
177 {
178 if (tmpError == Error::NONE) {
179 mClient = tmpClient;
180 }
181 });
182 if (mClient == nullptr) {
183 LOG_ALWAYS_FATAL("failed to create composer client");
184 }
185
186 // 2.2 support is optional
187 sp<IComposer> composer_2_2 = IComposer::castFrom(mComposer);
188 if (composer_2_2 != nullptr) {
189 mClient_2_2 = IComposerClient::castFrom(mClient);
190 LOG_ALWAYS_FATAL_IF(mClient_2_2 == nullptr, "IComposer 2.2 did not return IComposerClient 2.2");
191 }
192
193 if (mIsUsingVrComposer) {
194 sp<IVrComposerClient> vrClient = IVrComposerClient::castFrom(mClient);
195 if (vrClient == nullptr) {
196 LOG_ALWAYS_FATAL("failed to create vr composer client");
197 }
198 }
199}
mClient实现如下。
从上述总结可以知道，HWComposer很多业务逻辑都是直接跟硬件交互了。HAL位于操作系统和驱动程序之上，运行在用户空间中的服务程序。其目的是为上层的应用提供一个统一的查询硬件设备的接口。有了HAL接口，就可以将硬件开发和上层的应用开发分离开，上层的应用开发不必关系具体实现是什么硬件，同样地，如果硬件厂家需要改变硬件设备，只需要按照HAL接口的规范和标准提供对应的硬件驱动，而不必更改应用。（HAL层并不提供对硬件的实际操作，对硬件的实际操作仍然由具体的驱动程序来完成。）（此段文章摘自 https://blog.csdn.net/yyh448522331/article/details/77925907 ）
当硬件层产生了Vsync信号，会回调mComposeClient的HalEventCallback
其中onVsync就是所谓的同步信号，进而会调用到HWCompose里面的onVsync方法。
不过由于在SurfaceFlinger的init方法中
getBE().mHwc->registerCallback(this, ++getBE().mComposerSequenceId);
HWCompose把callback注册到SurfaceFlinger，那么当硬件层的Vsync信号到来的时候，
直接回调到SF的onVsync方法，方法如下。
1325void SurfaceFlinger::onVsyncReceived(int32_t sequenceId,
1326 hwc2_display_t displayId, int64_t timestamp) {
1327 Mutex::Autolock lock(mStateLock);
1328 // Ignore any vsyncs from a previous hardware composer.
1329 if (sequenceId != getBE().mComposerSequenceId) {
1330 return;
1331 }
1332
1333 int32_t type;
1334 if (!getBE().mHwc->onVsync(displayId, timestamp, &type)) {
1335 return;
1336 }
1337
1338 bool needsHwVsync = false;
1339
1340 { // Scope for the lock
1341 Mutex::Autolock _l(mHWVsyncLock);
1342 if (type == DisplayDevice::DISPLAY_PRIMARY && mPrimaryHWVsyncEnabled) {
1343 needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);
1344 }
1345 }
1346
1347 if (needsHwVsync) {
1348 enableHardwareVsync();
1349 } else {
1350 disableHardwareVsync(false);
1351 }
1352}
最后有一句， enableHardwareVsync()。主要是对mPrimaryDispSync的操作。后续文章再来分析DispSync.cpp的作用。SurfaceFlinger作为一个核心的系统服务，毫无疑问他的功能一定是有很多功能强大的类来组成，这个时候不能需要抽丝剥茧，慢慢分析。