抽丝剥茧：Flutter Engine隐藏的一个惊天Bug
零、背景介绍
Flutter技术在微视内经过大半年的探索，已经从存量业务的改造尝试阶段，开始进入增量业务的承接阶段。横版视频的为你推荐就是这样一个场景，原Native体验如下：
使用Flutter完成新业务的改造后体验如下：
新的UI体验更加丰富，在一些细节上（比如跟手滑动）也有所优化，后面将详细复盘挑战与解法。
本文将分析，由该业务上线而牵出的一个Flutte Engine的巨大Bug。在解决问题的过程，有山重水复、走投无路的沮丧，也有峰回路转、醍醐灌顶的激动，故此记录，以飨读者。
一、Crash来袭
在Flutter版本的为你推荐页面上线后（放量10%），负责质量的同学stevenqihu向我们反馈了一个Flutter的Native Crash。虽然没有完全放量，该Crash的发生次数已经来到了Top 2。
一方面，我们要保证质量数据的稳定；另一方面，也要保证产品需求的上线，所以解决这个问题迫在眉睫。
二、疑云重重
由于我并不是专业解Crash的同学，所以负责这块工作的bingozhuang也参与了进来。按照常规的解法，我们从Bugly上拿到了Crash的堆栈，如下：
#12927 1.io
SIGSEGV(SEGV_MAPERR):
#00 pc 00000000004aeb04 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#01 pc 0000000000218270 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#02 pc 000000000021b5e8 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#03 pc 000000000017994c /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#04 pc 00000000001791ec /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#05 pc 0000000000179214 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#06 pc 00000000000be234 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#07 pc 00000000000be2e0 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#08 pc 00000000000be2f8 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#09 pc 00000000000270ac /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#10 pc 000000000002a584 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#11 pc 000000000002c9ec /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#12 pc 00000000000144fc /system/lib64/libutils.so (_ZN7android6Looper9pollInnerEi+836) [arm64-v8a::6e28af754ab0291416498f650e306ff7]
#13 pc 0000000000014114 /system/lib64/libutils.so (_ZN7android6Looper8pollOnceEiPiS1_PPv+60) [arm64-v8a::6e28af754ab0291416498f650e306ff7]
#14 pc 000000000e2cd368 /vendor/lib64/libgralloc_extra.so (ALooper_pollOnce+96) [arm64-v8a::d050bf4fefcf3a8b991ea0bdb35b7260]
#15 pc 000000000002cafc /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#16 pc 0000000000029884 /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#17 pc 000000000002b59c /data/app/com.tencent.weishi-DT3Bh5C_tryVQSznNp4AeA==/lib/arm64/libflutter.so [arm64-v8a::0aa29a54fe1d9f96d4bad726f0374603]
#18 pc 0000000000083824 /system/lib64/libc.so (_ZL15__pthread_startPv+36) [arm64-v8a::974ac4902843d14d893999c925af5a95]
#19 pc 000000000002340c /system/lib64/libc.so (__start_thread+68) [arm64-v8a::974ac4902843d14d893999c925af5a95]
java:
[Failed to get Java stack]
然后，通过addr2line工具进行还原。令人匪夷所思的是，这些地址根本没法还原，于是我们做了以下尝试：
- 最有可能的：符号表没对上。可是，通过比较Crash信息携带的BuildID和用readelf读出的libflutter.so符号表的BuildID，发现他们是一样的！
- 继续上一个猜想，我们直接把带符号表的so打入微视，然后跑稳定性测试，抓到堆栈用同一个so仍然无法还原！
至此，我们遇到了第一个困难：无法还原符号表。这几乎是致命的，并且还将在后面继续阻碍我们，先按下不表。比较熟悉这块的bingo也给了一些猜想，比如
也有一个猜想，你试试32位的，他们那个回栈是基于unwind，一般来说也不至于有问题，有个点你可以考虑下，也有可能bugly对64位的兼容有问题，可以试试拿32位的包去测试一下
目前来说，堆栈无法还原的，这个看起来不是很好解决，我们只能根据一些额外的信息来进行分析，比如：
- 由
SIGSEGV(SEGV_MAPERR)可知，这是一个非法内存访问导致的Crash。 - 由
1.io可知，Crash发生在 Flutter 的 io 线程，该线程负责图片资源的离屏渲染，我们的Native业务代码一般运行在platform线程，Flutter业务代码一般运行在ui线程，所以这大概率不是我们业务代码导致的问题。
当然了，我们这个场景比较特殊，Flutter页面是以浮层的形式和Native共存，也不排除这个原因。
此外，我们的Flutter SDK版本是2.0.1，仅在Flutte 2.0发布后升级过一次，是不是因为这个版本还不太稳定（虽然也是stable分支的）。抱着一丝幻想，我们做了第一个尝试，把Flutter SDK升级到最新的稳定版本2.2.3。或许，这就是Flutter在开发过程中的一个Bug，升级到最新版本就好了，抱着一丝侥幸心理，我们进行了升级和灰度。天不遂人愿，Crash依然“源源不断”地有上报。
继续分析堆栈的潜在信息，可以发现堆栈的最下面有 pthread_start 和 ALooper_pollOnce 等信息，据此判断，应该是io线程创建后，启动（消息循环post的第一个逻辑）时发生的，于是我们把io线程的启动逻辑捋了一遍，找到一些可疑点但最后都被推翻了。事后来看，这是一个缺乏经验的判断，因为任何一次Crash，只要一直往上回溯，都能回溯到 ALooper_pollOnce 。不过，这部分尝试也不是完全没有价值：io线程，这个隐藏在Flutter Engine最底层的线程，开始漏出了它的冰山一角。
这一阶段，做了很多尝试，但是并没有什么有价值的突破。But，距离我给产品的deadline也越来越近
三、峰回路转
就在这疑云重重的时候，我们组另外一位同学（nickdxuli）反馈他遇到了一次为你推荐的Crash，堆栈和Bugly的一摸一样，于是我继续了解了下他的Crash场景：
vimerzhao 7-16 20:43
你的表现是退出横版视频，还是整个APP都退出了？
nickdxuli 7-16 20:45
退出横版视频时出现了，然后回到推荐页变成了其他视频
vimerzhao 7-16 20:45
好的
vimerzhao 7-16 21:36
你出现的是一进入就闪退吗？
vimerzhao 7-16 21:36
还是说你是故意进入之后立即退出才会出现
nickdxuli 7-16 23:14
故意进入后马上推出
虽然这个堆栈仍然无法还原，但是从以上对话至少可以推断出两点：
- 可能并不是io线程启动后的第一个逻辑Crash的，而是退出时Crash的
- 启动和退出的间隔可能要尽可能短，才能Crash
而且，结合线上Crash的出现频率，及以上对话提供的信息，我们应该是可以复现这个问题的。手动当然是不可能的，于是我设计了以下脚本：
for i in {1..1000}
do
echo "Welcome $i times"
# 启动横版视频页面的deeplink路由
adb shell am start -a android.intent.action.VIEW -d 'weishi://horizontal_video?*****************'
sleep 0.7 # 随机等待0.7～1.7s
sleep 0."$RANDOM"
adb shell input keyevent 4 # 退出并等待 1 s
sleep 1
done
果然，通过以上脚本，就可以在100次之内触发这个问题！至此，我们也看到了这个Crash的真面目：
这时，我冒出一个猜想，如果这个问题普遍存在，那么应该早就有人反馈给Flutter官方并被解决了（后面证明我还是too young），我们这个业务比较特殊，他是竖屏转横屏，那么有没有可能在某个瞬间Flutter以为当前是竖屏，然后下一个刻到达了横屏的临界点，于是发生了非法的内存访问， 看起来有点戏，和上面图中Crash发生时的横竖屏切换也能对得上。于是，我又做了一次灰度：延迟500ms初始化，如果猜想正确，Crash应该大大减少，然而并没有。
至此，又一个可能性破灭。
好在天无绝人之路，组内另外一个同事（panyu）也遇到了一次这个问题，并提供了一个不一样的堆栈，他的堆栈是可以还原的！！（注：为啥这次的堆栈可以还原？唯一说得通的特殊之处是panyu的手机是Google原生系统）
以下是附带手工还原信息的堆栈
07-20 21:14:23.741 9230 24550 F libc : Fatal signal 11 (SIGSEGV), code 0 (SI_USER) in tid 24550 (2.io), pid 9230 (WsPlayer-Worker)
07-20 21:14:24.357 27164 27164 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-20 21:14:24.357 27164 27164 F DEBUG : Build fingerprint: 'Phh/treble_arm64_bgS/phhgsi_arm64_ab:11/RQ2A.210505.003/210505:userdebug/test-keys'
07-20 21:14:24.357 27164 27164 F DEBUG : Revision: '0'
07-20 21:14:24.357 27164 27164 F DEBUG : ABI: 'arm64'
07-20 21:14:24.358 27164 27164 F DEBUG : Timestamp: 2021-07-20 21:14:24+0800
07-20 21:14:24.358 27164 27164 F DEBUG : pid: 9230, tid: 24550, name: 2.io >>> com.tencent.weishi <<<
07-20 21:14:24.358 27164 27164 F DEBUG : uid: 10275
07-20 21:14:24.358 27164 27164 F DEBUG : signal 11 (SIGSEGV), code 0 (SI_USER), fault addr --------
07-20 21:14:24.360 27164 27164 F DEBUG : backtrace:
07-20 21:14:24.360 27164 27164 F DEBUG : #00 pc 0000000000767dd0 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
OUTLINED_FUNCTION_7438 ld-temp.o:?
07-20 21:14:24.360 27164 27164 F DEBUG : #01 pc 00000000004c5ec8 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
std::__1::unique_ptr<GrGLContext, std::__1::default_delete<GrGLContext> >::operator->() const
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/libcxx/include/memory:?
07-20 21:14:24.360 27164 27164 F DEBUG : #02 pc 00000000004c9084 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
~GrGLSemaphore
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/skia/src/gpu/gl/GrGLSemaphore.cpp:16
07-20 21:14:24.360 27164 27164 F DEBUG : #03 pc 0000000000430a64 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
~RefHelper
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/skia/src/gpu/GrBackendTextureImageGenerator.cpp:42
07-20 21:14:24.360 27164 27164 F DEBUG : #04 pc 00000000004302f0 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
~GrBackendTextureImageGenerator
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/skia/src/gpu/GrBackendTextureImageGenerator.cpp:82
07-20 21:14:24.360 27164 27164 F DEBUG : #05 pc 0000000000430318 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.360 27164 27164 F DEBUG : #06 pc 000000000036da78 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.360 27164 27164 F DEBUG : #07 pc 000000000036db20 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
~SkImage_Lazy
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/skia/src/image/SkImage_Lazy.h:22
07-20 21:14:24.361 27164 27164 F DEBUG : #08 pc 000000000036db38 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.361 27164 27164 F DEBUG : #09 pc 00000000002d3b58 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
SkRefCntBase::unref() const
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/skia/include/core/SkRefCnt.h:77
07-20 21:14:24.361 27164 27164 F DEBUG : #10 pc 00000000002d7050 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
std::__1::function<void ()>::operator()() const
/Users/vimerzhao/SourceCode/flutter_source/src/out/android_release_arm64/../../third_party/libcxx/include/functional:2419
07-20 21:14:24.361 27164 27164 F DEBUG : #11 pc 00000000002d948c /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
fml::MessageLoopAndroid::OnEventFired()
/Users/vimerzhao/SourceCode/flutter_source_for_writing/src/out/android_release_arm64/../../flutter/fml/platform/android/message_loop_android.cc:92
07-20 21:14:24.361 27164 27164 F DEBUG : #12 pc 0000000000019dac /system/lib64/libutils.so (android::Looper::pollInner(int)+916) (BuildId: 5d6af74124211886d954d61c96514a46)
07-20 21:14:24.361 27164 27164 F DEBUG : #13 pc 00000000000199b0 /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112) (BuildId: 5d6af74124211886d954d61c96514a46)
07-20 21:14:24.361 27164 27164 F DEBUG : #14 pc 0000000000012c74 /system/lib64/libandroid.so (ALooper_pollOnce+100) (BuildId: 98721e1736430f099cefab596fc48463)
07-20 21:14:24.361 27164 27164 F DEBUG : #15 pc 00000000002d959c /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.361 27164 27164 F DEBUG : #16 pc 00000000002d62dc /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.361 27164 27164 F DEBUG : #17 pc 00000000002d8008 /data/app/~~2KomJ56WgxMlYGDqcaIs9w==/com.tencent.weishi-3QS7dDVKEWyhSaRKKAtxpA==/lib/arm64/libflutter.so (BuildId: 9df6c7c4b6627a8fb73c9e78930980a1ad61e210)
07-20 21:14:24.361 27164 27164 F DEBUG : #18 pc 00000000000afd4c /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: 88826ef406dbbed88068a41b1da6c056)
07-20 21:14:24.361 27164 27164 F DEBUG : #19 pc 0000000000050288 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 88826ef406dbbed88068a41b1da6c056)
不过，后面我用脚本跑了几次这台手机，再也没有出现这个堆栈了（就两个字：离谱）。
不管其他的，我们决定先攻克这份日志。
可以看到，以上日志中，我们能看到离Crash最近的点是 GrGLSemaphore 的析构函数，其逻辑如下
// 代码清单 1
// third_party/skia/src/gpu/gl/GrGLSemaphore.cpp
GrGLSemaphore::GrGLSemaphore(GrGLGpu* gpu, bool isOwned)
: fGpu(gpu), fSync(nullptr), fIsOwned(isOwned) {}
GrGLSemaphore::~GrGLSemaphore() {
if (fSync && fIsOwned) {
fGpu->deleteSync(fSync);
}
}
经验丰富的庄老师（bingo）一下就看出可能是 fGpu 这个对象在访问时已经被释放了，导致访问了一个非法地址，这是非常合理的！
于是我们在关键节点加上日志，得到如下信息：
虽然无法理解，但是铁证如山：GrGLGpu 有一定概率在 GrGLSemaphore 之前先析构（注意，这只是表象，我们后面会分析出真正的原因）。
四、妥协规避
在排查分析了一天（这里其实方向错了，我们去分析 deleteSync 里面的逻辑，试图揭开 GrGLGpu 提前析构的原因 ）之后，我们依旧无法解释这个现象。但是产品迫切希望这个Crash能在当前版本全量之前解决。
虽然无法彻底解释这个现象，但完全可以规避出问题的地方。于是，我们修改了Skia的源码，重新构建了一个Flutter Enine，发布之后Crash果然消失了。大概的解法如下:
首先，在 GrGLGpu 的析构触发之前预埋一个方法：
// 代码清单 2
// third_party/skia/include/core/SkRefCnt.h
class SK_API SkRefCntBase {
public:
......
// 新增方法，在 GrGLGpu 中实现逻辑
virtual void extraUnref() const {}
void unref() const {
SkASSERT(this->getRefCnt() > 0);
if (1 == fRefCnt.fetch_add(-1, std::memory_order_acq_rel)) {
extraUnref();
this->internal_dispose();
}
}
......
};
由于 GrGLGpu 和 GrGLSemaphore 是双向绑定的，所以我们可以在 GrGLGpu 析构时（ extraUnref 执行）通知绑定的 GrGLSemaphore，如下：
// 代码清单 3
// third_party/skia/src/gpu/gl/GrGLGpu.h
class GrGLGpu final : public GrGpu {
public:
static sk_sp<GrGpu> Make(sk_sp<const GrGLInterface>, const GrContextOptions&, GrDirectContext*);
~GrGLGpu() override;
// 存储所有和当前实例绑定的 GrGLSemaphore
std::unordered_set<GrGLSemaphore*> semaList;
// 在 GrGLGpu 析构之前执行
void extraUnref() const override {
for(auto f : semaList) {
f->valid = false; // 通知 GrGLGpu 的引用是无效的
}
}
......
}
下面，我们就可以在 GrGLSemaphore 创建时绑定到 semaList ，然后在析构时检查：
// 代码清单 4
// third_party/skia/src/gpu/gl/GrGLSemaphore.cpp
GrGLSemaphore::GrGLSemaphore(GrGLGpu* gpu, bool isOwned)
: fGpu(gpu), fSync(nullptr), fIsOwned(isOwned) {
valid = true;
fGpu->semaList.insert(this); // 注册到 GrGLGpu
}
GrGLSemaphore::~GrGLSemaphore() {
// 如果 GrGLGpu 已经析构，则 valid 为 false
if (fSync && fIsOwned && valid) {
fGpu->semaList.erase(this); // 主动解绑
valid = false;
fGpu->deleteSync(fSync);
}
}
通过以上蹩脚的代码，我们终于“解决”了这个Crash。
五、重整旗鼓
我们的山寨版 Flutter Engine 终于搭载着业务上线了，产品的压力已经没有了。但是，Skia作为一个广泛使用的图形库，它出问题的概率应该比Flutter更低，更有可能是Flutter的错误使用导致了Skia的Crash。而且，我们的山寨改法是无法合回谷歌的官方仓库的（显然）。
本着技术的初心，我们向这个问题发起了最终的冲锋。
首先，我们分析了几个关键问题。
5.1 真的是我们的问题吗？
结合 GrGLGpu 、 GrGLSemaphore 等类的作用，我们已经基本分析出，导致这个问题的关键并不是横竖屏，而是图片！图片的创建销毁也伴随着 GrGLSemaphore 的创建销毁，于是我们写了一个简单的Demo，进入一个Flutter页面加载5张图片，立即退出。果然，问题还是会出现！
至此，我们可以确定的说，这个问题并不是微视的横版视频才会出现，而是任何一个有图片的Flutter页面都会出现的，只是概率大小的问题（后面会详细探讨）。
5.2 GrGLGpu 、 GrGLSemaphore 等关键类的关系及作用？
结合上文的堆栈，我们梳理了Skia做图片渲染的几个关键类的关系，如下：
- io线程和ui线程都会持有
SKImage_Lasy，前者负责生产，后者负责消费（更严谨来说，raster线程负责消费，ui线程负责持有和管理） - SKImage_Lasy 持有 GrBackendTextureImageGenerator
- GrBackendTextureImageGenerator 持有 RefHelper
- RefHelper 持有 fSemaphore 字段，它是一个 GrGLSemaphore 的实例
因此，每个图片的销毁会伴随着 GrGLSemaphore 的销毁。 而 GrGLGpu 是一个全局对象，只有整体退出时才会销毁。
5.3 GrGLGpu 、 GrGLSemaphore 等关键类的析构顺序？
由于问题出在析构顺序错乱，所以，我们迫切需要知道这些类的析构是如何触发的。
一开始，我们使用 _Unwind_Backtrace 和 dladdr 在 GrGLGpu 的析构函数执行时进行回栈，但效果并不理想，如下：
和Bugly上的Crash上报差不多，关键信息并没有还原，而且这些偏移值也无法从符号表还原出来，只有前几位能对得上。
但是，转念一想，无论析构顺序是否发生错乱，每次析构的触发流程应该都是一样的，所以我们只需要观察正常情况的下的析构顺序就行了。于是，我们构建了一个debug版的libflutter.so，通过llvm调试，拿到了 GrGLGpu / GrGLSemaphore 的析构调用栈。GrGLGpu的回栈：
(lldb) c
Process 20783 resuming
Process 20783 stopped
* thread #19, name = '1.io', stop reason = breakpoint 1.1
frame #0: 0xcb9ed4e2 libflutter.so`GrGLGpu::~GrGLGpu(this=0xcd867300) at GrGLGpu.cpp:382:21
379 }
380 }
381
-> 382 GrGLGpu::~GrGLGpu() {
383 // Ensure any GrGpuResource objects get deleted first, since they may require a working GrGLGpu
384 // to release the resources held by the objects themselves.
385 // SkDebugf("skia v5 GrGLGpu::~GrGLGpu析构函数 %p", this);
Target 0: (app_process32) stopped.
(lldb) bt
* thread #19, name = '1.io', stop reason = breakpoint 1.1
* frame #0: 0xcb9ed4e2 libflutter.so`GrGLGpu::~GrGLGpu(this=0xcd867300) at GrGLGpu.cpp:382:21
frame #1: 0xcb329d6e libflutter.so`SkRefCntBase::internal_dispose(this=0xcd867300) const at SkRefCnt.h:102:9
frame #2: 0xcb2e8864 libflutter.so`SkRefCntBase::unref(this=0xcd867300) const at SkRefCnt.h:81:19
frame #3: 0xcb2e87f4 libflutter.so`void SkSafeUnref<SkImage>(obj=0xcd867300) at SkRefCnt.h:154:14
frame #4: 0xcb2e84b6 libflutter.so`sk_sp<SkImage>::~sk_sp(this=0xcc63c884) at SkRefCnt.h:255:9
frame #5: 0xcb88d794 libflutter.so`GrDirectContext::~GrDirectContext(this=0xcc63c820) at GrDirectContext.cpp:88:1
frame #6: 0xcb88d914 libflutter.so`GrDirectContext::~GrDirectContext(this=0xcc63c820) at GrDirectContext.cpp:68:37
frame #7: 0xcb329d6e libflutter.so`SkRefCntBase::internal_dispose(this=0xcc63c820) const at SkRefCnt.h:102:9
frame #8: 0xcb2e8864 libflutter.so`SkRefCntBase::unref(this=0xcc63c820) const at SkRefCnt.h:81:19
frame #9: 0xcb2e87f4 libflutter.so`void SkSafeUnref<SkImage>(obj=0xcc63c820) at SkRefCnt.h:154:14
frame #10: 0xcb2e84b6 libflutter.so`sk_sp<SkImage>::~sk_sp(this=0xe2d918f4) at SkRefCnt.h:255:9
frame #11: 0xcb3b071a libflutter.so`flutter::ShellIOManager::~ShellIOManager(this=0xe2d918f0) at shell_io_manager.cc:92:1
frame #12: 0xcb39fdba libflutter.so`std::__1::default_delete<flutter::ShellIOManager>::operator(this=0xc87fe100, __ptr=0xe2d918f0)(flutter::ShellIOManager*) const at memory:2338:5
frame #13: 0xcb39fd9c libflutter.so`std::__1::unique_ptr<flutter::ShellIOManager, std::__1::default_delete<flutter::ShellIOManager> >::reset(this=0xc87fe100, __p=0x00000000) at memory:2593:7
frame #14: 0xcb3a34c6 libflutter.so`flutter::Shell::~Shell(this=0xc87fe100)::$_5::operator()() at shell.cc:466:20
GrGLSemaphore 的回栈：
Process 21502 stopped
* thread #17, name = '1.io', stop reason = breakpoint 1.2
frame #0: 0xcba08666 libflutter.so`GrGLSemaphore::~GrGLSemaphore(this=0xcc5af8d0) at GrGLSemaphore.cpp:17:33
14 // SkDebugf( "v5 GrGLSemaphore::GrGLSemaphore构造函数: %p / %p / %p / %d",this, fGpu, fSync, fIsOwned);
15 valid = true;
16 fGpu->semaList.insert(this);
-> 17 }
18
19 GrGLSemaphore::~GrGLSemaphore() {
20 // SkDebugf( "v5 GrGLSemaphore::~GrGLSemaphore析构函数: %p / %p / %p / %d", this, fGpu, fSync, fIsOwned);
Target 0: (app_process32) stopped.
(lldb) bt
* thread #17, name = '1.io', stop reason = breakpoint 1.2
* frame #0: 0xcba08666 libflutter.so`GrGLSemaphore::~GrGLSemaphore(this=0xcc5af8d0) at GrGLSemaphore.cpp:17:33
frame #1: 0xcb2ee6e6 libflutter.so`std::__1::default_delete<flutter::IsolateConfiguration>::operator(this=0xcd17dffc, __ptr=0xcc5af8d0)(flutter::IsolateConfiguration*) const at memory:2338:5
frame #2: 0xcb2ee6c6 libflutter.so`std::__1::unique_ptr<flutter::IsolateConfiguration, std::__1::default_delete<flutter::IsolateConfiguration> >::reset(this=0xcd17dffc, __p=0x00000000) at memory:2593:7
frame #3: 0xcb2eadc8 libflutter.so`std::__1::unique_ptr<flutter::IsolateConfiguration, std::__1::default_delete<flutter::IsolateConfiguration> >::~unique_ptr(this=0xcd17dffc) at memory:2547:19
frame #4: 0xcb871eb2 libflutter.so`GrBackendTextureImageGenerator::RefHelper::~RefHelper(this=0xcd17dfc0) at GrBackendTextureImageGenerator.cpp:45:1
frame #5: 0xcb872266 libflutter.so`SkNVRefCnt<GrBackendTextureImageGenerator::RefHelper>::unref(this=0xcd17dfc0) const at SkRefCnt.h:184:13
frame #6: 0xcb87220c libflutter.so`GrBackendTextureImageGenerator::~GrBackendTextureImageGenerator(this=0xcc523200) at GrBackendTextureImageGenerator.cpp:88:17
frame #7: 0xcb872284 libflutter.so`GrBackendTextureImageGenerator::~GrBackendTextureImageGenerator(this=0xcc523200) at GrBackendTextureImageGenerator.cpp:86:67
frame #8: 0xcb2ee6e6 libflutter.so`std::__1::default_delete<flutter::IsolateConfiguration>::operator(this=0xcc82c684, __ptr=0xcc523200)(flutter::IsolateConfiguration*) const at memory:2338:5
frame #9: 0xcb2ee6c6 libflutter.so`std::__1::unique_ptr<flutter::IsolateConfiguration, std::__1::default_delete<flutter::IsolateConfiguration> >::reset(this=0xcc82c684, __p=0x00000000) at memory:2593:7
frame #10: 0xcb2eadc8 libflutter.so`std::__1::unique_ptr<flutter::IsolateConfiguration, std::__1::default_delete<flutter::IsolateConfiguration> >::~unique_ptr(this=0xcc82c684) at memory:2547:19
frame #11: 0xcb50b584 libflutter.so`SharedGenerator::~SharedGenerator(this=0xcc82c680) at SkImage_Lazy.cpp:39:7
frame #12: 0xcb50b55c libflutter.so`SkNVRefCnt<SharedGenerator>::unref(this=0xcc82c680) const at SkRefCnt.h:184:13
frame #13: 0xcb50b520 libflutter.so`void SkSafeUnref<SharedGenerator>(obj=0xcc82c680) at SkRefCnt.h:154:14
frame #14: 0xcb50a3fe libflutter.so`sk_sp<SharedGenerator>::~sk_sp(this=0xcc533b54) at SkRefCnt.h:255:9
frame #15: 0xcb50b2c8 libflutter.so`SkImage_Lazy::~SkImage_Lazy(this=0xcc533b30) at SkImage_Lazy.h:22:7
frame #16: 0xcb50b2e8 libflutter.so`SkImage_Lazy::~SkImage_Lazy(this=0xcc533b30) at SkImage_Lazy.h:22:7
frame #17: 0xcb32ad6e libflutter.so`SkRefCntBase::internal_dispose(this=0xcc533b30) const at SkRefCnt.h:102:9
frame #18: 0xcb2e9864 libflutter.so`SkRefCntBase::unref(this=0xcc533b30) const at SkRefCnt.h:81:19
frame #19: 0xcb2e97f4 libflutter.so`void SkSafeUnref<SkImage>(obj=0xcc533b30) at SkRefCnt.h:154:14
frame #20: 0xcb2e94b6 libflutter.so`sk_sp<SkImage>::~sk_sp(this=0xc87b5db8) at SkRefCnt.h:255:9
frame #21: 0xcb4a4e86 libflutter.so`SkRecords::DrawImage::~DrawImage(this=0xc87b5db4) at SkRecords.h:237:1
frame #22: 0xcb4a4d2c libflutter.so`void SkRecord::Destroyer::operator(this=0xc9ac427c, record=0xc87b5db4)<SkRecords::DrawImage>(SkRecords::DrawImage*) at SkRecord.h:115:47
frame #23: 0xcb4a4afe libflutter.so`decltype(this=0xcc6e5c90, f=0xc9ac427c)(nullptr))) SkRecord::Record::mutate<SkRecord::Destroyer&>(SkRecord::Destroyer&) at SkRecord.h:161:36
frame #24: 0xcb4a4704 libflutter.so`decltype(this=0xe2d92a98, i=2, f=0xc9ac427c)(nullptr))) SkRecord::mutate<SkRecord::Destroyer&>(int, SkRecord::Destroyer&) at SkRecord.h:51:28
frame #25: 0xcb4a46be libflutter.so`SkRecord::~SkRecord(this=0xe2d92a98) at SkRecord.cpp:15:15
frame #26: 0xcb4a4718 libflutter.so`SkRecord::~SkRecord(this=0xe2d92a98) at SkRecord.cpp:12:23
frame #27: 0xcb32ad6e libflutter.so`SkRefCntBase::internal_dispose(this=0xe2d92a98) const at SkRefCnt.h:102:9
frame #28: 0xcb2e9864 libflutter.so`SkRefCntBase::unref(this=0xe2d92a98) const at SkRefCnt.h:81:19
frame #29: 0xcb2e97f4 libflutter.so`void SkSafeUnref<SkImage>(obj=0xe2d92a98) at SkRefCnt.h:154:14
frame #30: 0xcb2e94b6 libflutter.so`sk_sp<SkImage>::~sk_sp(this=0xc87d3384) at SkRefCnt.h:255:9
frame #31: 0xcb54eb6c libflutter.so`SkBigPicture::~SkBigPicture(this=0xc87d3360) at SkBigPicture.h:23:7
frame #32: 0xcb54eb8c libflutter.so`SkBigPicture::~SkBigPicture(this=0xc87d3360) at SkBigPicture.h:23:7
frame #33: 0xcb32ad6e libflutter.so`SkRefCntBase::internal_dispose(this=0xc87d3360) const at SkRefCnt.h:102:9
frame #34: 0xcb2e9864 libflutter.so`SkRefCntBase::unref(this=0xc87d3360) const at SkRefCnt.h:81:19
frame #35: 0xcb32ba82 libflutter.so`flutter::SkiaUnrefQueue::Drain(this=0xe2d9bd20) at skia_gpu_object.cc:44:18
frame #36: 0xcb32bfaa libflutter.so`flutter::SkiaUnrefQueue::Unref(this=0xe2df2864)::$_0::operator()() const at skia_gpu_object.cc:30:47
frame #37: 0xcb32bf94 libflutter.so`decltype(__f=0xe2df2864)::$_0&>(fp)()) std::__1::__invoke<flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0&>(flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0&) at type_traits:3530:1
frame #38: 0xcb32bf7e libflutter.so`void std::__1::__invoke_void_return_wrapper<void>::__call<flutter::SkiaUnrefQueue::Unref(__args=0xe2df2864)::$_0&>(flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0&) at __functional_base:348:9
frame #39: 0xcb32bf68 libflutter.so`std::__1::__function::__alloc_func<flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0, std::__1::allocator<flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0>, void ()>::operator(this=0xe2df2864)() at functional:1533:16
frame #40: 0xcb32be8a libflutter.so`std::__1::__function::__func<flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0, std::__1::allocator<flutter::SkiaUnrefQueue::Unref(SkRefCnt*)::$_0>, void ()>::operator(this=0xe2df2860)() at functional:1707:12
frame #41: 0xcb330d60 libflutter.so`std::__1::__function::__value_func<void ()>::operator(this=0xc9ac4488)() const at functional:1860:16
frame #42: 0xcb3303fa libflutter.so`std::__1::function<void ()>::operator(this= Lambda in File skia_gpu_object.cc at Line 30)() const at functional:2419:12
frame #43: 0xcb33534c libflutter.so`fml::MessageLoopImpl::FlushTasks(this=0xe2d90bf8, type=kAll) at message_loop_impl.cc:130:5
frame #44: 0xcb3352a2 libflutter.so`fml::MessageLoopImpl::RunExpiredTasksNow(this=0xe2d90bf8) at message_loop_impl.cc:143:3
frame #45: 0xcb33e66a libflutter.so`fml::MessageLoopAndroid::OnEventFired(this=0xe2d90bf8) at message_loop_android.cc:94:5
frame #46: 0xcb33e6b0 libflutter.so`fml::MessageLoopAndroid::MessageLoopAndroid(this=0x0000004d, (null)=77, events=1, data=0xe2d90bf8)::$_0::operator()(int, int, void*) const at message_loop_android.cc:42:52
frame #47: 0xcb33e68e libflutter.so`fml::MessageLoopAndroid::MessageLoopAndroid((null)=77, events=1, data=0xe2d90bf8)::$_0::__invoke(int, int, void*) at message_loop_android.cc:40:40
frame #48: 0xec36de34 libutils.so`android::Looper::pollInner(int) + 1072
frame #49: 0xec36d98a libutils.so`android::Looper::pollOnce(int, int*, int*, void**) + 30
frame #50: 0xe53d969c libandroid.so`ALooper_pollOnce + 60
frame #51: 0xcb33e4ac libflutter.so`fml::MessageLoopAndroid::Run(this=0xe2d90bf8) at message_loop_android.cc:68:18
frame #52: 0xcb335268 libflutter.so`fml::MessageLoopImpl::DoRun(this=0xe2d90bf8) at message_loop_impl.cc:96:3
frame #53: 0xcb334bfc libflutter.so`fml::MessageLoop::Run(this=0xe2da93c0) at message_loop.cc:49:10
frame #54: 0xcb33ab10 libflutter.so`fml::Thread::Thread(this=0xcd3115dc)::$_0::operator()() const at thread.cc:36:10
frame #55: 0xcb33aa68 libflutter.so`decltype(__f=0xcd3115dc)::$_0>(fp)()) std::__1::__invoke<fml::Thread::Thread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)::$_0>(fml::Thread::Thread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)::$_0&&) at type_traits:3530:1
frame #56: 0xcb33aa52 libflutter.so`void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)::$_0>(__t=size=2, (null)=__tuple_indices<> @ 0xc9ac492c)::$_0>&, std::__1::__tuple_indices<>) at thread:341:5
frame #57: 0xcb33a996 libflutter.so`void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, fml::Thread::Thread(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)::$_0> >(__vp=0xcd3115d8) at thread:351:5
frame #58: 0xebec27f2 libc.so`__pthread_start(void*) + 24
frame #59: 0xebe6efd2 libc.so`__start_thread + 26
总结
可以看到， GrGLSemaphore 的调用栈和上文的Crash日志还原的堆栈基本一致。而 GrGLGpu 的析构则是由 Shell 析构引起的，即只有Flutter Engine销毁（一般是页面退出）时才会触发。
至此，我们前面得出的Crash原因“ GrGLGpu 在 GrGLSemaphore 之前析构”要修正一下了，这只是表面现象，本质是Flutter Engine销毁了，但是还有一张（或几张）图片资源没有销毁，而这个图片真正销毁时，其调用的 GrGLGpu 已经释放了，因而出现了一次非法内存访问。
那么，为什么会有一定概率出现这种Case？我们继续分析
六、水落石出
在开始这一阶段的分析之前，我们需要理清楚几个问题：
- 业务层使用一张图片，Flutter Engine做了哪些工作
- Flutter Engine销毁时做了哪些工作
6.1 Flutter的图片加载
首先分析第一个问题，这里以单帧图片（即PNG、JPG，区别于GIF）为例，其会调用 SingleFrameCodec::getNextFrame 方法，该方法会调用图片解码器进行解码，如下：
// 代码清单 5
// lib/ui/painting/single_frame_codec.cc
Dart_Handle SingleFrameCodec::getNextFrame(Dart_Handle callback_handle) {
...... // SKIP
decoder->Decode(descriptor_, target_width_, target_height_,
[raw_codec_ref](auto image) { // 注意这个回调
std::unique_ptr<fml::RefPtr<SingleFrameCodec>> codec_ref(raw_codec_ref);
fml::RefPtr<SingleFrameCodec> codec(std::move(*codec_ref));
auto state = codec->pending_callbacks_.front().dart_state().lock();
if (!state) { // CASE 1 ui线程已经销毁，直接返回
return;
}
tonic::DartState::Scope scope(state.get());
if (image.get()) { // CASE 2 绑定带ui线程相关实例进行使用
auto canvas_image = fml::MakeRefCounted<CanvasImage>();
canvas_image->set_image(std::move(image));
codec->cached_image_ = std::move(canvas_image);
}
..... // SKIP
});
..... // SKIP
return Dart_Null();
}
这里需要注意下 CanvasImage 这个类，他是Skia的图像数据转换为Flutter使用的图像数据的封装类，当Flutter需要销毁时，会触发其 dispose 方法，如下：
// 代码清单 6
// lib/ui/painting/image.cc
void CanvasImage::dispose() {
auto hint_freed_delegate = UIDartState::Current()->GetHintFreedDelegate();
if (hint_freed_delegate) {
hint_freed_delegate->HintFreed(GetAllocationSize());
}
image_.reset(); // 触发 flutter::SkiaGPUObject<SkImage> 的析构 ，见 代码清单 8
ClearDartWrapper();
}
下面，我们继续分析下 Decode 方法，如下：
// 代码清单 7
// lib/ui/painting/image_decoder.cc
void ImageDecoder::Decode(fml::RefPtr<ImageDescriptor> descriptor_ref_ptr,
uint32_t target_width,
uint32_t target_height,
const ImageResult& callback) {
TRACE_EVENT0("flutter", __FUNCTION__);
fml::tracing::TraceFlow flow(__FUNCTION__);
auto raw_descriptor = descriptor_ref_ptr.get();
raw_descriptor->AddRef();
FML_DCHECK(callback);
FML_DCHECK(runners_.GetUITaskRunner()->RunsTasksOnCurrentThread());
auto result = // io线程解码完成触发这个lambda
[callback, raw_descriptor, ui_runner = runners_.GetUITaskRunner()](
SkiaGPUObject<SkImage> image, fml::tracing::TraceFlow flow) {
ui_runner->PostTask(fml::MakeCopyable(
[callback, raw_descriptor, image = std::move(image),
flow = std::move(flow)]() mutable {
TRACE_EVENT0("flutter", "ImageDecodeCallback");
flow.End();
callback(std::move(image)); // 在ui线程触发 代码清单 5 的 callback
raw_descriptor->Release();
}));
};
if (!raw_descriptor->data() || raw_descriptor->data()->size() == 0) {
result({}, std::move(flow));
return;
}
// 执行第一个逻辑，生成原始的图片数据，在一个独立线程
concurrent_task_runner_->PostTask(
fml::MakeCopyable([raw_descriptor, //
io_manager = io_manager_, //
io_runner = runners_.GetIOTaskRunner(), //
result, //
target_width = target_width, //
target_height = target_height, //
flow = std::move(flow) //
]() mutable {
// Step 1: Decompress the image. On Worker.
auto decompressed = raw_descriptor->is_compressed()
? ImageFromCompressedData(raw_descriptor, target_width, target_height, flow)
: ImageFromDecompressedData(raw_descriptor,target_width, target_height, flow);
if (!decompressed) {
FML_LOG(ERROR) << "Could not decompress image.";
result({}, std::move(flow));
return;
}
// Step 2: Update the image to the GPU. On IO Thread.
// 在io线程，开始图片纹理的生成
io_runner->PostTask(fml::MakeCopyable([io_manager, decompressed, result,
flow =std::move(flow)]() mutable {
if (!io_manager) { // io_manager已经销毁，由 代码清单 10 导致
FML_LOG(ERROR) << "Could not acquire IO manager.";
result({}, std::move(flow));
return;
}
if (!io_manager->GetResourceContext()) {
result({std::move(decompressed), io_manager->GetSkiaUnrefQueue()},
std::move(flow));
return;
}
// 上传到raster线程，真正消费图片纹理数据的线程
auto uploaded = UploadRasterImage(std::move(decompressed), io_manager, flow);
if (!uploaded.get()) {
FML_LOG(ERROR) << "Could not upload image to the GPU.";
result({}, std::move(flow));
return;
}
// Finally, all done. 触发上面的lambda，最终将触发ui线程的callback
result(std::move(uploaded), std::move(flow));
}));
}));
}
通过以上逻辑，我们大概知道了Flutter是如何使用图片的，即：ui线程发起一次图片解码（Decode），io线程完成解码后会把SkImage封装成 SkiaGPUObject
// 代码清单 8
// flow/skia_gpu_object.h
template <class T> class SkiaGPUObject {
public:
using SkiaObjectType = T;
...... // SKIP
~SkiaGPUObject() { reset(); }
void reset() {
if (object_ && queue_) {
queue_->Unref(object_.release());
}
queue_ = nullptr;
FML_DCHECK(object_ == nullptr);
}
private:
sk_sp<SkiaObjectType> object_;
// 注意，这个队列是多线程共享，全局唯一的，存放需要解除引用的对象
fml::RefPtr<SkiaUnrefQueue> queue_;
FML_DISALLOW_COPY_AND_ASSIGN(SkiaGPUObject);
};
继续，我们分析下 SkiaUnrefQueue 的 Unref逻辑，如下所示。
// 代码清单 9
// flow/skia_gpu_object.cc
void SkiaUnrefQueue::Unref(SkRefCnt* object) {
std::scoped_lock lock(mutex_);
objects_.push_back(object); // 登记到销毁队列
if (!drain_pending_) {
drain_pending_ = true;
task_runner_->PostDelayedTask([strong = fml::Ref(this)]() {
strong->Drain(); // 在io线程开始销毁
}, drain_delay_);
}
}
void SkiaUnrefQueue::Drain() {
TRACE_EVENT0("flutter", "SkiaUnrefQueue::Drain");
std::deque<SkRefCnt*> skia_objects;
{
std::scoped_lock lock(mutex_);
objects_.swap(skia_objects); // 取出待销毁的对象
drain_pending_ = false;
}
for (SkRefCnt* skia_object : skia_objects) {
skia_object->unref(); // 见 代码清单 2
}
if (context_ && skia_objects.size() > 0) {
context_->performDeferredCleanup(std::chrono::milliseconds(0));
}
}
由此可知，正常情况下，ui线程析构一张图片的引用，最终会通过 SkiaUnrefQueue::Unref 触发 io线程的对应对象的析构。
一般来说，Flutter页面退出时，Flutter Engine销毁，ui线程也会销毁，下面开始分析销毁逻辑。
6.2 Flutter Engine的销毁
Flutter Engine 的销毁是由宿主页面控制的，比如 FlutterActivity 会间接调用一个JNI方法 nativeDestroy ，进而触发 Shell 的析构，其逻辑如下：
// 代码清单 10
Shell::~Shell() {
PersistentCache::GetCacheForProcess()->RemoveWorkerTaskRunner(
task_runners_.GetIOTaskRunner());
vm_->GetServiceProtocol()->RemoveHandler(this);
fml::AutoResetWaitableEvent ui_latch, gpu_latch, platform_latch, io_latch;
fml::TaskRunner::RunNowOrPostTask(
task_runners_.GetUITaskRunner(),
fml::MakeCopyable([engine = std::move(engine_), &ui_latch]() mutable {
engine.reset();
ui_latch.Signal(); // ui线程析构完成，释放
}));
ui_latch.Wait(); // 等待ui线程销毁完成
fml::TaskRunner::RunNowOrPostTask(
task_runners_.GetRasterTaskRunner(),
fml::MakeCopyable(
[this, rasterizer = std::move(rasterizer_), &gpu_latch]() mutable {
rasterizer.reset();
this->weak_factory_gpu_.reset();
gpu_latch.Signal();
}));
gpu_latch.Wait();
fml::TaskRunner::RunNowOrPostTask(
task_runners_.GetIOTaskRunner(),
fml::MakeCopyable([io_manager = std::move(io_manager_),
platform_view = platform_view_.get(),
&io_latch]() mutable {
io_manager.reset();
if (platform_view) {
platform_view->ReleaseResourceContext();
}
io_latch.Signal();
}));
io_latch.Wait();
fml::TaskRunner::RunNowOrPostTask(
task_runners_.GetPlatformTaskRunner(),
fml::MakeCopyable([platform_view = std::move(platform_view_),
&platform_latch]() mutable {
platform_view.reset();
platform_latch.Signal();
}));
platform_latch.Wait();
}
以上逻辑，其实一目了然，即Shell的销毁，会触发ui/raster/io/platform线程的依次销毁，有严格的顺序关系。那么正常情况下，ui线程会在执行 engine.reset(); 时销毁所有的图片，对应的io线程任务会一一进入队列，然后ui线程释放信号，raster线程销毁，接着io线程销毁的销毁任务（主要是 io_manager_的析构 ）进入队列，由于 ui_latch 的存在，图片的销毁任务一定会先进入队列， io_manager_ 的销毁理论上是最后进入队列的。
分析到这里，眼尖的读者其实可能发现了一个逻辑上的漏洞：在 代码清单 9 中，SkiaUnrefQueue::Drain 执行其实要等待 drain_delay_ (8ms)。为什么要等待这么一个时间呢？读者可以尝试自行思考。
那么如此就会带来一个问题：万一在这8ms内，io线程已经开始销毁了，那岂不是上文所说的顺序就不成立了？莫慌！我们看一下 ShellIOManager 的析构方法：
// shell/common/shell_io_manager.cc
ShellIOManager::~ShellIOManager() {
// Last chance to drain the IO queue as the platform side reference to the
// underlying OpenGL context may be going away.
is_gpu_disabled_sync_switch_->Execute(
fml::SyncSwitch::Handlers().SetIfFalse([&] { unref_queue_->Drain(); }));
}
写的很清楚了，哪怕 io_manager_ 早早开始了销毁，在此仍有最后一次机会执行Drain 方法。此外 Drain方法的定义也有一段值得注意的说明：
// flow/skia_gpu_object.h
// Usually, the drain is called automatically. However, during IO manager
// shutdown (when the platform side reference to the OpenGL context is about
// to go away), we may need to pre-emptively drain the unref queue. It is the
// responsibility of the caller to ensure that no further unrefs are queued
// after this call.
void Drain();
也就是说Drain要求IO manager在销毁之后不再被调用。目前来说，我们从理论上看都是符合预期的。
然而，理论终究是理论，Flutter Engine忽略了一个最极限的Case，即：
- ui线程在销毁前向io线程发送了一个图片解码请求，接着ui线程开始销毁；
- ui线程销毁结束，释放锁，io线程开始销毁，
io_manager_会导致GrGLGpu实例的析构； - ui线程请求解码的图片解码完成，返回给ui线程，此时在代码清单中会直接命中CASE 1（因为ui线程已经销毁了，故 代码清单 5 的callback中
dart_state()拿到的是null，而此时image实例（本质是SkImage）已经通过std::move进入了方法作用域，而方法内又没有处理这个指针，直接return了，所以image会因为没有被引用而直接触发析构） - SkImage 开始销毁，一步步调用到
GrGLSemaphore的析构函数，访问到fGpu（第2步中已经销毁）的非法内存，报错
如下图
以上解释，和我们的复现手段完全对得上，即：进入包含图片加载的Flutter页面，然后快速退出（卡退出时ui线程请求图片io线程解码的时间差）。
七、治标治本
至此，我们终于找到了这个Crash的真正原因。那么如何解决呢？在此，笔者提出一个简单的方法：既然io线程有一定概率在销毁自身之后仍有需要销毁的图片，那我们可以给 IO Manager 增加一个计数器，IO线程每生产一张图片，计数器+1；ui线程每消费一张图片，计数器-1。然后，在 代码清单 10 中，io线程销毁时，判断计数器如果大于0，则等待几毫秒，等待ui线程全部消费完成。核心逻辑如下：
// 替换代码清单10中io线程的销毁逻辑
void clearIo(fml::AutoResetWaitableEvent* io_latch) {
fml::TaskRunner::RunNowOrPostTask(
task_runners_.GetIOTaskRunner(),
fml::MakeCopyable([io_manager = &io_manager_,
platform_view = platform_view_.get(),
io_runner = task_runners_.GetIOTaskRunner(),
shell = this,
io_latch]() mutable {
// 有图片io线程生产了，但ui线程还没消费，则延迟io线程的销毁
if (io_manager->get()->count > 0) {
io_runner->PostDelayedTask([shell, io_latch]() {
shell->clearIo(io_latch);
}, fml::TimeDelta::FromMilliseconds(8));
return;
} else {
(*io_manager).reset();
if (platform_view) {
platform_view->ReleaseResourceContext();
}
io_latch->Signal();
}
}));
}
其中计数器的+1在 代码清单 7 的 UploadRasterImage 方法之后，计数器的-1在 代码清单 7 的 callback(std::move(image)) 调用之后，注意要post到io线程执行。
此外，要彻底解决这个问题，除了要考虑单帧图片，还有考虑多帧图片的解码。
当然了，我们对于这部分的逻辑也只是初窥门道，最终的解决办法将会以Issue的形式和Flutter的官方人员最终协定。
八、总结复盘
问题至此，算是彻底有了定论，简单复盘总结一下。
8.1 80%的时间都在试错
本文已经很冗长了，但实际上，我们在解决问题时做的尝试和思考远远更多，由于堆栈无法还原+相关逻辑不熟悉，我们80%的时间其实都在试错。
8.2 为什么我们遇到了
其实，从Github的issue来看，早前已经有人遇到过了一摸一样的问题： https://github.com/flutter/flutter/issues/48062 & https://github.com/flutter/flutter/issues/50959。
只是，由于这个问题的出现概率非常极限，而提出issue的人无法提供稳定复现的路径，所以这个issue自动被关闭了。
那为什么我们就这么倒霉，偏偏以如此高的概率遇到了？我个人认为有以下几个原因：
- 由本文开始的图片可以看出，这个Flutter页面要加载很多图片，所以出现Crash的可能性自然增加
- 由本文开始的图片可以看出，Flutter浮层和Native的视频播放器共存，CPU/GPU资源其实更加紧张，所以卡到Crash的概率会大很多。之前我用Demo一直跑不出Crash的原因就是进入之后的等待时间太长了，微视的复现区间大概在0.7～1.7s，而demo则大概在0～1.0s。
- 大部分Flutter页面可能引入Flutter Egine缓存或者 Flutter Engine共用机制，这样退出的时候其实 Engine不会销毁，自然不会触发这个问题。
8.3 为什么我们解决了
- nickdxuli和panyu提供信息非常重要，一个启发了我们找到复现策略，另一个直接提示了Crash位置
- bingo在Crash解决方面经验丰富，预判准确
- 我个人对Flutter的源码还算了解
这个问题非以一人之力可以解决，感谢团队内相关同学的鼎力相助。
压力到位，谷歌干废。
