腾讯 Kuikly 开源框架新增支持 Web
Kuikly是腾讯广泛应用的跨端开发框架,基于Kotlin Multiplatform技术构建,为开发者提供了技术栈更统一的跨端开发体验,由腾讯大前端领域 Oteam(公司级)推出。
本次在Android、iOS、鸿蒙开源基础上,将新增开源Web版,支持H5和微信小程序,进一步扩展多端适配场景。Kuikly适配的H5和微信小程序已接入腾讯多款业务,如搜狗输入法、鹅毛市集、QQ小游戏等。
Kuikly Web版在H5和微信小程序上已经实现了绝大多数核心组件能力,运行效果如下:
Kuikly是基于客户端技术栈设计,在支持Android、iOS、鸿蒙高性能跨端的基础上,拓展支持H5和小程序,以达到更多端的复用。这与一些业界跨端框架定位是类似的,如 Flutter、Compose Multiplatform 等。
官方从其中挑选了两个框架,从多个维度与它们对比在H5与微信小程序场景下的差异。
产物大小
在H5平台上,三个框架编译产物大小差别很大,Kuikly包体积优势明显。
- 业界基于终端技术栈的跨端方案,都是通过自绘引擎,通过 WASM 技术运行在浏览器上,编译后产物体积很大。
- Kuikly Web使用DOM渲染方案,不依赖第三方产物,产物远小于其他框架,只有463KB。
页面加载速度
在iOS,Android和PC浏览器环境进行性能测试(运行Hello World Demo),Kuikly在三个浏览器环境下加载速度都是最快的。
iOS加载速度对比
Android加载速度对比
PC 性能数据对比
在MacBook Pro M4Pro 电脑的Chrome浏览器(138.0.7204.158)上,使用开发者工具上进行了详细的性能测试。测出Kuikly的FCP耗时仅为87.76ms,不到其他框架的一半。
其他优势
在H5平台上与主流跨端框架对比,Kuikly还具有以下优势:
- 开发体验: Android Studio 完善的开发支持。
- 代码调试: 可直接调试JS或通过SourceMap调试Kotlin。
- SEO友好: 采用DOM渲染,传统的SEO优化都可以生效。
- 兼容性好: 仅依赖ES6和CSS3特性,大部分设备都支持。
- 生态复用: 编译产物是JS,采用DOM渲染方案,可通过Kuikly自定义扩展复用React等H5生态库。
微信小程序支持
主流的基于终端技术栈的跨端框架,缺少官方微信小程序运行方案支持,Kuikly Web版微信小程序的出现填补了这部分空白。
Kuikly的架构设计回顾
简单回归一下Kuikly的整体架构,跨端Core层处理框架核心逻辑,Render层负责不同平台渲染。新平台接入Kuikly需要实现自己的Render层。
Kuikly Web版本整体方案设计
在进行Kuikly Web版H5和微信小程序适配工作时,发现许多代码可以共用,因此抽象了一个Web容器运行时作为适配层,这个适配层依赖抽象的DOM API、KuiklyWindow、KuiklyDocument,实现了绝大部分Render逻辑。
Web容器运行时
通过抽象核心接口构建Web容器运行时,实现了以下能力:
- 将Kuikly的UI操作转换为标准DOM操作
- 为差异化模块(动画/列表/文本测量等)提供扩展接口
- 支持JS宿主通过实现Web容器运行时接口,接入Kuikly
H5运行时
浏览器提供了标准的DOM,Window,Document。Kuikly适配H5时只需实现动画,滚动列表,文本测量等少部分 Web容器运行时拓展接口。
微信小程序运行时
项目团队在适配微信小程序之前,调研了目前支持微信小程序的跨端框架。这些框架基本都是基于前端技术,在微信小程序上基本采用编译时或者运行时方案,最终都是数据驱动模板完成UI渲染。如下图:
借鉴了业界主流小程序框架Tarojs和Kbone的思路,结合Kuikly框架的特点,通过实现Web容器运行时接口,提供轻量级DOM和拓展接口实现,仅实现Kuikly需要的能力,并做了一系列针对Kuikly渲染流程的优化。如下图:
目前Kuikly适配微信小程序的方案在性能上仍有不少优化空间,后续将会探索编译Kuikly产物为WASM,使用预编译等方式优化Kuikly在微信小程序平台的体验。
技术展望
- 继续对Kuikly Web版进行性能优化,使用预编译进一步提升小程序性能,同时减少编译产物大小。
- 探索使用WASM提升计算密集型任务的执行效率,优化Kuikly Web版的使用体验
- 扩大Kuikly Web版支持范围,下半年将开源Electron环境的适配

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
字节跳动辟谣:与芯原股份并无 AI 芯片相关合作
近日,业内消息传字节跳动正与芯原股份联手设计一款先进的AI算力芯片。对此,字节跳动相关负责人回复称:字节跳动与芯原股份并无AI芯片相关合作。 这并不是字节跳动第一次传出与其他厂商联手设计 AI 芯片(处理器)。去年上半年,曾有外媒报道称字节跳动与博通公司合作开发 AI 处理器,以确保有足够多的高端芯片。这款 AI 处理器制程为 5nm,将由台积电制造。虽然设计工作进展顺利,但标志着设计阶段结束和制造开始的“流片”尚未开始。字节跳动后续否认了“与博通合作开发 AI 芯片”相关传闻。 去年 9 月,针对媒体报道的字节跳动计划与台积电就 AI 芯片开展合作,字节方面回应表示,报道不实。字节跳动称公司在芯片领域确实有一些探索,但还处于初期阶段,主要是围绕推荐、广告等业务的成本优化,所有项目也完全符合相关的贸易管制规定。
- 下一篇
高性能缓存设计:如何解决缓存伪共享问题
在多核高并发场景下,缓存伪共享(False Sharing) 是导致性能骤降的“隐形杀手”。当不同线程频繁修改同一缓存行(Cache Line)中的独立变量时,CPU缓存一致性协议会强制同步整个缓存行,引发无效化风暴,使看似无关的变量操作拖慢整体效率。本文从缓存结构原理出发,通过实验代码复现伪共享问题(耗时从3709ms优化至473ms),解析其底层机制;同时深入剖析高性能缓存库 Caffeine 如何通过内存填充技术(120字节占位变量)隔离关键字段,以及 JDK 1.8 的@Contended注解如何以“空间换时间”策略高效解决伪共享问题,揭示缓存一致性优化的核心思想与实践价值,为开发者提供性能调优的关键思路。 伪共享 伪共享(False sharing)是一种会导致性能下降的使用模式,最常见于现代多处理器CPU缓存中。当不同线程频繁修改同一缓存行(Cache Line)中不同变量时,由于CPU缓存一致性协议(如MESI)会强制同步整个缓存行,导致线程间无实际数据竞争的逻辑变量被迫触发缓存行无效化(Invalidation),引发频繁的内存访问和性能下降。尽管这些变量在代码层面彼此...
相关文章
文章评论
共有0条评论来说两句吧...