Before Kotlin 1.4.0, you could apply SAM (Single Abstract Method) conversions only when working with Java methods and Java interfaces from Kotlin. From now on, you can use SAM conversions for Kotlin interfaces as well. To do so, mark a Kotlin interface explicitly as functional with the fun modifier.

SAM conversion applies if you pass a lambda as an argument when an interface with only one single abstract method is expected as a parameter. In this case, the compiler automatically converts the lambda to an instance of the class that implements the abstract member function.

1. fun interface IntPredicate {
2. fun accept(i: Int): Boolean
3. }

5. val isEven = IntPredicate { it % 2 == 0 }

7. fun main() {
8. println("Is 7 even? - ${isEven.accept(7)}")
9. }

Learn more about Kotlin functional interfaces and SAM conversions.

面向库作者的显式 API 模式

Kotlin compiler offers explicit API mode for library authors. In this mode, the compiler performs additional checks that help make the library’s API clearer and more consistent. It adds the following requirements for declarations exposed to the library’s public API:

Visibility modifiers are required for declarations if the default visibility exposes them to the public API. This helps ensure that no declarations are exposed to the public API unintentionally.
Explicit type specifications are required for properties and functions that are exposed to the public API. This guarantees that API users are aware of the types of API members they use.

Depending on your configuration, these explicit APIs can produce errors (strict mode) or warnings (warning mode). Certain kinds of declarations are excluded from such checks for the sake of readability and common sense:

primary constructors
properties of data classes
property getters and setters
override methods

Explicit API mode analyzes only the production sources of a module.

To compile your module in the explicit API mode, add the following lines to your Gradle build script:

1. kotlin {
2. // for strict mode
3. explicitApi()
4. // or
5. explicitApi = 'strict'

7. // for warning mode
8. explicitApiWarning()
9. // or
10. explicitApi = 'warning'
11. }

1. kotlin {
2. // for strict mode
3. explicitApi()
4. // or
5. explicitApi = ExplicitApiMode.Strict

7. // for warning mode
8. explicitApiWarning()
9. // or
10. explicitApi = ExplicitApiMode.Warning
11. }

When using the command-line compiler, switch to explicit API mode by adding the -Xexplicit-api compiler option with the value strict or warning.

1. -Xexplicit-api={strict|warning}

For more details about the explicit API mode, see the KEEP.

混用具名与位置参数

In Kotlin 1.3, when you called a function with named arguments, you had to place all the arguments without names (positional arguments) before the first named argument. For example, you could call f(1, y = 2), but you couldn’t call f(x = 1, 2).

It was really annoying when all the arguments were in their correct positions but you wanted to specify a name for one argument in the middle. It was especially helpful for making absolutely clear which attribute a boolean or null value belongs to.

In Kotlin 1.4, there is no such limitation – you can now specify a name for an argument in the middle of a set of positional arguments. Moreover, you can mix positional and named arguments any way you like, as long as they remain in the correct order.

1. fun reformat(
2. str: String,
3. uppercaseFirstLetter: Boolean = true,
4. wordSeparator: Char = ' '
5. ) {
6. // ...
7. }

9. //Function call with a named argument in the middle
10. reformat("This is a String!", uppercaseFirstLetter = false , '-')

拖尾的逗号

With Kotlin 1.4 you can now add a trailing comma in enumerations such as argument and parameter lists, when entries, and components of destructuring declarations. With a trailing comma, you can add new items and change their order without adding or removing commas.

This is especially helpful if you use multi-line syntax for parameters or values. After adding a trailing comma, you can then easily swap lines with parameters or values.

1. fun reformat(
2. str: String,
3. uppercaseFirstLetter: Boolean = true,
4. wordSeparator: Character = ' ', //trailing comma
5. ) {
6. // ...
7. }

1. val colors = listOf(
2. "red",
3. "green",
4. "blue", //trailing comma
5. )

可调用引用改进

Kotlin 1.4 supports more cases for using callable references:

对具有默认参数值的函数的引用
可作为返回 Unit的函数的函数引用
根据函数的参数数量进行调整的引用
可调用引用的挂起转换

对具有默认参数值的函数的引用

Now you can use callable references to functions with default argument values. If the callable reference to the function foo takes no arguments, the default value 0 is used.

1. fun foo(i: Int = 0): String = "$i!"

3. fun apply(func: () -> String): String = func()

5. fun main() {
6. println(apply(::foo))
7. }

