Linux 终端模拟器实测:15 款终端的速度、内存和适用场景

Linux 终端模拟器的选择通常依赖截图和“极快”的主观描述。为了得到可比较的数据,本文在同一台 Ubuntu 桌面上安装了 15 款终端,分别测量启动到首帧、空闲内存占用,以及输出 16 MiB 文本所需时间。部分测试结果与常见印象不同,其中 Kitty 的启动慢问题还有一个只需一条命令的修复方法。

测试覆盖 GPU 渲染终端(Ghostty、Kitty、Alacritty、WezTerm、Rio)、发行版常见的 GTK 与 Qt 终端(Ptyxis、GNOME Console、GNOME Terminal、Konsole、Tilix、Terminator),以及小型传统终端(foot、st、rxvt-unicode、xterm)。每款终端都列出实测数据、适用场景与安装命令;Warp 和 Tabby 因无法自动化测试,仅进行首次启动观察。

Linux 终端性能测试结果

在这两项速度测试中,foot 都是最快的终端模拟器:首帧 39 ms,输出 16 MiB 文本 168 ms,空闲内存 6.9 MiB,仅 st 的内存占用更低。另一端最令人意外的是 Kitty:Ubuntu 软件包版本启动需要 558 ms,而在编译 Python 字节码后降到 199 ms。

下表按首帧时间排序,各列数值越低越好:

终端 渲染方式 首帧(ms) 空闲内存(MiB PSS) cat 输出 16 MiB(ms) 测试版本
foot CPU(pixman),仅 Wayland 39 6.9 168 1.25.0
st CPU(Xlib,XWayland) 45 3.4 278 0.9.3
rxvt-unicode CPU(Xlib,XWayland) 62 10.1 215 9.31
Rio GPU(wgpu) 98 60.8 215 0.5.28
Alacritty GPU(OpenGL) 100 39.0 256 0.16.1
WezTerm GPU(OpenGL) 101 66.8 916 nightly 20260929
xterm CPU(Xlib,XWayland) 125 7.0 485 407
Konsole Qt 136 40.7 477 25.12.3
Tilix VTE(GTK3) 185 36.7 376 1.9.6
Terminator VTE(GTK3) 263 36.8 296 2.1.5
Ghostty GPU(EGL 上的 OpenGL,GTK4) 308 78.9 195 1.4.0
GNOME Console VTE(GTK4) 317 67.2 461 49.2
GNOME Terminal VTE(GTK3) 322 25.3 325 3.58.0
Ptyxis VTE(GTK4) 348 68.2 346 50.1
Kitty(软件包版本) GPU(OpenGL) 558 88.0 212 0.45.0
Kitty(编译字节码后) GPU(OpenGL) 199 88.0 212 0.45.0

同样三项数据也可用图表表示:

图1

可以看到两个规律。基于 VTE 的 GNOME 系终端(Ptyxis、GNOME Console、GNOME Terminal)与同样使用 GTK4 构建窗口的 Ghostty,首帧都落在 308 至 348 ms 之间,说明这里的启动下限主要由 GTK 工具包决定,而不是渲染器。吞吐性能也不完全对应“GPU 加速”标签:GPU 终端 Ghostty、Kitty 和 Rio 接近 foot,而同样采用 GPU 的 WezTerm 却是最慢的 916 ms。Ghostty 1.4 在同一虚拟机中把文本输出时间从 542 ms 降到 195 ms,才进入第一梯队。

测试方法

所有测试都在 Proxmox 主机上的一台 Ubuntu 26.04 LTS 桌面虚拟机中完成:11 代 Core i7-1165G7 分配 4 个 vCPU、8 GB 内存,GNOME 50 使用 Wayland,分辨率 1280×800。要公平评估 GPU 终端,需要真实 OpenGL 支持,因此虚拟机启用 VirGL,把 OpenGL 4.3 调用传递到主机的 Iris Xe,而非退回软件渲染。这仍会增加转换层,所以 GPU 终端的结果适合作为该环境中的排名,不代表裸机绝对性能。

