Google Developers Korea Blog

AMP를 훨씬 빠르게 만드는 방법

Tuesday, November 20, 2018

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 번역 리뷰에는 Jimmy Moon(Webtech GDE)님이 참여해 주셨습니다.>
게시자: Sebastian Benz, Google 파트너 디벨로퍼 Advocate
ampproject.org에 “Optimizing your hosted AMP pages”(호스트된 AMP 페이지의 최적화)에 관한 새로운 가이드를 게시했었습니다. AMP 문서를 최적화하여 훨씬 더 빠르게 로드되도록 할 수 있는 방법을 설명한 가이드입니다. '잠깐, AMP는 원래 빠르게 로드되도록 만든 페이지 아냐?'라고 생각하실지 모르겠습니다. 물론 그 생각이 맞습니다. AMP 런타임은 속도에 최적화되어 있어 유효한 AMP 페이지는 모두 빠르게 로드됩니다. 하지만 브라우저가 AMP 페이지를 훨씬 더 빠르게 로드하는 데 도움이 되도록 구현할 수 있는 추가적인 성능 최적화가 있습니다. 이러한 변화는 사소한 것이지만, AMP의 유효성을 깨뜨리지 않고 로딩 성능을 상당히 개선할 수 있습니다. 예를 들어 XWP에서 개발 중인 AMP WordPress 플러그인은 가이드에 설명되어 있는 기술 중 몇 가지는 이미 제공되고 있습니다. 이에 따라 xwp.co의 로딩 시간이 12.6% 빨라졌습니다. 또 다른 예는 Evening Standard인데, 이 회사는 한 걸음 더 나아가 SSR(server-side-rendering)로 최적화된 AMP를 게시합니다. 그 결과, 유효한 AMP 버전보다 FCP가 69% 향상되었습니다.
관심을 가져야 할 이유는? 한발 물러나 생각해 봅시다. 이게 과연 필요한 걸까요? AMP 문서는 이 모든 최적화를 자동으로 수행하는 AMP 캐시에 의해 항상 제공되는 게 아닌가요? AMP 문서가 Google 또는 Bing 검색결과에 노출될 때와 같은 몇 가지 경우에는 그 말이 맞습니다. 하지만 다음과 같이 AMP 문서가 출처에서 제공되는 경우도 있습니다.

https://tasty.co와 같이 정규 웹페이지나 모바일 웹페이지를 AMP로 빌드할 때.

출처에 있는 AMP 문서에 대한 다른 플랫폼 링크. 예를 들어 Twitter는 표준 모바일 버전을 제공하는 대신 AMP 페이지에 대한 링크 연결을 시작했습니다. 즉, 사용자가 Twitter의 모바일 앱 중 하나에 있는 링크를 클릭하면 링크가 개발자의 자체 서버에 있는 페이지의 AMP 버전으로 이동한다는 의미입니다.

이와 같이 자체 서버에서 AMP 페이지를 제공하는 경우, AMP 페이지가 최적의 로딩 성능을 제공하도록 하는 것이 중요합니다.
브라우저가 AMP 페이지를 더 빠르게 로드할 수 있게 하는 방법은? AMP의 로딩 성능 최적화가 작동하는 방식을 빠르게 살펴봅시다. amp-img 또는 amp-video와 같은 AMP 특정 요소가 작동하도록 AMP 런타임을 로드할 필요가 있습니다. 즉, amp-img는 AMP 런타임이 로드된 후 이미지를 다운로드하기 시작할 뿐이라는 의미입니다. 따라서 다음과 같이 AMP 페이지가 더 빠르게 로드되도록 만들 수 있는 두 가지 기회가 주어집니다.

브라우저가 AMP 런타임을 최대한 빠르게 다운로드하는지 확인하세요.

AMP 런타임을 사용할 수 있기 이전에 이미지와 같이 중요한 자산의 다운로드를 시작하도록 브라우저를 설정하세요.