Previously, you had to write additional overloads for the function apply to use the default argument values.

1. // some new overload
2. fun applyInt(func: (Int) -> String): String = func(0)

可作为返回 `Unit`的函数的函数引用

In Kotlin 1.4, you can use callable references to functions returning any type in Unit-returning functions. Before Kotlin 1.4, you could only use lambda arguments in this case. Now you can use both lambda arguments and callable references.

1. fun foo(f: () -> Unit) { }
2. fun returnsInt(): Int = 42

4. fun main() {
5. foo { returnsInt() } // this was the only way to do it  before 1.4
6. foo(::returnsInt) // starting from 1.4, this also works
7. }

根据函数的参数数量进行调整的引用

Now you can adapt callable references to functions when passing a variable number of arguments (vararg) . You can pass any number of parameters of the same type at the end of the list of passed arguments.

1. fun foo(x: Int, vararg y: String) {}

3. fun use0(f: (Int) -> Unit) {}
4. fun use1(f: (Int, String) -> Unit) {}
5. fun use2(f: (Int, String, String) -> Unit) {}

7. fun test() {
8. use0(::foo)
9. use1(::foo)
10. use2(::foo)
11. }

可调用引用的挂起转换

In addition to suspend conversion on lambdas, Kotlin now supports suspend conversion on callable references starting from version 1.4.0.

1. fun call() {}
2. fun takeSuspend(f: suspend () -> Unit) {}

4. fun test() {
5. takeSuspend { call() } // OK before 1.4
6. takeSuspend(::call) // In Kotlin 1.4, it also works
7. }

在循环中的 `when` 内部使用 `break` 与 `continue`

In Kotlin 1.3, you could not use unqualified break and continue inside when expressions included in loops. The reason was that these keywords were reserved for possible fall-through behavior in when expressions.

That’s why if you wanted to use break and continue inside when expressions in loops, you had to label them, which became rather cumbersome.

1. fun test(xs: List<Int>) {
2. [email protected] (x in xs) {
3. when (x) {
4. 2 -> [email protected]
5. 17 -> [email protected]
6. else -> println(x)
7. }
8. }
9. }

In Kotlin 1.4, you can use break and continue without labels inside when expressions included in loops. They behave as expected by terminating the nearest enclosing loop or proceeding to its next step.

1. fun test(xs: List<Int>) {
2. for (x in xs) {
3. when (x) {
4. 2 -> continue
5. 17 -> break
6. else -> println(x)
7. }
8. }
9. }

The fall-through behavior inside when is subject to further design.

回到顶部

IDE 中的新工具

With Kotlin 1.4, you can use the new tools in IntelliJ IDEA to simplify Kotlin development:

新的灵活项目向导
协程调试器

新的灵活项目向导

With the flexible new Kotlin Project Wizard, you have a place to easily create and configure different types of Kotlin projects, including multiplatform projects, which can be difficult to configure without a UI.

The new Kotlin Project Wizard is both simple and flexible:

Select the project template, depending on what you’re trying to do. More templates will be added in the future.
Select the build system – Gradle (Kotlin or Groovy DSL), Maven, or IntelliJ IDEA. The Kotlin Project Wizard will only show the build systems supported on the selected project template.
Preview the project structure directly on the main screen.

Then you can finish creating your project or, optionally, configure the project on the next screen:

Add/remove modules and targets supported for this project template.
Configure module and target settings, for example, the target JVM version, target template, and test framework.

In the future, we are going to make the Kotlin Project Wizard even more flexible by adding more configuration options and templates.

You can try out the new Kotlin Project Wizard by working through these tutorials:

协程调试器

Many people already use coroutines for asynchronous programming. But when it came to debugging, working with coroutines before Kotlin 1.4, could be a real pain. Since coroutines jumped between threads, it was difficult to understand what a specific coroutine was doing and check its context. In some cases, tracking steps over breakpoints simply didn’t work. As a result, you had to rely on logging or mental effort to debug code that used coroutines.

In Kotlin 1.4, debugging coroutines is now much more convenient with the new functionality shipped with the Kotlin plugin.

Debugging works for versions 1.3.8 or later of kotlinx-coroutines-core.

The Debug Tool Window now contains a new Coroutines tab. In this tab, you can find information about both currently running and suspended coroutines. The coroutines are grouped by the dispatcher they are running on.

Now you can:

