WTK 全称 Toolkit AnyWhere，是 ZLG 开发的开源 GUI 引擎，旨在为嵌入式系统、WEB、各种小程序、手机和 PC 打造的通用 GUI 引擎，为用户提供一个功能强大、高效可靠、简单易用、可轻松做出炫酷效果的 GUI 引擎。

AWTK 寓意有两个方面：

• Toolkit AnyWhere。
• ZLG 物联网操作系统 AWorks 内置 GUI。

AWTK 运行效果截图：

AWTK 主要特色：

1、跨平台

AWTK 是跨平台的，这有两个方面的意思：

• AWTK 本身是跨平台的。目前支持的平台有 ZLG AWorks、Windows、Linux、MacOS、嵌入式 Linux、Android、Web 和嵌入式裸系统，可以轻松的移植到各种 RTOS 上。AWTK 以后也可以运行在各种小程序和 iOS 等平台上运行。
• AWTK 同时还提供了一套跨平台的基础工具库。其中包括链表、数组、字符串 (UTF8 和 widechar)，事件发射器、值、对象、文件系统、互斥锁和线程、表达式和字符串解析等等，让你用 AWTK 开发的应用程序可以真正跨平台运行。

2、高效

AWTK 通过一系列的手段保证 AWTK 应用程序高效运行：

• 通过脏矩算法只更新变化的部分。
• 支持 3 FrameBuffer 让界面以最高帧率运行 （可选）。
• UI 描述文件和主题文件使用高效的二进制格式，解析在瞬间完成。
• 支持各种 GPU 加速接口。如 OpenGL、DirectX、Vulkan 和 Metal 等。
• 支持嵌入式平台的各种 2D 加速接口。目前 STM32 的 DMA2D 和 NXP 的 PXP 接口，厂家可以轻松扩展自己的加速接口。

3、稳定

AWTK 通过下列方式极力让代码稳定可靠：

• 使用 cppcheck 和 facebook infer 进行静态检查。
• 使用 valgrind 进行动态内存检查。
• 近两万行的单元测试代码。
• ZLG 强大 GUI 团队的支持。
• 经过多个实际项目验证。
• 多平台 / 多编译器验证。
• 优秀的架构设计。
• Code Review。
• 手工测试。

4、强大

• 丰富的控件 （持续增加中）。
• 支持各种图片格式 (png/jpg/gif/svg)。
• 支持各种字体格式 （点阵和矢量）。
• 支持窗口动画
• 支持控件动画
• 支持高清屏。
• 支持界面描述文件。
• 支持主题描述文件。
• 支持控件布局策略。
• 支持对话框高亮策略。
• 丰富的辅助工具。
• 支持从低端的 Cortex M3 到各种高端 CPU。
• 支持无文件系统和自定义的文件系统。
• 支持裸系统和 RTOS。

5、易用

• 大量的示例代码。
• 完善的 API 文档和使用文档。
• ZLG 强大的技术支持团队。
• 用 AWTK 本身开发的界面编辑器 （开发中）。
• 声明式的界面描述语言。一行代码启用控件动画，启用窗口动画，显示图片 (png/jpg/svg/gif)。

6、高度扩展性

• 可以扩展自己的控件。
• 可以扩展自己的动画。
• 可以实现自己的主循环。
• 可以扩展自己的软键盘。
• 可以扩展自己的图片加载器。
• 可以扩展自己的字体加载器。
• 可以扩展自己的输入法引擎。
• 可以扩展自己的控件布局算法。
• 可以扩展自己的对话框高亮策略。
• 可以实现自己的 LCD 接口。
• 可以扩展自己的矢量引擎 （如使用 skia/cairo)。所有扩展组件和内置组件具有相同的待遇。

7、多种开发语言

AWTK 本身是用 C 语言开发的，可以通过 IDL 生成各种脚本语言的绑定。生成的绑定代码不是简单的把 C 语言的 API 映射到脚本语言，而是生成脚本语言原生代码风格的 API。目前支持以下语言 （以后根据需要增加）：

• C
• Lua
• Javascript on jerryscript
• Javascript on nodejs
• Javascript on quickjs

