Kotlin
A concise multiplatform language developed by JetBrains
Kotlin 1.4.20이 출시되었습니다
Kotlin 1.4.20이 새로운 실험적 기능과 함께 출시되었습니다. 커뮤니티 의견에 대해 열린 태도는 Kotlin 팀의 기본 원칙 중 하나로서, 저희에게는 새로운 기능의 프로토타입에 대한 여러분의 생각이 필요합니다. 직접 체험해 보고 Slack(여기 또는 YouTrack에서 초대 받기)에서 의견을 공유해 주세요.
주요 개선 사항은 다음과 같습니다.
- invokedynamic을 통한 문자열 연결 등의 새로운 JVM 기능 지원
- KMM 프로젝트의 향상된 성능 및 예외 처리
- JDK 경로:
Path(“dir”) / “file.txt”의 확장 기능
이 외에도 1.4.0에 추가된 기능을 포함하여 기존 기능에 대한 수많은 수정 및 개선 사항을 제공합니다. 따라서 이러한 기능 중에서 문제를 겪으신 적이 있다면 다시 한 번 사용해 보세요.
Kotlin 1.4.20의 기능을 자세히 알아보려면 계속 읽어보세요. Kotlin 문서 내 Kotlin 1.4.20의 새로운 기능 페이지에서 릴리스에 관한 간략한 개요를 확인할 수도 있습니다. 전체 변경 목록은 변경 로그에서 확인할 수 있습니다.
언제나 그렇듯이 이번 릴리스에 도움을 주신 외부 기여자들께 감사의 말씀을 전합니다.
그러면 지금부터 세부 사항에 대해 알아보겠습니다!
Kotlin/JVM
JVM에서는 새로운 JVM 15 대상을 추가했으며 주로 기존 기능과 성능을 개선하고 버그를 수정하는 데 중점을 두었습니다.
invokedynamic 문자열 연결
Java 9 이후 JVM에서 문자열 연결은 동적 메소드 호출(바이트코드의 invokedynamic 명령어)을 통해 수행됩니다. 이러한 방식은 이전 구현보다 더 빠르게 작동하고 메모리를 덜 소비하며, 바이트코드 변경 없이 향후 최적화를 위한 공간을 남겨 둡니다.
Kotlin에서도 성능 개선을 위해 이 메커니즘을 구현하기 시작하여, 이제 JVM 9 이상의 대상에서 문자열 연결을 동적 호출로 컴파일할 수 있게 되었습니다.
현재 이 기능은 실험적이며 다음의 경우에 적용됩니다.
- 연산자(
a + b), 명시적(a.plus(b)), 참조((a::plus)(b)) 형식의String.plus - 인라인 및 데이터 클래스의
toString - 상수가 아닌 단일 인수가 있는 경우를 제외한 문자열 템플릿(KT-42457 참조)
invokedynamic 문자열 연결을 사용하려면 다음 값 중 하나와 함께 -Xstring-concat 컴파일러 옵션을 추가하세요.
- StringConcatFactory.makeConcatWithConstants()를 사용하여 문자열에 대해
invokedynamic연결을 수행하는indy-with-constants(1.5에서 JVM 9 이상의 대상에서 디폴트 값이 될 예정) - StringConcatFactory.makeConcat()을 사용하여 문자열에 대해
invokedynamic연결을 수행하는indy StringBuilder.append()를 통해 클래식 연결로 다시 전환하는inline
Kotlin/JS
Kotlin/JS는 계속해서 빠른 속도로 발전하고 있으며, 이번 릴리스에서는 새로운 프로젝트 마법사용 템플릿, 효과적인 프로젝트 구성 제어를 위한 향상된 DSL 등 다양한 개선 사항을 제공합니다. 또한 새로운 IR 컴파일러에는 오류가 있는 프로젝트를 컴파일하는 완전히 새로운 방법이 탑재되어 있습니다.
Gradle DSL 변경 내용
Kotlin/JS Gradle DSL에는 webpack 구성 조정, 자동 생성된 package.json 파일 수정, 이행 종속 요소에 대한 향상된 제어를 포함해 프로젝트 설정 및 사용자 지정을 단순화하는 여러 업데이트가 적용되었습니다.
webpack 구성을 위한 단일 지점
Kotlin 1.4.20에는 commonWebpackConfig라는 브라우저 대상에 대한 새로운 구성 블록이 도입되었습니다. webpackTask, runTask, testTask에 대한 구성을 복제하는 대신, 이 구성 블록 내의 단일 지점에서 공통 설정을 조정할 수 있습니다.
세 가지 작업 모두에 대해 기본적으로 CSS 지원을 활성화하려면 프로젝트의 build.gradle(.kts)에 다음 스니펫을 포함하기만 하면 됩니다.
Gradle에서 package.json 사용자 지정
package.json 파일은 일반적으로 JavaScript 프로젝트의 작동 방식을 정의하여, 실행 가능한 스크립트, 종속 요소 등을 식별합니다. 이 파일은 빌드가 진행되는 동안 Kotlin/JS 프로젝트용으로 자동 생성됩니다. 그러나 package.json의 내용은 상황별로 다양하기 때문에 이 파일을 쉽게 맞춤 설정할 수있는 방법을 만들어 달라는 요청이 많았습니다.
Kotlin 1.4.20부터는 Gradle 빌드 스크립트에서 package.json 프로젝트 파일에 항목을 추가할 수 있습니다. package.json에 사용자 지정 필드를 추가하려면 컴파일 packageJson 블록에서 customField 함수를 사용하세요.
그러면 프로젝트를 빌드할 때 구성 파일 build/js/packages/projectName/package.json에 다음 블록이 추가됩니다.
"hello": {
"one": 1,
"two": 2
}
구성에 스크립트 필드를 추가해 명령줄에서 프로젝트를 쉽게 실행하려는 경우든, 다른 후처리 도구에 대한 정보를 포함하려는 경우든, 사용자 지정 필드를 지정하는 이 새로운 방법이 유용하기를 바랍니다.
선택적 yarn 종속 요소 해결(실험적)
npm의 종속 요소를 포함할 때 종속 요소(이행 종속 요소)를 정밀하게 제어하고 싶은 경우가 있습니다. 이러한 경우에는 다양한 이유가 있을 수 있습니다. 사용 중인 라이브러리의 종속 요소 중 하나에 중요한 업그레이드를 적용하고 싶을 수도 있고, 현재 애플리케이션을 중단하는 이행 종속 요소의 업데이트를 롤백하고 싶을 수도 있을 것입니다. Yarn의 선택적 종속 요소 해결을 통해 원본 작성자가 지정한 종속 요소를 재정의할 수 있으므로 개발을 이어갈 수 있습니다.
Kotlin 1.4.20에서는 프로젝트의 Gradle 빌드 스크립트에서 이 기능을 구성할 수 있는 예비적(실험적) 방법을 제공합니다. 나머지 Kotlin/JS 옵션과의 원활한 API 통합은 여전히 작업 중이지만 YarnPlugin에 있는 YarnRootExtension을 통해 이미 기능을 사용할 수 있습니다. 프로젝트에서 해결된 패키지 버전에 영향을 미치려면 resolution(해결) 기능을 사용하세요. 인수에서 패키지 이름 선택자(Yarn에 지정된 대로)와 원하는 버전을 지정하세요.
build.gradle.kts 파일의 선택적 종속 요소 해결을 위한 예시 구성은 다음과 같습니다.
여기에서 react가 필요한 모든 npm 종속 요소는 버전 16.0.0을 수신하고, 프로세서는 버전 3.0.0으로 decamelize 종속 요소를 수신합니다. 또한 include 및 exclude 호출을 resolution 블록에 전달할 수도 있으므로 허용 가능한 버전에 대한 제약 조건을 지정할 수 있습니다.
세분화된 작업 공간 비활성화(실험적)
빌드 시간을 단축하기 위해 Kotlin/JS Gradle 플러그인은 특정 Gradle 작업에 필요한 종속 요소만 설치합니다. 예를 들어, webpack-dev-server 패키지는 *Run 작업 중 하나를 실행할 때만 설치되며 assemble 작업을 실행할 때는 설치되지 않습니다. 이렇게 되면 불필요한 다운로드는 피할 수 있지만 여러 Gradle 프로세스를 병렬로 실행할 경우 문제가 발생할 수 있습니다. 예를 들어 종속 요소 요구사항이 충돌했을 때 두 가지 npm 패키지 설치가 실행되면 오류가 발생할 수 있습니다.
이 문제를 해결하기 위해 Kotlin 1.4.20에는 이러한 _세분화된 작업 공간_을 비활성화하는 새로운(실험적) 옵션이 포함됩니다. 선택적 종속 요소 해결에 대한 실험적 지원과 마찬가지로, 이 기능은 현재 YarnRootExtension을 통해 액세스할 수 있지만 향후 나머지 Kotlin/JS Gradle DSL과 더 긴밀하게 통합될 것입니다. 이 기능을 사용하려면 build.gradle.kts 파일에 다음 스니펫을 추가하세요.
이 구성을 사용하면 Kotlin/JS Gradle 플러그인은 현재 실행되지 않는 작업에 사용되는 종속 요소를 포함하여 프로젝트에서 사용될 수 있는 모든 npm 종속 요소를 설치합니다. 즉, 첫 Gradle 빌드는 조금 오래 걸릴 수 있지만 다운로드한 종속 요소는 실행하는 모든 작업에 대해 최신 상태가 됩니다. 이렇게 하면 여러 Gradle 프로세스를 병렬로 실행해도 충돌을 피할 수 있습니다.
새로운 마법사 템플릿
프로젝트 생성 시 더 편리하게 프로젝트를 사용자 지정할 수 있도록 Kotlin용 프로젝트 마법사에 조정 가능한 Kotlin/JS 애플리케이션용 템플릿이 새로 추가되었습니다. 브라우저 및 Node.js 런타임 환경 모두에서 사용할 수 있는 템플릿이 마련되어 있습니다. 이러한 템플릿은 프로젝트의 좋은 시작점으로 삼을 수 있고 초기 구성을 세세하게 조정할 수 있습니다. 여기에는 새 IR 컴파일러 활성화 설정 또는 추가 라이브러리 지원 설정 등이 포함됩니다.
Kotlin 1.4.20에서는 다음 세 가지 템플릿을 사용할 수 있습니다.
- Browser Application을 사용하면 브라우저에서 실행되는 베어본 Kotlin/JS Gradle 프로젝트를 설정할 수 있습니다.
- React Application에는 적절한 kotlin-wrappers를 사용하여 React 앱을 빌드하는 데 필요한 모든 것이 포함되어 있습니다. 이 템플릿은 스타일시트, 탐색 구성 요소, 상태 컨테이너를 위한 통합 기능을 활성화하는 옵션을 제공합니다.
- Node.js Application은 프로젝트가 Node.js 런타임에서 실행되도록 프로젝트를 사전 구성합니다. 이 템플릿에는 이전 게시물에서 소개한 실험적 kotlinx-nodejs 패키지를 직접 포함할 수 있는 옵션이 함께 제공됩니다.
컴파일 오류 무시(실험적)
또한 Kotlin 1.4.20에서는 Kotlin/JS IR 컴파일러에서 사용할 수 있는 새로운 컴파일 오류 무시 기능을 선보입니다. 이 기능을 사용하면 애플리케이션이 일반적으로 컴파일러에서 컴파일되지 않는 상태에 있어도 애플리케이션을 사용해 볼 수 있습니다. 예를 들어 복잡한 리팩토링을 수행하거나 컴파일 오류와 전혀 관련이 없는 시스템 부분에서 작업하는 경우에 이용할 수 있습니다. 이 새로운 컴파일러 모드를 사용하면 컴파일러는 잘못된 코드를 무시하고 컴파일을 거부하는 대신 런타임 예외로 대체합니다.
Kotlin 1.4.20에는 코드 내 컴파일 오류를 무시하기 위한 두 가지 허용 정책이 다음과 같이 있습니다.
SEMANTIC모드에서 컴파일러는 구문은 정확하지만 의미 면에서 맞지 않은 코드를 허용합니다. 그 예로는 유형 불일치가 있는 구문(예:val x: String = 3)을 들 수 있습니다.SYNTAX모드에서 컴파일러는 코드에 구문 오류가 있는 경우에도 모든 코드를 허용합니다. 작성된 코드가 무엇이든 컴파일러는 실행 가능한 실행 파일을 생성하려고 시도합니다.
컴파일 오류 무시는 실험적 기능이므로 사용하려면 컴파일러 옵션에서 선택해야 합니다. 이 기능은 Kotlin/JS IR 컴파일러에서만 사용할 수 있습니다. 기능을 활성화하려면 build.gradle.kts 파일에 다음 스니펫을 추가하세요.
오류가 있는 상태에서 컴파일할 수 있는 기능이 Kotlin/JS 프로젝트 작업 시 피드백 루프를 강화하고 반복 작업의 속도를 높이는 데 도움이 되기를 바랍니다. 이 기능을 사용하면서 의견이 있거나 문제를 발견한 경우 YouTrack에 해당 내용을 남겨주시기를 기다리겠습니다.
이 기능의 구현은 계속 개선 중이므로 추후 Kotlin/JS Gradle DSL 및 해당 작업과의 더 긴밀한 통합도 제공될 예정입니다.
Kotlin/Native
성능은 1.4.20에서 Kotlin/Native의 주요 우선순위 중 하나입니다. 이 부분에서 핵심 기능은 향후 릴리스에서 개선할 예정인 새로운 이스케이프 분석 메커니즘의 프로토타입입니다. 물론 빨라진 범위 확인(in) 등의 소소한 성능 향상도 있습니다.
1.4.20에서 Kotlin/Native 개발에 적용된 개선 사항의 또 다른 측면은 개선 및 버그 수정입니다. 새로운 1.4 기능(예: 코드 공유 메커니즘)에서 발견된 문제뿐만 아니라 이전 문제 중에서도 다수를 해결했습니다. 한 가지 개선 사항은 함수 참조에서의 equals 및 hashCode 작동 방식이나 프로퍼티 초기화 같은 코너 케이스에서 Kotlin/Native와 Kotlin/JVM 간의 동작 불일치를 수정한 것입니다.
마지막으로, Objective-C 예외를 Kotlin 예외로 래핑하는 옵션으로 Objective-C 상호운용 기능을 확장하여 해당 예외가 Kotlin 코드에서 처리되도록 했습니다.
이스케이프 분석
_이스케이프 분석_은 객체를 스택에 할당할 수 있는지 아니면 힙으로 "이스케이프"해야 하는지 여부를 컴파일러에서 결정할 때 사용하는 기술입니다. 스택에서의 할당은 속도가 훨씬 빠르며 향후 가비지 수집이 필요하지 않습니다.
Kotlin/Native에는 이미 지역 이스케이프 분석이 있지만 이제 더 효율적인 새로운 전역 이스케이프 분석을 프로토타입으로 구현하여 도입하려 합니다. 이 분석은 릴리스 빌드에 대한 별도의 컴파일 단계에서 수행됩니다(-opt 컴파일러 옵션 사용).
이 프로토타입은 이미 벤치마크에서 평균 10%의 성능 향상 등 몇가지 기대되는 결과를 거두었습니다. 현재는 알고리즘을 최적화하여 스택 할당용 객체를 더 많이 찾고 프로그램 속도를 더 높일 수 있는 방법을 연구하고 있습니다.
저희가 프로토타입 작업을 계속하는 동안 사용자 여러분이 이 기능을 사용해보고 실제 프로젝트에서 얻은 결과를 공유해 주시면 큰 도움이 될 것입니다.
이스케이프 분석 단계를 사용하지 않으려면 -Xdisable-phases=EscapeAnalysis 컴파일러 옵션을 사용하세요.
Objective-C 예외 래핑 옵션
Objective-C에서 예외의 목적은 Kotlin에서의 예외의 목적과 매우 다릅니다. Objective-C의 예외는 일반적으로 개발 중 오류를 찾는 데 사용이 한정됩니다. 그러나 기술적으로 Objective-C 라이브러리는 런타임 시 예외를 던질 수 있습니다. 이전에는 Kotlin/Native에서 이러한 예외를 처리할 수 있는 옵션이 없었기 때문에 라이브러리에서 던져진 NSException이 발생하면 전체 Kotlin/Native 프로그램이 종료되었습니다.
1.4.20에서는 프로그램 충돌을 방지하기 위해 런타임에서 이러한 예외를 처리하는 옵션을 추가했습니다. NSException을 Kotlin의 ForeignException으로 래핑하도록 선택하면 Kotlin 코드에서 추가 처리를 수행할 수 있습니다. 이러한 ForeignException은 원본 NSException에 대한 참조를 보유하고 있으므로 근본 원인에 대한 정보를 얻을 수 있습니다.
Objective-C 예외 래핑을 활성화하려면 cinterop 호출에서 -Xforeign-exception-mode objc-wrap 옵션을 지정하거나 foreignExceptionMode = objc-wrap 프로퍼티를 .def 파일에 추가하세요. CocoaPods 통합 기능을 사용하는 경우, 다음과 같이 종속 요소의 pod {} 빌드 스크립트 블록에서 옵션을 지정하세요.
디폴트 동작은 변경되지 않습니다. Objective-C 코드에서 예외가 던져지면 프로그램이 종료됩니다.
CocoaPods 플러그인 개선 사항
향상된 작업 실행
이번 릴리스에서는 작업 실행 흐름이 크게 개선되었습니다. 예를 들어 새로운 CocoaPods 종속 요소가 추가되어도 기존 종속 요소가 다시 빌드되지 않습니다. 대상을 추가해도 기존 대상에 대한 종속 요소는 다시 빌드되지 않습니다.
확장된 DSL
1.4.20에서는 Kotlin 프로젝트에 CocoaPods 종속 요소를 추가할 수 있도록 DSL을 확장했습니다.
CocoaPods 저장소의 로컬 Pods 및 Pods 외에도 다음 유형의 라이브러리의 종속 요소를 추가할 수 있습니다.
- 사용자 지정 사양 저장소의 라이브러리
- Git 저장소의 원격 라이브러리
- 아카이브의 라이브러리(임의의 HTTP 주소로도 사용 가능)
- 정적 라이브러리
- 사용자 지정 cinterop 옵션이 있는 라이브러리
이전 DSL 구문은 계속 지원됩니다.
다음 예시에서 DSL의 변경 내용을 몇가지 살펴보겠습니다.
-
Git 저장소의 원격 라이브러리에 있는 종속 요소.
해당하는 키워드를 사용하여 태그, 커밋 또는 브랜치를 지정할 수 있습니다. 예:또한 이러한 키워드를 결합하여 필요한 버전의 Pod를 가져올 수도 있습니다.
-
사용자 지정 사양 저장소의 라이브러리에 있는 종속 요소.
다음과 같이 특수specRepos매개변수를 사용하세요.
더 많은 예시는 Kotlin 및 CocoaPods 샘플에서 찾을 수 있습니다.
업데이트된 Xcode 통합 기능
Kotlin이 Xcode에서 올바르게 작동하려면 Podfile을 몇가지 변경해야 합니다.
-
Kotlin Pod에 Git, HTTP 또는 specRepo pod 종속 요소가 있는 경우 Podfile에서도 해당 요소를 지정해야 합니다. 예를 들어 CocoaPods 저장소의
AFNetworking에 있는 종속 요소를 추가하는 경우 Podfile에서도 다음과 같이 선언하세요.pod 'AFNetworking'
-
사용자 지정 사양의 라이브러리를 추가할 경우에는 Podfile의 시작 부분에 사양 위치도 지정해야 합니다.
source 'https://github.com/Kotlin/kotlin-cocoapods-spec.git' target 'kotlin-cocoapods-xcproj' do // ... other Pods ... pod 'example' end
통합 오류는 이제 IntelliJ IDEA에 자세한 설명이 있으므로 Podfile에 문제가 발생한 경우 수정 방법에 대한 정보를 바로 얻을 수 있습니다.
Kotlin 및 CocoaPods 샘플의 withXcproject 브랜치를 확인해 보세요. 여기에는 kotlin-cocoapods-xcproj라는 기존 Xcode 프로젝트와의 Xcode 통합 예시가 포함되어 있습니다.
Xcode 12 라이브러리 지원
Xcode 12와 함께 제공되는 새로운 라이브러리에 대한 지원을 추가했습니다. 이 라이브러리를 Kotlin 코드에서 마음껏 사용하세요!
멀티플랫폼 라이브러리 게시의 구조 업데이트
Kotlin 1.4.20 이전에는 멀티플랫폼 라이브러리 게시에 플랫폼별 게시와 메타데이터 게시가 포함되었습니다. 그러나 메타데이터 게시에만 의존할 필요가 없었으므로 이 아티팩트는 명시적으로 사용되지 않았습니다.
Kotlin 1.4.20부터는 더 이상 별도의 메타데이터 게시가 없습니다. 이제 메타데이터 아티팩트가 전체 라이브러리를 나타내는 루트 게시에 포함되며, 공통 소스 세트에 종속 요소로서 추가될 때 자동으로 알맞은 플랫폼용 아티팩트로 확인됩니다.
단, Maven Central과 같은 저장소의 요구사항을 충족하려면 분류자 없는 빈 아티팩트를 라이브러리의 루트 모듈에 추가해서는 안 됩니다. 그렇게 하면 현재 이 모듈에 포함된 메타데이터 아티팩트와 충돌할 수 있습니다.
1.4.20으로 게시된 라이브러리와의 호환성
계층적 프로젝트 구조 지원을 활성화한 후 Kotlin 1.4.20 이상에서 이러한 지원과 함께 게시된 멀티플랫폼 라이브러리를 사용하려면, 프로젝트의 Kotlin도 버전 1.4.20 이상으로 업그레이드해야 합니다.
라이브러리 작성자이고 계층적 프로젝트 구조 지원이 포함된 Kotlin 1.4.20 이상에서 멀티플랫폼 라이브러리를 게시하는 경우, 계층적 프로젝트 구조 지원을 활성화한 이전 Kotlin 버전 사용자는 라이브러리를 이용할 수 없다는 점에 유의하세요. 이러한 경우 Kotlin을 1.4.20 이상으로 업그레이드해야 합니다.
그러나 그러한 사용자 또는 그러한 사용자의 라이브러리 사용자가 계층적 프로젝트 구조 지원을 활성화하지 않은 경우, 이전 Kotlin 버전을 사용해도 라이브러리를 계속 이용할 수 있습니다.
멀티플랫폼 라이브러리 게시에 관해 자세히 알아보세요.
표준 라이브러리 변경 내용
java.nio.file.Path용 확장 기능
1.4.20부터 표준 라이브러리는 java.nio.file.Path에 대한 실험적 확장 기능을 제공합니다.
관용적 Kotlin 방식으로 최신 JVM 파일 API로 작업하는 것은 이제 kotlin.io 패키지의 java.io.File 확장 기능으로 작업하는 것과 유사해졌습니다. 대부분의 Files의 정적 메소드가 Path 유형의 확장 기능으로 제공되므로 더 이상 해당 메소드를 호출할 필요가 없습니다.
이러한 확장 기능은 kotlin.io.path 패키지에 있습니다. Path 자체는 JDK 7 이상에서 제공되므로 이 확장 기능은 kotlin-stdlib-jdk7 모듈에 배치되어 있습니다. 사용하려면 실험적 어노테이션인 ExperimentalPathApi를 선택해야 합니다.
이러한 확장 기능이 포함된 초기 PR을 제출해주신 기여자 AJ Alt 님께 특별히 감사의 말씀을 전합니다.
String.replace 함수의 성능 향상
Kotlin 커뮤니티에서 개선 사항이 제안될 때마다 저희는 항상 기쁩니다. 다음도 그러한 사례 중 하나입니다. 이번 릴리스에서는 String.replace() 함수의 구현을 변경했습니다.
대소문자를 구분하는 변형은 indexOf를 기반으로 하는 수동 교체 루프를 사용하는 반면, 대소문자를 구분하지 않는 변형은 정규식 일치를 사용합니다.
이 개선 사항은 특정 경우에 함수의 실행 속도를 높여줍니다.
Kotlin Android Extensions 지원 중단
Kotlin Android Extensions는 제작된 이래, Android 에코시스템에서 Kotlin의 인기를 높이는 데 큰 역할을 했습니다. 이러한 확장 기능을 통해 저희는 다음과 같이 상용구 코드를 줄일 수 있는 편리하고 효율적인 도구를 개발자에게 제공했습니다.
- UI 상호작용을 위한 통합 뷰(
kotlinx.android.synthetics) - 객체를
Parcel객체로서 전달하기 위한Parcelable구현 생성기(@Parcelize)
처음에 저희는 kotlin-android-extensions에 더 많은 구성 요소를 추가하려고 생각했습니다. 그러나 이 작업은 진행되지 않았고, 심지어 이 플러그인을 독립된 부분으로 분할해 달라는 사용자 요청도 있었습니다.
Android 에코시스템은 항상 발전하고 있으며 개발자는 작업을 더 편하게 도와주는 새로운 도구를 얻고 있습니다. Kotlin Android Extensions가 메우던 몇가지 격차는 이제 Google의 기본 메커니즘으로 해결되었습니다. 예를 들어 UI 상호작용을 위한 간결한 구문의 경우, 이제 Kotlin synthetics처럼 findViewById를 대체하는 뷰 바인딩이 있는 Android Jetpack이 생겼습니다.
이러한 두 가지 요인을 고려하여 뷰 바인딩을 위한 synthetics를 폐기하고 Parcelable 구현 생성기를 별도의 플러그인으로 이동하기로 했습니다.
1.4.20에서는 kotlin-android-extensions에서 Parcelable 구현 생성기를 추출하고 나머지는 지원 중단 주기를 시작하여 현재 synthetics로만 제공하고 있습니다. 지금 synthetics은 지원 중단 경고와 함께 계속 작동하지만, 나중에는 작업 중인 프로젝트를 다른 솔루션으로 전환해야 합니다. synthetics에서 뷰 바인딩으로 Android 프로젝트를 마이그레이션하는 방법은 이 가이드라인을 참조하세요.
Parcelable 구현 생성기는 이제 새로운 kotlin-parcelize 플러그인에서 사용할 수 있습니다. kotlin-android-extensions 대신 이 플러그인을 적용하거나 synthetics를 계속 사용하려는 경우 추가로 적용하세요. @Parcelize 어노테이션은 kotlinx.parcelize 패키지로 이동되었습니다.
업데이트 방법
프로젝트를 최신 버전의 Kotlin으로 업데이트하기 전에 play.kotl.in에서 온라인으로 새로운 언어 및 표준 라이브러리 기능을 사용해 볼 수 있습니다.
IntelliJ IDEA 및 Android Studio에서 Kotlin 플러그인을 1.4.20 버전으로 업데이트할 수 있습니다. 여기에서 그 방법을 알아보세요.
이전 Kotlin 버전으로 생성한 기존 프로젝트에서 작업하려면 해당 프로젝트 구성에서 1.4.20 Kotlin 버전을 사용하세요. 자세한 내용은 Gradle 및 Maven에 대한 문서를 참조하세요.
명령줄 컴파일러는 GitHub 릴리스 페이지에서 다운로드할 수 있습니다.
이 릴리스에서는 다음 라이브러리 버전을 사용할 수 있습니다.
- kotlinx.atomicfu 버전 0.14.4
- kotlinx.coroutines 버전 1.4.1
- kotlinx.serialization 버전 1.0.1
- ktor 버전 1.4.1
- kotlinx.html 버전 0.7.2
- kotlinx-nodejs 버전 0.0.6
kotlin-wrappers(kotlin-react 등)의 라이브러리 버전은 해당 저장소에서 찾을 수 있습니다.
릴리스에 관한 세부 정보 및 호환되는 라이브러리 목록은 여기에 나와 있습니다.
새 릴리스에서 이슈가 발생한 경우 언제든지 Slack(여기에서 초대 받기)에서 도움을 요청하거나 YouTrack에 이슈를 보고해 주세요.
외부 기여자
이 릴리스에 포함된 풀 리퀘스트를 제공해 주신 모든 외부 기여자께도 감사의 마음을 전합니다.
Jinseong Jeon
Toshiaki Kameyama
Steven Schäfer
Mads Ager
Mark Punzalan
Ivan Gavrilovic
pyos
Jim Sproch
Kristoffer Andersen
Aleksandrina Streltsova
cketti
Konstantin Virolainen
AJ Alt
Henrik Tunedal
Juan Chen
KotlinIsland
Valeriy Vyrva
Alex Chmyr
Alexey Kudravtsev
Andrey Matveev
Aurimas Liutikas
Dat Trieu
Dereck Bridie
Efeturi Money
Elijah Verdoorn Enteerman
fee1-dead
Francesco Vasco
Gia Thuan Lam
Guillaume Darmont
Jake Wharton
Julian Kotrba
Kevin Bierhoff
Matthew Gharrity
Matts966
Raluca Sauciuc
Ryan Nett
Sebastian Kaspari
Vladimir Krivosheev
n-p-s
Pavlos-Petros Tournaris
Robert Bares
Yoshinori Isogai
Kris
Derek Bodin
Dominik Wuttke
Sam Wang
Uzi Landsmann
Yuya Urano
Norbert Nogacki
Alexandre Juca
이 게시물은 Pavel Semyonov가 작성한 Kotlin 1.4.20 Released를 번역한 글입니다.
Subscribe to Kotlin Blog updates
