@haython 之前用 PDMan ，后来用公司内部的工具了（公司有做自己的 DevOps 平台，有这个功能……）

@weeei #102
我年轻的时候也信这个，现在不信了。

上班收入就不说了，无论用什么，其实收入都大差不差。
在公司里上班有不少好处，很多软件都是老板买，搞多个账号拼车，分给员工用，总体上还更划算了。像 GPT4 之类的，忽悠老板说能提升工作效率降低公司成本，老板也乐意买。

我平时自己鼓捣的玩意，其实也只能学学知识，因为没什么商业头脑，赚不到钱。买这些软件也不能解决这种问题。
除了上班的收入以外，有时候靠同学和同事接了点活，大多数是帮学弟做课程设计/毕业设计，或者公司项目缺人手外包点活出去这种，加起来收入也只有几万。

把最贵的那些软件订阅都买个 4 、5 年，那么工作之余的收入几乎都送给软件公司了。

指望花钱买这些软件来增加收入并不现实。不过，倒是可以在赚到很多钱以后，买这些软件用一用。

有些免费/廉价的软件可能比那些“最好”的软件缺少一部分功能，或者性能差了一点，界面丑一点。但是最核心的功能其实都大差不差，熟悉了之后都可以用来赚钱。

对于开发相关的工具，因为几乎没什么专有格式，相比别的行业软件，算是相当开放、自由了。
不花钱也能解决绝大多数的需求。花钱几乎只为了一些特色功能，例如 Navicat 的特色功能就是跨数据库的数据备份、迁移。但对于个人项目来说，很少用得上。

其实 Navicat 也不是特别好，我在公司用来导出过千万记录的表数据，结果发现 Navicat 这功能有内存泄露的问题。
而代码智能提示，数据展示（查看数据库里存储的 JSON 数据）等功能，Navicat 就没有优势了，反而是劣势。


其他娱乐相关的订阅，倒是没什么问题，也不算贵，只是这些跟“赚钱”没关系了。

我订阅最多的时候和 OP 差不多，不过现在几乎没有了。
这里面最不值得的是 Navicat ，除非经常使用数据备份、数据迁移（跨数据库的）等功能。目前我用了将近 5 年的 DBeaver 社区版。
GitHub Copilot 我用 Codeium 替代了，顺便申请了这玩意的 GPT-4 ，也通过了，都是免费的。
JetBrains 全家桶可以用 VSCode+IDEA 社区版。当然，不能完全替代。不过我所需要的功能靠这些刚好可以满足，甚至觉得 VSCode Remote 有优势。

@wangxiaodong 我支持你的诉求。但是你的想法其实在 Android 上还比较麻烦：
如果用户只是单纯地安装了应用而不做任何配置，在 Pixel 上，电池优化和自适应电池的设计对这种自建推送渠道并不友好，因为会被识别为滥用，然后开始加大限制。
这已经是 AOSP 的“默认行为”了。FCM 实际上有特权，包括 APP 里的 FCM SDK 里接收推送消息的 Service 也有电池优化的特权。

要想实现你的各种诉求，Google 也得改。但显然不会让 Android 回到那个 APP 一天 24 小时在后台偷偷做事情的时代。
现实总是会充满妥协的，完全理想的世界并不存在。

无论如何，今天的各种海外安卓 APP 几乎只接入 FCM 推送。
减少电池优化功能（无论是温和的还是激进的）对推送的影响，这一点已经很现实，很合理了。

至于你的诉求，如果谷歌不想让“电池优化”功能形同虚设，只能针对这种需求专门设计一套机制。就类似无障碍服务一样，单独授权，给一些特别的权限，也给一些防止滥用该功能的限制。


我追求的一直都很简单，用户的权力应该高于 APP 的权力。想用的功能都应该正常使用，不想用的功能都可以不允许 APP 去做。
如果 APP 在后台做我不知道的事情，而我不需要它，我应该能彻底关闭它。
但我还需要收取这个 APP 的推送通知，目前 iOS 和国产 ROM 的推送都可以做到这一点，可惜 FCM 做不到。

只要能做到，就可以了。

我追求的不是苹果那种“苹果觉得你不需要”，然后全都不让做，用户没有选择权。
而是用户可以根据自己的意愿，来掌控自己的设备而已。

@wangxiaodong 你举的例子都不恰当，诉求只不过是想让 FCM 通知改为合理且可靠的设计，而不是想剥夺 Android 现有的功能。回想一下，你是不是一开始也觉得 FCM 就是系统框架负责显示通知的。