8、国际化

• 支持 Unicode。
• 支持输入法。
• 支持字符串翻译 （实时生效）。
• 支持图片翻译 （实时生效）。
• 文字双向排版 （计划中）。

9. 开放源码，免费商用 (LGPL)。

是不是很强大，想了解更多，请阅读原文。

开源项目地址：https://github.com/zlgopen/awtk

开源项目作者：zlgopen

者 | 褚杏娟、核子可乐

近日，JetBrains 发布了Kotlin 1.8.20 beta 版本，其中包括一项名为“Kotlin/Wasm”的实验性功能，明确将 WebAssembly 设为编译目标。据介绍，新版本依赖于原生 Wasm 垃圾收集功能 WasmGC，后者同样处于早期开发阶段。

JetBrains 总结了 Kotlin/Wasm 的优势：

• 与 wasm32 Kotlin/Native 目标相比，Kotlin/Wasm 的编译速度更快，因为后者不必使用 LLVM。
• 由于 Wasm 垃圾收集支持，与 wasm32 目标相比，Kotlin/Wasm 与 JS 的互操作性、与浏览器的集成更容易。
• 与 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 应用程序启动时间可能更快，因为 Wasm 具有紧凑且易于解析的字节代码。
• 与 Kotlin/JS 和 JavaScript 相比，Kotlin/Wasm 应用程序运行时性能更快，因为 Wasm 是一种静态类型语言。

不过，目前还没有 IDE 为 Kotlin/Wasm 提供支持。JetBrains 在版本发行说明中提到，“我们以开箱即用的形式，为 Kotlin/Wasm 提供 Kotlin 标准库（stdlib）和测试库（kotlin/test）。”

浏览器中运行的 Kotlin/Wasm 演示

此前，通过基于 LLVM 的 Kotlin-Native 编译指向和 LLVM Wasm 支持，Kotlin 已经能够在某种程度上实现向 Wasm 的编译，这种旧方法被称为 wasm32。随着新版本的发布，该方法将成为被弃用的多种 Kotlin/Native 编译目标之一。

作为一种 JVM 语言，Kotlin 具备垃圾收集机制，但此前 Wasm 一直无法原生支持垃圾收集，这就要求各垃圾收集语言自行提供解决方案。Wasm-gc 就是其中一项提案，承诺“对高级语言做出有效支持”。此次，这一设计有望超越自定义解决方案，并减少应用程序的二进制文件大小。Wasm-gc 可通过浏览器 Flag 在最新版本的 Chrome、Firefox 和 Edge 上启用。

Kotlin 的“通用型语言”理想

早在 2017 年，主流浏览器都已经支持 WebAssembly。随着 WebAssembly 的蓬勃发展，各种编程语言也在增加对其的支持。比如，C/C++、Rust、Golang 等已支持将语言编译到 WebAssembly 目标平台，Lua、JavaScript、Ruby 和 Python 等支持将语言的虚拟机或解释器编译到 WebAssembly 平台。

2021 年，WebAssembly 开源项目开始支持 GC（垃圾回收器），为实现 WebAssembly 支持像 Java、Kotlin 这样的前端语言做准备。同年，Kotlin 程序语言开发团队更新了发展路线，其中的一个重点就是增加 WebAssembly 支持。

Kotlin 总项目经理 Egor Tolstoy 表示，他们认为 WebAssembly 会成为未来创建丰富网页应用程序的新标准，而 Kotlin 必需要能够完美的提供支持。因此官方火力全开，组建了一个专门团队来开发 Kotlin/Wasm 工作，并且与 WebAssembly 垃圾回收提案作者紧密合作，要实现 Kotlin 语言的基本功能、函数库和基本 Gradle 的支持，还要添加实验性 JavaScript 互通操作功能。

Kotlin 在 2017 Google 发表声明后总被当成是安卓专用开发语言，但实际上，Kotlin 正在积极地向多平台语言演进，即“通用型语言”。

