Compose 측정항목과 뷰 측정항목 비교

UI 개발을 가속화하고 Android를 개선하는 Jetpack Compose 참조하세요. 그러나 기존 앱에 Compose를 추가하면 앱의 APK 크기, 빌드, 런타임 성능 등이 있습니다

APK 크기 및 빌드 시간

이 섹션에서는 Sunflower 샘플 앱 - 권장사항을 보여주는 앱 뷰 기반 앱을 Compose로 이전할 수 있습니다

APK 크기

프로젝트에 라이브러리를 추가하면 APK 크기가 커집니다. 결과 리소스 및 코드가 포함된 각 프로젝트의 축소된 출시 APK용입니다. 축소가 사용 설정되었고, R8 전체 모드를 사용하고, APK Analyzer를 사용하여 측정되었습니다.

Sunflower에 Compose를 처음 추가했을 때 APK 크기가 2,252KB에서 3,034KB: 782KB 증가 생성된 APK는 뷰와 Compose를 혼합하여 사용할 수 있습니다 이러한 증가는 종속 항목을 Sunflower에 추가했습니다.

반대로 Sunflower가 Compose 전용 앱으로 이전되었을 때 APK 크기는 3,034KB에서 2,966KB로 감소하여 68KB 감소입니다. 감소의 원인이 된 것입니다. AppCompat 및 ConstraintLayout입니다.

빌드 시간

Compose를 추가하면 Compose 컴파일러로 인해 앱의 빌드 시간이 늘어납니다. 앱에서 컴포저블을 처리할 수 있습니다. 다음을 사용하여 얻은 결과는 다음과 같습니다. 독립형 gradle-profiler 도구로, 빌드를 여러 번 실행하므로 의 디버그 빌드 기간 동안 평균 빌드 시간을 얻을 수 있다는 것을 해바라기:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

Sunflower에 Compose를 처음 추가했을 때 평균 빌드 시간이 299초에서 증가했습니다. 399ms로 지연되어 100ms 증가합니다. 이 기간은 Compose 컴파일러로 인한 것입니다. 프로젝트에 정의된 Compose 코드를 변환하는 추가 작업 실행

반대로 다음과 같은 경우 평균 빌드 시간은 342ms(57ms 감소)로 Sunflower의 Compose 이전이 완료되었습니다. 이러한 감소는 데이터 삭제, 프로젝트 실행 또는 삭제와 같은 빌드 시간을 전체적으로 단축하는 바인딩, kapt를 KSP로 사용하는 종속 항목 이전, 업데이트 최신 버전에 여러 종속 항목을 배포합니다

요약

Compose를 채택하면 앱의 APK 크기가 효과적으로 증가하고 컴파일 프로세스로 인해 앱의 빌드 시간 성능 향상 살펴보겠습니다 하지만 이러한 장단점은 Compose의 이점(특히 개발자 생산성 향상 관련) 살펴봤습니다 예를 들어 Play 스토어팀에서는 UI를 작성할 때 필요한 코드가 훨씬 적기 때문에 때로는 최대 50%에 이릅니다. 코드 생산성 및 유지보수성 향상

팀을 위한 Compose 채택에서 더 많은 우수사례를 읽어 볼 수 있습니다.

런타임 성능

이 섹션에서는 Jetpack Compose의 런타임 성능과 관련된 주제를 다룹니다. Jetpack Compose와 뷰 시스템의 성능을 비교하는 방법 측정할 수 있습니다

스마트 재구성

UI의 일부가 잘못된 경우 Compose는 업데이트가 필요한 부분입니다. 이에 대한 자세한 내용은 수명 주기 컴포저블과 Jetpack Compose 단계 문서를 참조하세요.

기준 프로필

기준 프로필은 일반적인 사용자 경험의 속도를 높이는 좋은 방법입니다. 기준 포함 앱의 프로필을 만들면 처음 구현했을 때보다 코드 실행 속도가 약 30% 향상될 수 있습니다. 해석 및 적시 (JIT) 컴파일 단계를 피하여 포함할 수 있습니다.

