一键导入
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,然后仅修改差异清单中列出的项即可。