원클릭으로
kuikly-multi-module-config
Kuikly 多模块工程配置助手。指导如何创建 Kuikly 子模块、配置多模块。当用户需要创建新 Kuikly 子模块、配置多模块参数、解决 KuiklyCoreEntry 入口类冲突时使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Kuikly 多模块工程配置助手。指导如何创建 Kuikly 子模块、配置多模块。当用户需要创建新 Kuikly 子模块、配置多模块参数、解决 KuiklyCoreEntry 入口类冲突时使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Analyze KuiklyUI Compose DSL recomposition performance issues from Recomposition Profiler output. Use when the user mentions 重组分析、重组优化、卡顿分析、recomp 报告、recomposition analysis, or asks to analyze profiler_report.json / profiler_frames.jsonl log files generated by KuiklyUI Recomposition Profiler.
Kuikly UI 框架开发助手。帮助使用 Kuikly 组件(View、Text、Button、List、Image、Modal、ActionSheet、Input、Scroller、Tabs 等 UI 组件)和模块(Router、Network、SP、Notify 等系统模块),自动提供正确的 import 语句、API 使用方法和完整代码示例。支持传统 Kuikly DSL(attr/event)和 Compose DSL 两种开发方式。适用场景:Kuikly 页面开发、组件使用、布局实现、事件处理、FlexBox 布局、响应式状态管理、动画效果、页面路由跳转、网络请求、列表渲染、自定义组件/模块扩展、Kuikly 编码问题、KuiklyUI 开发。
Kuikly DSL 动画开发助手(Kuikly DSL)。指导使用声明式和命令式两种方式实现 transform、opacity、backgroundColor、frame 等属性动画,涵盖串行/并行编排与动画取消。当用户需要实现动画效果时使用。
Kuikly 资源文件管理与加载助手。指导如何在 Kuikly 中添加、打包和加载 assets 资源,包括目录结构规范(common/页面资源)、各平台打包配置(Android/iOS/鸿蒙/H5/微信小程序/动态化)、ImageUri API 使用。当用户需要在 Kuikly 中使用本地图片资源、配置 assets 打包时使用。
Compose DSL 混用 Kuikly DSL 完整开发助手。指导如何在 Compose DSL 页面中嵌入 Kuikly DSL 组件(DeclarativeBaseView / ViewContainer)及在 Compose 中调用 Kuikly Module。当用户需要在 Compose 页面中复用 Kuikly DSL 组件、封装原生 View 为 Composable、在 Compose 中调用 Kuikly Module时使用。
Kuikly 协程与多线程编程助手。指导如何在 Kuikly 中进行异步编程,包括 Kuikly 内建协程、kotlinx 协程、kuiklyx 协程库。当用户在 Kuikly 中需要执行异步任务、切换线程、使用协程、回到 Kuikly 线程更新 UI、排查线程安全问题时使用。
SOC 직업 분류 기준
| name | kuikly-multi-module-config |
| description | Kuikly 多模块工程配置助手。指导如何创建 Kuikly 子模块、配置多模块。当用户需要创建新 Kuikly 子模块、配置多模块参数、解决 KuiklyCoreEntry 入口类冲突时使用。 |
子模块中有 Kuikly 页面(使用了 @Page 注解)才需要多模块设置。若子模块无页面则为普通 KMP 模块,无需特殊配置。
多模块解决的核心问题:多个独立 Kuikly 模块会导致 KuiklyCoreEntry 入口类冲突。
当用户要求创建 Kuikly 子模块时,按以下步骤执行:
🚨 强制规则:在执行任何配置操作之前,必须先向用户询问子模块名称。 即使用户只说了"帮我建一个子模块",也必须先停下来询问子模块要叫什么名字,拿到名称后才能继续。 绝对不要自行假设或编造子模块名称。
向用户询问以下信息(如未提供):
🔴 必须询问(缺一不可,未获得答案前不得执行后续步骤):
kuikly_business)settings.gradle.kts 中确认,如果无法确定则询问用户(通常是 demo 或 shared)确认名称后,展示以下 checklist:
Task Progress:
- [x] Step 1: 确认子模块名称 → ${用户提供的名称}
- [x] Step 2: 确认主模块名称 → ${确认的主模块名}
- [ ] Step 3: 创建子模块目录和 build.gradle.kts
- [ ] Step 4: 修改 settings.gradle.kts
- [ ] Step 5: 修改主模块 build.gradle.kts(依赖 + KSP 多模块参数)
- [ ] Step 6: 创建子模块 src 目录结构
- [ ] Step 7: 生成示例页面(@Page)
- [ ] Step 8: 检查是否有多套 Gradle 配置(如有则每套都需配置)
按顺序执行以下配置,每步完成后勾选 checklist:
在根目录 settings.gradle.kts 中添加子模块 include:
include(":${子模块名}")
// 如果主模块有 buildFileName 配置,子模块也需要:
project(":${子模块名}").buildFileName = buildFileName
修改主模块,添加两处配置:
// 1. commonMain 依赖中添加子模块
kotlin {
sourceSets {
val commonMain by getting {
dependencies {
implementation(project(":${子模块名}"))
}
}
}
}
// 2. ksp 块中配置多模块参数
ksp {
arg("moduleId", "${主模块名}")
arg("isMainModule", "true")
arg("subModules", "${子模块名}") // 多个子模块用 & 分隔
arg("enableMultiModule", "true")
}
已有 subModules 时:在现有值后追加
&${子模块名},如"sub1&sub2&${新子模块}"
直接复制主模块的
build.gradle.kts到子模块目录,然后仅修改以下差异点,其余配置(plugins、targets、cocoapods 等)保持与主模块完全一致。
需要修改的差异点:
// 差异 1:ksp 块 — 修改多模块参数
ksp {
// 其余参数保持不变...
arg("moduleId", "${子模块名}") // ← 改为子模块自己的名称
arg("isMainModule", "false") // ← 关键:改为 false
arg("enableMultiModule", "true")
// ★ 删除 subModules 参数(子模块不需要)
}
// 差异 2:android.namespace — 改为子模块包名
android {
namespace = "com.tencent.kuikly.${子模块名}"
}
// 差异 3:commonMain dependencies — 移除对其他子模块的依赖(保留 core、compose 等基础依赖)
完整差异清单详见 SUBMODULE_CONFIG.md
${子模块名}/
├── build.gradle.kts
├── src/
│ ├── commonMain/
│ │ ├── kotlin/com/tencent/kuikly/${子模块名}/
│ │ │ └── pages/ # 放 @Page 页面
│ │ └── assets/ # 资源文件(可选)
│ ├── androidMain/ # 以下 *Main 目录根据主模块架构按需创建
│ │ ├── AndroidManifest.xml
│ │ └── kotlin/
│ ├── iosMain/
│ │ └── kotlin/
│ └── jsMain/
│ └── kotlin/
<?xml version="1.0" encoding="utf-8"?>
<manifest package="com.tencent.kuikly.${子模块名}"/>
在子模块的 pages 目录下创建一个示例页面文件,确保子模块至少有一个 @Page 页面可以验证配置是否正确。
示例页面模板详见 SUBMODULE_CONFIG.md 中的「示例页面模板」章节。
页面文件路径:${子模块名}/src/commonMain/kotlin/com/tencent/kuikly/${子模块名}/pages/SamplePage.kt
有些项目会为不同平台维护多套 Gradle 配置文件(例如鸿蒙单独使用 build.ohos.gradle.kts、settings.ohos.gradle.kts),此时需要:
build.*.gradle.kts 或 settings.*.gradle.kts 文件build.gradle.kts、settings.gradle.kts、主模块 KSP 参数等)都需要在每套配置中重复执行一遍build.gradle.kts(如 build.ohos.gradle.kts),内容同样基于对应的主模块配置文件复制后修改差异点💡 判断方法:查看
settings.gradle.kts中是否有buildFileName相关配置,或者主模块目录下是否有多个build.*.gradle.kts文件。
鸿蒙平台的具体适配细节详见 MAIN_MODULE_CONFIG.md
| 配置项 | 主模块 | 子模块 |
|---|---|---|
moduleId | 主模块名(如 "shared") | 子模块名(如 "feature_chat") |
isMainModule | "true" | "false" |
subModules | 所有子模块名,& 分隔 | 不需要 |
enableMultiModule | "true" | "true" |
| commonMain 依赖 | implementation(project(":子模块")) | 不依赖主模块 |
子模块依赖主模块的 KuiklyCoreEntry 生成,不能独立存在。必须通过主模块编译。
每个模块的 moduleId 必须不同,否则 KSP 生成的入口类会冲突。
子模块的 ksp 块中不要配置 subModules 参数。
子模块配置了 cocoapods 插件后,Gradle 会自动生成 podspec 文件,无需手动创建。同时,iOS Podfile 中不需要单独 pod 引入子模块,因为子模块会和主模块统一编译生成一个 framework(shared.framework)。
子模块的 plugins、kotlin targets、cocoapods、android 块等其余配置建议和主模块保持一致,避免因配置差异导致编译或运行时问题。操作方式:直接复制主模块的 build.gradle.kts,然后仅修改差异清单中列出的项即可。