除窗口大小外,每款终端都使用发行版默认字体、主题和回滚设置。窗口统一设置为 100 列 × 30 行,并在每次运行后通过 stty size 验证。Ghostty 数据来自 10 月 28 日在新克隆的相同虚拟机与主机上重跑 1.4.0 的结果,同时运行 Ubuntu 1.3 软件包作为对照。

  • 首帧时间:一个小型 GNOME Shell 扩展记录合成器收到新窗口第一帧的时间。数值为 fork 终端到日志记录之间的间隔,先预热 3 次,再对 20 次启动取中位数。
  • 空闲内存:终端启动的全部进程 PSS 总和,数据来自 /proc/<pid>/smaps_rollup,包括 gnome-terminal-server、ptyxis-agent,但不包括其中运行的 shell。启动后等待 10 秒,对 3 次测量取中位数。方法曾与 smem 交叉验证,Alacritty 的 smaps_rollup 为 41.6 MiB,smem 为 41.5 MiB。
  • 吞吐性能:用 cat 输出一个 16 MiB、由 96 字符 base64 行组成的文件,在终端内用 date +%s%N 计时,执行 6 次取最后 5 次的中位数。

为何不使用常见的 hyperfine 'alacritty -e true'?因为这个指标容易误导。测试也运行了它以及“启动到 shell 运行”的指标,部分终端差距很大:

终端 启动到 shell 运行(ms) hyperfine -e true(ms) 启动到首帧(ms)
foot 15 34 39
WezTerm 35 49 101
Alacritty 77 94 100
GNOME Console 154 窗口保持打开 317
GNOME Terminal 290 62(server 已运行) 322
Kitty(软件包版本) 651 721 558

WezTerm 在真正绘制前就启动 shell,基于 shell 的计时会少算约 65 ms。foot true 退出太快,合成器甚至没有记录到一帧。GNOME Terminal 的 62 ms 是客户端把请求交给已运行的 gnome-terminal-server;每次测量前杀掉 server 后,首帧时间变为 322 ms。

1. foot:Wayland 上最快的终端

foot 除内存外几乎在所有指标中领先,仅 st 的内存更低:首帧 39 ms、空闲内存 6.9 MiB、16 MiB 输出 168 ms。它仅支持 Wayland,用 pixman 在 CPU 上渲染。server 模式(foot --server 配合 footclient)可进一步降低新窗口成本。它没有标签页和图形设置,需编辑 ~/.config/foot/foot.ini,分屏交由 tmux 或多个窗口完成。在 GNOME 下它会自行绘制标题栏,因为 Mutter 不提供服务端装饰,仅影响外观。

首次启动最不习惯的是默认字体为 8 pt 等宽字体,明显小于其他终端。

图2

在 Ubuntu 中安装:

sudo apt install foot

如果使用 X11 而不是 Wayland,foot 无法启动,应选择 st 或 rxvt-unicode。

2. Alacritty:快速、简单、跨平台

若要 GPU 渲染但不想学习大量功能,Alacritty 是合适选择。首帧 100 ms、空闲内存 39.0 MiB、输出 16 MiB 用 256 ms,处于前列;Linux、macOS 和 Windows 使用同一份 TOML 配置。与 foot 一样,标签页和分屏交给 tmux 或窗口管理器。Vi 模式、正则提示和实时配置重载足以覆盖大多数日常需求。

图3

Ubuntu 软件包比上游落后一个版本,但对多数用户足够:

sudo apt install alacritty

如需当前上游版本,可从源码用 cargo 构建。

3. Ghostty:原生体验与 GPU 渲染

Ghostty 是近期讨论最多的终端,也适合作为日常主力:提供真正的 GTK4 标签页与分屏、合理的默认主题、Kitty 图形协议,以及因默认值合理而通常无需修改的配置文件。早期 1.3 软件包性能并不突出,16 MiB 输出需要 533 ms,落后于 GTK4 VTE 终端。1.4 版本明显改善。

在相同虚拟机中并排测试三个构建:

Ghostty 构建 首帧(ms) 空闲内存(MiB PSS) cat 16 MiB(ms)
Ubuntu 软件包(报告 1.3.0) 303 67.4 556
源码构建 1.3.1 310 72.6 542
源码构建 1.4.0 308 78.9 195