Easily check the state of each coroutine.
See the values of local and captured variables for both running and suspended coroutines.
See a full coroutine creation stack, as well as a call stack inside the coroutine. The stack includes all frames with variable values, even those that would be lost during standard debugging.

If you need a full report containing the state of each coroutine and its stack, right-click inside the Coroutines tab, and then click Get Coroutines Dump. Currently, the coroutines dump is rather simple, but we’re going to make it more readable and helpful in future versions of Kotlin.

Learn more about debugging coroutines in this blog post and IntelliJ IDEA documentation.

回到顶部

新编译器

The new Kotlin compiler is going to be really fast; it will unify all the supported platforms and provide an API for compiler extensions. It’s a long-term project, and we’ve already completed several steps in Kotlin 1.4.0:

新的、更强大的类型推断算法 is enabled by default.
新的 JVM 与 JS IR 后端 are now in Alpha. They will become the default once we stabilize them.

新的更强大的类型推断算法

Kotlin 1.4 uses a new, more powerful type inference algorithm. This new algorithm was already available to try in Kotlin 1.3 by specifying a compiler option, and now it’s used by default. You can find the full list of issues fixed in the new algorithm in YouTrack. Here you can find some of the most noticeable improvements:

会自动推断类型的更多情况
lambda 表达式最后一个表达式的智能转换
可调用引用的智能转换
属性委托的更佳推断
具有不同参数的 Java 接口的 SAM 转换
Kotlin 中的 Java SAM 接口

会自动推断类型的更多情况

The new inference algorithm infers types for many cases where the old algorithm required you to specify them explicitly. For instance, in the following example the type of the lambda parameter it is correctly inferred to String?:

1. //sampleStart
2. val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
3. "weak" to { it != null },
4. "medium" to { !it.isNullOrBlank() },
5. "strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
6. )
7. //sampleEnd

9. fun main() {
10. println(rulesMap.getValue("weak")("abc!"))
11. println(rulesMap.getValue("strong")("abc"))
12. println(rulesMap.getValue("strong")("abc!"))
13. }

In Kotlin 1.3, you needed to introduce an explicit lambda parameter or replace to with a Pair constructor with explicit generic arguments to make it work.

lambda 表达式最后一个表达式的智能转换

In Kotlin 1.3, the last expression inside a lambda wasn’t smart cast unless you specified the expected type. Thus, in the following example, Kotlin 1.3 infers String? as the type of the result variable:

1. val result = run {
2. var str = currentValue()
3. if (str == null) {
4. str = "test"
5. }
6. str // the Kotlin compiler knows that str is not null here
7. }
8. // The type of 'result' is String? in Kotlin 1.3 and String in Kotlin 1.4

In Kotlin 1.4, thanks to the new inference algorithm, the last expression inside a lambda gets smart cast, and this new, more precise type is used to infer the resulting lambda type. Thus, the type of the result variable becomes String.

In Kotlin 1.3, you often needed to add explicit casts (either !! or type casts like as String) to make such cases work, and now these casts have become unnecessary.

可调用引用的智能转换

In Kotlin 1.3, you couldn’t access a member reference of a smart cast type. Now in Kotlin 1.4 you can:

1. import kotlin.reflect.KFunction

3. sealed class Animal
4. class Cat : Animal() {
5. fun meow() {
6. println("meow")
7. }
8. }

10. class Dog : Animal() {
11. fun woof() {
12. println("woof")
13. }
14. }

16. //sampleStart
17. fun perform(animal: Animal) {
18. val kFunction: KFunction<*> = when (animal) {
19. is Cat -> animal::meow
20. is Dog -> animal::woof
21. }
22. kFunction.call()
23. }
24. //sampleEnd

26. fun main() {
27. perform(Cat())
28. }

You can use different member references animal::meow and animal::woof after the animal variable has been smart cast to specific types Cat and Dog. After type checks, you can access member references corresponding to subtypes.

属性委托的更佳推断

The type of a delegated property wasn’t taken into account while analyzing the delegate expression which follows the by keyword. For instance, the following code didn’t compile before, but now the compiler correctly infers the types of the old and new parameters as String?:

1. import kotlin.properties.Delegates

3. fun main() {
4. var prop: String? by Delegates.observable(null) { p, old, new ->
5. println("$old → $new")
6. }
7. prop = "abc"
8. prop = "xyz"
9. }

具有不同参数的 Java 接口的 SAM 转换

