1una0bserver 最近的时间轴更新 1una0bserver 最近的时间轴更新 |
1una0bserverV2EX 第 656951 号会员，加入于 2023-10-30 14:53:56 +08:00今日活跃度排名 5041 |
| 掘金现在好像无人维护？ 互联网 • 1una0bserver • 38 天前 • 最后回复来自 cvooc | 11 |
| 发现一个新的 JVM 构建工具 Mill 分享发现 • 1una0bserver • 281 天前 • 最后回复来自 1una0bserver | 2 |
| 知乎现在想展开必须用户登录了？ 知乎 • 1una0bserver • 2024-05-24 12:52:08 PM • 最后回复来自 house9394 | 8 |
1una0bserver 最近回复了
4 天前 回复了 DandelionFlowers 创建的主题 › 分享发现 › 发现小红书、小绿书被风控会连坐设备 |
@docx 小绿书早就变味了，现在差不多就这样
8 天前 回复了 Leeeeex 创建的主题 › 软件 › 现在反而不敢买买断制 app 了 |
只有可以完全离线使用的软件或者开源软件才可以考虑买断，联网会员+国内作者大概率一段时间后跑路
19 天前 回复了 Fdyo 创建的主题 › Windows › 微软将投入更多资源来提升 Windows 11 基础体验 |
投入更多资源提升体验 ❌
雇佣更多阿三写 bug 画饼 ✔️
雇佣更多阿三写 bug 画饼 ✔️
21 天前 回复了 sunr0163513 创建的主题 › 问与答 › 各位，启动广告真心好恶心，除了换成苹果真心没办法解决嘛？鸿蒙会不？ |
鸿蒙更糟糕，你连去广告手段都没有了，当初刚有开发者搞了个 homojump 还在开发阶段，只是展示了下，官方火速禁用辅助功能 API
21 天前 回复了 zhixiao 创建的主题 › 程序员 › trae 我感觉用起来还可以啊 |
烂完了，早期连 code diff 都做不好，要么直接把文件内容整没了要么 diff 的代码错行，现在好不容易没这个问题了，问题模型还是烂，当初同样的 Claude 模型比其他家的明显降智，怀疑掺了不少水。最新的 solo 模式更是烂完了，solo code 模式 pro 会员开 max 开 plan ，经常不遵循指令复读，连继续都执行不对，指令修改文件给我直接输出回复里了还不对，要求按照文档来，结果写代码仍然不看文档用的旧 API+编的 API 不看 lint 到处 mock 到处 try catch ，甚至 try catch 还 tm 嵌套好几层！我从来没见过最近的模型写出过这么烂的代码，一年多前的 qwen 都没有！甚至不如最近出的 kat coder pro ，那个模型水平虽然没有其他的好，会写 mock 而且经常 API 对不上或者冗余封装，但是好歹量给足了而且免费啊，trae 这个感觉很多时候就是 7b 十几 b 的水平，然后记忆大一点。这玩意也就 IDE 界面做的好点，个人测试效果远不如 kiro/cursor/codebuddy/qwen 。刚被这玩意折腾了几小时，本来想设定好 plan 开 auto 睡觉起来看成果，结果被这玩意的折腾好几个小时成果还烂的一 p ，早知道不如买 minimax 了
78 天前 回复了 bigtear 创建的主题 › 分享发现 › 国内大数据下真就一点隐私都没有 |
首先，不要使用任何联网的输入法，更别说还是微信输入法这种实时回传数据的输入法
142 天前 回复了 halden 创建的主题 › 问与答 › 求证工信部关于鸿蒙适配进度的要求 |
今日笑点
159 天前 回复了 vincentCheong 创建的主题 › Android › Android 零基础, 现在要负责公司的一个项目, 还望老手给一些建议 |
159 天前 回复了 vincentCheong 创建的主题 › Android › Android 零基础, 现在要负责公司的一个项目, 还望老手给一些建议 |
@1una0bserver 你如果要用原生 view 写的话，我建议用 anko ，Contour 之类对 view 的 dsl 封装写，尽量避免用 xml ，一是更加接近声明式的写法，写起来更舒服点，二是避开 xml 中写 UI 的一堆坑。
159 天前 回复了 vincentCheong 创建的主题 › Android › Android 零基础, 现在要负责公司的一个项目, 还望老手给一些建议 |
首先我非常建议用 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 系统，你得替他们擦屁股。
至于框架的话，考虑到设备兼容性和性能较低，首先排除 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 系统，你得替他们擦屁股。
Select Language