이런 결과를 얻기 위한 관건은 rel=preload와 같은 리소스 힌트를 사용하여 중요한 리소스의 다운로드 우선순위를 정하는 것입니다. AMP 최적화 가이드에서는 리소스 힌트를 사용하여 AMP 페이지를 최적화할 수 있는 다양한 방법을 설명합니다. 최적화된 AMP 템플릿을 빠르게 생성할 수 있게 해주는 AMP Boilerplate Generator를 살펴보는 것도 좋은 생각입니다.
first-contentful-paint를 향상할 방법은? 성능 최적화를 한 단계 더 진행할 수도 있습니다. AMP 런타임은 정적 페이지 레이아웃 시스템을 구현하여 렌더링과 스크롤링 정크를 줄입니다. AMP 런타임이 로드될 때까지 AMP 상용구 코드가 처음에는 문서를 숨기는 방식으로 작동합니다. AMP 런타임은 로드된 후 레이아웃을 계산하고 그 내용을 보여줍니다. 이 접근 방식은 AMP 런타임이 로드될 때까지는 사용자에게 빈 페이지가 표시된다는 단점이 있고 프로그레시브 렌더링을 지원하지 않습니다. 이런 부정적 측면을 상쇄하기 위해 AMP SSR(server-side-rendering)을 사용하여 FCP(first-contentful-paint) 시간을 개선할 수 있습니다. 이런 식으로, AMP 런타임 자바스크립트를 실행하지 않고 AMP 문서를 페인팅할 수 있도록 AMP 상용구를 제거할 수 있습니다. 예를 들어 AMP Boilerplate Generator의 SSR 버전은 일반 AMP 버전보다 2배 빠르게 렌더링합니다.
blog-how-to-make-amp-faster-filmstrip

서버에 있는 AMP 문서의 최적화 방법을 알아보려면 AMP Optimizer를 확인해보세요.
성능 향상이란? 최적화가 로딩 성능에 어떤 영향을 주는지 알아보기 위해 필자는 다음과 같이 AMP Start Bike Shop 템플릿의 방문 페이지를 세 가지 다른 버전으로 만들어 보았습니다.

이미지 없음: 로드되는 AMP 런타임에 종속되는 시각적 콘텐츠가 없는 최상의 사례를 보여주는 시나리오를 시뮬레이션하기 위한 버전

이미지: 콘텐츠가 로드되는 AMP 런타임에 종속될 때의 로딩 시간을 보여주기 위한 버전

자체 호스트 글꼴: 커스텀 폰트에 따른 영향을 보여주기 위한 버전

각 페이지에 대해 다음 4가지 변형을 테스트했습니다.
1. 원본: 원래의 유효한 AMP 버전.
2. 최적화: 다음과 같은 최적화를 구현하는 유효하고 최적화된 AMP 버전
3.

4. 최적화 + SSR: 이전 버전과 같은 최적화를 구현하지만 AMP Optimizer를 통해 SSR(server-side-rendering)을 추가로 사용합니다. 참고: 이 버전은 유효한 AMP가 아닙니다. 5. 캐시: 참조로 사용되며 Google AMP Cache에 의해 제공되는 버전

300ms의 지연 시간으로 1.6Mbps 3G 연결 시, Motorola G(4세대)를 통해 Chrome에서 수행되는 모든 테스트는 Webpagetest에 의해 3회 실행됩니다. 이 문서에서 Webpagetest에 대한 링크를 포함한 전체 결과를 찾을 수 있습니다. 실제 기기에서 테스트를 실행하므로 실행 시간에 차이가 날 수 있습니다.

이제 그 결과를 살펴봅시다.

이미지 없음

	로드 시간(초)		렌더링 시작(초)		최초의 상호 작용(초)
원본	4.569		4.569		4.424
최적화	4.564	-0.11%	4.564	-0.11%	4.423	-0.02%
최적화 + SSR	2.233	-51.13%	2.233	-51.13%	4.48	1.27%
AMP 캐시	2.039	-55.37%	2.039	-55.37%	3.508	-20.71%

서버 측 렌더링 버전에 대해 50% 이상 빠른 로드 시간은 서버 측 렌더링 AMP의 이점을 분명히 보여줍니다. 하지만 상호 작용 시간은 여전히 로드되는 AMP 런타임에 따라 다르므로 변경되지 않습니다.

이미지

	로드 시간(초)		렌더링 시작(초)		최초의 상호 작용(초)
원본	5.435		4.591		5.367
최적화	4.591	-15.53%	4.566	-0.54%	5.094	-5.09%
최적화 + SSR	4.095	-24.66%	1.892	-58.79%	4.818	-10.23%
AMP 캐시	3.827	-29.59%	1.834	-60.05%	4.13	-23.05%