吞吐提升最明显:在相同硬件上,1.4 比 1.3.1 快约 2.8 倍。上游发布说明称纯 ASCII 解析从 128 MB/s 提升至 725 MB/s,真实 asciinema 记录快约 25%,1 万行回滚历史的窗口缩放快约 6 倍。本文只复现了吞吐结果,但数据说明解析改进在 GTK 窗口中同样有效。

空闲内存反而上升:全新 1.4 窗口占用 78.9 MiB,同方式编译的 1.3.1 为 72.6 MiB。1.4 启动日志出现 EGL vendor=Mesa Project,因为渲染移到了独立 EGL 线程,再将完成的帧交给 GTK;1.3 直接在 GTK OpenGL 控件中绘制。1.4 还对空闲回滚历史进行压缩,上游称在 macOS 和 64 位 Linux 上可减少该历史物理内存的 70% 至 90%,因此默认回滚上限从 10 MB 提高到 50 MB。本文没有独立测量压缩效果。

如不希望使用压缩,可在 ~/.config/ghostty/config.ghostty 设置:

scrollback-compression = false

图4

Ubuntu 26.04 的 universe 仓库提供 Ghostty,可直接安装,但该包仍是 1.3:

sudo apt install ghostty

Ghostty 不为 Linux 直接提供二进制,官方安装页列出发行版软件包。测试当天,稳定 snap 通道、社区 PPA 与 AppImage 仍为 1.3.1,因此 1.4 需从发布压缩包构建。构建要求 GTK 4.18、libadwaita 1.7 以上与 Zig 0.17;Ubuntu 26.04 提供 GTK 4.22 和 libadwaita 1.9,满足要求,Ubuntu 24.04 不满足。先安装构建依赖:

sudo apt install build-essential pkg-config libgtk-4-dev libadwaita-1-dev \
  gettext libxml2-utils blueprint-compiler libgtk4-layer-shell-dev xz-utils curl

再按 Ghostty 发布说明获取对应版本的 Zig 并构建。生产机器可继续使用发行版软件包,等待仓库更新到 1.4;自行构建时应保存编译参数和版本,方便后续升级。

4. Kitty:输出快,启动需先编译字节码

Kitty 输出 16 MiB 文本耗时 212 ms,仅次于 foot 和 Ghostty 1.4,功能也最丰富:标签页、多种分屏布局、自有图像协议,以及 SSH shell 集成和 Unicode 输入等“kittens”。它的空闲内存最高,为 88.0 MiB。启动时间则异常,Ubuntu 软件包版本首帧需 558 ms,慢于所有 GTK 终端。

原因在于 Kitty 以优化级别 2 运行 Python 代码,会查找 .opt-2.pyc 字节码文件,而 Ubuntu 软件包安装时只生成普通 .pyc。每次启动都要在内存中重新编译模块,并尝试缓存到 /usr/lib/kitty 与 Python 标准库目录,但写入被拒绝。可统计一次启动中的失败写入:

strace -f -r -e trace=openat,execve -o /tmp/k.trace kitty sh -c "sleep 0.5"
grep -c "opt-2.pyc.*EACCES" /tmp/k.trace

测试得到 135 次权限拒绝,其中 51 次来自 Kitty 自带模块,其余来自其导入的 Python 标准库模块。以 root 编译一次即可:

sudo python3 -OO -m compileall -q /usr/lib/kitty

重新运行 20 次启动测试后,Kitty 首帧中位数从 558 ms 降至 199 ms。再次跟踪仍有 31 次缓存未命中,但都在 Python 标准库中,不在 Kitty 自身。软件包升级会替换 /usr/lib/kitty,因此每次更新后都要重新执行命令。

图5

安装仓库版本:

sudo apt install kitty
sudo python3 -OO -m compileall -q /usr/lib/kitty

5. WezTerm:终端中的多路复用器

WezTerm 的价值主要不在绘制文本,而在附加功能:内置多路复用器支持标签页、面板和断开会话后继续存在的工作区;SSH 域可把远程面板放在本地标签页中;Lua 配置可以编程。首帧 101 ms、空闲内存 66.8 MiB,但 16 MiB 输出耗时 916 ms,是十五款终端中最慢的,接近倒数第二 xterm 的 485 ms 两倍。若经常查看长构建日志,这一差异可感知;若把 WezTerm 当 tmux 替代品,则影响较小。

