debuggerx 最近的时间轴更新 debuggerx 最近的时间轴更新 | debuggerxV2EX 第 223488 号会员，加入于 2017-03-29 10:25:41 +08:00今日活跃度排名 7253 |
www.debuggerx.com
| 看了几个“发现”，我也说个操作，看有多少人知道的？ 2 分享发现 debuggerx 2025 年 7 月 6 日 最后回复来自 zoumaoping | 41 |
| 简书通过 UA 判断拒绝 Linux 浏览器显示图片/访问网站 1 分享发现 debuggerx 2024 年 11 月 12 日 最后回复来自 kaysar | 12 |
| 我也整了个在线版的仙剑 1，打开网页即玩，针对移动端做了适配，还有云存档 分享发现 debuggerx 2023 年 10 月 21 日 最后回复来自 debuggerx | 4 |
| 分享一个让 Fcitx5 更符合简中用户使用习惯的优化脚本 分享创造 debuggerx 2023 年 10 月 9 日 最后回复来自 joelincn | 5 |
| 屏蔽 V2EX 无聊的 AI 讨论的油猴脚本 分享发现 debuggerx 2023 年 2 月 20 日 最后回复来自 debuggerx | 4 |
| 红米笔记本 air 使用 Linux ，启动时内核会卡住 30 秒，求解决方案或思路 Linux debuggerx 2021 年 7 月 4 日 最后回复来自 liuxu | 42 |
| 续：《浏览器关闭最后一个标签页后的行为》，写了个插件试图找回当年用世界之窗的感觉～ 程序员 debuggerx 2021 年 6 月 30 日 最后回复来自 wdssmq | 30 |
| 迫于兼容 iOS 设备， golang 写了个把静态博客中 webp 图片在线转为 jpg 的工具 程序员 debuggerx 2020 年 11 月 24 日 最后回复来自 MrKrabs | 10 |
| 用 go 写了个把静态博客中 webp 图片在线转为 jpg 的工具，不知道有人需要吗 问与答 debuggerx 2020 年 11 月 23 日 |
| 不知是否火星,能科普下这个站是什么情况么 分享发现 debuggerx 2018 年 10 月 25 日 最后回复来自 nullornull | 7 |
debuggerx 最近回复了
3 月 27 日 回复了 hanxiV2EX 创建的主题 程序员 跨平台 GUI 应用开发还是 Flutter 强 |
@a33291 有个 fvp ，国人作者直接基于 ffmpeg 开发的，除了 Linux 可能还有点问题，其他平台基本都可以
3 月 26 日 回复了 nomisk 创建的主题 程序员 跨端技术应该入坑哪个 |
@Oilybear 个人体验：
即使是单一平台的 APP ，不管是古法编程还是 AI 辅助还是纯 agent 项目，用 flutter 的效率和效果都不比原生差。这里的原因我认为主要是两点：
1. flutter 相比原生的社区生态是降维打击，很多功能都有写好的库，而且很多积极维护的库不仅处理了跨平台兼容性问题，甚至平台本身的兼容性问题和 bug 都处理了，开发体验和稳定性比原生还好。
2. 不管是安卓还是 iOS 其实总的来说都还处于稳定成熟的传统原生（ OC 、xml ）向现代但不够成熟的方案（ compose 、swiftui ）转变的过程中，相比之下对于 AI 来说，flutter 是考虑到稳定性、确定性、丰富度更优的方案。
如果考虑到多平台，而且需要长期维护迭代，而不是一锤子买卖的项目，跨端方案比多端原生的优势更是巨大。这不是简单的两个平台只需要多一倍 token 这么简单的问题，下面是 gemini 的分析：
1. 软件工程的终极噩梦：状态与逻辑同步
无论 AI 多么聪明，如果在原生端分别实现，你依然会有两套完全独立的业务逻辑代码。
假设你需要修改一个电商 App 的“购物车结算逻辑”。 原生方案下，你需要分别 prompt （提示） AI 去修改 iOS 的 Swift 代码和 Android 的 Kotlin 代码。由于原生系统的生命周期、状态管理模式（如 iOS 的 SwiftUI/Combine 对应 Android 的 Compose/Flow ）不同，AI 生成的代码结构会截然不同。
这就导致了：
a. Bug 的不对称性：双端可能出现完全不同的 Bug 。iOS 可能因为闭包循环引用导致内存泄漏，Android 可能因为协程未取消导致崩溃。
b. 需求对齐极难：随着业务迭代，两套代码会逐渐“漂移”（ Drift ），最终导致同一个功能在两端的表现不一致。
c. 跨端方案的优势：使用跨端逻辑意味着业务核心代码只有一份。修一个 Bug ，双端自动生效，这不仅是写得快，更是错得少。
补充一下，哪怕只是最简单的业务逻辑，你让 AI 分别用 java/kotlin 和 OC/swift 去写两遍，其实都不一定能保证它们在各种 case 下的表现能“完全一致”，但如果核心业务逻辑是完全共享的，不管是用 dart 、js 、c 还是 rust ，就很难会出现不一致的问题导致的 bug 。
2. 代码生命周期中的“维护成本”公式
在软件工程中，代码的创建成本在整个生命周期中只占极小部分。代码写出来是一次性的，但阅读、重构、排查 Bug 需要持续投入。维持双端甚至多端一致性的沟通和校验成本比 AI 的创建成本要高得多。
你是愿意让人类开发者（哪怕借助 AI ）去 Review （审查）一份跨端代码的 Pull Request ，还是同时去 Review 两份基于不同语言、不同架构的 PR ？代码量翻倍，意味着人类审查的认知负荷（ Cognitive Load ）翻倍。AI 可以生成代码，但最终为线上 Bug 负责的依然是人类。
3. 多端生态不仅是 iOS 和 Android
现代跨端框架（如 Uni-app, Taro, React Native Web ）解决的不仅仅是手机 App 的问题。
现在的企业往往需要：iOS App 、Android App 、微信小程序、支付宝小程序、H5 移动端网页、甚至桌面客户端。 如果你让 AI 去写原生代码，你需要让 AI 分别写：1. Swift (iOS) 2. Kotlin (Android) 3. WXML/WXSS/JS (微信小程序) 4. GTK\Qt\Win32
即使 AI 能写，部署、测试、发版需要经过 4 个完全不同的流水线。而使用跨端框架，一套代码编译到多端，配合 AI 辅助编写这套“统一代码”，这才是真正的效率乘数效应。
即使是单一平台的 APP ，不管是古法编程还是 AI 辅助还是纯 agent 项目，用 flutter 的效率和效果都不比原生差。这里的原因我认为主要是两点：
1. flutter 相比原生的社区生态是降维打击，很多功能都有写好的库，而且很多积极维护的库不仅处理了跨平台兼容性问题，甚至平台本身的兼容性问题和 bug 都处理了，开发体验和稳定性比原生还好。
2. 不管是安卓还是 iOS 其实总的来说都还处于稳定成熟的传统原生（ OC 、xml ）向现代但不够成熟的方案（ compose 、swiftui ）转变的过程中，相比之下对于 AI 来说，flutter 是考虑到稳定性、确定性、丰富度更优的方案。
如果考虑到多平台，而且需要长期维护迭代，而不是一锤子买卖的项目，跨端方案比多端原生的优势更是巨大。这不是简单的两个平台只需要多一倍 token 这么简单的问题，下面是 gemini 的分析：
1. 软件工程的终极噩梦：状态与逻辑同步
无论 AI 多么聪明，如果在原生端分别实现，你依然会有两套完全独立的业务逻辑代码。
假设你需要修改一个电商 App 的“购物车结算逻辑”。 原生方案下，你需要分别 prompt （提示） AI 去修改 iOS 的 Swift 代码和 Android 的 Kotlin 代码。由于原生系统的生命周期、状态管理模式（如 iOS 的 SwiftUI/Combine 对应 Android 的 Compose/Flow ）不同，AI 生成的代码结构会截然不同。
这就导致了：
a. Bug 的不对称性：双端可能出现完全不同的 Bug 。iOS 可能因为闭包循环引用导致内存泄漏，Android 可能因为协程未取消导致崩溃。
b. 需求对齐极难：随着业务迭代，两套代码会逐渐“漂移”（ Drift ），最终导致同一个功能在两端的表现不一致。
c. 跨端方案的优势：使用跨端逻辑意味着业务核心代码只有一份。修一个 Bug ，双端自动生效，这不仅是写得快，更是错得少。
补充一下，哪怕只是最简单的业务逻辑，你让 AI 分别用 java/kotlin 和 OC/swift 去写两遍，其实都不一定能保证它们在各种 case 下的表现能“完全一致”，但如果核心业务逻辑是完全共享的，不管是用 dart 、js 、c 还是 rust ，就很难会出现不一致的问题导致的 bug 。
2. 代码生命周期中的“维护成本”公式
在软件工程中，代码的创建成本在整个生命周期中只占极小部分。代码写出来是一次性的，但阅读、重构、排查 Bug 需要持续投入。维持双端甚至多端一致性的沟通和校验成本比 AI 的创建成本要高得多。
你是愿意让人类开发者（哪怕借助 AI ）去 Review （审查）一份跨端代码的 Pull Request ，还是同时去 Review 两份基于不同语言、不同架构的 PR ？代码量翻倍，意味着人类审查的认知负荷（ Cognitive Load ）翻倍。AI 可以生成代码，但最终为线上 Bug 负责的依然是人类。
3. 多端生态不仅是 iOS 和 Android
现代跨端框架（如 Uni-app, Taro, React Native Web ）解决的不仅仅是手机 App 的问题。
现在的企业往往需要：iOS App 、Android App 、微信小程序、支付宝小程序、H5 移动端网页、甚至桌面客户端。 如果你让 AI 去写原生代码，你需要让 AI 分别写：1. Swift (iOS) 2. Kotlin (Android) 3. WXML/WXSS/JS (微信小程序) 4. GTK\Qt\Win32
即使 AI 能写，部署、测试、发版需要经过 4 个完全不同的流水线。而使用跨端框架，一套代码编译到多端，配合 AI 辅助编写这套“统一代码”，这才是真正的效率乘数效应。
3 月 26 日 回复了 nomisk 创建的主题 程序员 跨端技术应该入坑哪个 |
@lingz004 舍得花钱就找个设计师，或者找个靠谱的能生图的 AI 出几张图也行，然后还原设计稿呗，专业的事交给专业的人或工具。
肯下工夫就多看看成熟优秀的设计指南，参考精致的设计案例，但是有些人天生审美细胞不发达，比如我，自己做的小工具基本就靠抄 deepin 的设计，不然搞出来的东西自己都嫌弃……
比如：
https://www.debuggerx.com/2023/07/18/remote-system-monitor
https://github.com/debuggerx01/weekly_todo
肯下工夫就多看看成熟优秀的设计指南，参考精致的设计案例，但是有些人天生审美细胞不发达，比如我，自己做的小工具基本就靠抄 deepin 的设计，不然搞出来的东西自己都嫌弃……
比如：
https://www.debuggerx.com/2023/07/18/remote-system-monitor
https://github.com/debuggerx01/weekly_todo
3 月 25 日 回复了 nomisk 创建的主题 程序员 跨端技术应该入坑哪个 |
Flutter +3
公司项目从移动端到 pc 端到上位机，全是一套 flutter 项目搞定的
公司项目从移动端到 pc 端到上位机，全是一套 flutter 项目搞定的
3 月 5 日 回复了 Zlooooo 创建的主题 职场话 有两个 offer 我该如何选择？ |
首先排除 hw 云
3 月 4 日 回复了 mrfox 创建的主题 Android 关于 miracast |
AirReceiverLite ，某些自制 TV 系统会带，可以找找学习版。
2 月 9 日 回复了 archliinux 创建的主题 程序员 开发者怒批华为云 C++ SDK 质量：文档失效、基础代码错误频出 |
@killertom 都烂，但是能烂到没法用的，华子那是独一份儿
2 月 8 日 回复了 caiyuan 创建的主题 Linux 求推荐 Linux 桌面 |
公司开发电脑用 deepin v23 两年了，准备年后回来趁需求空档期换成 deepin v25
2 月 4 日 回复了 VinsonGuo 创建的主题 Android 小米要用 Flutter 来重写系统 App 了 |
@liyafe1997 冷启动时长这点我赞成你的说法，但实际来说没 unity 那种那么夸张，不负责任大致估计的话，如果原生冷启动只要十几几十毫秒，flutter 则可能需要 200ms 甚至更多。
但有意思的点是，现在的 os 都会为了视觉和体感的流畅加入启动动画，这个时间在一定程度上缩小了差距，另外系统应用一般功能单一，不会在启动时加入全屏启动页并初始化一大堆东西，所以相比于其他商业应用，启动性能也是会好很多的。
但有意思的点是，现在的 os 都会为了视觉和体感的流畅加入启动动画，这个时间在一定程度上缩小了差距，另外系统应用一般功能单一，不会在启动时加入全屏启动页并初始化一大堆东西，所以相比于其他商业应用，启动性能也是会好很多的。
Select Language