여기서 이미지를 미리 로드하면 로드 시간이 상당히 개선된다는 점을 알 수 있습니다. 유효한 최적화 AMP 버전은 로딩 속도가 15% 더 빨라지는 반면, 최적화 + SSR 버전은 '불과' 24%만 더 빨라질 뿐입니다. 이는 이미지 렌더링이 로드되는 AMP 런타임에 따라 결정되기 때문입니다.

자체 호스트 글꼴

	로드 시간(초)		렌더링 시작(초)		최초의 상호 작용(초)
원본	5.509		4.609		5.424
최적화	4.55	-17.41%	4.53	-1.71%	5.112	-5.75%
최적화 + SSR	4.478	-18.71%	1.989	-56.85%	5.203	-4.07%
AMP 캐시	3.978	-27.79%	1.847	-59.93%	4.317	-20.41%

이 경우에는 서버 측 렌더링 버전이 추가 글꼴 다운로드로 인해 지연되므로 최적화와 최적화 + SSR 사이의 전체 로드 시간 차이가 매우 작아집니다. 그래도 서버 측 렌더링을 사용하면 렌더링은 훨씬 빨리 시작합니다.

참고: AMP Cache는 모든 경우에 더 빠릅니다. 그 주된 이유는 다음 두 가지입니다.

이미지 최적화를 추가로 수행합니다.
같은 도메인에서 런타임이 제공되므로 AMP 런타임을 다운로드하기 위해 다시 https 연결을 설정할 필요가 없습니다.

결론

자체 서버에서 AMP 페이지가 훨씬 빠르게 로드되도록 만들 수 있다는 점을 살펴보았습니다. AMP 페이지를 게시하는 모든 이에게 핵심적인 사항은 다음과 같이 정리할 수 있습니다.

페어링된 AMP를 호스트하는 웹사이트는 캐시되지 않은 AMP 문서에 연결된 Twitter 및 기타 플랫폼에서 최상의 로딩 성능을 보장해야 합니다. 몇 가지 사소한 변경으로 AMP 페이지를 1초라도 더 빠르게 로드할 수 있다는 점을 기억하세요.
AMP로 빌드한 웹사이트는 프로그레시브 렌더링을 사용하고 FCP 시간을 대폭 개선해주는 AMP Optimizer의 사용을 고려해봐야 합니다.

우리는 새로운 최적화 방법을 발견하고 AMP 로딩 성능을 개선하기 위해 적극적으로 노력하고 있습니다.

Android Studio 3.2

