1una0bserver

不要解析，通过更好的模型实现。数据清洗更重要，全部转成文本。复杂的图喂给 Gemini pro 转换，它代码绘图效果比较好。如果是一些特殊的代码没法在 markdown 里绘制的，直接根据渲染引擎自定义 parser 。

看起来不错，但是对于其他语言写的非 Web 前端框架支持怎样？比如 flutter ，Swift UI ，compose ，qt 之类的。

让 ai vibe 下，改成 cloudflare d1+worker+pages 的架构，蹭 cloudflare 的饭

看了你的代码库，很明确就是技术不行，估计人也年纪大了，学不动了。
首先，git 提交大部分都是 Update xxx 这种，完全没下过心思按内容 commit ，更别说好好写提交内容。别人完全没法贡献。这点上就是学 git 几个月的大学生都比你强吧。而且你放搜索等于没有的 gitee ，基本找不到。
其次，技术栈太旧了。从实现方式来看，感觉作者根本没有经历过大前端时代一样，除了编译链，技术栈还停留在 15 年前。
DirectUI 是 2010 年左右流行的技术，本身早就是淘汰的技术了。你要是为了兼容 XP 我还能理解，其他原因在现代用纯属自己给自己找麻烦。
XML 写 UI 都被 Google 等淘汰多久了，UI 与逻辑语言不一致，调试编译麻烦得一 p 。
引擎和 demoUI 实现也不行，我当初入门编程学的易语言，用的各种 UI 都吊打你现在的绘制效果，那还是 12 年左右。
命令式 UI 已经被响应式 UI 淘汰不知多少年了。
Mvvm 现在都比较少提了，现在热门的是 MVI 。
布局引擎现在绝大多数都是用成熟的 yoga ，无论是效果还是可维护性都更强。
sdl 现在大学生都能写了吧，而且也不算太轻量。如果要从头写的话，我很难想象除了 MCU ，即使是资源受限设备，为什么不用 Android 原生/flutter embedded/imgui/qt/rust 那些轮子，ai 写起来方便多了。
即使是说上面的框架都不允许使用，要用现代技术栈从头用各种轮子搭一个，我觉得都比直接用你这套框架写起来更快。
总之我很难想出为什么要用这套 UI 框架。

从审美和技术推断，作者的年龄可能至少也有 40+了，而且大部分都是在中小厂做 Windows/信创客户端开发，从来没有去大厂干过。并且已经有孩子并且大概率不小了。出来搞这个框架，可能是为了证明技术搞点 KPI ，可能是遭遇裁员潮失业了出来创业，或者只是单纯的爱好这方面技术。
如果不是真的爱好技术，或者真的想吃一辈子这行的饭，我建议还是转行或者转行政吧。你干了十几年，却没有积累下足够的技术，只是像拉磨的驴子那样原地转圈，连时代浪潮都没跟上，绝对卷不过年轻人的，更别说 ai 或者技术比你好的同龄人了。否则，我觉得你真的需要下苦功夫从头学习了，至少也得把各种开发规范，架构设计学学吧。

同样是 c++轻量级跨平台，看看隔壁是怎么做的: https://github.com/sudoevolve/EUI-NEO
更别说现在都是 harness + rust + GPUI 的时代了
看了一眼你的官网，更是惨不忍睹，上古 ui 风格不谈了，你连最基础的布局都做不好，在我这里显示都不正常，哥们这是 2026 年啊，不是 2006 年，你就是完全放开让 ai 自己做的主页都比你现在这好多了。。。你现在还不明白为什么没人用吗？因为真的一眼就能看出技术不行啊，甚至都不愿意下功夫打磨下。

谢谢提醒，我是接 codex ，被这玩意折磨好几天了，准备换 axonhub 。

