Kuikly（Kotlin UI Kit，发音同quickly），是使用Kotlin开发了声明式UI框架，映射到系统原生控件做渲染，最终用KMM（Kotlin Multiplatform Mobile）实现跨端。
Kuikly是一个开发语言高度同源的跨端框架，从业务代码、UI框架、布局层以及渲染层全部使用Kotlin语言（iOS渲染层是OC），这样不仅减少跨语言通信的性能成本，而且开发体验上更纯粹和高效。编译产物上，Android端采用原生的AAR方式，而iOS端通过KMM编译生成.framework，这样就不仅保证了原生开发体验，也保证了原生性能。如果希望实现动态化，Android端可以通过KMM编译成SO，iOS端可以编译成JS（KMM已经可以编译成Wasm，未来有稳定版本后就可以正式使用）。Kuikly具有优异的原生开发体验，相比于Hippy，更符合终端开发习惯。
自我介绍：
演讲选题思考：
演讲结构：
当前工具分类的模糊性：
近期AI赛道异常“内卷”，硅谷甚至出现了“996”乃至“007”的新闻。AI在编码（如Cursor、Anthropic）和解决复杂问题（如ACM竞赛夺冠、IMO金牌水平）上的表现，似乎已超越大部分程序员。
这引发了一个普遍的焦虑：AI coding + AI debug 是否将形成一个完美闭环，从而替代程序员？
然而，在快手这样拥有亿级日活（DAU）的复杂业务场景中，我们的实践表明，需要冷静看待这一议题。AI并非替代者，而是团队产出的放大器。今天的分享，将围绕快手在性能稳定性领域如何利用AI进行智能诊断与实践，揭示AI在真实工业场景中扮演的角色。
自2017年Google提出Transformer后，AI在各领域实现突破。
2023年起，大语言模型商业化加速，年增速达30倍以上。
AICoding 领域是发展最快的学科之一，因为反馈机制明确（“对就是对，错就是错”）。
这边文章是 Qcon 上海站 2025 来自支付宝的KMP分享总结, 主题为”AI Agent编码助手实战：面向KMP原生跨端实现研发提效”
文章参考: 支付宝 MYKMP 原生跨平台解决方案
文章参考 : AI Agent 编码助手实战：面向 KMP 原生跨端实现研发提效
本次分享首先对相关核心技术术语进行说明：
| 术语名称 | 术语介绍 |
|---|---|
| KMP（Kotlin Multiplatform） | JetBrains 基于 Kotlin 推出的一套跨端框架，允许开发者使用 Kotlin 语言编写一次业务逻辑代码，然后将其编译成适用于多个平台的原生应用、Web 应用或服务端应用。 |
| CMP（Compose Multiplatform） | JetBrains 提供的一套基于 Compose 基础库的声明式 UI 跨端框架，支持在 Android、iOS、桌面和 Web 开发共享 UI。 |
| 支付宝 KMP 原生跨端 | 在 “Kotlin + Compose Multiplatform” 的基础上，为支付宝终端开发者提供一整套完善的跨端框架能力。 |
| AntUI 组件库 | 基于 Compose 编写的支付宝 UI 组件库，包含丰富且风格统一的 UI 组件。 |
| OHOS、Harmony | OHOS 是鸿蒙项目的开源操作系统基底，而 HarmonyOS 是基于 OHOS 打造的商用智能终端操作系统。 |
在iOS开发过程中，是否经常遇到这样的场景：简单修改几行代码，想要立刻看到效果，却需要重新增量编译，苦苦等待编译、链接、安装、运行这个漫长的过程；特别是在中大型项目(如手Q)中，增量编译耗时也要60s甚至更多，非常影响开发效率。
为了解决增量编译，业界上也有IPAPatch及InjectionIII方案：
IPAPatch 是基于编译子工程，链接为动态库打包到宿主工程，需要改变代码依赖逻辑，使用局限性大且效果并不理想。
InjectionIII 也是基于dylib注入原理实现的iOS热重载能力，但是不支持真机以及dylib注入时仅简单处理函数替换，热重载的能力存在比较大的局限性，如存在对release版本静态库或动态库依赖的代码文件或存在被hook的类的实现代码文件进行热重载，要么无法支持，要么可能出现循环调用而导致应用出现Crash，且对Swift、C++代码的热重载支持也非常有限。如果基于InjectionIII的基础上进行开发，后续如果InjectionIII更新则不利于迭代。
上述两个方案均不能满足我们的需求，因此我们决定在基于dylib注入的原理基础上对热重载实现进行探索实现。