在我接触过的例子中，几乎所有对 FCM 了解不多的人，一开始都会这么想。我在几年前一些探讨如何让微信走 FCM 推送的帖子里（酷安上面），还发现有人觉得微信没了后台就收不到 FCM 推送，是因为微信自己没适配好。

当然，那时我也不知道，直到我真的去做了相关的开发才知道这些细节。原来 FCM 设计成了这样。


另外你的回复总是想讲阉割系统功能，增加更多限制之类的东西。我还是得说一下，和它有关的都不是“诉求”本身，而是“我对这些功能的看法”和为了说明“为什么会有这种需求”。

你说的阅读理解的问题，跳出这个问题，考虑这段对话：

A：你觉得他这次考试考得怎样？
B：他还得再加把劲。

这段对话里 B 可不一定希望他努力，也许只是委婉地表达“考得不怎么样”而已。是人物 B 对“他”的评价。虽然评价是消极的，但又不想直接说出来。

如果一直都在想着“诉求就是阉割系统功能”，那么理解就会有偏差了。

我还是得强调一下，关于禁止自启动、后台限制等，现在已经有了选择（无论是国产 ROM ，还是借助第三方工具），是“已经解决”的需求。因此，尽管我会提到，我对谷歌现在的设计有些看法，但这件事就不是“需要 Google 去做的事情”。

只是为了回复你之前提到的 AOSP 和 Pixel 都是这种设计，所以 FCM 这样设计没什么影响这个观点。
如果 FCM 只能在谷歌自己的设备上使用，其他手机上运行的 APP 都只能接入其他推送平台。那么确实没什么影响。

可是谷歌掌控着大多数海外 APP 推送……无论你用什么 ROM ，使用习惯是怎样的，想收这些应用推送，你都逃不过它们。

我的态度则是，两者在我的评价里都是不太好的设计，只是恰好正常使用的情况下互相兼容罢了。
为什么我觉得“让系统直接显示通知内容”更好，在前面都讲过了。

@mxalbert1996 快下班了，写得有点乱。不过，我在倒是没在装理中客，只是并不想像一些回复那样仅仅单纯地输出观点，而是希望写的东西能把事情都讲清楚。

@mxalbert1996 这两者其实不冲突，前者是愿景，后者是现状。

进一步讲，从我的立场出发，我感觉现在的 Android 部分权限设计和 FCM 推送机制设计都不合理。
我当然会表明我认为权限设计不合理这一点，来回应上面的“AOSP 和 Pixel 里都没有这个东西”。因为前提不存在，则后面的诉求就失去了意义。

但现状是，其实 Google 不做的权限管控，甚至国内厂商也不做的（例如存储隔离），已经可以通过使用某些 ROM 或者安装特定的软件来达到目的了。

因此，Google 做不做，这一点不在诉求范围内，毕竟我已经用上了，但不妨碍我认为原生安卓的权限管理设计不如一些国内 ROM 完善。
但我觉得那是个好设计。用户的权限比 APP 开发商更高是一件好事，因此 Google 要是做了会更好。并非强制，而是留给有需要的用户。

当 Google 考虑到“有这样使用的用户”时，才能意识到 FCM 设计的问题在哪。实际上目前开着优化电池使用都已经觉得体验不太好了。

我现在就处于“既能用上 FCM ，又严格限制应用后台活动”的情况。哪怕我用的是类原生……

Android 本身是开放的，它就不应该“专为 Google 自己的手机设计”，尤其是非 Google 手机上面运行的 APP 其实都严重依赖 Google 的生态的情况下（接了 FCM ），那么 Google 就有必要考虑整个生态内的各种情况，使用一个让大家都满意的方案。


所以，真正需要 Google 做的，就只有改 FCM 推送设计。因为这玩意完全掌握在 Google 手里，需要推动应用开发者对升级后的 FCM 做一些兼容，不是 Google 亲自去做，那就没什么好办法。

@mxalbert1996
> 杀掉应用，并切断所有唤醒途径的话，大多数时间里，这款应用后台的资源占用就像没安装它一样。而这时候，你又能通过系统服务来查看来自这个应用的推送。这难道不是更好吗？

