网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

技术上的另一大挑战便是外界对于 QQ桌面端使用 Electron的质疑,尤其是内存方面。外界有些用户在没有使用和分析的情况下对此发表一些夸大和否定的言论,也确实给 QQ技术团队带来不小压力,但他们却始终坚定选型方向,也相信其中的问题可以被攻克和解决。

技术选择之争:为何 QQ选择 Electron而非纯 Native技术栈?

确实当时有很多人在问,为什么 Windows不用原生去实现?为什么不用 Qt?

“首先不太想和以前一样,Windows、macOS、Linux三端各由一个团队分开负责。在国内这种人才环境里面,相关的纯原生的开发人员其实非常难招了,桌面端的人才稀缺,同时也投入比较大。

而对于 Qt技术栈,他们首先考虑的其实还是人才的问题,国内熟练 Qt技术栈的人非常少。如果对这个框架不了解,使用它反而是一个负向作用。

至于微软的 Webview2,从本质上讲,Webview2和 Electron并没有太大的区别,只是相对在其中打包了一些微软自身的优化措施,其他方面也不是很完善,而且还无法跨平台。虽然内存方面相较于 Electron做了更多的优化。但据了解,比如微软 Teams也没有完全切到 Webview2。并且由于它没有开源,因此也没有办法基于 Webview2做定制优化。

包括 Flutter,QQ团队表示他们当时也有过调研。他们放弃的一个原因是 Flutter在桌面端的完善程度并不高,也担心标准化的问题。虽然当前 Flutter非常流行,但谁也说不好这是不是“2015年的 React Native”。大家担心随着时间推移,这套技术可能会失去维护支持,因为本身 Google使用 Flutter的占比也比较小。

“虽然它很热,但我们历史上踩过了很多很多非标准化的坑,一旦某个技术栈热度一过、维护力度不够,它就会成为全新的负债,做选型时必然也是避免再有类似经历。”

至于为什么最后选择 Electron,QQ技术团队表示主要是基于以下几个考量:

首先最看重的是框架成熟度和技术栈的标准化。Electron基于 Web技术栈,有足够低的上手和使用成本,不需要为了使用框架本身,还需要投入额外巨大人力成本去做基建和周边工具链的建设,以前在 RN、Flutter的实践上都有类似的情况。而使用 Electron,现有的 Web前端的大部分基建都可以直接复用,而且使用 Web开发 UI的效率,在主流技术栈里算是很高的了。至于迭代效率我觉得从新版桌面 QQ功能的迭代速度就可以证明,这放在以前是完全办不到的。另外由于 Web技术栈是标准化的,假如 Electron修改开源协议或者要闭源了,他们也能很方便的去写出一套类似的框架。只不过现在已经有开源的了,没必要再去重复建设一个。而且随着 Web标准长久发展,Web技术栈也不会有大的问题,而且还会越来越好。

其次是技术经验及人才储备,技术选型是否适合当前团队也是一个很重要的考虑点,团队是否有相关的技术积累,是否有人才储备来持续投入这个技术栈。Qt的确在性能上是一个很好的选择,但目前团队对 Qt没有太多积累,基建基本没有,而且相关人才其实比较匮乏,招聘就更难了。而当前 QQ技术团队 Web前端团队还是有比较多的积累,在 QQ频道项目中,也完整验证了 Electron的技术可行性。

最后就是 Electron具备的桌面端跨平台的优势。但 QQ NT架构并不是仅指 Electron,Electron主要是作为 UI跨平台的框架,只是占比很小的一部分,并且 QQ桌面端不是全部用 Electron实现,QQ NT最核心的部分还是 QQ底层通用抽象的模块,称之为 NT内核,包括核心登录、消息系统、关系链、富媒体、长连接、数据库等等模块,完全用 C++实现,全平台通用。因此底层是完全跨平台的架构,而 Electron只是上层桌面端 UI跨平台较薄的一层。

“其实我们当时选型的时候,也的确看得到大家对 Electron的评价褒贬不一,但我们还是有信心去解决这个问题,前期也做了一些技术的 Demo和预研。实际上 Electron并没有糟糕到这个地步。我们觉得可能是国内很多没有用过 Electron的开发者,对这个框架有些忌惮。其实你到 Electron的网站去看,还是有非常多国内外的亿级 DAU产品都使用 Electron框架。目前这几年主流的桌面端应用基本都选择了 Electron,如 Visual Studio Code、Discord、Slack、Skype、Whatsapp、Figma等等,新的应用基本上也是首选 Electron,版本的迭代速度和社区氛围都很在线。”