android-studio - Kotlin Multiplatform Mobile 找不到 klib 包

Question

我读过这些 SO 帖子 1 , 2 , 3它面临着类似的问题。我正在尝试在我的 KMM Android 项目中使用 .klib。 Klib 是从 library.h C 头文件构建的。这是我所做的:

我构建了 Kotlin 库

在 KMM shared 项目中使用以下 Gradle block :

kotlin {
    ...
    androidNativeArm64 { // target
        compilations.getByName("main") {
            val mylib by cinterops.creating {
                defFile(project.file("mylib.def"))

                packageName("c.mylib")
                // Options to be passed to compiler by cinterop tool.
                compilerOpts("-I/home/me/CLionProjects/mylib/")

                // Directories for header search (an analogue of the -I<path> compiler option).
                includeDirs.allHeaders("/home/me/CLionProjects/mylib/")

                // A shortcut for includeDirs.allHeaders.
                includeDirs("/home/me/CLionProjects/mylib/")
            }
        }
        binaries {
            sharedLib() // https://kotlinlang.org/docs/mpp-build-native-binaries.html#declare-binaries
        }
    }
}

使用 mylib.def 文件

headers = /home/me/CLionProjects/mylib/library.h
headerFilter = /home/me/CLionProjects/mylib/*
package = c.mylib

构建时，.klib 和构建文件夹出现在共享项目的classes 目录中，如下所示:

Platform 下的红线表示错误:

Expected class 'Platform' has no actual declaration in module MyApplication.shared.androidNativeArm64Main for Native

但显然 that may just be a system glitch (不确定 - “创建实际类......”的 Alt+Enter 解决方案似乎没有做任何事情)。假设这不是问题，我继续...

我检查.klib 细节

运行 .konan/.../bin/klib info mylib.klib 我没有得到 c.mylib 作为包名，但是 com. example.myapplication:shared-cinterop-mylib 代替(见下文)。我可以接受(虽然不确定为什么它不是我在 Gradle 中指定的)

Resolved to: /home/me/AndroidStudioProjects/MyApplication/shared/build/classes/kotlin/androidNativeArm64/main/shared-cinterop-mylib
Module name: <com.example.myapplication:shared-cinterop-mylib>
ABI version: 1.4.1
Compiler version: 1.4.10
Library version: null
Metadata version: 1.4.0
IR version: 1.0.0
Available targets: android_arm64

我尝试在我的 androidApp Gradle 中包含这个包

我想访问我的 androidApp 项目中的 .klib。我尝试了 c.mylib 和 com.example.myapplication:shared-cinterop-mylib 这两个包。

我尝试将 implementation("com.example.myapplication:shared-cinterop-mylib") 添加到我的 androidApp Gradle 文件中，但出现错误:

Could not determine the dependencies of task ':androidApp:lintVitalRelease'.Could not resolve all artifacts for configuration ':androidApp:debugCompileClasspath'.Could not find com.example.myapplication:shared-cinterop-mylib:.Required by:project :androidAppPossible solution:

• Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html

我不确定提示是否能解决问题，但我尝试使用例如将文件添加到 androidApp Gradle repositories { ... } block 中

    maven {
        url = uri("/home/me/AndroidStudioProjects/MyApplication/shared/build/classes/kotlin/androidNativeArm64/main/shared-cinterop-mylib.klib")
    }

但我不确定这是将文件添加到存储库的正确方法。

问题

任何人都可以帮助我在 androidApp 中识别包吗？我会继续努力。

Answer 1

您可能对针对不同平台的不同 Kotlin 版本感到困惑。请查看 the documentation有关详细信息，而我将在此处尝试解释基本概念。

Kotlin Multiplatform 通常由三种不同的编译器组成:一种用于构建 JVM，一种用于转换为 JS，一种用于编译特定于平台的 native 二进制文件(可执行文件、静态或共享库)。 KMM 技术是关于在两个不同的平台(iOS 和 Android)之间共享您的代码。

这里的重要细节是，KMM 旨在让开发人员更轻松地将此共享代码包含到他们现有的代码库中——通常是用于 iOS 的 Swift 或 Objective-C 和用于 Java 的，或用于 Android 的 Kotlin/JVM。这很重要，因为该项目是使用 Kotlin/Native 和 Kotlin/JVM 构建的。

在您的代码中，我看到了一个额外的平台声明。 androidNativeArm64，这是一个 Kotlin/Native 目标，而不是经典的 Android 目标。它使用其他编译器，并因此生成一个共享库。这就是为什么

1. 您可以定义一个 cinterop block ，为 header 创建绑定(bind)，但是
2. 这些绑定(bind)仅作为 Kotlin/Native 编译的一部分适用。

您在此处创建的 KLIB 本身并不是库，而是 native 库 (mylib) 的一组绑定(bind)。它使您能够从 Kotlin 代码中使用 mylib 的 API，编写在 androidNativeArm64Main 源代码集中。由于此时您没有这样的源集，您的项目无法正确构建，并显示有关缺少实际声明的警告。

总结上述所有内容。以下是在项目的当前状态下您可以做和不能做的事情:

可以

• 使用来自您的 Kotlin/Native 代码的绑定(bind)(将文件添加到 shared/src/androidNativeArm64Main/kotlin/)
• 使用这些绑定(bind)将代码编译到共享库(.so 文件)
• 按照 Android NDK 文档 (here) 中的说明使用此共享库

或

• 删除 Kotlin/Native Android 目标，并在 shared/src/androidMain/kotlin/
中删除不使用 C API 的代码

不能

• 依赖于来自 Kotlin/JVM 模块的 KLIB(例如 androidApp 一般项目或 shared 中的 androidMain 源集)
• 发布绑定(bind)并且不关心将生成的工件与 C 库链接
• 使用从 Kotlin/Native 编译的共享库或静态库比使用 C/C++ native 库更容易(抱歉，但这与您可能在此处尝试避免的 JNI 相同)

抱歉，回答又长又复杂，如有任何问题，请在下面的评论部分与我联系。我很乐意纠正我的任何错误或不准确之处。