Kotlin has supported SAM conversions for Java interfaces from the beginning, but there was one case that wasn’t supported, which was sometimes annoying when working with existing Java libraries. If you called a Java method that took two SAM interfaces as parameters, both arguments needed to be either lambdas or regular objects. You couldn’t pass one argument as a lambda and another as an object.

The new algorithm fixes this issue, and you can pass a lambda instead of a SAM interface in any case, which is the way you’d naturally expect it to work.

1. // FILE: A.java
2. public class A {
3. public static void foo(Runnable r1, Runnable r2) {}
4. }

1. // FILE: test.kt
2. fun test(r1: Runnable) {
3. A.foo(r1) {}  // Works in Kotlin 1.4
4. }

Kotlin 中的 Java SAM 接口

In Kotlin 1.4, you can use Kotlin 中的 Java SAM 接口 and apply SAM conversions to them.

1. import java.lang.Runnable

3. fun foo(r: Runnable) {}

5. fun test() {
6. foo { } // OK
7. }

In Kotlin 1.3, you would have had to declare the function foo above in Java code to perform a SAM conversion.

统一的后端与可扩展性

In Kotlin, we have three backends that generate executables: Kotlin/JVM, Kotlin/JS, and Kotlin/Native. Kotlin/JVM and Kotlin/JS don’t share much code since they were developed independently of each other. Kotlin/Native is based on a new infrastructure built around an intermediate representation (IR) for Kotlin code.

We are now migrating Kotlin/JVM and Kotlin/JS to the same IR. As a result, all three backends share a lot of logic and have a unified pipeline. This allows us to implement most features, optimizations, and bug fixes only once for all platforms. Both new IR-based back-ends are in Alpha.

A common backend infrastructure also opens the door for multiplatform compiler extensions. You will be able to plug into the pipeline and add custom processing and transformations that will automatically work for all platforms.

We encourage you to use our new JVM IR and JS IR backends, which are currently in Alpha, and share your feedback with us.

回到顶部

Kotlin/JVM

Kotlin 1.4.0 includes a number of JVM-specific improvements, such as:

新的 JVM IR 后端
在接口中生成默认方法的新模式
统一用于空检测的异常类型
在 JVM 字节码中的类型注解

新的 JVM IR 后端

Along with Kotlin/JS, we are migrating Kotlin/JVM to the unified IR backend, which allows us to implement most features and bug fixes once for all platforms. You will also be able to benefit from this by creating multiplatform extensions that will work for all platforms.

Kotlin 1.4.0 does not provide a public API for such extensions yet, but we are working closely with our partners, including Jetpack Compose, who are already building their compiler plugins using our new backend.

We encourage you to try out the new Kotlin/JVM backend, which is currently in Alpha, and to file any issues and feature requests to our issue tracker. This will help us to unify the compiler pipelines and bring compiler extensions like Jetpack Compose to the Kotlin community more quickly.

To enable the new JVM IR backend, specify an additional compiler option in your Gradle build script:

1. kotlinOptions.useIR = true

If you enable Jetpack Compose, you will automatically be opted in to the new JVM backend without needing to specify the compiler option in kotlinOptions.

When using the command-line compiler, add the compiler option -Xuse-ir.

You can use code compiled by the new JVM IR backend only if you’ve enabled the new backend. Otherwise, you will get an error. Considering this, we don’t recommend that library authors switch to the new backend in production.

生成默认方法的新模式

When compiling Kotlin code to targets JVM 1.8 and above, you could compile non-abstract methods of Kotlin interfaces into Java’s default methods. For this purpose, there was a mechanism that includes the @JvmDefault annotation for marking such methods and the -Xjvm-default compiler option that enables processing of this annotation.

In 1.4.0, we’ve added a new mode for generating default methods: -Xjvm-default=all compiles all non-abstract methods of Kotlin interfaces to default Java methods. For compatibility with the code that uses the interfaces compiled without default, we also added all-compatibility mode.

For more information about default methods in the Java interop, see the documentation and this blog post.

统一用于空检测的异常类型

Starting from Kotlin 1.4.0, all runtime null checks will throw a java.lang.NullPointerException instead of KotlinNullPointerException, IllegalStateException, IllegalArgumentException, and TypeCastException. This applies to: the !! operator, parameter null checks in the method preamble, platform-typed expression null checks, and the as operator with a non-null type. This doesn’t apply to lateinit null checks and explicit library function calls like checkNotNull or requireNotNull.