Tuesday, November 20, 2018

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 번역 리뷰에는 이승민(Android GDE)님이 참여해 주셨습니다.>게시자: Jamal Eason, Android 제품 관리자
Android Studio 3.2를 다운로드하실 수 있습니다. Android Studio 3.2는 앱 개발자가 최신 Android 9 Pie 릴리스를 사용하고 새로운 Android App Bundle을 빌드할 수 있는 최선의 수단입니다. 우리는 Google I/O '18에서 Android Studio의 이 업데이트를 발표한 이후로 20여 가지의 새로운 기능을 구체화하고 더욱 가다듬었고 이처럼 Android Studio 3.2의 안정적 출시를 위한 품질 개선 노력에 집중해왔습니다. 모든 개발자는 Android Studio 3.2를 사용해 새로운 앱 게시 형식인 Android App Bundle을 사용하는 방향으로 전환해야 합니다. 최소한의 작업만으로 Android Studio를 사용해 앱 번들을 생성할 수 있습니다. Google Play에 앱 번들을 일단 업로드하고 나면 사용자에게 더 작고 최적화된 앱을 배포할 수 있습니다. 얼리 어답터들은 이미 앱 번들을 사용한 덕분에 이전 APK 앱 크기에 비해 앱 크기를 11%~64% 줄이는 효과를 보았습니다. 놓치지 말아야 할 또 다른 기능은 Energy Profiler입니다. 이 새로운 프로파일러는 개발한 앱이 에너지 사용량에 미치는 영향을 진단하고 개선하는 데 도움이 되는 도구 집합을 제공합니다. 가장 많이 쇄도하는 사용자 요청 사항 중 하나가 바로 기기 배터리 수명 개선인데, Android Studio 3.2에서 Energy Profiler를 사용하면 앱이 알맞은 시점에 적당량의 에너지만 사용하도록 함으로써 앱 개발자로서 기기 배터리 수명의 개선에 기여할 수 있습니다. 마지막으로, 새로운 Android Emulator Snapshots 기능도 확인해 보셔야 합니다. 이 기능을 사용하면 화면, 앱, 설정의 현재 상태를 포함하는 에뮬레이터의 현재 상태에 대한 스냅샷을 빠르게 생성할 수 있습니다. 2초 이내에 에뮬레이터 스냅샷을 재개하거나 부팅할 수 있습니다. 초고속 부팅 시간을 원하거나 예측 가능한 Android 환경에서 테스트를 실행할 방안을 찾고 있는 앱 개발자에게는 Android Emulator Snapshots가 앱 개발의 판도를 바꿔주는 대단한 기능입니다. Android Studio 3.2에는 이런 주요 기능 외에도 20가지의 눈에 띄지는 않지만 품질 향상에 기여하는 다수의 새로운 기능이 있습니다. Android Studio 3.2를 사용하면 Android Jetpack부터 Android Slices를 포함한 Google AI(Artificial Intelligence) API의 최신 기술까지 다양한 최신 기술에 걸맞은 앱도 개발할 수 있습니다. 카나리아 및 베타 릴리스 모두에 대해 일찍부터 소중한 피드백을 보내주신 분들께 감사합니다. 보내주신 피드백 덕분에 Android Studio 3.2의 품질과 기능을 더욱 개선할 수 있었습니다. 다음의 안정적 릴리스를 사용할 준비가 되어 있고 새로운 생산성 기능 세트를 사용해보고 싶으시다면 오늘 바로 Android Studio 3.2를 다운로드하여 새로운 변화를 시작해보세요. 아래에 Android Studio 3.2의 모든 새로운 기능을 주요 개발자 워크플로우를 기준으로 정리해 두었으니 확인해 보세요. 개발

Slices 지원 - Slices는 Google 검색 제안과 Google 어시스턴트에서 앱 콘텐츠를 노출하여 내장된 Android AI 기능을 이용하는 새로운 방식입니다. Android Studio 3.2에는 새로운 Slice Provider API로 앱을 확장하는 데 도움이 되는 내장 템플릿뿐 아니라 Slices를 생성할 때 모범 사례를 확실히 따르도록 하기 위한 새로운 lint 검사 기능도 있습니다. 사용하려면 프로젝트 폴더를 마우스 오른쪽 버튼으로 클릭하고 New→ Other→ Slice Provider로 이동하세요. 자세히 알아보기.

샘플 데이터 - 플레이스홀더 데이터를 사용하여 앱 설계를 지원하는 기능입니다. 이 기능은 런타임 데이터에 종속되는 레이아웃의 시각화에 도움이 됩니다. Layout Editor에서 팝업 창을 통해 RecyclerViews, ImageViews, TextViews와 같은 뷰를 게재하기 위한 기본 제공 샘플 데이터를 추가할 수 있습니다. 자세히 알아보기.

머티리얼 디자인 업데이트 - Android Design 지원 라이브러리에서 새로운 MaterialComponents 앱 테마 및 라이브러리로의 마이그레이션을 시작할 때 Android Studio 3.2에서 BottomAppBar, 버튼, 카드, 텍스트 필드, 새로운 글꼴 스타일 등의 새로운 위젯과 업데이트된 위젯에 액세스할 수 있습니다. 자세히 알아보기.

CMakeList 편집 지원 - 앱에 C/C++를 사용하는 개발자를 위해, Android Studio에는 CMake를 위해 더 나은 지원 기능이 있습니다. 이번에 출시되는 Android Studio 3.2에서는 공통적인 CMakeList 빌드 스크립트 명령어에 대해 코드 완성 및 구문 강조표시 기능을 사용할 수 있습니다.

새로운 어시스턴트 - Android Studio 3.2에는 업데이트 후에 자동으로 열려 IDE에 대한 최신 변경 내용을 알려주는 새로운 어시스턴트 패널이 있습니다. Help → What's New in Android Studio로 이동하여 이 패널을 열 수도 있습니다.

