今日笑点

@kaicity
@LittleFox 早几年确实有些运营商定制的低端机是有 NFC 的，甚至是全功能的 NFC ，不过目的不是给老人用的，是给营业厅的工作人员开卡用的

@1una0bserver 你如果要用原生 view 写的话，我建议用 anko ，Contour 之类对 view 的 dsl 封装写，尽量避免用 xml ，一是更加接近声明式的写法，写起来更舒服点，二是避开 xml 中写 UI 的一堆坑。

首先我非常建议用 kotlin ，而且是 full kotlin ，本身 kotlin 经过优化已经和 Java 原生没啥性能差别了，而且 full kotlin 还可以不用考虑 Java 的空安全问题了。Java 你如果用了某些高版本特性或者函数必须 desuger 。而且某些机型魔改 ART ，未实现 JVM 中的某些函数（此处指某国产自研品牌），你用 kotlin stblib 中自己实现的同功能函数就不会遇到这个坑。
至于框架的话，考虑到设备兼容性和性能较低，首先排除 flutter ，在老低端机上性能较差，而且新版本用的 vulkan 和 Impeller 对老设备兼容性很差。uniapp 性能较差，uniapp-x 虽然是编译到原生，但其可用的插件很少，需要根据业务慎重考虑。所以基本就是 compose 和 view 里选。
你提到的 compose 性能问题，在多个版本的优化后，基本是早期才有的问题了。目前最多就是在长列表加载复杂数据这种场景，可能在某些极端场景下不如 recycleview 了，毕竟 recycleview 是优化了很多年的东西了。而且 compose 的一个好处就在于和原生 view 无缝兼容，具体使用中可以和原生 view 混合编写。原生那堆东西写起来非常折磨人，不如 compose 写起来舒服多了，你是前端的话应该更有体会。但是 compose 也不是说没有别的问题了，比如最新版本 1.8.x 我记得在某些 Android p 设备上会闪退，需要一点魔法，太旧的版本性能又太差，我个人建议图稳定先 1.5.x-1.6.x ，等熟悉了再升级。还有就是 compose 最低兼容到 Android 5 ，你要是需要兼容 Android 4.x 这种极老的设备的话，那就只能选择原生 view 了。
原生 view 是兼容性最强的，但也是坑最多的，写起来最折磨人的，上限极高下限极低，完全看你水平了。我反正能不用原生就不用原生写，太折磨人了。原生 view 除了写法折磨人，主要坑点在于不同版本兼容性适配，style 系统，还有不同系统对于 view 的魔改上。其中 style 系统折磨人的地方在于，它会因为你用的不同 SDK 版本，不同真机系统而出现不同的 bug ，还有 IDE 大多时候识别不出来 xml 中的问题，你需要在编译时甚至运行时闪退才知道有问题，而且很不好排查问题出在哪里。还有不同品牌系统多多少少都会魔改 view 系统，你得替他们擦屁股。

@AEnjoyable 有没有一种可能，我自己就是被 pcdn 误伤的受害者🥲
我用的移动流量，无论是镜像下载还是网页访问，都会被 ban ，而用家里的电信宽带就没事。后来我查了下我的出口 ip ，发现 ip 位于 pcdn 较多的 ip 网段内，估计是被识别为疑似 pcdn 了。倒是 ban 的就几个固定的镜像站，好像是 tuna 和 ustc 等几个，索性我就手动编辑了下源不用这几个了。

还有一种可能，你 ip 被识别为 pcdn 了，所以被 ban 了

一眼 kapt 和 dagger2 ，我自己写的应用用这俩的时候编译每次都得等一会，而且经常因为莫名其妙的原因编译卡住，清理缓存能缓解。迁移到 ksp+k2 能缓解一些，但还是慢。后来想想我写的也没多复杂，也不吃性能，研究了下迁移到 kodein 并移除 ksp 后，速度快多了，增量也能秒编译了。不过你这是 systemui ，没法像我那样迁移，无解，最多能清下编译缓存试试。

webdav 好像可以吧？

@WebKit WiFi direct 已经是非常普及的技术了，互传的协议只要系统在 11+就能用...

koreader 、librera reader

@catazshadow 槽点太多简直无处吐槽...虽说是要挑个轻量的发行版，但是你要跑最新的主线 Linux 好歹得有个像样的硬件吧，你拿个连山寨机都不如的单核酷睿是什么意思？这配置拿来跑任何最近的发行版都够呛，还不如跑 xp 呢，非要跑 Linux 估计也就只能选 tiny core Linux 和 puppy 这种极其轻量的但是砍了非常多东西的了...
还有 Linux 为了新特性和对新平台的兼容性，本来对老硬件就不友好，你这上古配置还不如去跑 bsd ，那个够老。
而且早期 x64 平台的 acpi 本来就一堆问题，你这除了硬件本身性能差的原因外，驱动兼容性才更是问题，所以把驱动兼容性问题造成的自检慢归罪于发行版不够轻量你觉得这逻辑说得通吗？

要轻量是吧，我建议用 alpine 和 void Linux🤔

@sagaxu 看了下，得手搓相关插件，我觉得我没有这个能力（

目前看来，看衰 idea 捧 vscode 的基本都是前端开发者。jb 的 bug 确实多，但是很多功能都是无法替代的，而 vscode 根本和 idea 就不是一个定位，cursor 和 remote Dev 方面 vscode 更好也并非单纯是 jb 比 vscode 差太多，个人更倾向于 IDE 技术栈的问题。
vscode 底座是 electron ，jb 底座是 JRE ，从技术和生态上讲，Web/js 搞 remote Dev 明显是更方便的。而且 vscode 更接近于编辑器，架构设计上也更轻量，选用其进行二次开发显然是比选 jb 更方便的，但这并非 jb 比 vscode 差的理由。

首先把乱七八糟的右键菜单扩展都关了，尤其是百度网盘的，这玩意严重影响右键菜单的响应速度

@rcj6056 默认配置没问题，这个版本我也用过，我一直用的 canary 通道 Linux 版建项目都没问题，应该就是你网有问题，可能是代理配置有问题或者 DNS 有问题

@zeroli 对的，agp8.8.1 最低 gradle8.10.2 ，要是真是默认就不会配置成这样，不知道 op 怎么建的，严重怀疑手工建的或者直接改的。

./gradlew clean 试试，agp 改 8.7.1 试试，还有我很怀疑你用的仓库地址有问题，我的建议是别用国内源，国内源有时有问题 maven central 的依赖没法用。
代理用本地 http/socks 代理别用远程镜像。
那个网络测试按钮基本就是废的，只能判断有没有返回结果没法判断是不是返回的正确结果