aosp14/15官方Freeform工具栏CaptionWindow显示不同步bug修复方案总结

背景：

在自由窗口选中右下角频繁进行相关拖拽放大缩小自由窗口，会出现CaptionWindow工具栏和自由窗口Activity宽度不同步问题。
单独一帧看也可以看到工具栏显示宽度宽，Activity显示宽度窄

今天来讲解一下相关的修复方案讨论。

问题修复后的成果及总结：

成果展示：

明显上图可以看出在拖动自由窗口过程中，已经没有出现工具栏和Activity显示宽度不一致的问题了。

问题本质原因修复方案总结：

核心问题就在于CaptionWindow在systemui中进行刷新，而Activity是在应用进程单独刷新，在拖动时候会不断修改Activity和CaptionWindow相关的bounds大小，但是二者又处于两个进程单独刷新，导致没有掌握好刷新节奏，这类问题在分屏课程，ShellTransition课程中其实也是有详细讲解的。所以根据课程所学知识大家应该知道修改方案的核心就是让CaptionWindow的刷新和Activity的刷新要进行同步事物管理既可以。

（具体的实战修改patch目前只对高级八件套及以上vip开放，具体获取方式私聊马哥）

修改画面同步后副作用：

触摸拖动自由窗口的跟手性变差
因为CaptionWindow刷新需要进行等待Activity完全刷新完成才可以进行一起刷新，所以必然会导致刷新的跟手程度不好。

总结：
这个bug感觉Google不予修复也是无奈源头方案定错了，虽然把这个问题修复了，就和现象一样跟手性不好了，所以还是建议用分屏自由课程方案来做自由窗口呗，彻底抛弃Google自动的自由窗口变化交互

其他非正面修复方案：

因为上面的正面修复会带来跟手性问题，那么是否可以考虑修改相关的交互方案来规避该bug呢？
也就是不考虑正面修复bug，而是考虑使用修改交互方式来规避该bug方式，其实在公司的实战开发中这种通过修改交互方式来规避bug还比较常见，一般面对以下几种情况时候就会考虑交互上来规避：

1、正面修复bug难度太大，耗费时间太多，时间投入性价比低

2、正面修复bug波及太多，会引发很多副作用

3、交互修改更可以优化用户体验

那么针对自由窗口CaptionWindow和Activity刷新不同步问题用什么交互方式来改善呢？

方案1（难度大，修改多体验好）：
改善成和国内主流手机厂商一样的方案，针对自由窗口的放大采用等比例缩放方案，这这个方案马哥课程已经有详细实战讲解，当然难度也比较大

方案2（最简单，修复快，需要产品同意）：
这个是学员在vip群中提出的一个规避方案

采用在拖拽放大自由窗口时候显示一个ICON的图层，类似拖动分屏时候分屏显示的ICON图层方案

拖动自由窗口时候显示ICON图层，这样就可以只看到ICON图层，看不到下面的Freeform窗口相关

更多framework实战干货，请关注下面“千里马学框架”