图6

最后一个正式标签版本发布于 2024 年 2 月,官方 Linux 安装页将 Ubuntu 24.04 及更高版本标为“Nightly Only”,因此测试使用 APT 仓库中的 nightly。添加仓库密钥和源:

curl -fsSL https://apt.fury.io/wez/gpg.key |
  sudo gpg --yes --dearmor -o /usr/share/keyrings/wezterm-fury.gpg

echo 'deb [signed-by=/usr/share/keyrings/wezterm-fury.gpg] https://apt.fury.io/wez/ * *' |
  sudo tee /etc/apt/sources.list.d/wezterm.list

sudo chmod 644 /usr/share/keyrings/wezterm-fury.gpg

nightly 包与旧稳定包冲突,只能选一个:

sudo apt update
sudo apt install wezterm-nightly

nightly 是项目当前积极维护的构建,测试当周仓库仍有提交。

6. Ptyxis:Ubuntu 与 Fedora 的默认终端

近期安装 Ubuntu 26.04 或 Fedora Workstation 时,Ptyxis 已是默认终端。Ubuntu 的 ubuntu-desktop-minimal 依赖它,xdg-terminal-exec 指向 org.gnome.Ptyxis.desktop;Fedora 从 41 开始切换。它最突出的能力是容器感知:新标签页会进入与当前标签页相同的 podman、Toolbx 或 Distrobox 容器,profile 可绑定容器,每个标签页也能运行在独立的 systemd scope 中。首帧 348 ms、空闲内存 68.2 MiB,均处于较重一端,吞吐 346 ms 居中。

图7

Ubuntu 26.04 桌面无需安装;最小安装或其他版本可执行:

sudo apt install ptyxis

窗口大小由 org.gnome.Ptyxis 的 GSettings 键 default-columns 与 default-rows 控制,而不是命令行参数。

7. Konsole:KDE 的主力终端

在完整工具箱终端中,Konsole 首帧最快,为 136 ms;空闲内存 40.7 MiB,吞吐 477 ms。它保留传统终端中最实用的附加功能:分割视图、按 profile 设置、SSH 管理与快捷命令插件,以及标签页活动或静默监控。它在 Plasma 上最自然,在 GNOME 上则外观不太协调,安装时还会带入大量 KDE Frameworks。

图8

sudo apt install konsole

它是 Kubuntu 及其他 Plasma 版本的默认终端。

8. GNOME Console 与 GNOME Terminal

GNOME Console(二进制名为 kgx)是 GNOME 自带的精简 GTK4 终端:首帧 317 ms、空闲内存 67.2 MiB、吞吐 461 ms。它提供标签页概览网格,偏好设置极少,这正是其设计目标。GNOME Terminal 是 Ubuntu 多年使用的旧 GTK3 终端,26.04 中仍与 Ptyxis 并存;它是测试中最轻的 VTE 终端,空闲内存 25.3 MiB,冷启动首帧 322 ms,吞吐 325 ms,配置与快捷键编辑器比 Console 完整。

sudo apt install gnome-console gnome-terminal

两者与 Ptyxis、Tilix、Terminator 共用 VTE 控件,因此转义序列支持一致。GTK4 版本(Ptyxis、Console)通过 GSK 渲染,字体呈现可能与 GTK3 版本略有差异。

9. Tilix:单窗口平铺

Tilix 可将窗口分为平铺面板,支持拖放重排、保存和恢复布局,并向所有面板广播输入,适合同时维护多台虚拟机。首帧 185 ms、空闲内存 36.7 MiB、吞吐 376 ms。问题在维护状态:最后发布于 2023 年 11 月,仓库仅偶尔提交,不应期待新功能。

sudo apt install tilix

在 GNOME 50 上仍可正常工作,广播输入是许多人继续使用它的原因。

10. Terminator:面向系统管理员的终端