如今，JetBrains 提供了多个支持多平台的库，如 kotlinx.coroutines、kotlinx.serialization、kotlinx-datetime。而 Kotlin 社区也紧跟着这样的趋势发展，出现了愈来愈多的库、框架来支持多平台，如 Arrow、Okio、Apollo 等在新版本中都支持了多平台开发。

Kotlin/Wasm 究竟有什么潜力

在最初的设计中，WebAssembly 只是 C、C++或 Rust 这些低级语言的编译目标。至于 Python、Ruby 甚至是 JavaScript 等动态语言，能充当解释性的虚拟机即可。

但 WebAssembly 垃圾收集（GC）的贡献者们正努力把它打造成垃圾收集语言（例如 Java、Kotlin 或 Dart）的编译目标，并停止使用 JavaScript 作为 Web 字节码。此外，他们还考虑把其他语言也都转化成前端开发中的理想选项，而不必像 TypeScript 那样把一切先编译成 JavaScript。

请注意，这些语言已经能够在各个应用程序内提供自己的自定义垃圾收集，借此实现对 WebAssembly 的编译。这样做的缺点就是这样生成的工件会更大，所以也不知道 WasmGC 真正推出时，原来的这种处理方式还有没有竞争力。

WasmGC 的实现源自 Chrome、Firefox、Edge 和 Safari 四大浏览器的一个持续性项目，目前需要使用 Flag 加以启用（例如，在 Chrome 或 Edge 上，需要使用--js-flags=--experimental-wasm-gc 命令行参数）。正是因为达不到开箱即用的程度，所以该技术目前还没能得到广泛采用。

但是，当 WasmGC 步入第四阶段并在大多数浏览器中实现开箱即用后，能够利用 WasmGC 的语言将迎来显著的竞争优势。

在 VMware 从事 Spring Framework 工作的 Sébastien Deleuze 称，Kotlin/Wasm 很早就在关注 WasmGC，谷歌也在使用 J2CL 和 Dart 在 Google Sheets 中将 Java 编译为 WasmGC。

前端（及全栈）开发

“因为要求开发者同时了解 Kotlin 和 JavaScript 两套生态系统，所以我个人一直对 Kotlin/JS 不太感冒，但 Kotlin/Wasm 确实是个重塑前端开发面貌的好机会。”Deleuze 表示，“当然，Kotlin/Wasm 必须要提供良好的 JavaScript 互操作性（它也确实做到了），并作为可选项。”

目前，Kotlin/Wasm 提供 DOM API，所以某些 Kotlin/Wasm 前端框架可能已经足够成为前端开发的理想选择。Deleuze 表示自己可能也会试试将 Kotlin/Wasm 用于前端开发，再配合 Spring Boot Kotlin/JVM 后端实现 Kotlin 中的全栈开发。

但从另一个角度来看，WebAssembly 还有更多值得发掘的亮点。如果 Compose for Web（Android 上使用的多平台版 Jetpack Compose）能够用 Kotlin/Wasm 代替 Kotlin/JS 来完美执行基于 Canvas 的像素渲染，结果又会如何？（稍做剧透，其实已经实现了。）

如果 Kotlin/Wasm 能够用 WebAssembly 来取代 JavaScript，支持一种新的 Jamstack 架构，结果又会如何？

WebAssembly 组件模型

要想充分理解 Kotlin/Wasm 的巨大潜力，就不能不提 WebAssembly 组件模型。正是它的存在，让我们能使用任意支持 WebAssembly 的语言，为 WebAssembly 开发组件。这项工作的基石正是 WIT 格式，可用于描述导入和展出并生成特定于语言的 binding。

Deleuze 亲自实践了一下，看看 WIT 是如何被转译成 Kotlin 的，结果看起来还不错。例如，其尝试将 WIT variant 定义为：

variant filter {
    all,
    none,
    some(list<string>),
 }

复制代码

转译出的 Kotlin 代码如下：

sealed interface Filter {
   object All : Filter
   object None : Filter
   class Some(val value: List<String>): Filter
}

复制代码

利用 String 提供的 null 安全特性，WIT option<string> 能够被准确转译为 Kotlin 惯用的选项值处理方式。在 Deleuze 看来，Kotlin 协程也将成为组件模型异步支持绑定中一个强大的竞争优势。