AndroidX 리팩터링 지원 - Android Jetpack의 컴포넌트 중 하나는 Android 확장 라이브러리(AndroidX)를 Android 지원 라이브러리의 대체 라이브러리로 도입한 것입니다. AndroidX를 새 프로젝트에 추가하려면 gradle.properties 파일에 android.useAndroidX=true를 추가하기만 하면 됩니다. 뿐만 아니라, Android Studio 3.2에는 프로젝트를 새로운 네임스페이스와 종속 항목으로 마이그레이션하는 데 도움이 되는 새로운 리팩터링 액션이 기본 제공됩니다. 또한 AndroidX 네임스페이스로 마이그레이션하지 않은 Maven 종속 항목이 있는 경우 Android Studio 빌드 시스템은 이러한 프로젝트 종속 항목도 자동으로 변환합니다. 자세히 알아보기.

IntelliJ 플랫폼 업데이트 - Android Studio 3.2에는 IntelliJ 2018.1.6 플랫폼 릴리스가 포함됩니다. 이 IntelliJ 릴리스에서는 데이터 흐름 분석, 디버깅, 새로운 검사, 인라인 외부 주석, 부분 Git 커밋 외에도 다수의 기능에 많은 개선 사항이 추가되었습니다. 자세히 알아보기.

Kotlin 업데이트 - Android Studio 3.2에는 Kotlin 1.2.61과 함께 Kotlin 친화적인 Android 9 Pie SDK 지원 기능이 번들로 묶여 있습니다. 자세히 알아보기.

빌드

Android App Bundle - Android App Bundle은 사용자에게 더 작은 APK를 전달하고 앱의 다운로드 크기를 줄이는 데 도움이 되도록 디자인된 새로운 앱 게시 형식입니다. Dynamic Delivery라고 부르는 Google Play의 새로운 앱 서비스 모델은 각 사용자의 기기 구성에 맞춰 최적화된 APK를 생성하여 사용자가 앱 실행에 필요한 코드와 리소스만 다운로드하도록 앱 번들을 처리합니다. Android Studio 3.2를 사용하거나 명령줄을 통해 코드를 앱 번들로 손쉽게 빌드하고, 앱 코드를 전혀 변경하지 않고 언어, 화면 밀도, ABI를 기반으로 더 작은 APK의 이점을 누릴 수 있습니다. 자세히 알아보기.

Android App Bundle 빌드

D8 Desugaring - 경우에 따라, 새로운 Java Language 기능에 새로운 바이트코드와 언어 API가 필요할 수 있습니다. 하지만 이전 Android 기기에서는 이러한 기능을 지원하지 않을 수도 있습니다. Desugaring을 통해 빌드 프로세스 중에 새로운 바이트코드와 언어 API를 이전의 것으로 바꾸는 방법으로 이전 기기에서도 이러한 기능을 사용할 수 있습니다. Android Studio 3.2의 경우 D8 Desugaring 기능은 기본적으로 활성화되어 있으며, 현재 대부분의 최신 언어 변경 내용을 사용하는 동시에 이전 기기를 대상으로 삼을 수도 있습니다.

R8 Optimizer - 우리는 Android Studio 3.2부터 시작해서 ProGuard 대신 R8을 사용하여 자바 언어 바이트코드를 최적화하고 축소하는 방향으로 전환하기 시작하고 있습니다. R8은 아직 실험 단계이므로 R8을 사용하여 앱을 게시하라고 권장하지는 않지만, R8이 ProGuard를 완전히 대체하기 전에 필요한 조정 작업을 할 수 있도록 Android Studio 팀에게 조기에 피드백을 주시면 정말 큰 도움이 될 것입니다. 자세히 알아보기.

테스트

Emulator Snapshots - 최신 Android Emulator 릴리스를 사용하면 에뮬레이터의 현재 상태를 보여주는 스냅샷을 생성하고 2초 내에 어떤 스냅샷으로든 부팅하고 전환할 수 있습니다. Android Emulator Quickboot 기능을 기반으로 빌드된 Android Snapshots는 눈에 보이지 않을 정도로 속도가 향상된 이번 안정적 릴리스로 훨씬 더 빠르게 저장하고 로드할 수 있습니다. 앱을 테스트하고 개발할 때 Android Snapshots를 사용하면 구성하고 싶은 사전 설정, 앱, 데이터 및 설정으로 AVD(Android Virtual Device) 스냅샷을 미리 구성하고 같은 스냅샷으로 반복해서 되돌아갈 수 있습니다. 자세히 알아보기.