Terminator 提供与 Tilix 类似的分屏和广播,并仍在积极发布。它用 Python 与 GTK3 编写,首帧 263 ms,空闲内存 36.8 MiB,吞吐 296 ms。布局保存在普通配置文件中,分组功能可只向部分面板广播。

sudo apt install terminator

安装后会成为 x-terminal-emulator 替代项,若发现其他应用开始打开 Terminator,应检查该替代设置。

11. Rio:新一代 GPU 终端

Rio 是用 Rust 编写、基于 wgpu 的终端,wgpu 也是 Firefox WebGPU 使用的渲染栈。它的首帧 98 ms、吞吐 215 ms,接近 Alacritty,空闲内存 60.8 MiB。它提供标签页与分屏,TOML 配置里的窗口尺寸按像素而不是列设置。

图9

Ubuntu 仓库中的 rio 是无关软件,因此应从发布页面选择对应会话的 .deb:

curl -fsSLO https://github.com/raphamorim/rio/releases/download/v0.5.28/rioterm_0.5.28_amd64_wayland.deb
sudo apt install ./rioterm_0.5.28_amd64_wayland.deb

X11 会话应选择单独的 _x11.deb。固定版本号便于复现测试,升级前应查看发布说明。

12. st、rxvt-unicode 与 xterm:最小的 X11 终端

三者都可通过 XWayland 在现代 GNOME 桌面上运行,仍然有用。来自 suckless 的 st 是测试中内存最低的终端,空闲仅 3.4 MiB,首帧 45 ms。它需要修改 config.h 并重新编译,Ubuntu 的软件包名为 stterm。rxvt-unicode 首帧 62 ms、空闲 10.1 MiB、吞吐 215 ms,是三者中吞吐最快的,但自 2023 年 1 月后未发布新版本。xterm 是许多终端测试转义序列支持的参考实现,空闲 7.0 MiB,但吞吐较慢,为 485 ms。

sudo apt install stterm rxvt-unicode xterm

它们适合旧硬件、极简窗口管理器,或在 GPU 栈损坏时仍需启动终端的场景。

额外测试:Warp 与 Tabby

两者没有进入基准表,因为无法通过脚本驱动。Warp 没有在启动时直接执行命令的参数,首次启动会停在 Welcome 页面并要求点击 Get started。其客户端采用 AGPL v3 开源,功能围绕 AI 代理与块式命令历史,面向的用户与上述终端不同。Tabby 是基于 Electron 的终端,内置 SSH 和串口配置,但全新安装后 tabby run 在 30 秒内没有执行探测脚本,因此没有可比较的计时。

图10

Warp 可从下载页的 .deb 安装,Tabby 可从 GitHub Releases 的 .deb 安装。安装第三方软件前应核对发布者与签名,并根据团队策略决定是否允许 Electron 或 AI 终端访问工程源码。

已从旧榜单移除的终端

一些曾经常见 Linux 终端项目已停止维护。应在采用前检查项目状态:

终端 状态 替代选择
eDEX-UI 仓库已归档,最后发布于 2021 年 10 月 Ghostty 或 Kitty 配合主题
Termite 2021 年归档,README 说明已被 Alacritty 替代 Alacritty
Aminal 改名为 Darktile 后标记为实验性并放弃,最后提交于 2023 年 3 月 Alacritty 或 Rio
Upterm 已归档,最后发布于 2018 年 5 月 Warp
Hyper 2023 年 1 月后无稳定版本 Tabby
Terminus 已更名为 Tabby Tabby

应该选择哪款 Linux 终端

最佳选择取决于使用方式。可按任务参考下表:

需求 选择 理由
Wayland 上最快、最轻 foot 首帧 39 ms,空闲 6.9 MiB,吞吐最快
无需学习即可使用 GPU 渲染 Alacritty 100 ms、39.0 MiB,跨平台配置一致
标签页、分屏、原生 GTK 外观 Ghostty 功能丰富组中默认值最好,1.4 吞吐 195 ms
功能最全且输出快 Kitty 吞吐 212 ms,编译字节码后启动 199 ms
替代 tmux WezTerm 内置多路复用与 SSH 域,但吞吐最慢 916 ms
Toolbx 与 Distrobox 工作流 Ptyxis 新标签页保持当前容器
向多个面板广播输入 Terminator 或 Tilix 首帧 263 ms 与 185 ms,Terminator 仍在发布
旧硬件或极简窗口管理器 st 或 rxvt-unicode 空闲内存 3.4 MiB 与 10.1 MiB