用 warg 实现 WebAssembly 包管理

大家可能会好奇 WebAssembly 要如何发布和使用。别担心，面向 WebAssembly 包的标准化管理项目 Warg，有望带来各种包 repo 实例，其中的关键就是 WebAssembly 包 repo 将支持多语言。

没错，Maven Central 或者 NPM 在 Java 和 JavaScript 之外的语言中也有使用，但无论是生产还是消费都摆脱不了“二等公民”的阴影。Warg 和 WebAssembly 将真正把多语言组件推向全新的高度。

Deleuze 预测，像 Rust/C/C++这样的语言将主要用于生产 Wasm 组件（强调效率，只为非共享方法提供极小、甚至干脆不提供运行时）；而 Kotlin/Wasm 这类能利用 WasmGC 的语言，则主要负责构建使用这些组件的应用程序。当然，Rust 也可以用来开发 Wasm 应用程序，但 Deleuze 猜测 WasmGC 语言才是这类用例中的主导者。

WASI

所谓 WASI，简言之就是在定义标准化系统接口（包括文件系统、时钟、环境变量、命令行参数或者标准输入/输出）应该如何被公开给 Wasm 应用程序。机器学习、人工智能或者云存储等其他用例也可以通过 WASI 进行标准化。

Kotlin/Wasm 目前还不支持 WASI，但开发团队已经提供低级 API 实现。有趣的是，只需要提供 WASI 平台中的特定部分，就能使用 Kotlin 的多平台库（例如 kotlinx-datetime 或 Okio）。

“ Kotlin/Wasm + WASI ”将并发出惊人的潜能：它可以提供 Kotlin/JVM 的替代方案，将应用程序部署到云端、边缘甚至是 Serverless 函数的形式；也被大量用作容器镜像的替代方案，能在几微秒内完成实例化、提供更高的安全性且不依赖于任何特定硬件或操作系统。这样的特性可能让人想起 Java 在 1995 年提出的“一次编写，随处运行”（WORA）口号。

目前实现这一愿景的主要障碍在于，Wasmtime 等纯 WASI 运行时还不支持 WasmGC。目前，运行 Kotlin/Wasm WASI 应用程序的主要途径是利用 Node WASI 支持。

附：如何启用 Kotlin/Wasm

要启用 Kotlin/Wasm 并对其进行测试，请更新您的 build.gradle.kts 文件：

plugins {
    kotlin("multiplatform") version "1.8.20-Beta"
}




kotlin {
    wasm {
        binaries.executable()
        browser {
        }
    }
    sourceSets {
        val commonMain by getting
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test"))
            }
        }
        val wasmMain by getting
        val wasmTest by getting
    }
}

复制代码

可查看包含 Kotlin/Wasm 示例的 GitHub 存储库

要运行 Kotlin/Wasm 项目，您需要更新目标环境的设置：

• Chrome，对于版本 109 或更高版本：

1. 在您的浏览器中转到 chrome://flags/#enable-webassembly-garbage-collection。
2. 重新启动浏览器应用程序。

• Firefox，对于版本 111 或更高版本：

1. 在您的浏览器中转到 about:config。
2. 启用 javascript.options.wasm_function_references 和 javascript.options.wasm_gc 选项。
3. 重新启动浏览器应用程序。

• Edge，对于版本 109 或更高版本：

使用命令行参数运行应用程序-- js-flags=--experimental-wasm-gc。

参考链接：

https://devclass.com/2023/02/14/kotlin-debuts-experimental-kotlin-wasm-target-in-new-beta-a-new-approach-to-frontend-development/

https://seb.deleuze.fr/the-huge-potential-of-kotlin-wasm/

https://kotlinlang.org/docs/whatsnew-eap.html?utm_campaign=1.8.20-Beta&utm_medium=social&utm_source=twitter#leave-your-feedback-on-kotlin-wasm

推荐阅读：

一个架构师在 2023 年需要掌握哪些“必杀技”？

本文转载来源：

https://www.infoq.cn/news/WBIxUbWPE4OhI7Q4wtS2