AI时代，我该不该深入一个跨端框架？
- 内容介绍
- 文章标签
- 相关推荐
我开心到飞起。 这篇文章在情感色彩、噪音和结构上做了大量的调整，力求避免过于规整的语言模式。 AI时代，我该不该深入一个跨端框架？ 学习 Kotlin 的起点并不是兴趣，而是工作。2025 年初， 团队负责的业务开始引入 KuiklyUI 做跨端开发，我承担了部分业务模块的开发，自然也就开始接触 Kotlin。 围绕这件事， 过去一年我系统补完了 Kotlin、KMP、Compose 的基础，能流畅地写 KuiklyUI 业务代码。学到这个程度之后我开始重新审视一个看起来很朴素的问题：会用，是不是就够了？ 这篇文章是这个问题的回答，也是后续 KuiklyUI 系列的。它不是一篇技术文，而是一次方向选择的复盘——从被动学习者，到主动深入者。 业务背景说起来不复杂。2025 年初，团队负责的业务需要一边覆盖多个移动端平台。传统 H5 方案性能不够， 纯原生开发又意味着双倍人力，KuiklyUI 是团队当时考虑的技术选型之一，到头来也成了主力方案，我跟你交个底...。 一开始我的目标很朴素，能用 Kuikly 把业务写起来就行。但真正动手之后才发现， KuiklyUI 是用 Kotlin DSL 写的，业务代码里到处涉及协程异步、声明式 UI、状态管理。这些概念虽然在前端世界里都有对应物， 但 Kotlin 的写法和心智模型与 JavaScript、TypeScript 差别不小。不补语言基础，连业务代码都写不流畅。 于是我列了一张看不懂的清单。这张清单决定了接下来一年的学习路线。 第一块短板：Kotlin 语言本身 KuiklyUI 的业务代码就是 Kotlin。它大量使用了 Kotlin 特有的语言特性： 函数：让现有 API 像原生函数一样调用 密封类：简化空泛处理 协程异步：提升响应式能力 数据类：自动生成 equals/hashCode/toString 这些特性和 TypeScript 的心智模型并不是一一对应的。语言基础不补，写出来的代码就是勉强能跑的状态，看团队同事的代码也半懂不懂。 第二块短板：Kotlin Multiplatform KuiklyUI 的跨端能力建立在 KMP 之上。不熟 commonMain / androidMain / iosMain 的目录约定, 搞不清楚哪段代码跑在哪个平台；不懂 expect / actual 机制, 看不懂跨端代码是怎么组织的。 第三块短板：Compose 的声明式 UI 思想 KuiklyUI 的 Compose DSL 借鉴了 Jetpack Compose. 不理解 remember / Modifier / 状态提升, 就理解不了 KuiklyUI 为什么这么设计 API, 为什么 UI 不更新, 为什么状态要这样组织。 关于 KMP 和平台差异 平台主要特点适用场景 Android原生 UI 组件Android 原生应用 iOSSwift/Objective-CiOS 原生应用 Web Web 技术栈跨平台 Web 应用 Desktop Desktop GUI framework跨平台桌面应用 一年来的成果与产物 腾讯云开发者社区专栏《前端开发学 kotlin》: 内容涵盖语言入门、 构建系统、协程、DSL等主题开源 Compose Multiplatform learning repository: 每个主题配一个可独立运行 lesson 从“能干活”到“懂原理” AI 工具崛起下的挑战 AI编程工具加速普及, 工程师判断力和决策能力而非单纯的代码量. AI擅长结构化任务, 人工需处理架构选择权.，来日方长。 对比表格: AI vs 人工效率 任务 AI 人工 API 调用模板生成 高效率 低效率 单元测试编写 中等效率 低效率 ] 深入探索的方向 架构图分析: 理解每个层级的职责边界 设计决策剖析: 分析关键设计选择背后的权衡 案例驱动学习: 通过实际问题来加深理解 这次决定继续往下走的原因在于: AI时代更看重的是能否把整个框架理解透彻; 而不仅仅是会使用某个工具. 将重心放在判断力和决策能力上, 这才是长期发展的关键. 下一步将从 KuiklyUI 的整体架构图开始讲解....
我开心到飞起。 这篇文章在情感色彩、噪音和结构上做了大量的调整，力求避免过于规整的语言模式。 AI时代，我该不该深入一个跨端框架？ 学习 Kotlin 的起点并不是兴趣，而是工作。2025 年初， 团队负责的业务开始引入 KuiklyUI 做跨端开发，我承担了部分业务模块的开发，自然也就开始接触 Kotlin。 围绕这件事， 过去一年我系统补完了 Kotlin、KMP、Compose 的基础，能流畅地写 KuiklyUI 业务代码。学到这个程度之后我开始重新审视一个看起来很朴素的问题：会用，是不是就够了？ 这篇文章是这个问题的回答，也是后续 KuiklyUI 系列的。它不是一篇技术文，而是一次方向选择的复盘——从被动学习者，到主动深入者。 业务背景说起来不复杂。2025 年初，团队负责的业务需要一边覆盖多个移动端平台。传统 H5 方案性能不够， 纯原生开发又意味着双倍人力，KuiklyUI 是团队当时考虑的技术选型之一，到头来也成了主力方案，我跟你交个底...。 一开始我的目标很朴素，能用 Kuikly 把业务写起来就行。但真正动手之后才发现， KuiklyUI 是用 Kotlin DSL 写的，业务代码里到处涉及协程异步、声明式 UI、状态管理。这些概念虽然在前端世界里都有对应物， 但 Kotlin 的写法和心智模型与 JavaScript、TypeScript 差别不小。不补语言基础，连业务代码都写不流畅。 于是我列了一张看不懂的清单。这张清单决定了接下来一年的学习路线。 第一块短板：Kotlin 语言本身 KuiklyUI 的业务代码就是 Kotlin。它大量使用了 Kotlin 特有的语言特性： 函数：让现有 API 像原生函数一样调用 密封类：简化空泛处理 协程异步：提升响应式能力 数据类：自动生成 equals/hashCode/toString 这些特性和 TypeScript 的心智模型并不是一一对应的。语言基础不补，写出来的代码就是勉强能跑的状态，看团队同事的代码也半懂不懂。 第二块短板：Kotlin Multiplatform KuiklyUI 的跨端能力建立在 KMP 之上。不熟 commonMain / androidMain / iosMain 的目录约定, 搞不清楚哪段代码跑在哪个平台；不懂 expect / actual 机制, 看不懂跨端代码是怎么组织的。 第三块短板：Compose 的声明式 UI 思想 KuiklyUI 的 Compose DSL 借鉴了 Jetpack Compose. 不理解 remember / Modifier / 状态提升, 就理解不了 KuiklyUI 为什么这么设计 API, 为什么 UI 不更新, 为什么状态要这样组织。 关于 KMP 和平台差异 平台主要特点适用场景 Android原生 UI 组件Android 原生应用 iOSSwift/Objective-CiOS 原生应用 Web Web 技术栈跨平台 Web 应用 Desktop Desktop GUI framework跨平台桌面应用 一年来的成果与产物 腾讯云开发者社区专栏《前端开发学 kotlin》: 内容涵盖语言入门、 构建系统、协程、DSL等主题开源 Compose Multiplatform learning repository: 每个主题配一个可独立运行 lesson 从“能干活”到“懂原理” AI 工具崛起下的挑战 AI编程工具加速普及, 工程师判断力和决策能力而非单纯的代码量. AI擅长结构化任务, 人工需处理架构选择权.，来日方长。 对比表格: AI vs 人工效率 任务 AI 人工 API 调用模板生成 高效率 低效率 单元测试编写 中等效率 低效率 ] 深入探索的方向 架构图分析: 理解每个层级的职责边界 设计决策剖析: 分析关键设计选择背后的权衡 案例驱动学习: 通过实际问题来加深理解 这次决定继续往下走的原因在于: AI时代更看重的是能否把整个框架理解透彻; 而不仅仅是会使用某个工具. 将重心放在判断力和决策能力上, 这才是长期发展的关键. 下一步将从 KuiklyUI 的整体架构图开始讲解....