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）?！?/span>

瀏覽器中運行的 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 確實是個重塑前端開發面貌的好機會?！盌eleuze 表示，“當然，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