Jetpack Compose 라이브러리에는 자체 기준 프로필이 포함되어 있으며 앱에서 Compose를 사용할 때 자동으로 이러한 최적화를 구현할 수 있습니다. 하지만 이러한 최적화는 Compose 라이브러리 내의 코드 경로에만 영향을 미치므로 기준 프로필을 추가하는 것이 좋습니다. 앱을 사용하여 Compose 외부의 코드 경로를 처리할 수 있습니다.

View 시스템과의 비교

Jetpack Compose에는 뷰 시스템에 비해 많은 개선사항이 있습니다. 이러한 개선사항은 다음 섹션에서 설명합니다.

View 시스템 확장

TextView, Button 또는 ImageView와 같이 화면에서 그리는 모든 View에는 메모리 할당과 명시적 상태 추적을 비롯하여 모든 사용 사례를 지원하는 다양한 콜백이 필요합니다. 또한 맞춤 View 소유자는 명시적 로직을 구현하여 다시 그리지 못할 때 스테이트리스(Stateless) 컨테이너를 실행하는 관리형 컴퓨팅 플랫폼입니다

Jetpack Compose에서는 여러 가지 방법으로 이러한 문제를 해결했습니다. Compose에는 명시적인 업데이트 가능한 객체입니다. UI 요소는 구성 가능한 간단한 함수 이 객체의 정보가 재생 가능한 방식으로 컴포지션에 작성됩니다. 이렇게 하면 명시적 상태 추적, 메모리 할당 및 해당 기능을 모두 요구하는 대신 해당 기능을 요구하는 컴포저블 지정된 View 유형의 확장자입니다.

또한 Compose는 스마트 리컴포지션을 제공하므로 변경할 필요가 없는 경우 이전에 그린 결과를 재생합니다.

다중 레이아웃 패스

기존 ViewGroups는 측정과 레이아웃에 많은 표현력이 있습니다. 다중 레이아웃 패스가 발생하기 쉬운 API 이러한 다중 레이아웃 패스가 뷰 계층 구조의 특정 중첩 지점에서 실행되면 지수 작업이 발생할 수 있습니다.

Jetpack Compose는 단일 레이아웃 패스를 적용합니다. 를 사용해야 합니다. 이렇게 하면 Compose가 효율적으로 처리할 수 있습니다. 여러 측정이 필요한 경우 Compose는 내장 기능 측정

View 시작 성능

View 시스템이 특정 레이아웃을 처음 표시할 때는 XML 레이아웃을 확장해야 합니다. Jetpack Compose에서는 레이아웃이 자동으로 Kotlin으로 작성되고 앱의 나머지 부분처럼 컴파일됩니다.

Compose 벤치마크

Jetpack Compose 1.0에서는 debug 모드와 release 모드의 앱 성능 사이에 큰 차이가 있습니다. 앱을 프로파일링할 때 대표적인 시간 측정에는 항상 debug 대신 release 빌드를 사용합니다.

Jetpack Compose 코드의 성능을 확인하려면 Jetpack Macrobenchmark 라이브러리. 자세히 알아보려면 Jetpack Compose와 함께 사용하려면 MacrobenchmarkSample 프로젝트

Jetpack Compose팀은 Macrobenchmark를 사용하여 일어날 수 있습니다. 예를 들어 지연 열 벤치마크를 참조하세요. 및 대시보드 회귀를 추적할 수 있습니다

Compose 프로필 설치

Jetpack Compose는 번들로 묶이지 않은 라이브러리이므로 뷰 시스템의 UI 툴킷 클래스와 드로어블. 프로필을 활용하는 Jetpack Compose 1.0 출시 빌드용 설치 프로필 설치 프로그램을 사용하면 앱이 중요 코드를 지정할 수 있습니다. 설치 시점에 AOT (Ahead-Of-Time) 컴파일되어야 합니다. Compose는 Compose 앱의 시작 시간과 버벅거림을 줄이는 프로필 설치 규칙을 제공합니다.