[Kotlin/Native] 你想知道的都在这里了

再一次过来帮大家踩坑了，Kotlin/Native 虽然很方便，但是坑依然不少，通过这一篇文章踩完吧，希望以后不要再碰到环境或编译问题了。

首先我依然要吐槽官方的新建项目向导，建出来几乎都是不能改的，目录都写死，一改就编不过去。后面就是干脆把 CLion 里的向导去掉了，这可怎么办才好:( 随后在升级了 IntelliJ IDEA 后发现，原来 Kotlin/Native 相关的东西都在这里了。亲儿子就是不一样啊，这么一看 CLion 简直是后妈养的。

在 IntelliJ IDEA 里新建一个 Kotlin/Native 项目，然后我们来说说 build.gradle。

plugins {
    id 'kotlin-multiplatform' version '1.3.31'
}

这一段是对跨平台编译插件的引入，有一些教程上说需要引入 kotlin-native 插件，这是没有必要的，我也不知道是什么情况下才需要引用 kotlin-native 插件。

kotlin {
    macosX64("macos") {
        binaries {
            executable {
                entryPoint "main"
            }
        }
    }
}

这一段用于指出在 Mac 下的编译方式，这里提供了编译为可执行程序的目标。这里还可以编译成别的东西，比如说 framework:

kotlin {
    macosX64("macos") {
        binaries {
            framework {
                baseName = "sample"
            }
        }
    }
}

如果要实现跨平台编译，需要添加其他平台的 Target，比如说同时编译到 linux 下，可以增加这样的代码段:

linuxX64("linux") {
    binaries {
        executable {
            entryPoint "main"
        }
    }
}

下面要讲的东西是重点中的重点，对于代码的配置，为什么 CLion 建立的项目不能乱改，很大程度上就是这部分的配置被写得太死。先来看这一段代码；

kotlin {
    sourceSets {
        commonMain {
            dependencies {
                implementation kotlin('stdlib-common')
            }
        }
        macosMain {

        }
    }
}

这里的 commonMain 是固定不变的，任何项目都可以拥有全局的 commonMain 目录，在这里写平台无关的代码，同时，对应的文件夹路径必须为 src/commonMain/kotlin，这是不能个修改的，修改的结果是使得这些代码无法被编译。

如果要添加通用的依赖，可以加在 commonMain 配置内，而 macosMain 下面所配置的依赖，将只作用于 Mac 平台。无论在什么时候，commonMain 内配置的依赖都会被所有的 Target 引用，所以需要非常谨慎，有的时候引用的库不能工作在 Linux 或 Windows，那么对应的这两个平台就会报错。对于这种情况，只能把各个平台的依赖单独写开，如:

kotlin {
    sourceSets {
        commonMain {
            ... ...
        }
        macosMain {
            dependencies {
                implementation "group:name:version"
            }
        }
    }
}

对了，还有一种依赖写法是 implementation kotlin('stdlib-common')，这是 kotlin 提供的便利，这样的代码对应的真实库是 org.jetbrains.kotlin:kotlin-stdlib-common:1.3.31，其规则为 org.jetbrains.kotlin:kotlin- 加上库的名称，加上当前所使用的 kotlin 版本号。

下面再来说 macosMain 的情况，这个名称的来源是在上面 macosX64 一句内设定的，这里可以随意修改，如:

kotlin {
    macosX64("sample") {
        ... ... 
    }
    sourceSets {
        commonMain {
            ... ...
        }
        sampleMain {
            ... ...
        }
    }
}

在这种情况下，只要编译平台与源码内定义的名称一致，同时物理文件的目录同样改为 src/sampleMain/kotlin 即可生效。或许有的人会问，sampleMain 写着太丑了，后面的 Main 能否去掉，答案是不能，这是一种约定俗成的写法。

通常情况下，我们会将 main 函数写在 commonMain 里，以便进行统一的编译，这里大家一定发现了，在 commonMain 里，是不带 posix 库的，也就是无法引用平台的能力。所以就有人说了，Kotlin/Native 只是一套通用的语法，只能拿来写写算法，不实用啊。这里就是一种很大的误会，其实我们可以很轻易的把跨平台的东西拆开，分开写不同的代码（当然话又说回来，之前跟我学 CodeTyphon 的人都已经体会到一套 API 直接跨平台的好处了，现在分平台写代码必然不习惯，或许等后面 Kotlin/Native 拥有更多跨平台方向的包装库后，这个现象会好转，大家也可以自己造轮子）。

好了，下面来看一个实际的例子，要输出当前平台怎么做呢？Kotlin/Native 没有宏，只是依赖 gradle 来判断平台。

这里有两个全新的概念，分别是 期待 和 现实，我们可以用 expect 声明一个期待，用 actual 来声明一个现实。如下所示：

expect val platformName: String    // 在 commonMain 内

fun main(args: Array<String>) {
    println(platformName)
}

这里的 platformName 是一个期待，它会由 现实 的函数，在编译期来填充。

actual val platformName: String get() = "Mac"    // 在 macosMain 内

actual val platformName: String get() = "Linux"    // 在 linuxMain 内

编译后我们就可以看到效果了，针对不同的平台，可以打印出不同的结果。

对于任意成员，都可以用 expect 来修饰，表示它将被 actual 实现，但是要注意，一个 expect 必须在所有的 Target 内都有实现，否则编译会报错。

下面来看一个更为实际的例子，获取程序自身的全路径:

expect val exePath: String    // 在 commonMain 内

fun main(args: Array<String>) {
    println(exePath)
}

actual val exePath: String get() {      // 在 macosMain 内
    memScoped {
        val length = PROC_PIDPATHINFO_MAXSIZE
        val pathBuf = allocArray<ByteVar>(length)
        val myPid = getpid()
        val res = proc_pidpath(myPid, pathBuf, length.toUInt())
        if (res < 1) throw RuntimeException("proc_pidpath failed: $res")
        return pathBuf.toKString()
    }
}

actual val exePath: String get() {    // 在 linuxMain 内
    memScoped {
        val length = PATH_MAX.toULong()
        val pathBuf = allocArray<ByteVar>(length.toInt())
        val myPid = getpid()
        val res = readlink("/proc/$myPid/exe", pathBuf, length)
        if (res < 1) throw RuntimeException("/proc/$myPid/exe failed: $res")
        return pathBuf.toKString()
    }
}

这样就可以简单包装住各个平台不同的代码，并且给到一个统一的输出。

这里也提一下 memScoped 这种闭包的写法，在 memScoped 内，只要申请内存，在闭包结束时会自动释放，不再需要手动管理内存。

关于指针，指针可能是最让人难理解的东西了，从 C 的时代起，就有无数英雄跪倒在指针而止步不前。Kotlin/Native 一样支持指针，也尽可能的尝试让指针更容易操作。

用一个例子来解释就行了:

#include <stdio.h>
int main() {
    int a[] = {1, 3, 5, 7, 9};
    int* p = a;
    printf("%d\n", *p);
    p++;
    printf("%d\n", *p);
    return 0;
}

以上 C 语言代码转换成 Kotlin/Native 就是这样的:

import kotlinx.cinterop.*
fun main() {
    val a = arrayOf(1, 3, 5, 7, 9)
    var p = nativeHeap.allocArray<IntVar>(a.size)
    for (i in a.indices) { p[i] = a[i] }
    println(p.pointed.value)
    p = (p + 1)!!
    println(p.pointed.value)
}

关于指针，更详细的内容可以参考官方的文档(点击进入)