Kuikly扩展库开发指南如何打造跨端组件库并共享给社区【免费下载链接】KuiklyUI基于KMP技术的高性能、全平台开发框架具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意本仓库为Github仓库镜像PR或Issue请移步至Github发起感谢支持项目地址: https://gitcode.com/Tencent-TDS/KuiklyUIKuikly扩展库是基于 KMPKotlin Multiplatform技术的高性能跨端组件开发方式它让业务无关的 View 和 Module 能够脱离宿主工程独立打包、独立发布最终沉淀为可共享给整个社区的跨端组件库。本指南将带你在 5 个步骤内完成一个扩展库工程以 LottieView 组件为例的搭建、验证与发布。为什么需要 Kuikly 扩展库在普通业务开发中扩展一个原生 View 的做法是在 Kuikly 侧实现跨端逻辑在 Android / iOS / 鸿蒙侧分别实现平台接口并注册到各平台 Render。这种方式适合单业务使用但存在两个痛点难以共享组件代码分散在主工程里其他业务线无法直接依赖集成成本高多业务方各自维护一份代码版本升级困难。Kuikly 扩展库的核心思路是把跨端层逻辑和各平台侧实现以独立 Module 的形式组织在同一个工程中实现跨端侧、各平台侧源码的独立打包与独立发布。扩展库工程结构速览以社区 Lottie 组件为例一个典型的 Kuikly 扩展库工程包含以下模块模块作用kLottieViewLottieView 跨端侧实现KMP 模块kLottieViewAndroid安卓端实现Android LibrarykLottieViewIOSiOS 端实现CocoaPods 库kLottieViewOhos鸿蒙端实现Static Libraryshared跨端 Demo 模块用于联调验证androidApp/iosApp/ohosApp等各平台宿主 Demo 工程完整的工程结构与目录设计说明可参考官方指引文档kuikly_extension_lib_guide.md。第一步创建 Kuikly 模板工程使用 Android Studio 新建工程File - New - New Project - Kuikly Project Template选择标准模板即可。这个模板工程将作为后续所有模块的调试沙箱让你可以在真实宿主中验证组件编译与运行效果。第二步创建 KMP 跨端模块跨端模块是组件的大脑负责暴露给 Kuikly DSL 使用的组件接口Attr 属性、Event 事件、viewName 等。创建方式有两种方式一通过 Android Studio 的Import Module创建之后参考模板shared模块配置build.gradle.kts方式二推荐直接拷贝模板工程的shared模块并改名配置更少、更可控。拷贝后需要做几处关键修改build.gradle.kts引入kotlin(multiplatform)、maven-publish等插件cocoapods 配置的baseName改为模块名如kLottieView无 JS Target 时可删除相关闭包与 androidMain 依赖build.ohos.gradle.kts在kotlin闭包中增加ohosArm64编译目标并移除 Android、iOS Target 配置避免重复发布podspec 文件文件名与内部引用统一改为新模块名与 cocoapods 的baseName保持一致。最后将新模块注册进settings.gradle.kts与settings.ohos.gradle.ktsinclude(:kLottieView) 开发阶段可先在 Demo 模块的依赖中添加implementation(project(:kLottieView))即可通过 IDE 直接运行 androidApp、iosApp、ohosApp 快速验证跨端模块能否正常编译。第三步实现各平台侧逻辑跨端模块只是接口声明真正的渲染需要各平台侧落地实现安卓端Android Library 模块在 Android Studio 中File - New - New Module - Android Library命名如kLottieViewAndroid然后让androidApp依赖该模块。平台侧通过实现IKuiklyRenderViewExport接口把原生 View 暴露给 Kuikly 侧。iOS 端CocoaPods 库直接新建kLottieViewIOS目录放置平台侧实现编写对应的.podspec文件并在iosApp的 Podfile 中添加本地依赖。iOS 侧组件通过运行时机制暴露给 Kuikly无需手动注册这是三端中最省心的一边。鸿蒙端Static Library 模块在 DevEco Studio 中打开ohosApp工程创建 Static Library 模块。由于 DevEco 默认把模块建在ohosApp目录下建议将其移动到工程根目录与 Android、iOS 模块保持同级的目录结构移动后需同步更新两处依赖路径根目录build-profile.json5的模块srcPath以及entry下oh-package.json5中的本地依赖声明。平台侧通过继承KuiklyRenderBaseView按需实现call、createArkUIView和setProp方法完成渲染对接。各平台侧接口的完整编写细节可查阅官方文档扩展原生View。第四步集成验证集成验证的关键是将各平台侧 View 注册到各平台 Render打通 Kuikly 侧与平台侧的逻辑连接Android 侧重写registerExternalRenderView调用renderViewExport(组件名, 构造闭包)完成注册iOS 侧组件运行时自动暴露无需注册鸿蒙侧在KuiklyViewDelegate的getCustomRenderViewCreatorRegisterMap中把组件名映射到对应 View 的构造器。注册完成后在sharedDemo 模块中编写页面调用你的组件分别运行三端宿主工程确认组件属性设置、事件回调、方法调用都工作正常即可进入发布阶段。第五步发布产物共享给社区Kuikly 扩展库需要对各模块独立发布产物与渠道各不同模块发布方式产物渠道KMP 跨端模块Android/iOS./gradlew :kLottieView:publishMaven 仓库KMP 跨端模块鸿蒙./gradlew -c settings.ohos.gradle.kts :kLottieView:publishMaven 仓库版本号建议加_ohos后缀区分Android 平台模块./gradlew :kLottieViewAndroid:publishMaven 仓库iOS 平台模块打包为 PodCocoaPods鸿蒙平台模块ohpm 发布OpenHarmony ohpm几个容易踩坑的细节跨端模块的发布配置基于maven-publish插件配置group与version后即可支持签名发布未配置凭据时可先发布到mavenLocal自测鸿蒙与 Android/iOS 是两次独立发布版本号务必区分如x.y.z与x.y.z_ohos避免产物互相覆盖业务无关的组件建议同步上架社区组件市场让更多开发者能发现并复用你的工作相关指引见 社区组件 与 贡献指南。写在最后从模板工程到社区共享Kuikly 扩展库的完整链路是模板工程 → KMP 跨端模块 → 三端平台实现 → 注册验证 → 独立发布。掌握这条链路后无论是团队内部沉淀通用 UI 能力还是对外开源组件都能以最小成本实现跨端复用。 建议从官方示例组件如 LottieView、MMKV 鸿蒙适配实践入手阅读源码参考文档Kuikly扩展库创建指引、KMP组件鸿蒙适配指引迈出你的第一个扩展库【免费下载链接】KuiklyUI基于KMP技术的高性能、全平台开发框架具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意本仓库为Github仓库镜像PR或Issue请移步至Github发起感谢支持项目地址: https://gitcode.com/Tencent-TDS/KuiklyUI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kuikly扩展库开发指南：如何打造跨端组件库并共享给社区
Kuikly扩展库开发指南如何打造跨端组件库并共享给社区【免费下载链接】KuiklyUI基于KMP技术的高性能、全平台开发框架具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意本仓库为Github仓库镜像PR或Issue请移步至Github发起感谢支持项目地址: https://gitcode.com/Tencent-TDS/KuiklyUIKuikly扩展库是基于 KMPKotlin Multiplatform技术的高性能跨端组件开发方式它让业务无关的 View 和 Module 能够脱离宿主工程独立打包、独立发布最终沉淀为可共享给整个社区的跨端组件库。本指南将带你在 5 个步骤内完成一个扩展库工程以 LottieView 组件为例的搭建、验证与发布。为什么需要 Kuikly 扩展库在普通业务开发中扩展一个原生 View 的做法是在 Kuikly 侧实现跨端逻辑在 Android / iOS / 鸿蒙侧分别实现平台接口并注册到各平台 Render。这种方式适合单业务使用但存在两个痛点难以共享组件代码分散在主工程里其他业务线无法直接依赖集成成本高多业务方各自维护一份代码版本升级困难。Kuikly 扩展库的核心思路是把跨端层逻辑和各平台侧实现以独立 Module 的形式组织在同一个工程中实现跨端侧、各平台侧源码的独立打包与独立发布。扩展库工程结构速览以社区 Lottie 组件为例一个典型的 Kuikly 扩展库工程包含以下模块模块作用kLottieViewLottieView 跨端侧实现KMP 模块kLottieViewAndroid安卓端实现Android LibrarykLottieViewIOSiOS 端实现CocoaPods 库kLottieViewOhos鸿蒙端实现Static Libraryshared跨端 Demo 模块用于联调验证androidApp/iosApp/ohosApp等各平台宿主 Demo 工程完整的工程结构与目录设计说明可参考官方指引文档kuikly_extension_lib_guide.md。第一步创建 Kuikly 模板工程使用 Android Studio 新建工程File - New - New Project - Kuikly Project Template选择标准模板即可。这个模板工程将作为后续所有模块的调试沙箱让你可以在真实宿主中验证组件编译与运行效果。第二步创建 KMP 跨端模块跨端模块是组件的大脑负责暴露给 Kuikly DSL 使用的组件接口Attr 属性、Event 事件、viewName 等。创建方式有两种方式一通过 Android Studio 的Import Module创建之后参考模板shared模块配置build.gradle.kts方式二推荐直接拷贝模板工程的shared模块并改名配置更少、更可控。拷贝后需要做几处关键修改build.gradle.kts引入kotlin(multiplatform)、maven-publish等插件cocoapods 配置的baseName改为模块名如kLottieView无 JS Target 时可删除相关闭包与 androidMain 依赖build.ohos.gradle.kts在kotlin闭包中增加ohosArm64编译目标并移除 Android、iOS Target 配置避免重复发布podspec 文件文件名与内部引用统一改为新模块名与 cocoapods 的baseName保持一致。最后将新模块注册进settings.gradle.kts与settings.ohos.gradle.ktsinclude(:kLottieView) 开发阶段可先在 Demo 模块的依赖中添加implementation(project(:kLottieView))即可通过 IDE 直接运行 androidApp、iosApp、ohosApp 快速验证跨端模块能否正常编译。第三步实现各平台侧逻辑跨端模块只是接口声明真正的渲染需要各平台侧落地实现安卓端Android Library 模块在 Android Studio 中File - New - New Module - Android Library命名如kLottieViewAndroid然后让androidApp依赖该模块。平台侧通过实现IKuiklyRenderViewExport接口把原生 View 暴露给 Kuikly 侧。iOS 端CocoaPods 库直接新建kLottieViewIOS目录放置平台侧实现编写对应的.podspec文件并在iosApp的 Podfile 中添加本地依赖。iOS 侧组件通过运行时机制暴露给 Kuikly无需手动注册这是三端中最省心的一边。鸿蒙端Static Library 模块在 DevEco Studio 中打开ohosApp工程创建 Static Library 模块。由于 DevEco 默认把模块建在ohosApp目录下建议将其移动到工程根目录与 Android、iOS 模块保持同级的目录结构移动后需同步更新两处依赖路径根目录build-profile.json5的模块srcPath以及entry下oh-package.json5中的本地依赖声明。平台侧通过继承KuiklyRenderBaseView按需实现call、createArkUIView和setProp方法完成渲染对接。各平台侧接口的完整编写细节可查阅官方文档扩展原生View。第四步集成验证集成验证的关键是将各平台侧 View 注册到各平台 Render打通 Kuikly 侧与平台侧的逻辑连接Android 侧重写registerExternalRenderView调用renderViewExport(组件名, 构造闭包)完成注册iOS 侧组件运行时自动暴露无需注册鸿蒙侧在KuiklyViewDelegate的getCustomRenderViewCreatorRegisterMap中把组件名映射到对应 View 的构造器。注册完成后在sharedDemo 模块中编写页面调用你的组件分别运行三端宿主工程确认组件属性设置、事件回调、方法调用都工作正常即可进入发布阶段。第五步发布产物共享给社区Kuikly 扩展库需要对各模块独立发布产物与渠道各不同模块发布方式产物渠道KMP 跨端模块Android/iOS./gradlew :kLottieView:publishMaven 仓库KMP 跨端模块鸿蒙./gradlew -c settings.ohos.gradle.kts :kLottieView:publishMaven 仓库版本号建议加_ohos后缀区分Android 平台模块./gradlew :kLottieViewAndroid:publishMaven 仓库iOS 平台模块打包为 PodCocoaPods鸿蒙平台模块ohpm 发布OpenHarmony ohpm几个容易踩坑的细节跨端模块的发布配置基于maven-publish插件配置group与version后即可支持签名发布未配置凭据时可先发布到mavenLocal自测鸿蒙与 Android/iOS 是两次独立发布版本号务必区分如x.y.z与x.y.z_ohos避免产物互相覆盖业务无关的组件建议同步上架社区组件市场让更多开发者能发现并复用你的工作相关指引见 社区组件 与 贡献指南。写在最后从模板工程到社区共享Kuikly 扩展库的完整链路是模板工程 → KMP 跨端模块 → 三端平台实现 → 注册验证 → 独立发布。掌握这条链路后无论是团队内部沉淀通用 UI 能力还是对外开源组件都能以最小成本实现跨端复用。 建议从官方示例组件如 LottieView、MMKV 鸿蒙适配实践入手阅读源码参考文档Kuikly扩展库创建指引、KMP组件鸿蒙适配指引迈出你的第一个扩展库【免费下载链接】KuiklyUI基于KMP技术的高性能、全平台开发框架具备统一代码库、极致易用性和动态灵活性。 Provide a high-performance, full-platform development framework with unified codebase, ultimate ease of use, and dynamic flexibility. 注意本仓库为Github仓库镜像PR或Issue请移步至Github发起感谢支持项目地址: https://gitcode.com/Tencent-TDS/KuiklyUI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
