OpenHarmony3.2  图形64/32位环境下出现UI刷新效率的差异。

使用自动列表切换的测试程序 demo3.hap

32位系统环境下，可以达到60 fps  (FB检测)

64位系统环境下，不稳定，多数是在30-40 fps.

经初步定位，有异常的阻塞耗时在图形合成上面。   

所理解的过程是， onVsync->Rapaint->(Redraw--commit),   这里commit会对应到最终的fbfresh，并通过ioctl到FB驱动进行推帧。

从下图trace 图（1） 来看fbfresh对应的ioctl用时很大，有时候会超过20MS。 原因是 vsync机制的影响。在源软件中display_device/vsync/sorft_vsync.cpp下

会有GFBGIOGET_VBLANK的操作。

在64位情况FB的IOCTL模式为unlock_ioctl，并在这里加上了互斥锁。导致fbfresh的ioctl必须要等到GFBGIOGET_VBLANK完成才能生效。

而32位时FB的ioctl模式为compat_ioctl，这里就没有互斥锁。fbfresh的ioctl不受影响，基本没有大的用时。

下图trace中  H:GFBIGET_VBLANK 为自增加项 。

 图（1）

从代码上的理解上来看

对应的workThread中的checkRuning ，需要等待enableVsync后才会去做GFBGIOGET_VBLANK的操作，只有Rapaint基本结束后才会调用enableVsync-true。CheckRuning这里有wait阻塞操作，这样的机制是可以避免上诉问题。 图 （2）

 但从实际运行来看，不符合预期，比较奇怪，感觉CheckRuning这里有wait没有正常生效。

CheckRuning似乎不用EnableVsync唤醒也能往下走，导致GFBGIOGET_VBLANK长时间 的运行，影响FB的其他IOCTL的访问。

实际上这种情况在32位下也一样，CheckRuning几乎没有等待时间 。只是32位上，ioctl没有互斥锁。

所以想咨询下这种情况的原因是什么？

 图 （2）