This change increases the number of possible null check optimizations that can be performed either by the Kotlin compiler or by various kinds of bytecode processing tools, such as the Android R8 optimizer.

Note that from a developer’s perspective, things won’t change that much: the Kotlin code will throw exceptions with the same error messages as before. The type of exception changes, but the information passed stays the same.

在 JVM 字节码中的类型注解

Kotlin can now generate type annotations in the JVM bytecode (target version 1.8+), so that they become available in Java reflection at runtime. To emit the type annotation in the bytecode, follow these steps:

Make sure that your declared annotation has a proper annotation target (Java’s ElementType.TYPE_USE or Kotlin’s AnnotationTarget.TYPE) and retention (AnnotationRetention.RUNTIME).
Compile the annotation class declaration to JVM bytecode target version 1.8+. You can specify it with -jvm-target=1.8 compiler option.
Compile the code that uses the annotation to JVM bytecode target version 1.8+ (-jvm-target=1.8) and add the -Xemit-jvm-type-annotations compiler option.

Note that the type annotations from the standard library aren’t emitted in the bytecode for now because the standard library is compiled with the target version 1.6.

So far, only the basic cases are supported:

Type annotations on method parameters, method return types and property types;
Invariant projections of type arguments, such as Smth<@Ann Foo>, Array<@Ann Foo>.

In the following example, the @Foo annotation on the String type can be emitted to the bytecode and then used by the library code:

1. @Target(AnnotationTarget.TYPE)
2. annotation class Foo

4. class A {
5. fun foo(): @Foo String = "OK"
6. }

回到顶部

Kotlin/JS

On the JS platform, Kotlin 1.4.0 provides the following improvements:

新的 Gradle DSL
新的 JS IR 后端

新的 Gradle DSL

The kotlin.js Gradle plugin comes with an adjusted Gradle DSL, which provides a number of new configuration options and is more closely aligned to the DSL used by the kotlin-multiplatform plugin. Some of the most impactful changes include:

Explicit toggles for the creation of executable files via binaries.executable(). Read more about the executing Kotlin/JS and its environment here.
Configuration of webpack’s CSS and style loaders from within the Gradle configuration via cssSupport. Read more about using them here.
Improved management for npm dependencies, with mandatory version numbers or semver version ranges, as well as support for development, peer, and optional npm dependencies using devNpm, optionalNpm and peerNpm. Read more about dependency management for npm packages directly from Gradle here.
Stronger integrations for Dukat, the generator for Kotlin external declarations. External declarations can now be generated at build time, or can be manually generated via a Gradle task. Read more about how to use the integration here.

新的 JS IR 后端

The IR backend for Kotlin/JS, which currently has Alpha stability, provides some new functionality specific to the Kotlin/JS target which is focused around the generated code size through dead code elimination, and improved interoperation with JavaScript and TypeScript, among others.

To enable the Kotlin/JS IR backend, set the key kotlin.js.compiler=ir in your gradle.properties, or pass the IR compiler type to the js function of your Gradle build script:

1. kotlin {
2. js(IR) { // or: LEGACY, BOTH
3. // . . .
4. }
5. binaries.executable()
6. }

For more detailed information about how to configure the Kotlin/JS IR compiler backend, check out the documentation.

With the new @JsExport annotation and the ability to generate TypeScript definitions from Kotlin code, the Kotlin/JS IR compiler backend improves JavaScript & TypeScript interoperability. This also makes it easier to integrate Kotlin/JS code with existing tooling, to create hybrid applications and leverage code-sharing functionality in multiplatform projects.

Learn more about the available features in the Kotlin/JS IR compiler backend in the documentation.

回到顶部

Kotlin/Native

In 1.4.0, Kotlin/Native got a significant number of new features and improvements, including:

在 Swift 与 Objective-C 中支持挂起函数
默认支持 Objective-C 泛型
Objective-C/Swift 互操作中的异常处理
默认在苹果目标平台生成 release 版 .dSYM
性能改进
简化了 CocoaPods 依赖项的管理

在 Swift 与 Objective-C 中支持 kotlin 的挂起函数

In 1.4.0, we add the basic support for suspending functions in Swift and Objective-C. Now, when you compile a Kotlin module into an Apple framework, suspending functions are available in it as functions with callbacks (completionHandler in the Swift/Objective-C terminology). When you have such functions in the generated framework’s header, you can call them from your Swift or Objective-C code and even override them.

