Keyword: KMM Gradle，Kotlinx serialization

到Day9使用Kotlin DSL 管理依赖的Code放在
KMMDay9

我们要进行网路请求，以往在iOS上可能使用Maya，Android上使用Retrofit居多．
但Retrofit与Maya都不能给另外一个平台使用，所以需要为了各平台去独立写一份网路请求的程序码．
而在KMM这边，藉由官方提供的网路框架Ktor，可以实现双平台共用同一份Code，进而减少开发成本．
我们将要学习如何去使用Ktor，不过在这之前，必须先引入Ktor，而这其中也有不少的眉角

什麽是Ktor

这是由JetBrain推出的框架Ktor，用於Web api开发与测试，而且Kotlin常用的Coroutine，DSL等等的特性，也有支援．利用Kotlin的跨平台特性，可以轻易地开发出不同版本使用．

对於我们Client端，也有特别开发出支援各Client端的支援，让前後端都能在一个框架下进行沟通．

(在我刚开始学习KMM的时一直被官网的介绍所误导，以为Ktor只有提供後端开发，

後来询问Kotlin官方技术传教士圣佑後，才了解到Client端也有一份专属的内容)

Gradle 与依赖

要使用Ktor，就需要在Gradle内声明依赖关系，如果是Android开发者应该对此熟悉．Gradle有许多功能，负责管理编译流程，管理第三方库使用，调整参数等等的．

这次主要是使用到依赖管理的功能．这也是gradle最常使用的部分

KMM的架构稍微复杂，在这个刚建起来的KMM专案内，build.gradle就有三个．分别是:

1. 整个专案一起共用的build.gradle.kts(蓝色)
2. Shared部分使用的build.gradle.kts(红色)
3. android部分独自使用的build.gradle.kts(绿色)

这三个Gradle负责管理不同的依赖，放错位置可能会发生摸不着头绪的问题．
以後会称之为gradle(project) / gradle(shared) / gradle(android) 来分别代表这三个Gradle
要能够成功使用ktor，这几个gradle都需要做不同程度的修改，让我们开始吧．

Ktor的依赖

由於Ktor是使用在共用的网路请求，这个网路请求通常不会因为平台不同而改变，所以首要修改的就是shared内的gradle，让双平台一起共用的部分．找到gradle(shared)内的sourceSets．

sourceSets分别管理各区块的依赖，commonMain / androidMain / iosMain分别对应着 共通 / android专用 / iOS专用

而如果在建立专案时有选择"建立预设test档案"，还会多出commonTest/ androidTest/ iosTest，看名字就能知道分别是 共通测试 / android专用测试 / iOS专用测试

在不同的区块设定补上以下内容，通常来说，如果和平台没有关系的功能就会在common引入，而和平台实作有关系的就会分别到各平台的模块中．

sourceSets{
	val ktor_version = "1.6.3"
	val commonMain by getting {
        dependencies {
			．．．
			implementation("io.ktor:ktor-client-core:${ktor_version}" )
            implementation("io.ktor:ktor-client-json:${ktor_version}")
            implementation("io.ktor:ktor-client-logging:${ktor_version}")
            ．．．
        }
	}
	．．．
	val androidMain by getting {
      dependencies{
			．．．
            implementation("io.ktor:ktor-client-okhttp:${ktor_version}")
			．．．
        }
  }
．．．
	val iosMain by getting {
      dependencies{
			．．．
            implementation("io.ktor:ktor-client-ios:${ktor_version}")
			．．．
        }
  }
}

(注意：预设专案有些部分的getting後面没有大括弧，需要自己补上大括弧以及"dependencies"字眼)

Kotlinx serialization的依赖

除了网路请求的框架，我们还需要把网路请求的回传转换成object，一般来说是使用Gson比较多，不过这次我们换换口味，使用Kotlin官方推出的Kotlinx serialization进行解析，Kotlinx serialization 不仅支援多平台，完美符合我们的需求．且由於不是使用反射进行序列化，因此可以提供更快速的效能．甚至还能支援protobuff格式．

要使用到Kotlinx serialization 同样的，也需要在多个地方修改

首先是整个专案的gradle(project)，在buildScript内补上Kotlinx serialization的来源

buildscript {
    repositories {
       ．．．
    }
    dependencies {
        val serialization_version = "1.5.21"
        ．．．
        classpath("org.jetbrains.kotlin:kotlin-serialization:$serialization_version")
    }
}

再来是共通部分的gradle(shared)，除了在共通部分加入的依赖以外，plugin的地方也要加入Kotlinx serialization的plugin，才能在编译时产生对应物件．

plugins {
    ．．．
    id("kotlinx-serialization")
    ．．．
}

sourceSets {
    ．．．
        val ktor_version = "1.6.3"
    ．．．
        val commonMain by getting {
           dependencies {
            ．．．
	        implementation("io.ktor:ktor-client-serialization:${ktor_version}")
	        ．．．
            }
        }
      ．．．
    }

由於KMM的区块相当多元，所以需要在不同的Gradle里面放入不同的依赖，一开始的时候会搞不大清楚这个依赖要放在哪里，但是只要根据依赖的作用，就能了解所需要修改的位置

今天先把基础依赖建好了，但是实际上使用这样会很难管理版本，尤其在专案变大，或是像KMM这样有多平台的专案．就更为复杂．所以明天我们先学习如何使用Kotlin DSL来管理依赖