当然可行。但还是考虑下你技术栈比较好，跨平台很多需要自己造轮子，太费功夫就不划算了

你是说 jetpack compose 的 preview 装饰器吗？为什么要在 preview 用 activity 才是问题吧？这玩意就不是用来干这个的，生命周期都不完整吧

你是不是在找：数字孪生

自信点，不是一般的慢...我做 android 开发，语言是 kotlin ，经常改一下打包好几分钟，而且下载依赖死活不走代理，简直就是折磨人...

@tigerc 其实自带也不安全，上个刚出的报告，几乎所有国内内置输入法都可以被轻易中间人攻击...

数据安全？既然都做离线了，不能出个没有网络权限的纯离线版？不能半开源，软件主体开源，输入法内核闭源？

你信他数据安全，不如信我是秦始皇，v 我 50 封你做万户侯🤣
我实在想不起来有哪家大厂一直信守诺言始终如一的例子，你能不能帮我回忆下？
还有微信键盘刚出 beta 的时候有个日志体积暴增的 bug 呢，一小会就好几 g 的 log ，你能不能解释一下你这 log 打进去什么数据了这么大啊😅

@snowflake007 原来阿里著名巨坑 KPI 项目啊，我以前还踩过，weex 原本捐给 Apache ，结果后面公开版本不维护又出来了，所以又改依赖地址了，好像是 implementation 'io.weex:weex_sdk:0.30.2'这个。顺便说一下，你如果之后想升级到更高 target SDK ，那么只能迁移到 uniapp 那边，他们还在维护一个自己的 weex ，不过可能部分代码得改。weex 其实阿里到现在都在用，甚至升级渲染方式了，但是不公开属实恶心，让广大开发者上了贼船然后又要赶下去，要不是后面有 uniapp 维护真不知道该怎么办。

29 到 30 升级没那么难，源码跑不起来不至于。我更低的包都迁移过 target 32+了，只不过需要点魔法操作。

在 Android dpc 基础上开发下，禁止应用安装什么的

op 的逻辑有点逆天，从实现了 wasm 开始的 v8 经常出漏洞=wasm 高危？这明显是 c++老项目堆 bug 的原因吧，你要不看看其他 wasm 的运行时，有几个经常出 cve 的？云原生那边解决安全问题的一种趋势就是把原生代码编译到 wasm 在沙箱里执行，怎么到你这里就成了 wasm 经常出问题呢？而且换一种思路，从浏览器实现了 wasm 到现在正好是勒索软件和黑客活动逐渐增多的时间段，可不可以认为是黑客活动逐渐增多并且盯上了浏览器的原因？

输入法这个东西绝对是只有开源可控才能称得上安全的，因为不联网传输数据的方法多的是，比如进程间通信，写入加密文件到本地供其他软件读取等等，这些都是某些软件为了推广明明确确干过的，推广都是如此，更别说更有价值的用户输入了...可惜即使现在进入 ai 时代，开源输入法的体验还是不太行...

发个外链，类似百度网盘，只有输入正确密码才能看到，内容有时间限制过期无法解密

qq 频繁发送内容相同的非正常域名邮件似乎也会丢弃邮件，之前测试伪装时间戳的时候发现的。顺便可以试试 189 邮箱？这个对自建邮件的拦截似乎没那么严格，我之前可以轻松发过去。

其实用 compose multiplatform 感觉是最稳妥的，都有 Java fx 代码了，迁移到 compose 绝对方便，而且也支持部分热重载。不过看你踌躇满志的样子，其实心里早就想拿 tauri+rust 重造轮子了吧？既然如此不妨试试，试一遍就知道了。不过仍然建议只要不是 UI 层的东西老老实实用 rust 写，少用 js ，小心埋 cve 。也可以考虑考虑编译到 wasm 的一些框架。还有远离系统菜单和托盘，这玩意经常出问题，不管是 kmp 还是 Web 都是。

rotaeno 能选择三种传感器数据来源，正常情况下前两个都能用，可以试着玩玩这个。估计是传感器延时太高，更新系统可能会有帮助。

自建通知可以考虑 UnifiedPush

NetworkLocationProvider 的参考实现可以看看 microg 项目里的 UnifiedNlp 部分