For example, if you write this Kotlin function:

1. suspend fun queryData(id: Int): String = ...

…then you can call it from Swift like so:

1. queryData(id: 17) { result, error in
2. if let e = error {
3. print("ERROR: \(e)")
4. } else {
5. print(result!)
6. }
7. }

For more information about using suspending functions in Swift and Objective-C, see the documentation.

默认支持 Objective-C 泛型

Previous versions of Kotlin provided experimental support for generics in Objective-C interop. Since 1.4.0, Kotlin/Native generates Apple frameworks with generics from Kotlin code by default. In some cases, this may break existing Objective-C or Swift code calling Kotlin frameworks. To have the framework header written without generics, add the -Xno-objc-generics compiler option.

1. kotlin {
2. targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
3. binaries.all {
4. freeCompilerArgs += "-Xno-objc-generics"
5. }
6. }
7. }

Please note that all specifics and limitations listed in the documentation are still valid.

Objective-C/Swift 互操作中的异常处理

In 1.4.0, we slightly change the Swift API generated from Kotlin with respect to the way exceptions are translated. There is a fundamental difference in error handling between Kotlin and Swift. All Kotlin exceptions are unchecked, while Swift has only checked errors. Thus, to make Swift code aware of expected exceptions, Kotlin functions should be marked with a @Throws annotation specifying a list of potential exception classes.

When compiling to Swift or the Objective-C framework, functions that have or are inheriting @Throws annotation are represented as NSError*-producing methods in Objective-C and as throws methods in Swift.

Previously, any exceptions other than RuntimeException and Error were propagated as NSError. Now this behavior changes: now NSError is thrown only for exceptions that are instances of classes specified as parameters of @Throws annotation (or their subclasses). Other Kotlin exceptions that reach Swift/Objective-C are considered unhandled and cause program termination.

默认在苹果目标平台生成 release 版 `.dSYM`

Starting with 1.4.0, the Kotlin/Native compiler produces debug symbol files (.dSYMs) for release binaries on Darwin platforms by default. This can be disabled with the -Xadd-light-debug=disable compiler option. On other platforms, this option is disabled by default. To toggle this option in Gradle, use:

1. kotlin {
2. targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
3. binaries.all {
4. freeCompilerArgs += "-Xadd-light-debug={enable|disable}"
5. }
6. }
7. }

For more information about crash report symbolication, see the documentation.

性能改进

Kotlin/Native has received a number of performance improvements that speed up both the development process and execution. Here are some examples:

To improve the speed of object allocation, we now offer the mimalloc memory allocator as an alternative to the system allocator. mimalloc works up to two times faster on some benchmarks. Currently, the usage of mimalloc in Kotlin/Native is experimental; you can switch to it using the -Xallocator=mimalloc compiler option.
We’ve reworked how C interop libraries are built. With the new tooling, Kotlin/Native produces interop libraries up to 4 times as fast as before, and artifacts are 25% to 30% the size they used to be.
Overall runtime performance has improved because of optimizations in GC. This improvement will be especially apparent in projects with a large number of long-lived objects. HashMap and HashSet collections now work faster by escaping redundant boxing.
In 1.3.70 we introduced two new features for improving the performance of Kotlin/Native compilation: caching project dependencies and running the compiler from the Gradle daemon. Since that time, we’ve managed to fix numerous issues and improve the overall stability of these features.

简化了 CocoaPods 依赖项的管理

Previously, once you integrated your project with the dependency manager CocoaPods, you could build an iOS, macOS, watchOS, or tvOS part of your project only in Xcode, separate from other parts of your multiplatform project. These other parts could be built in Intellij IDEA.

Moreover, every time you added a dependency on an Objective-C library stored in CocoaPods (Pod library), you had to switch from IntelliJ IDEA to Xcode, call pod install, and run the Xcode build there.

Now you can manage Pod dependencies right in Intellij IDEA while enjoying the benefits it provides for working with code, such as code highlighting and completion. You can also build the whole Kotlin project with Gradle, without having to switch to Xcode. This means you only have to go to Xcode when you need to write Swift/Objective-C code or run your application on a simulator or device.

Now you can also work with Pod libraries stored locally.

Depending on your needs, you can add dependencies between:

A Kotlin project and Pod libraries stored remotely in the CocoaPods repository or stored locally on your machine.
A Kotlin Pod (Kotlin project used as a CocoaPods dependency) and an Xcode project with one or more targets.

