1una0bserver

今日笑点

@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+就能用...