Android Emulator Snapshots

Microsoft® Hyper-V™ Support - 이제는 Windows® 10 컴퓨터(Hyper-V가 사용 설정된 컴퓨터)에서 Android Emulator를 실행할 수 있습니다. Intel HAXM은 여전히 가장 빠른 Android Emulator 환경을 위한 기본 하이퍼바이저입니다. 하지만 Microsoft에서 최근에 발표한 오픈소스와 새로운 WHPX(Windows Hypervisor Platform) API가 추가된 덕분에, Android Emulator는 새로운 Hyper-V Support를 사용하여 로컬 가상 머신 등, Hyper-V의 지원을 받는 다른 애플리케이션과 공존할 수 있습니다. 자세히 알아보기.

AMD® 프로세서 지원 - 현재 Windows 10에 설치되는 Android Emulator는 AMD 프로세서를 지원합니다. 이전에는 Windows 실행 시 Android Emulator를 실행하면 소프트웨어 에뮬레이션이 느려지는 한계가 있었지만, AMD 프로세서를 보유한 개발자는 이제 하드웨어 가속 성능을 활용할 수 있습니다. 자세히 알아보기.

Android Emulator의 화면 녹화 - 이제는 Android Emulator의 새로운 화면 녹화 기능으로 임의의 Android API 레벨에서 화면과 오디오를 둘 다 기록할 수 있습니다. 과거에는 실제 Android 기기의 화면 녹화 기능은 Android 4.4 KitKat(API 19) 이상에서만 작동했고, 그나마 오디오를 기록할 방법이 없었고 Android Emulator 지원도 제한적이었습니다. 하지만 최신 Android Emulator(v28.0 이상)에서는 이러한 제한이 더는 없습니다. 그 밖에, 출력을 GIF와 WebM으로 변화하는 기능도 보너스로 기본 제공됩니다. Android Emulator Extended Controls 패널, 명령줄, Android Studio에서 이 새로운 화면 녹화 기능을 실행할 수 있습니다. 자세히 알아보기

Android Emulator용 가상 장면 카메라 - Android Emulator의 새로운 가상 장면 카메라는 증강 현실 환경을 빌드하기 위한 Google 플랫폼인 ARCore용 앱을 개발하는 데 도움이 됩니다. 이 에뮬레이터는 AR 앱용 ARCore API와 함께 작동하도록 보정되고 가상 장면 비트맵 이미지를 삽입할 수도 있습니다. 이 가상 장면 카메라를 일반 HAL3 호환 카메라로 사용할 수도 있습니다. 자세히 알아보기.

ADB Connection Assistant - Android Studio 3.2에는 Android ADB 기기 연결 문제의 해결에 도움이 되는 새로운 어시스턴트 시스템이 있습니다. ADB Connection Assistant는 Android 기기를 개발 시스템에 연결하기 위한 일반적인 문제해결 단계를 안내해줍니다. 이 어시스턴트는 Run 대화상자에서 실행하거나 Tools → Connection Assistant로 이동하여 실행할 수 있습니다. 자세히 알아보기.

최적화

Energy Profiler - 배터리 수명은 많은 모바일 사용자의 주요 관심사로, 당신의 앱이 알고 있는 수준보다 많이 배터리 수명에 영향을 미칠 수 있습니다. Android Studio 성능 프로파일러 모음의 새로운 Energy Profiler는 개발한 앱이 Android 기기에 미치는 에너지 영향을 파악하는 데 도움이 될 수 있습니다. 이제는 시스템 컴포넌트의 예상 에너지 사용량을 시각화하는 것은 물론, 배터리 방전을 일으킬 수 있는 백그라운드 이벤트를 검사할 수도 있습니다. Energy Profiler를 사용하려면 Android 8.0 Oreo(API 26) 이상을 실행하는 Android 기기 또는 에뮬레이터에 연결되어 있어야 합니다. 자세히 알아보기.

Energy Profiler