Complete the initial configuration, and when you add a new dependency to cocoapods, just re-import the project in IntelliJ IDEA. The new dependency will be added automatically. No additional steps are required.

Learn how to add dependencies.

回到顶部

Kotlin 多平台

多平台项目处于 Alpha 版。语言特性与工具都可能在未来的 Kotlin 版本中发生变化。

Kotlin 多平台 reduces time spent writing and maintaining the same code for different platforms while retaining the flexibility and benefits of native programming. We continue investing our effort in multiplatform features and improvements:

使用分层项目结构在多个目标中共享代码
在分层结构中利用原生库
只需指定一次 kotlinx 依赖项

Multiplatform projects require Gradle 6.0 or later.

使用分层项目结构在多个目标中共享代码

With the new hierarchical project structure support, you can share code among several platforms in a multiplatform project.

Previously, any code added to a multiplatform project could be placed either in a platform-specific source set, which is limited to one target and can’t be reused by any other platform, or in a common source set, like commonMain or commonTest, which is shared across all the platforms in the project. In the common source set, you could only call a platform-specific API by using an expect declaration that needs platform-specific actual implementations.

This made it easy to share code on all platforms, but it was not so easy to share between only some of the targets, especially similar ones that could potentially reuse a lot of the common logic and third-party APIs.

For example, in a typical multiplatform project targeting iOS, there are two iOS-related targets: one for iOS ARM64 devices, and the other for the x64 simulator. They have separate platform-specific source sets, but in practice, there is rarely a need for different code for the device and simulator, and their dependencies are much alike. So iOS-specific code could be shared between them.

Apparently, in this setup, it would be desirable to have a shared source set for two iOS targets, with Kotlin/Native code that could still directly call any of the APIs that are common to both the iOS device and the simulator.

Now you can do this with the hierarchical project structure support, which infers and adapts the API and language features available in each source set based on which targets consume them.

For common combinations of targets, you can create a hierarchical structure with target shortcuts.

For example, create two iOS targets and the shared source set shown above with the ios() shortcut:

1. kotlin {
2. ios() // iOS device and simulator targets; iosMain and iosTest source sets
3. }

For other combinations of targets, create a hierarchy manually by connecting the source sets with the dependsOn relation.

1. kotlin {
2. sourceSets {
3. desktopMain {
4. dependsOn(commonMain)
5. }
6. linuxX64Main {
7. dependsOn(desktopMain)
8. }
9. mingwX64Main {
10. dependsOn(desktopMain)
11. }
12. macosX64Main {
13. dependsOn(desktopMain)
14. }
15. }
16. }

1. kotlin{
2. sourceSets {
3. val desktopMain by creating {
4. dependsOn(commonMain)
5. }
6. val linuxX64Main by getting {
7. dependsOn(desktopMain)
8. }
9. val mingwX64Main by getting {
10. dependsOn(desktopMain)
11. }
12. val macosX64Main by getting {
13. dependsOn(desktopMain)
14. }
15. }
16. }

Thanks to the hierarchical project structure, libraries can also provide common APIs for a subset of targets. Learn more about sharing code in libraries.

在分层结构中利用原生库

You can use platform-dependent libraries, such as Foundation, UIKit, and posix, in source sets shared among several native targets. This can help you share more native code without being limited by platform-specific dependencies.

No additional steps are required – everything is done automatically. IntelliJ IDEA will help you detect common declarations that you can use in the shared code.

Learn more about usage of platform-dependent libraries.

只需指定一次依赖项

From now on, instead of specifying dependencies on different variants of the same library in shared and platform-specific source sets where it is used, you should specify a dependency only once in the shared source set.

1. kotlin {
2. sourceSets {
3. commonMain {
4. dependencies {
5. implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2'
6. }
7. }
8. }
9. }

1. kotlin {
2. sourceSets {
3. val commonMain by getting {
4. dependencies {
5. implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2")
6. }
7. }
8. }
9. }

Don’t use kotlinx library artifact names with suffixes specifying the platform, such as -common, -native, or similar, as they are NOT supported anymore. Instead, use the library base artifact name, which in the example above is kotlinx-coroutines-core.

However, the change doesn’t currently affect:

The stdlib library – starting from Kotlin 1.4.0, the stdlib dependency is added automatically.
The kotlin.test library – you should still use test-common and test-annotations-common. These dependencies will be addressed later.

