社区编辑申请
注册/登录
前车之鉴:聊聊钉钉 Flutter 落地桌面端踩过的“坑”
开发 前端 新闻
本文将阐述钉钉基于 Flutter 构建的跨四端应用框架(代号 Dutter)的技术实践与踩坑经验。

本文主要介绍一下钉钉 Flutter 业务灰度过程中,在桌面端遇到并处理过的几个 FlutterEngine 层面的 Bug。具体包含:

  • Mac 端:
  • Windows 端:

下面来为大家分别介绍一下。

FlutterEngine Mac 端问题

1.1 FlutterEngine 退出之后内存泄漏问题

1 问题背景

Mac 端 FlutterViewController 在销毁之后,其开辟的内存并未并实际释放,会出现内存泄漏问题。此问题在 Flutter issue 中有一些讨论,但一直未有明确定位。在钉钉 Mac 端 Flutter 业务灰度过程中也遇到此问题,如无法处理将直接影响 Dutter 在 Mac 端落地的可行性:

2 定位分析

一句话原因:

Mac 端 FlutterEngine 实现中对 weak property 使用不合理导致。FlutterViewController 强持有 FlutterEngine,后者持有一个指向 FlutterViewController 的 weak property。FlutterViewController 在 dealloc 流程中尝试释放 FlutterEngine,但是此时 FlutterEngine 中持有的 weak property 已经无法正确访问(nil),导致释放流程未能正常执行,出现泄漏。

下面结合具体实现来为大家做一个简单说明。

由于设计到 OC 和 C++ 对象生命周期管理问题, FlutterEngine 内部对象持有关系略微特殊一些,大致如下图所示:

  • FlutterViewController 作为对外暴露的主要 Class,负责创建并持有 FlutterEngine 以及 FlutterView;
  • FluterEngine 在初始化阶段会自己强持有自己,并在 shutdown 时自我 Release;
  • FlutterEngine 会创建并持有 FlutterRenderer,FlutterRenderer 会强持有 FlutterView;
  • FlutterEngine 间接强持有 FlutterView;
  • FlutterEngine 有一个指向 FlutterViewController 的弱引用指针。

正常情况下,FlutterViewController 退出之后,会通过调用 FlutterEngine 的 setViewController 传入 nil 的方式,来触发 FlutterEngine shudown 动作。参考实现如下:

即正常情况下,FlutterViewController dealloc 之后应该触发 369 行代码运行,进而释放 FlutterEngine 资源。但是实际运行情况缺不是这样,在代码运行到 359 行时,尝试判断 if (_viewController != controller) 时并未成立。通过上述代码我们知道,controller 是外部传入的对象此时为 nil;_viewController 作为一个 weak proptry,在 FlutterViewController 进入 dealloc 流程之后也变为 nil。因而在此流程下,我们希望中的 shutDownEngine 方法并未被调用。

3 处理方案

问题定位之后处理方式就很简单了,可以在 FlutterViewController dealloc 的时候手动触发 FlutterEngine shutDownEngine 方法。并且通过在上层通过 OC 动态特性 hook 实现、或者直接修改重新编译 FlutterEngine 都可以。

但此处修改一定要谨慎,注意完整还原 FlutterEngine 中的 shutdown 流程,否则可能导致我们遇到的第二个问题:死锁。

1.2 FlutterEngine shutdown 阶段死锁问题

1 问题背景

钉钉最初在处理上述「FlutterEngine 泄漏」问题时,采用了一种相对比较简单的方案:在 FlutterViewController dealloc 方法中,手动调用 FlutterEngine 提供的 shutDownEngine 方法,手动触发相关资源释放。

通过此方案,FlutterViewController 退出之后内存确实出现了下降,但是在灰度时发现偶尔会有整个页面卡死的情况。通过对出现问题的链路进行简单分析以及配合暴力测试,我们在 debug 环境对问题做了还原。最终初确认 UI 线程与 Raster 线程出现死锁,死锁之后的线程状态大致如下。