System Trace - CPU Profiler의 새로운 System Trace 기능을 사용하면 앱이 시스템 리소스와 상호 작용하는 방식을 세세한 수준까지 자세히 검사할 수 있습니다. 스레드 상태의 정확한 타이밍과 지속 시간을 검사하고, 모든 코어에 걸쳐 CPU 병목현상이 발생하는 위치를 시각화하고, 사용자설정 추적 이벤트를 추가하여 분석할 수 있습니다. 시스템 추적을 사용하려면 앱 프로파일링을 시작하고 클릭하여 CPU Profiler로 들어간 다음, System Trace 기록 구성을 선택하세요. 자세히 알아보기.

프로파일러 세션 - 이제는 Android Studio가 열려 있는 동안 Profiler 데이터가 '세션'으로 자동 저장되므로, 다음에 해당 데이터를 다시 보고 검사할 수 있습니다. 다음에 다른 도구로 분석하거나 검사하기 위해 CPU 기록과 힙 덤프를 가져오고 내보내는 기능도 추가했습니다. 자세히 알아보기.

자동 CPU 기록 - 이제는 Debug API를 사용하여 CPU 활동을 자동으로 기록할 수 있습니다. 앱을 기기에 배포한 후 프로파일러는 앱이 startMethodTracing(String tracePath)를 호출할 때 CPU 활동 기록을 자동으로 시작하고 앱이 stopMethodTracing()을 호출할 때 기록을 중지합니다. 마찬가지로, 이제는 실행 구성에서 Start Recording a Method Trace on Startup 옵션을 사용 설정하여 앱이 시작될 때 CPU 활동 기록을 자동으로 시작할 수도 있습니다. 자세히 알아보기.

JNI 참조 추적 - Android 앱에 C/C++ 코드를 사용하는 개발자를 위해, Android Studio 3.2에서는 Memory Profiler에서 JNI 코드의 메모리 할당을 검사할 수 있도록 되어 있습니다. Android 8.0 Oreo(API 26) 이상을 실행하는 기기에 앱을 배포하는 한, JNI 참조에서 할당 호출 스택으로 드릴다운할 수 있습니다. 이 기능을 사용하려면 메모리 프로파일러 세션을 시작하고 Live Allocation 드롭다운 메뉴에서 JNI Heap을 선택하세요. 자세히 알아보기.

요약하자면, Android Studio 3.2의 최신 카나리아 버전에는 다음과 같은 새로운 주요 기능이 포함되어 있습니다.

개발

AndroidX 리팩터링
샘플 데이터
머티리얼 디자인 업데이트
Android Slices
CMakeList 편집
새로운 어시스턴트
새로운 Lint 검사
Intellij 플랫폼 업데이트
Kotlin 업데이트

빌드

Android App Bundle
D8 Desugaring
R8 Optimizer

테스트

Android Emulator Snapshots
Android Emulator의 화면 녹화
가상 장면 Android Emulator 카메라
AMD 프로세서 지원
Hyper-V 지원
ADB Connection Assistant

최적화

Energy Profiler
시스템 추적
프로파일러 세션
자동 CPU 기록
JNI 참조 추적

자세한 내용은 출시 노트를 참조하세요.
시작하기
다운로드 페이지에서 Android Studio 3.2 최신 버전을 다운로드하세요. 이전 카나리아 출시 버전의 Android Studio를 사용 중이라면 Android Studio Canary 14 이상으로 업데이트해야 합니다. Android Studio의 안정적인 버전을 그대로 유지하고 싶을 경우 Android Studio의 안정적인 릴리스 버전과 카나리아 출시 버전을 동시에 실행할 수 있습니다. 자세히 알아보기. 위에서 언급한 Android Emulator 기능을 사용하려면 Android Studio SDK Manager를 통해 다운로드한 Android Emulator v28.0.7 이상을 실행 중이어야 합니다. 어떤 점이 마음에 드는지, 어떤 문제나 기능에 대해 알고 싶은지 피드백을 보내주시면 감사하겠습니다. 뛰어난 제품 품질을 유지하기 위해 이전 릴리스 채널에서 본 두어 가지 기능(예: Navigation Editor)이 안정적인 릴리스 채널에서는 기본적으로 비활성화되어 있다는 점에 유의하세요. 버그나 문제를 발견하면 언제든지 문제를 제기해 주세요. Google+ 페이지나 Twitter에서 저희 Android Studio 개발 팀과 계속 소통하시기 바랍니다.

AMP를 훨씬 빠르게 만드는 방법

Android Studio 3.2

Tag

Archive

Feed

Google Korea

Products

Developers