If you need a dependency only for a specific platform, you can still use platform-specific variants of standard and kotlinx libraries with such suffixes as -jvm or -js, for example kotlinx-coroutines-core-jvm.

Learn more about configuring dependencies.

回到顶部

Gradle 项目改进

Besides Gradle project features and improvements that are specific to Kotlin 多平台, Kotlin/JVM, Kotlin/Native, and Kotlin/JS, there are several changes applicable to all Kotlin Gradle projects:

现在默认添加了对标准库的依赖
Kotlin 项目需要最近版本的 Gradle
改进了 IDE 对 Kotlin Gradle DSL 的支持

默认添加了对标准库的依赖

You no longer need to declare a dependency on the stdlib library in any Kotlin Gradle project, including a multiplatform one. The dependency is added by default.

The automatically added standard library will be the same version of the Kotlin Gradle plugin, since they have the same versioning.

For platform-specific source sets, the corresponding platform-specific variant of the library is used, while a common standard library is added to the rest. The Kotlin Gradle plugin will select the appropriate JVM standard library depending on the kotlinOptions.jvmTarget compiler option of your Gradle build script.

Learn how to change the default behavior.

Kotlin 项目的最低 Gradle 版本

To enjoy the new features in your Kotlin projects, update Gradle to the latest version. Multiplatform projects require Gradle 6.0 or later, while other Kotlin projects work with Gradle 5.4 or later.

改进了 IDE 对 *.gradle.kts 的支持

In 1.4.0, we continued improving the IDE support for Gradle Kotlin DSL scripts (*.gradle.kts files). Here is what the new version brings:

Explicit loading of script configurations for better performance. Previously, the changes you make to the build script were loaded automatically in the background. To improve the performance, we’ve disabled the automatic loading of build script configuration in 1.4.0. Now the IDE loads the changes only when you explicitly apply them.

In Gradle versions earlier than 6.0, you need to manually load the script configuration by clicking Load Configuration in the editor.

In Gradle 6.0 and above, you can explicitly apply changes by clicking Load Gradle Changes or by reimporting the Gradle project.

We’ve added one more action in IntelliJ IDEA 2020.1 with Gradle 6.0 and above – Load Script Configurations, which loads changes to the script configurations without updating the whole project. This takes much less time than reimporting the whole project.

![*.gradle.kts – Load Script Changes and Load Gradle Changes](https://static.bookstack.cn/projects/kotlin-guide-1.4.20-zh/

（本文超出站点单文档体积上限，已截断）

Kotlin 1.4

Kotlin 1.4.0 的新特性

语言特性与改进

Kotlin 接口的 SAM 转换

面向库作者的显式 API 模式

混用具名与位置参数

拖尾的逗号

可调用引用改进

对具有默认参数值的函数的引用

可作为返回 Unit的函数的函数引用

根据函数的参数数量进行调整的引用

可调用引用的挂起转换

在循环中的 when 内部使用 break 与 continue

IDE 中的新工具

新的灵活项目向导

协程调试器

新编译器

新的更强大的类型推断算法

会自动推断类型的更多情况

lambda 表达式最后一个表达式的智能转换

可调用引用的智能转换

属性委托的更佳推断

具有不同参数的 Java 接口的 SAM 转换

Kotlin 中的 Java SAM 接口

统一的后端与可扩展性

Kotlin/JVM

新的 JVM IR 后端

生成默认方法的新模式

统一用于空检测的异常类型

在 JVM 字节码中的类型注解

Kotlin/JS

新的 Gradle DSL

新的 JS IR 后端

Kotlin/Native

在 Swift 与 Objective-C 中支持 kotlin 的挂起函数

默认支持 Objective-C 泛型

Objective-C/Swift 互操作中的异常处理

默认在苹果目标平台生成 release 版 .dSYM

性能改进

简化了 CocoaPods 依赖项的管理

Kotlin 多平台

使用分层项目结构在多个目标中共享代码

在分层结构中利用原生库

只需指定一次依赖项

Gradle 项目改进

默认添加了对标准库的依赖

Kotlin 项目的最低 Gradle 版本

改进了 IDE 对 *.gradle.kts 的支持

可作为返回 `Unit`的函数的函数引用

在循环中的 `when` 内部使用 `break` 与 `continue`

默认在苹果目标平台生成 release 版 `.dSYM`