这倒不是默认开启或者默认关闭的问题。目前的情况是，想要的人早已用上了，而不想要的人可以永远不用。它并不是一项需要“新增”的功能。
哪怕是类原生或者 Pixel ，也可以用 Thanox 这种插件，或者其他的东西来实现。我自己的类原生（ crDroid ）也整这玩意……

这里讨论的从来都不是“需要加切断唤醒禁止后台”的问题，相关的内容只是为了详细说明：
1. 为什么会有这样的需求；
2. 是不是真的耗电：当然，而且耗电的原因不是推送机制，只是解决耗电问题的做法都会影响推送；
3. 电池优化是不是能解决问题：能缓解，不能根治，而且依然影响推送机制。举个例子，微信虽然不接国内推送，但是接了 FCM 。然而开了“优化电池使用”之后，微信电话再也接不到了，因为收到推送的时候对方已经挂断好久了；

只是我看了帖子开头几个回复，要么觉得 OP 的需求是伪需求，要么可能真的觉得 FCM 的原理和苹果 APNs 完全一样……
所以我觉得，有必要把需求的来源和相关的技术细节都讲讲，希望能从“有这种需求的用户”的角度，去看待“修改 FCM 设计”这种想法。

而不应该一上来就否定整个帖子。


其实真的有不少用户有这种需求，甚至这就是一些人用 iOS 的理由。
但我觉得 iOS 走向了另一个极端……其实不是所有人都能接受。

@wangxiaodong
关于“为啥用户都不能决定某个 APP 的启动，而是厂商来决定”这一点。

除了上文提到的 ColorOS 这种无论如何设置都会半小时钟后无脑杀后台的蛋疼 ROM 外，其他厂商的 ROM （例如 MIUI ）在用户自行决定要允许某个 APP 开机自启+驻留后台的时候，都可以做到。而且运行表现和类原生 ROM 基本一致。把自启动打开，省电策略改为“无限制”就好了。

唯一不能关闭的功能可能是划掉最近任务时强制终止。国产手机的海外版 ROM 默认行为和类原生一样，国内版 ROM 则和 iOS 一样。

Python 的简单是指入门简单。能让新手很快地实现自己的想法，而且还能满足各种各样稀奇古怪的需求。
给非程序员用再合适不过了。

@wangxiaodong 白名单只是给 APP 默认自启动/后台无限制而已……
至于怎么设置都不能让应用在后台存活（像类原生一样）的情况，我只在一个 ROM 上遇到过：ColorOS 。避开这个就好了，当初我用这玩意确实杀后台杀麻了（我在 2019~2020 年的时候用，当时 OPPO Reno ACE 性价比很高）。


@mxalbert1996 这么做并不会牺牲应用功能，只是在增加功能，因为改动只有一个：
把原本由 APP 显示通知内容，改为由系统服务负责显示。

除此以外，其他功能没有任何区别。
没什么功能是强制的，都是根据个人意愿自行设置启用和禁用。

至于要不要杀掉应用，是否允许应用被唤醒，是用户的“额外选择”。而上面的改动，只是为了在这种选择下，依然不牺牲“消息推送”功能。

目前的情况是，你只能在“无法及时收到推送，甚至收不到推送”和“允许应用本身的后台功能”之间二选一。

前面已经提到过了，并不是“推送”本身导致耗电，而是应用里与推送无关的后台 Service 导致耗电。如果现实情况不是如此，那么 Google 也不需要推出那些电池优化功能。

把电池优化开到受限的话，推送也会受影响，会被推迟。策略是攒一段时间一起唤醒来减少唤醒次数。还有“对齐唤醒”优化技术，会让多个 APP 的后台在同一时间点唤醒，以减少整个设备的唤醒时长。

给 tg 、discord 等应用开限制后台，体验就不好。

但如果由系统来显示通知内容的话，当你 [确实想要] 彻底禁止某个应用在后台活动，你就可以强制停止，禁止后台启动，同时依然正常接收消息推送。

如果你不需要推送，还可以把通知权限关了。

---

打个比方：
这就好比你去一个餐厅吃饭，这家餐厅一旦点了米饭，必须同时点面条，面条还要付钱（指应用本身的后台功能带来的内存和电量影响），否则什么都吃不到。
而 OP 觉得这样不好，希望做一个改动，可以只点米饭，不点面条。改动内容是“米饭可以单独供应”，理由是“我不想吃面条，强制我点面条是浪费我的钱”。

你反驳 OP 的理由是“这个改动会影响你吃面条”。