终端只是工作环境的一半。安装 Nerd Fonts 补丁字体、配置合适的 shell 提示符,并使用 tmux 保持断开后会话继续,对日常体验的影响通常大于节省 100 ms 启动时间。

测试中遇到的错误与特殊行为

这些问题都没有使终端彻底无法使用,但各自的排查都消耗了时间。

Kitty:“opt-2.pyc … = -1 EACCES (Permission denied)”

这是软件包安装时未生成优化字节码导致的,按要求执行 sudo python3 -OO -m compileall -q /usr/lib/kitty 即可。升级 Kitty 后需重复执行。不要修改 /usr/lib/kitty 的权限开放用户写入,权限拒绝说明系统目录受到保护。

foot:“compositor does not implement the XDG toplevel icon protocol”

该提示表示合成器未实现 XDG 顶层窗口图标协议。不影响运行,但窗口图标可能缺失。可升级合成器、改用支持该协议的桌面环境,或在 foot 配置中接受这一显示差异。

GNOME Console 在命令退出后窗口仍保持打开

GNOME Console 使用 -e 运行命令后不会像其他终端一样自动关闭,测试的 15 秒超时将其终止。其他终端会在命令结束时关闭。通过脚本或快捷键启动 GNOME Console 时应注意这一行为,必要时显式关闭窗口。

Tabby 误解析为命令准备的参数

运行 tabby run sh -c '...' 时,Tabby 会把 -c 当作自己的选项,导致 shell 命令被错误解析。可将命令写入脚本,再传入脚本路径。Tabby 在 Ubuntu 26.04 还会输出 Fontconfig 缓存版本警告,因为其内置 fontconfig 比系统版本旧,这条警告无害。

Proxmox 虚拟机中的 GPU 终端使用软件渲染,除非启用 VirGL

使用标准 VGA 显示时,客户机的 glxinfo -B 会显示 llvmpipe 且“Accelerated: no”,GPU 终端的测试结果会被 CPU 软件渲染主导。Proxmox 的 virtio-gl 显示可将 OpenGL 传递给主机 GPU,但主机需先安装 GL 库。在 Proxmox 节点执行:

apt install -y libgl1 libegl1
qm set 9412 --vga virtio-gl,memory=256

其中 9412 是虚拟机 ID,应替换为实际值。冷启动后,客户机 glxinfo -B 应显示主机 GPU,并有“Accelerated: yes”。注意 QEMU 的 screendump 在 VirGL 下会因“no surface”而无法使用,本文截图时曾临时切回标准显示。

Ghostty 构建:“Out of memory: Killed process (zig)”

8 GB 虚拟机首次构建 1.4.0 时,约四分钟后进程被杀。后台构建日志可能没有 Zig 错误,仅突然结束。可用以下命令确认:

sudo dmesg | grep -i "out of memory"

测试显示 Zig 进程约使用 7.5 GB 常驻内存。1.3.1 在同一机器构建峰值约 1 GiB,而 1.4.0 需要约 7.0 GiB,因此以前能成功构建旧版本的机器也可能失败。增加交换文件,或在 16 GB 以上内存的机器构建。不要为了完成构建而关闭系统内存保护。

Avatar photo

关于 木子

Email: muzi@vip.rockylinux.cn 微信:VebinLee QQ: 2306867585
Founder of the Rocky Linux Chinese community, MVP、VMware vExpert、TVP, advocate for cloud native technologies, with over ten years of experience in site reliability engineering (SRE) and the DevOps field. Passionate about Cloud Computing、Microservices、CI&CD、DevOps、Kubernetes, currently dedicated to promoting and implementing Rocky Linux in Chinese-speaking regions.
用一杯咖啡支持我们,我们的每一篇[文档]都经过实际操作和精心打磨,而不是简单地从网上复制粘贴。期间投入了大量心血,只为能够真正帮助到您。
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