@NekoBoss 你这个没有做其他应用的对照实验的话，我觉得很难排除是其他方面的问题。你有试过关闭其他应用的剪贴板权限之后，还能粘贴它里面吗？还有我强烈建议你按我上面的过程排查下禁止 intent/app link 后是否还会提示。
还有小米会篡改系统的 app ops 设置，然后使用它自己隐藏的 ops 权限，这点早在 MIUI 时代就是这样了，所以我几乎敢确定这不是应用本身的问题，也肯定不是 AOSP 原生的问题。似乎只有 rikka 的 app ops 应用有做这方面的处理，只不过不知道你的系统版本，app ops 停更有点久了，你的系统可能用不了。如果是这样的话，我建议你关闭 MIUI 优化再试 PMX 。
还有你说的这个，我好像在几年前就在酷安看到过类似 bug ，很难想象这么多年过去了小米还没修。如果你还在用旧版系统，那我觉得你很有必要升级下了。

先问是不是，再问为什么。op 这种很明显的先射箭后画靶的提问，都没有人复现下，就来论证什么 Android 的弊端了是吧，实在是给我看得气笑了😅
首先放我的结论，欢迎讨论：
因为这就不是只靠读剪贴板实现的，谁说 Web 往 app 传数据只能靠剪贴板的。

首先 AOSP 就没有原生的剪贴板运行时权限，各厂商所谓的空白通行证也好，剪贴板权限也好，都是在 Android 4.3+引入的 App Ops 机制上实现的，而这个和运行时权限的一个重大区别在于，这里的拒绝在实现上其实不是真的拒绝授予权限，而是通过返回空数据实现的。所以这个拒绝读取剪贴板其实就是 READ_Clipboard 权限的封装而已，虽然不能排除厂商自己魔改的实现有问题。但是我通过以下操作判断，大概率不是实现问题。
我放一下我的测试环境，Android 14 ，ColorOS ，使用 App Ops 监控和管理相关权限。
先下好客户端登录，限制其权限，关闭。在 chrome 下访问云盘页面，拉起 app ，确实成功读取到下载文件信息。
注意之后：关闭应用，按理此时已复制到剪贴板，那么我再次打开时，如果真的是读取剪贴板，应该仍然能弹出对话框，但是实际上并没有。那么就说明，可能不是读取剪贴板，或者未触发读取剪贴板的条件。尝试手动点击所有 tab ，重新手动复制剪贴板内容，均未有反应。
结合以前看到过的案例，像是 Facebook 通过 websocket 和应用通信来绕过，怀疑 websocket 。于是换了个能屏蔽本地通信的浏览器 WebLibre ，然后打开同一个网页，仍然能拉起 app 并显示弹窗，说明不是靠 websocket 本地通信，至少并不只是这个。
那么结果就显而易见了，答案就在谜面上，读取链接的方式除了剪贴板外，最简单直接的方式就在打开 app 时通过 intent/app link 传递数据！事实上，我很早就注意到了这一点，前面所有能弹出对话框的时候，基本上都是首次自动跳转和手动点击后拉起 app 的时候，而之所以这么大费周章，主要是想排除下其他可能。之后的验证就很简单了，找个能手动禁止拉起 app 的浏览器，比如 via ，禁止后打开网页，点击打开 app ，会自动复制到剪贴板。然后我们手动打开 app ，即使再次点击网页上的打开 app ，由于 intent 被阻止，即使手动切换到文件 tab ，也没有弹出保存窗口。
那么为什么 op 会认为是 bug 导致仍然能访问剪贴板呢？考虑到网盘类应用普遍在打开网页时自动复制剪贴板并跳转应用，导致注意力集中在强提示的剪贴板内容提醒，而忽略了跳转应用本身就能传递数据，加上 op 可能使用 chrome 这种不对网页唤起做拦截的浏览器，导致网页打开时的隐藏 intent 拉起被忽略，认为是自己打开的那个 app 实例。当然，我们也不能排除是 op 的 hyper OS 的垃圾代码中的漏洞导致剪贴板拦截读取无效。关于这点，我觉得都没必要先考虑漏洞问题，先随便找个开源的简单记事本应用禁止读取剪贴板，测试下能不能粘贴，再去把上面我的测试重测下，再去考虑漏洞问题也不迟。