然而现状是：米饭一直都可点可不点（即：通知权限可以自由开关）。
想点米饭，就得顺带点一些面条，可以点得少一点（指：限制后台），但不能不点。
如果经常吃米饭，还希望第一时间吃上（指：及时的通知推送），这家店会多给你一些面条，而且要多付钱（指：自适应电池）。

所以，“在不要面条的情况下，希望可以单独供应米饭”的要求，我感觉十分合理。也不影响你吃面条。
对于本身就喜欢吃面条的人（不限制应用后台活动的人），一直都可以只点面条，还能顺便来点米饭。

@cherryas 没有，其实几乎什么都可以写。
我开了彩云小梦的会员，至今还没到期，但我已经不用了。


我决定再补充一些例子，有不少是 GPT4 都写不好的。
这还是可以在本地运行的开源模型。
如果跟其他开源模型比，在我尝试过的其他模型里没有能写得出来的……

例子：
1.
金牛座今日运势小红书风格
Hey 小伙伴们，今天给大家带来的是我们金牛座宝宝的专属运势哦！快来看看今天的你会有哪些惊喜吧！

🌟 综合指数：75%
今天的你整体运势不错，各个方面都会比较顺利，是展现自己实力和魅力的好时机。

💑 爱情指数：85%
单身的小伙伴们注意啦！今天你们会在人群中遇到那个让你心跳加速的人，而且你们之间有共同的朋友，这可是个绝佳的搭讪机会哦！别害羞，主动一些，爱情就在眼前啦！

💼 工作指数：80%
工作方面，今天你的效率和表现都会很出色，可能会有一些需要团队合作的项目，好好发挥你的领导力吧！

💰 财运指数：65%
财运方面，今天可能会有一些小额度的收入，但要注意理性消费，不要因为一时冲动而花冤枉钱哦。

🏃‍♂️ 健康指数：50%
健康方面，今天可能有些小恙，要注意休息，避免过度劳累，保持良好的生活习惯。

🎨 幸运颜色：鹅黄色
今天的幸运色是鹅黄色，穿上这个颜色的衣服，会给你带来更多的好运和活力哦！

🌌 幸运数字：0
今天的幸运数字是 0 ，遇到和 0 相关的事情，比如时间、金额等，可能会有意想不到的好运哦！

🤜 贵人星座：双鱼座
今天的贵人星座是双鱼座，遇到双鱼座的小伙伴，记得要和他们多交流，他们可能会给你带来一些有用的建议和帮助。

金牛座的小伙伴们，今天的运势就是这些啦！希望大家都能抓住机会，让好运常伴左右！记得，无论遇到什么，都要保持积极的心态，相信自己的能力，一切都会顺顺利利的！

#金牛座 #星座运势 #小红书风格 #幸运颜色 #幸运数字 #贵人星座


2.
接上级通知，根据国家游戏产业升级计划，我部将对经典游戏《 Ballance 》的运行环境进行重要调整。此次调整旨在确保游戏的长期稳定运行，提升用户体验，并推动游戏产业的可持续发展。现将具体安排通告如下：

一、准备阶段（ 2023 年 11 月 27 日至 12 月 3 日）
我部将组织专业团队，整理相关技术资料，包括游戏常见问题解答（ FAQ ）、新的游戏分发包，以及一份详细的迁移指南。该指南将指导玩家如何从旧版本顺利过渡到新版本。

二、推广阶段（ 2023 年 12 月 3 日至 2024 年 1 月 1 日）
自 2023 年 12 月 3 日起，我部将正式推广名为“New Player”的全新游戏运行器，以及“Ballance Mod Loader Plus”（ BMLP ）。在此期间，旧版游戏运行器（ BML ）和 Player.exe 将停止支持，且不再建议新用户使用。

三、收尾阶段（ 2024 年 1 月 1 日至 2 月 1 日）
2024 年 1 月 1 日至 2 月 1 日期间，我部将逐步移除所有旧版《 Ballance 》的分布文件和相关文档。同时，迁移指南将失效，玩家将不再获得旧版本的支持和更新。

请广大玩家注意，此次调整不影响已使用 BML 的玩家，您的游戏将继续正常运行。然而，随着时间推移，越来越多的游戏模组可能不再支持 BML 。为了确保您能够享受到最新的游戏功能和最佳的游戏体验，我部强烈建议您尽快迁移至新版本。