UI 线程状态:

Raster 线程:

2 定位分析

一句话原因:

钉钉侧调用 FlutterEngine shutDownEngine 方法不合理导致。shutDownEngine 之前,必须先调用 FlutterView 的 shutdown 方法来停止渲染流程。待渲染流程正常停止之后,才可进入 FlutterEngine 资源释放流程,否则即有可能出现上述死锁问题。

因为此问题为钉钉调用不合理导致,具体异常原因不再深入分析,感兴趣的同学可以根据上述线索自行查阅。

3 处理方案

在上层补全 FlutterEngine 释放流程,在调用 FlutterEngine shutDownEngine 之前首先调用 FlutterView shutdown 停止 Raster 线程。

1.3 低版本 macOS OpenGL 析构阶段 Crash 问题

1 问题背景

此问题还是接两个问题,在处理完问题1和问题2之后,参考 FlutterEngine shutdown 流程,钉钉会在 FlutterViewController 析构之后做3件事情:

  1. 将 FlutterRenderer 中绑定的 FlutterView 置为 nil;
  2. 调用 FlutterView shutdown 方法;
  3. 调用 FlutterEngine shutDownEngine 方法。

经过一系列处理之后,测试发现内存泄漏和死锁问题基本得以根治。但是在内部灰度过程中发现低版本 macOS 上会出现 Crash,堆栈大致如下:

2 定位分析

一句话原因:

与问题2类似,此问题也是因为钉钉处理泄漏问题而引入。其大致由两方面因素迭代导致。一方面因为重置 FlutterOpenGLRenderer 绑定的 FlutterView,导致在 embedder 层创建的 OpenGL 对象被提前释放;另外一方面因为低版本 macOS OpenGL 实现不完善析构流程中未能对关键链路做保护,进而导致异常。

下面对异常相关代码做一下简答分析,避免其他同学再遇到类似问题。

  1. 在 FlutterEngine setViewController 方法中,如果处于释放流程,会调用 FlutterOpenGLRenderer setFlutterView 方法,并传入 nil:

  1. FlutterOpenGLRenderer setFlutterView 方法在入参为 nil 时,会释放其内部维护的 NSOpenGLContext 对象:

  1. FlutterEngine 底层实现会在 GrDirectContext 对象析构时执行 flush,如果此时 OpenGL 相关对象已经释放,在低版本 macOS(10.11, 10.12)会出现 Crash:

3 处理方案

由于出现问题的部分是由钉钉上层代码触发,处理相对比较简单。最终我们在所有使用 OpenGL 渲染的 Mac 设备上(macOS 10.14 之前的版本)移除 FlutterView 置空动作。即最终 FlutterViewController 释放阶段只执行以下两个动作:

  1. 调用 FlutterView shutdown 方法;
  2. 调用 FlutterEngine shutDownEngine 方法。

FlutterEngine Windows 端问题

2.1 Win7 设备渲染模块「Crash + 残影」问题

1 问题背景

此问题背景略微有些复杂,如果细分来看的话,此问题应该可以拆分为两个子问题。

第一个问题是,在部分 Win7 设备上(x86 + x64)出现 d3d11 导致的 Crash,堆栈大致如下:

由于迟迟无法定位导致此问题的具体原因、且 Flutter 官方表示他们对 Win7 设备的覆盖度并不完善「参考」(https://github.com/flutter/flutter/issues/92650#issuecomment-961341821)。因此我们决定对 FlutterEngine 稍加定制,在 Win7 等陈旧设备上强制通过「软解模式」来渲染 Flutter 页面。

本以为通过此方式可以绕过此问题,但很不幸运的是此方案暴露了 FlutterEngine 里另外一个 Bug:通过「软解模式」来渲染页面时,FlutterViewController 关闭只有有一定概率会导致 Windows 桌面出现残影。

2 定位分析

一句话原因:

此问题主要是因为 FlutterEngine 内部 shutdown 流程中,未及时修改 FlutterWindowsEngine 指向 FlutterWindowsView 对象的指针,导致多线程场景下出现野指针;因为野指针导致raster 线程在 FlutterWindowsView 已经销毁情况下仍向其输出绘制帧,进而导致异常。

在定位时,我们通过增加辅助 log 的方式来加快问题定位过程。通过对关键节点补充日志,我们很快发现了可疑点:

上图是出现问题之后关键节点输出的日志。我们通过日志可以得到以下关键信息:

  1. OnBitmapSurfaceUpdated 是 FlutterWindowsView 的成员函数。但是在输出最后两行 OnBitmapSurfaceUpdated 方法时,FlutterWindowsView 的析构函数已被执行(野指针);
  2. 最后一次执行 OnBitmapSurfaceUpdated 时,渲染使用的 Window 句柄为 nullptr,即可供渲染的窗口(与 FlutterWindowsView 绑定)以被释放。

因为最后渲染所使用 Window 句柄为 nullptr,进而导致出现残影问题。

补充说明:在调用 C++ 成员函数时,即使调用时 this 已经为野指针,但只要成员函数中并未访问到 this 对象,则不会出现内存访问异常(Crash)。

3 处理方案

修改 FlutterEngine 内部实现,在 SoftwareRenderer 模式下 FlutterWindowsView 析构时,置空 FlutterWindowsEngine 指向其的指针(因 GPU 模式会有异常输出,暂未修改):

通过此方式,可以保证在 FlutterWindowsView 销毁之后 raster 线程中的任务不会再回调渲染接口:

2.2 FlutterPlugin 注册阶段野指针 Crash

1 问题背景

在钉钉 Flutter 版本「+面板」业务 Windows 端一灰、二灰阶段出现较多例 Crash,客户端整体 Crash 率高达 x%:

通过简单分析,还原 Crash 堆栈大致如下:

从堆栈可以达到两个比较重要的信息:

  1. Crash 出现在 FlutterEngine 初始化阶段,具体是在 Plugin 注册时出现异常;
  2. 导致 Crash 原因是野指针问题。

2 定位分析

一句话原因:

Flutter 为 Windows 平台提供 wrapper 层代码中,包含一个设计上为单例的对象 PluginRegistrarManager。PluginRegistrarManager 主要服务于 FlutterPlugin 注册、设计上为一个单例,其内部通过 map 维持了一个 FlutterEngine 指针与 Registrar 的映射关系,保证 Registrar 与 FlutterEngine 生命周期保持一致。但是因为 wrapper 层的代码在构建时被编入了 pulgin.dll,导致每一个 plugin.dll 中都包含一份 PluginRegistrarManager 实现副本,即「单例机制」失效。带来的问题是 FlutterEngine 析构时无法正确清除 PluginRegistrarManager 中的绑定关系,导致其内部维护一个失效的指针地址,再次访问时出现 Crash。

下面简单介绍一下分析过程。通过暴力测试,我们可以复现问题:

根据上图可以确认,出现 Crash 是因为 FlutterEngine 对象野指针导致。进一步定位插件注册时 Engine 指针来源,最终可定位到 flutter::PluginRegistrarManager::GetInstance()->GetRegistrar() 方法中:

进一步分析 PluginRegistrarManager 中的实现,可知 GetRegistrar 内部需要 map + emplace 方法来维系 FlutterEngine 地址与 Registrar 关系:

其内部会通过 FlutterDesktopPluginRegistrarSetDestructionHandler 将方法注册到底层 Engine 对象中,其会在 FlutterEngine 析构时被调用,进而解除绑定关系:

问题即出现在此流程中, 如果 PluginRegistrarManager 并非真正的单例,且 FlutterEngine 只能维护一份有效的 OnRegistrarDestroyed 回调 ,那么在 FlutterEngine 析构时,有部分 PluginRegistrarManager 对象中保存的 FlutterEngine 地址不会被清除,再次使用时即会导致问题。

3 处理方案

修改 FlutterEngine wrapper 层 PluginRegistrarManager 实现,优化「单例」实现方案。将单例生命周期周期管理下层到底层,wrapper 层仅负责提供相关服务。

具体可参考:

2.3 Flutter Window 可见性变化之后页面白屏

1 问题背景

在 Windows 端 Flutter 页面中,如果将 Flutter Window:

  • 先通过 ShowWindow(flutter_wnd, SW_HIDE) 隐藏;
  • 再通过 ShowWindow(flutter_wnd, SW_SHOWNORMAL) 显示出来。

会发现 Flutter 页面内容无法正常展示,画布上为空白一片。如果在白屏之后通过 setState 或者 拖拽窗口等方式触发  Flutter 页面刷新,则内容可被正常渲染。

2 定位分析

此问题相对比较明确,Flutter Windows 端实现存在 bug,在 Window 可见性发生变化之后,应重新出发 flush 将最新视图绘制到对应窗口,但是目前此流程并未实现,导致出现以上问题。

3 处理方案

此问题已经提交issue,暂时钉钉侧是通过上层补偿的方式来绕过此此问题。我们在 Native Window 可视性变化之后,手动通知 Flutter 侧刷新当前可见页面,以此触发重绘、规避问题。

总结

以上即为钉钉 Flutter 落地过程中桌面端处理的几大主要问题。从我们实际体验来看,虽然在 Flutter v2.10 版本已经正式发布对 Windows 的支持。但仅从稳定性角度来看,Flutter 在 Mac 端的表现无疑要优于 WIndows。如果有其它团队希望在使用 Flutter 在桌面单端做一下尝试,我们优先推荐选择 Mac 端,其无论是上手门槛还是性能稳定性表现,相比 Windows 端要更有优势。

责任编辑:张燕妮 来源: 阿里巴巴移动技术
相关推荐

2022-05-18 10:58:36

LinuxKali Linux

2022-05-24 08:21:16

数据安全API

2022-05-16 07:35:21

Windows远程桌面远程服务器

2022-05-11 12:52:25

框架实践应用

2022-05-16 08:50:23

2022-05-17 08:39:05

VueViteTypeScript

2022-05-16 10:41:40

GNOME 42Console控制台

2022-05-10 08:59:25

2022-04-18 16:25:17

办公软件钉钉飞书

2022-05-17 09:19:17

XebianLinuxLinux 发行版

2022-04-23 17:49:05

元宇宙51CTOMetaCon

2022-05-13 09:27:55

Widget机票业务App

2022-05-20 11:25:59

中台计算数据

2022-03-31 07:52:01

Java多线程并发

2022-05-17 13:40:21

云原生混部开源

2022-04-02 10:23:12

MySQL数据库

2022-04-28 09:36:51

微服务性能云原生

2022-04-22 13:04:43

微软Windows 10

2022-05-13 11:24:09

数据美团

2022-04-11 07:50:58

同话题下的热门内容

让程序员心动的11种新编程语言Flutter vs ReactJS:2022年应该选哪个?再有人问你什么是分库分表,直接把这篇文章发给他前端配置化真香~上班又多了60%的摸鱼时间2022年值得使用的 Node.js 框架HTTP 的缓存为什么这么设计?前端监控的搭建步骤,别再一头雾水了!如何加快Java中大型集合的处理

编辑推荐

太厉害了,终于有人能把TCP/IP协议讲的明明白白了!牛人5次面试腾讯不成功的经验HBase原理–所有Region切分的细节都在这里了Javascript如何监听页面刷新和关闭事件如何搭建一个HTTPS服务端
我收藏的内容
点赞
收藏

51CTO技术栈公众号