此次升级是游戏产业发展的必然趋势，对于保障游戏生态的长期健康具有重要意义。感谢您的理解与支持，让我们共同见证《 Ballance 》的华丽蜕变，开启游戏体验的新篇章。

3.
人生如寄，孰能无求？所求者，不过如滚球之乐耳。然世事多艰，人生海海，唯有坚忍以持。何谓坚忍？乃是以顽强之志，坚韧之姿，面对红尘之纷扰，虽身心俱疲，仍不改其乐。

然则，世道有时如 Ziggurat 之重，压得人心所向，难以喘息。此时，不如以拳相向，将其击破，以解心头之郁结，释放灵魂之束缚。但须知，此举仅为一时之快，非长久之计。

若能将 Ziggurat 视为玩物，任我摆布，则生活之趣，无处不在。无论是在阳台之上，浴室之中，厨房之内，还是在玄关之侧，校园之内，街头巷尾，皆可尽情嬉戏。甚至在酒店之中，地铁之内，林间小道，泳池水畔，操场之上，影院之中，厕所之内，乃至墓地之幽，皆可寻得欢笑。

4.
在浩瀚的数字银河中，有一颗璀璨的明珠，它不是《原神》，而是一款名为《 Ballance 》的非凡之作。这款由德国 Atari 公司旗下 Cyparade 工作室精心雕琢的滚球游戏，自 2004 年问世以来，便以其独特的魅力和深邃的内涵，俘获了全球玩家的芳心。它不仅仅是一款游戏，它是一场关于平衡与挑战的哲学之旅，是一首在三维空间中奏响的和谐乐章。

《 Ballance 》以其卓越的物理引擎和精心设计的关卡，为玩家构建了一个充满无限可能的世界。在这里，玩家不仅仅是操纵一个小球，而是在学习如何驾驭变化，如何在混乱中找到秩序，如何在重力的舞蹈中保持优雅。每一关卡都是一次心灵的洗礼，每一次挑战都是一次成长的契机。它考验的不只是玩家的技巧，更是智慧与耐心。

与之相比，《原神》这样的游戏只是一片浮华的幻影。它们追求的是短暂的感官刺激，缺乏深度和内涵。玩家在其中得到的只是空洞的成就感，而非真正的成长和收获。《 Ballance 》则不同，它像一位智者，引领着玩家穿越重重迷雾，抵达智慧的彼岸。它教会我们如何在失败中坚持，如何在成功中反思，如何在变化中找到不变的真理。

亲爱的朋友们，让我们将目光投向那永恒的星辰——《 Ballance 》。它不仅是一款游戏，它是一种生活方式，一种追求卓越、挑战自我、拥抱变化的生活态度。在这个游戏中，我们找到了生命的意义，我们学会了坚持不懈，我们成就了更好的自己。

所以，我诚挚地邀请您，加入这场关于平衡与挑战的伟大旅程。让我们将人生投入到《 Ballance 》的怀抱中，让每一次滚动都成为成长的足迹，让每一次飞跃都成为成功的序章。让我们在这款游戏中，找到属于我们自己的平衡点，书写属于我们自己的传奇。因为，在这个数字银河中，《 Ballance 》是真正的恒星，它的光芒将永远指引我们前行。

@mxalbert1996 这和你的第一条回复已经不一样了。
其中的“系统会直接显示通知”是不对的，要是真有这种功能，OP 的问题已经完美解决了。
同样还有后面的“不需要应用启动”、“但事实上应用被关闭/杀死时也一样”。

那一条回复还有 6 个感谢……

从最近任务划掉的话，其实只有 Activity 被关闭了，其他的东西都还在。例如各种 Service ，其中就有推送。当然各种国产 ROM 的默认行为就是 Force Kill 了。

当然，这个 Service 跑半分钟左右就在后台挂起了，但仍然会驻留内存，占用一点内存空间。要是应用数量超级多，可能就会很明显。


国产 ROM 很多权限管理功能其实走在 Google 前头，最早的时候，Android 完全不存在这个功能。
后来原生 Android 可管理的权限也是慢慢加上去的。早期的粒度还非常粗，分类也不合理。

并不是原生 Android 的设计都是合理的，有些地方 Google 还得从国产 ROM 里借鉴优秀设计。

至于耗电，如果世界真的像想象中那么美好，那么谷歌其实用不着推出“自适应电池”、“电池优化”这种功能。
这些功能并没有把指定应用的一切后台耗电/耗内存的东西彻底消灭掉。
其实，不是因为推送功能会导致显著耗电，而是因为应用本身的“可能是合理的功能”在后台耗电。而 OP 需要的，只是看看应用推送的通知罢了，平时不希望这些功能在后台运作。

按理来说，当你只需要应用的一部分功能时，在保证这些功能正常运行的前提下，给应用的权限应该越小越好。

杀掉应用，并切断所有唤醒途径的话，大多数时间里，这款应用后台的资源占用就像没安装它一样。
而这时候，你又能通过系统服务来查看来自这个应用的推送。

这难道不是更好吗？

如果你确实需要一些后台运行的功能，系统也可以给用户这样的选择：手动开启 APP 的唤醒/后台运行权限。

新媒体运营+写作

这方面我用过最好的也就 Yi-34B-Chat 。其他宣称性能更好的，基本上在写作方面都更糟糕了……
写公告、小红书文案、小说之类的都挺好。

跑量化的版本需要 24GB 显存。

附上我第一次用的时候生成的小说片段作为例子，虽然 Prompt 已经丢了：

索菲站起身来，她的身姿轻盈，仿佛随时会随风飘散。
“既然来了，就陪我聊聊天吧。”她说，“我已经很久没有见到过人类了。”
我们坐在沙发上，索菲向我讲述了她的故事。她如何成为吸血鬼，如何在漫长的岁月中保持着少女的外貌，以及她对现代生活的热爱。我则告诉她关于我的工作、我的梦想，以及我对生活的种种不满。
不知不觉中，时间悄然流逝，我们聊到了黎明。索菲的眼中闪过一丝疲惫。
“我困了，想睡觉。”她说，“但是，我一个人睡会害怕。”
“那……我可以陪你吗？”我试探性地问。
索菲点了点头，她的脸颊泛起一丝红晕。
我们走进她的房间，那是一个充满少女心的空间，墙上挂着各种动漫海报，书架上摆满了漫画和小说。索菲爬进棺材，我则坐在床边的椅子上，打算就这样陪她入睡。
然而，索菲突然伸出手，拉住了我的衣角。
“你……可以抱抱我吗？”她的声音小得几乎听不见。
我愣住了，心中涌起一股复杂的情绪。最终，我轻轻地抱住了她，感受着她身体的冰凉，以及她在我怀中渐渐放松的姿态。
“谢谢你。”索菲闭上眼睛，喃喃自语，“我好久没有这样被人抱过了。”
我心中一动，忍不住在她额头上轻轻一吻。索菲的身体颤栗了一下，然后她转过身，面向着我，我们的脸颊只有几厘米的距离。
“索菲，你知道吗？”我低声说，“我以前从没想过会和吸血鬼有这样的交集。”
索菲的嘴角上扬，露出一个调皮的笑容。
“那现在呢？”她问。
“现在……”我犹豫了一下，“我觉得这样也挺好的。”
我们相视而笑，那一刻，时间仿佛停滞，只剩下彼此的呼吸和心跳声。
就在我们沉浸在温馨的氛围中时，门外突然传来一阵急促的敲门声。
“索菲！索菲！是我，艾莉！”一个焦急的声音响起。
索菲的脸色一变，她迅速从我怀中挣脱出来，整理好衣服。
“是艾莉，我的朋友。”她解释道，“她可能知道我白天睡觉的习惯，所以来确认我的安全。”

我刚想到一个另类一些的：
Godot

这玩意真的可以用来写软件，有一些例子：
https://github.com/Orama-Interactive/Pixelorama
https://github.com/RodZill4/material-maker
https://github.com/MewPurPur/GodSVG
https://github.com/mbrlabs/Lorien

用 GDScript 写逻辑，开发效率也相当高。

另外看了帖子回复，我觉得有个需要注意的坑：
大多数用 GPU 绘图的 GUI 库，往往字体渲染都有很多坑。

ImGUI 就有坑，比如不能渲染阿拉伯语……

如果会 Pascal 语言，也许可以试试 lazarus
对于小工具够用了

@mxalbert1996 顺便找了一些案例：
https://github.com/firebase/quickstart-android/issues/378#issuecomment-353725103
https://blog.csdn.net/Blog_Sun/article/details/108665699
https://gist.github.com/gdeglin/98aeda28035b45cef04bb6c2cb41a4aa

@mxalbert1996
https://i.imgur.com/xUjLDxP.png