Google for Developers Korea Blog

새로운 Google Play 기능을 활용한 구독 서비스 성장 및 최적화를 소개해드립니다

2018년 7월 13일 금요일

.post-body span { white-space: normal !important; }

블로그 원문은 이 곳에서 확인하실 수 있으며 리뷰에는 양찬석(Google)님이 도움을 주셨습니다.
게시자: Larry Yang 및 Angela Ying, Google Play 제품 관리자
Google Play 구독 서비스 사용자는 매년 80% 이상 급증하고 있습니다. 구독 서비스 사용자 성장세를 지속적으로 유지하고 더욱 건강한 구독 생태계를 만들기 위한 노력은 계속되고 있습니다. 지난 I/O 2018에서 구독 과정에서의 여러 가지 개선 사항 및 개발자가 원하는 방식대로 비즈니스를 관리할 수 있게 해주는 새로운 도구가 발표되었습니다.
구독 서비스 사용자에게 더 많은 통제권 부여 구글에서 실시한 연구 결과 사용자들은 구독을 통해 얻을 수 있는 가치에는 만족하는 반면 다음과 같은 불안을 갖고 있는 것으로 조사되었습니다.

구독을 취소할 수 있는 기능이 없어서 구독 서비스의 '덫'에 갇힐 수 있음

특정 구독에 얼마나 지출하고 있는지 파악하는 것이 힘듬 

이러한 걱정 때문에 흥미를 끄는 구독 앱이 있어도 선뜻 구독을 결정하지 못하는 것으로 나타났습니다. 새로운 구독 센터는 이런 우려를 해소하기 위해 출시되었습니다. Google Play에서 구독 중인 내용을 한눈에 확인하고 관리할 수 있습니다.

구독 센터를 통해 다음과 같은 일을 할 수 있습니다.

자신의 모든 구독 상황 및 세부 정보와 상태 확인

백업 결제 방법의 설정을 포함한 결제 방법 관리 및 업데이트

구독 갱신

취소한 구독 복원

구독 취소

그 밖에도, 사용자가 구독을 취소할 경우 취소 설문조사를 표시하는 기능이 추가되었습니다. 사용자가 취소하는 이유에 관해 피드백을 남기면 이 후 개발자가 이를 확인할 수 있습니다. 현재 서버 측 API 쿼리를 통해 취소 설문조사 데이터를 볼 수 있습니다.

새로운 구독 센터에는 빈 상태의 'Get Started' 링크도 있는데, 사용자는 이 링크를 현재 인기있거나 추천되는 구독 앱을 검색할 수 있습니다.

구독 센터의 출범과 함께, 개발자가 앱에서나 이메일 또는 웹을 통해 사용자가 자신의 구독을 관리하도록 안내할 목적으로 사용할 수 있는 새로운 딥 링크도 선보일 예정입니다. 패키지 이름과 SKU를 사용하여 딥 링크를 생성한 다음 앱 내에서 원하는 곳에 딥 링크 버튼을 추가해 사용할 수 있습니다. 자세한 내용은 Android 개발자 웹사이트를 참조하세요.
개발자에게 더 많은 통제권 부여 사용자를 위한 더 나은 환경을 만드는 것 외에, 개발자가 더욱 유연하게 비즈니스를 관리할 수 있도록 새로운 도구를 준비하고 있습니다. 많은 개발자분이 원하시는 기능 중 하나가 바로 가격 변경입니다. 이제 곧 개발자는 완전히 별개의 SKU를 설정할 필요 없이 Google Play Console을 통해 특정 SKU 가격을 변경하고, 사용자에게 가격 변경을 수락하도록 요청할 수 있습니다. Google Play는 이메일, 푸시 알림 및 인앱 메시지를 통해 사용자에게 가격 변경 사실을 알리고, 갱신 날짜까지 사용자가 이에 동의하지 않으면 구독이 취소됩니다. 사전 체험판 프로그램 참가에 관심이 있으시면 여기서 등록하세요.
그 외 I/O에서 다음과 같은 기능이 소개되었습니다.

사용자의 만료일을 변경하지 않고 구독 업그레이드

Play Console에서 일부 환불 실행

맨 마지막 갱신만이 아니라 특정 구독 갱신에 대해 환불

서버 측 API 사용시 주문 ID 사용 가능

Google Play Developer API와 함께 Refund API 사용

여기에 더해 올해 초에 발표된 더 빠른 테스트 갱신과 유연한 도입 가격 기능도 확인해보시기 바랍니다.
새로운 기능을 구현하실 계획이라면 I/O에서 버전 1.1로 출시된 Google Play Billing Library를 사용하는 것을 추천드립니다. 이 결제 라이브러리는 AIDL 파일 위에 있는 추상화 계층이며, 빌드 종속성 파일을 업데이트할 때 API 업데이트가 자동으로 이루어집니다. 만료일이 동일한 가격 변경 및 업그레이드/다운그레이드 기능등은 Google Play Billing Library를 사용해 구현하실 수 있습니다.이 후에도 새롭게 소개될 기능 중 일부는 Google Play Billing Library를 사용하는 경우에만 사용하실 수 있게됩니다.
모두에게 더 나은 환경 훌륭한 사용자 환경을 구축하면 양질의 구독자 기반이 형성될 것이라고 확신합니다. 개발자가 더 나은 방식으로 비즈니스를 관리할 수 있도록 돕는 도구와 통계를 제공함으로써 개발자 여러분이 자신의 비즈니스와 고객에게 최상의 결과를 안겨줄 수 있는 더 좋은 사용자 경험을 제공할 수 있을거라 믿습니다.

업데이트된 YouTube-8M과 제2회 YouTube-8M 대용량 동영상 이해 챌린지 및 워크샵을 소개합니다

2018년 7월 12일 목요일

.post-body span { white-space: normal !important; } 게시자: Joonseok Lee, Google AI 소프트웨어 엔지니어
Kaggle과 함께 최초의 YouTube-8M 대용량 동영상 이해 챌린지를 조직했으며, 60개국 946명으로 구성된 742개 팀들이 동영상 수준 레이블을 정확하게 할당하는 분류 알고리즘을 개발하기 위해 YouTube-8M 데이터세트(2017 에디션)를 사용했습니다. 이 경연의 목표는 동영상을 분류하는 머신러닝 모델을 개선하는 데 도움이 되는 대용량 동영상 이해, 표현 학습, 노이즈 데이터 모델링, 전이 학습 및 도메인 적응 접근방식에서 성능 개선을 촉진하는 것이었습니다. 이 경연 외에도 우리는 CVPR’17에서 관련 워크샵을 주최했으며, 경연의 상위 입상자들과 연구원들이 동영상 이해 분야에서 자신들이 최고의 기술을 내놓을 수 있었던 방법에 대한 아이디어를 서로 공유했습니다.
동영상 이해를 촉진하기 위한 이러한 지속적인 노력의 일환으로 YouTube-8M 데이터세트의 또 다른 업데이트, 새로운 Kaggle 동영상 이해 챌린지 그리고 ECCV'18(2018 European Conference on Computer Vision)에서 열리는 제2회 YouTube-8M 대용량 동영상 이해 워크샵을 소개해드리겠습니다.

업데이트된 YouTube-8M 데이터세트(2018 에디션) YouTube-8M(2018 에디션)에서는 주석의 품질이 대폭 개선되었으며, 오디오 시각적 콘텐츠와 제목, 설명 및 기타 메타데이터를 조합하는 머신러닝 시스템을 사용하여 더욱 정확한 실측 주석을 제공합니다. 업데이트된 버전에는 610만개의 URL이 포함되고, 3,862개의 시각적 어휘 항목으로 레이블이 달리며, 각 동영상에는 하나 이상의 레이블과 동영상당 평균 3개의 레이블이 주석으로 달립니다. 또한 스타터 코드를 업데이트했으며, 데이터세트에서 TensorFlow 동영상 주석 모델을 다운로드하고 학습하기 위한 지침이 업데이트되었습니다.
제2회 YouTube-8M 동영상 이해 챌린지 제2회 YouTube-8M 동영상 이해 챌린지에 초대받은 참가자는 YouTube-8M을 학습 데이터로 사용하여 오디오 시각적 콘텐츠 분류 모델을 빌드한 다음, 알 수 없는 하위 테스트 동영상에 레이블을 달게 됩니다. 작년과 달리 올해는 모델 크기에 엄격한 제한이 있으며, 참가자는 빠듯한 예산 내에서 (최대한 많은 모델을 조합하는 대신) 단일 모델을 내놓아야 합니다. 상위 다섯 팀에게는 각각 뮌헨에서 열리는 ECCV’18에 참여할 수 있는 $5,000의 여행 티켓이 수여됩니다. 자세한 내용은 Kaggle 경연 페이지를 참조하세요.
제2회 YouTube-8M 대용량 동영상 이해 워크샵 ECCV’18에서 열리는 이 워크샵은 저명한 연구원들의 초청 토론 뿐만 아니라 아이디어 교류를 촉진하기 위한 챌린지 상위 입상자들의 프레젠테이션으로 구성됩니다. 참가를 원하는 분은 YouTube-8M 데이터세트를 바탕으로 하는 자신의 연구, 실험 또는 애플리케이션을 설명하는 문서를 제출해야 하며, 자신의 챌린지 참가를 요약하는 문서도 함께 제출해야 합니다. 자세한 내용은 워크샵 페이지를 참조하세요.
새로운 챌린지 및 워크샵과 더불어 데이터세트에 대한 이번 업데이트가 대용량 동영상 이해 분야의 연구를 지속적으로 발전시킬 수 있기를 바랍니다. 다시 만날 수 있기를 바랍니다!
감사의 말 이 게시물에는 Sami Abu-El-Haija, Ke Chen, Nisarg Kothari, Joonseok Lee, Hanhan Li, Paul Natsev, Sobhan Naderi Parizi, Rahul Sukthankar, George Toderici 및 Balakrishnan Varadarajan과 Kaggle의 Sohier Dane, Julia Elliott, Wendy Kan 및 Walter Reade를 비롯하여 많은 기계 인지 연구원들의 노고가 반영되어 있습니다. 또한 YouTube 파트너들이 보내준 지원과 조언에도 감사를 드립니다.

Google Play 보안 메타데이터 및 오프라인 앱 배포에 대해 안내드립니다

2018년 7월 12일 목요일

.post-body span { white-space: normal !important; }

<블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 김태호(Google)님이 참여해 주셨습니다>

게시자: James Bender, Google Play 제품 관리자
작년 12월, Google Play에서 배포되는 애플리케이션의 신뢰성 향상을 위한 애플리케이션 보안 정책이 발표되었습니다. 이에 따라, 현재 Google Play를 통해 배포되는 APK에는 Google Play에서 배포된 APK임을 확인하기 위한 소량의 보안 메타데이터가 추가되어 있습니다.
데이터 요금제가 비싸거나 네트워크 인프라가 좋지 않은 국가에서는 Google Play를 거치지 않고 P2P(Peer-to-Peer)로 앱을 공유하는 경우가 흔합니다. 앞서 소개한 정책 업데이트는, 개발자들이 이들 국가에 거주하는 잠재고객층을 더욱 폭넓게 확보할 수 있도록 도와주는 것을 목표로 하고 있습니다.
Play에서 승인한 배포 채널을 통해 획득한 애플리케이션에 대해 기기가 오프라인 상태에 있더라도 앱의 출처를 확인할 수 있도록 지원할 예정입니다. 또한, 기기가 온라인 상태로 복귀했을 때 해당 애플리케이션을 사용자의 Play 라이브러리에 추가하여, Play를 통해 해당 애플리케이션의 업데이트를 받을 수 있도록 할 예정입니다.
즉, Play에서 공인한 오프라인 배포 채널이 제공되는 셈이므로 개발자에게 도움이 될 뿐 아니라, P2P로 배포된 앱들도 Play를 통해 앱 업데이트를 받을 수 있게 되므로 사용자들에게도 도움이 됩니다.
이를 위해 개발자나 사용자들이 따로 해야 할 일은 없습니다. Google Play에서 지원하는 최대 APK 크기 또한 APK Signing Block에 삽입되는 소량의 메타데이터를 감안하여 조정되고 있습니다. Google Play의 모바일 앱 생태계의 무결성 개선과 더불어, 이 메타데이터는 개발자에게 새로운 배포 채널을 제공할 뿐 아니라 더 많은 사람들이 앱을 최신 상태로 유지할 수 있도록 지원할 것입니다.
이 블로그 게시물이 얼마나 유용했는지 알려주세요.
★ ★ ★ ★ ★

Android P에서 SDK 지원 버전 업데이트에 대해 안내드립니다

2018년 7월 4일 수요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 정승욱(Android GDE)님이 참여해 주셨습니다>
게시자: David Brazdil 및 Nicolas Geoffray, 소프트웨어 엔지니어
Android에서 사용자와 개발자에게 최상의 환경을 제공하는 데 큰 관심을 두고 있습니다. 개발자는 각 OS 릴리스에서 새로운 기능을 사용하여 사용자를 위해 놀라운 사용 환경을 제공할 수 있지만, 우리는 일부 앱 개발자가 SDK에서 지원되지 않는 인터페이스를 사용하는 바람에 사용자가 앱을 사용하다가 장애를 겪고 개발자가 문제를 수습하려고 급하게 새로운 버전을 내놔야 하는 사례가 증가하고 있다는 점을 알아차렸습니다. 우리는 더 나은 결과를 원하며 새로운 OS가 나올 때마다 Android가 안정적으로 작동하도록 하기 위해 개발자 여러분의 도움이 필요합니다.
석 달 전에 Android P에서 SDK에서 지원되지 않는 인터페이스의 사용을 제한하기 시작하겠다는 계획을 발표했습니다. 우리는 이러한 제한이 개발자의 출시 워크플로에 영향을 줄 수 있다는 점을 잘 알고 있으며, SDK에서 지원되지 않는 인터페이스의 사용을 감지하는 도구뿐 아니라 새로운 정책에 맞춰 조정하고 피드백을 보낼 시간을 확보할 수 있기를 원합니다.
Developer Preview와 베타 1에서 우리는 이러한 제한이 앱에 미치는 영향을 확인할 수 있는 방법을 제시했습니다. Developer Preview에서는 제한된 API를 사용할 경우 로그와 알림 메시지에 그 사실이 나타나고 베타 1에서는 이러한 제한을 프로그래밍 방식으로 찾아서 자체 로그 기록을 수행할 수 있게 해주는 StrictMode 정책을 제공했습니다. 예를 들면 다음과 같습니다.

우리는 SDK에서 지원되지 않는 인터페이스를 앱에 사용하려는 다양한 이유가 있을 수 있다는 점을 이해하며, 우리에겐 여러분의 앱이 Android P에서 계속 올바로 작동하도록 하는 것이 중요합니다. 많은 개발자께서 Issue Tracker를 통해 다양한 사용 사례를 설명해 주셨는데, 정말 고맙습니다. 이러한 요청 중 대부분의 경우, 우리는 Android P에 대해 SDK에서 지원되지 않는 특정 인터페이스를 그레이리스트에 추가하여 이러한 인터페이스에 대한 제한을 해제했습니다. 또한 우리 팀은 수백만의 앱에 대한 정적 분석을 수행하고 내부 및 외부 베타 테스터가 보내온 수천 개의 자동 보고서를 처리했습니다. 이 분석을 통해 SDK에서 지원되지 않지만 앱이 의존하는 인터페이스를 추가로 파악하여 그레이리스트에 추가했습니다. 그레이리스트에 오른 모든 인터페이스에 대해 공개 SDK 대안을 조사하여 향후 출시에 반영토록 하겠습니다. 하지만 SDK에서 지원되지 않는 인터페이스의 일부 사용 사례를 미처 파악하지 못했을 수도 있으므로, 대상 SDK가 Android Oreo 또는 이전 버전인 앱에서는 해당 인터페이스 대다수를 사용할 수 있도록 했습니다.
요컨대, Android P에서 작동하는 앱에 대해서는 SDK에서 지원되지 않는 인터페이스의 사용에 제한이 따를 것입니다. Android P를 타겟으로 하고 있는 개발자는 그레이리스트에서 SDK에서 지원되지는 않지만 계속 사용할 수 있는 인터페이스를 확인할 수 있으며, 이에 해당되지 않는 비 SDK 인터페이스에는 액세스할 수 없을 것입니다. Android Oreo 또는 이전 버전을 타겟으로 하는 경우에는 대부분의 제한 사항이 적용되지 않겠지만, 그레이리스트에 없는 비 SDK 인터페이스에 액세스할 경우 logcat 경고를 받게 됩니다. 참고로, 사용자에게는 이러한 경고가 표시되지 않습니다. 새롭게 선보이는 베타 2 릴리스를 사용해보시고 StrictMode를 통해 비 SDK 인터페이스 사용 여부를 확인하세요. 베타 2에서 비 SDK 인터페이스 사용을 제한하기 위해 구현한 내용은 최종 릴리스에서 구현할 내용과 거의 일치할 것이라 보셔도 됩니다. 새로 작성한 FAQ도 살펴보시기 바랍니다. 기능과 관련한 어떤 의문점이든 FAQ를 통해 해결하실 수 있길 바랍니다. 혹시 그래도 해결할 수 없는 문제가 있다면 저희에게 알려주세요!

Chrome 68 베타: 홈 스크린에 추가, 페이먼트 핸들러, 라이프 사이클 주기

2018년 6월 27일 수요일

.post-body span { white-space: normal !important; } <블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 문현경(Webtech GDE)님이 참여해 주셨습니다> 별도의 언급이 없는 한, 아래에 기술된 변경 사항은 Android, Chrome OS, Linux, macOS, Windows용 최신 Chrome 베타 채널 릴리스에 적용됩니다. ChromeStatus.com에서 Chrome 68의 전체 기능 목록을 확인하실 수 있습니다. Chrome 68은 2018년 6월 27일 현재 베타 버전입니다.

프로그레시브 웹 앱의 '홈 스크린에 추가' 동작에 새로운 기능 '홈 스크린에 추가' 프롬프트가 나타나는 방식과 시점에 대한 통제권을 더 많이 가졌으면 한다는 개발자들의 의견을 자주 들었습니다. Android에서는 Chrome 68부터 이 프롬프트가 나타나는 시점에 관한 제어권을 개발자에게 더 많이 제공하는 방향으로 바뀝니다. 개발자는 이제 '홈 스크린에 추가' 동작에 대한 컨텍스트를 추가로 제공함으로써 클릭률을 높일 수 있습니다.

홈 스크린에 추가 대화상자
'홈 스크린에 추가' 기준을 충족하는 사이트의 경우 Chrome에서 beforeinstallprompt 이벤트를 발생시켜 '홈 스크린에 추가' 배너를 더 이상 자동으로 표시하지 않습니다. 대신에 해당 이벤트 발생 시 개발자가 이벤트를 저장하고 앱에 설치 가능함을 나타내는 버튼이나 다른 UI 요소를 추가할 수 있습니다. 사용자가 설치 버튼을 클릭할 때 개발자가 저장된 beforeinstallprompt 이벤트에서 prompt()를 호출하여 새로운 '홈 스크린에 추가' 모달 대화상자를 표시할 수 있습니다. beforeinstallprompt 이벤트는 사용자 동작이 없더라도 시작될 수 있지만, prompt()의 경우 사용자 동작이 필요합니다.
let installPromptEvent;

window.addEventListener('beforeinstallprompt', (event) => {
// Prevent Chrome <= 67 from automatically showing the prompt
event.preventDefault();
// Stash the event so it can be triggered later.
installPromptEvent = event;
// Update UI notify the user they can add to home screen
document.querySelector('#install-button').disabled = false;
});

개발자에게 beforeinstallpromptevent를 처리하고 앱에 설치 버튼을 추가할 시간을 주기 위한 임시 조치로서, 사용자가 '홈 스크린에 추가' 기준을 충족하는 사이트를 처음 방문할 때 Chrome은미니 정보 표시줄을 표시합니다. 일단 미니 정보 표시줄을 해제하고 나면 충분한 시간(현재는 3개월)이 경과해야 이 표시줄이 다시 표시됩니다.

홈 스크린에 추가 미니 정보 표시줄
이 새로운 UI 요소에 대한 자세한 내용, 코드 샘플 및 스크린샷은 홈 스크린에 추가 동작 변경 사항을 참조하세요.

Payment Handler API Payment Request API 덕분에 완벽한 네이티브 브라우저 UI를 사용자가 기본 설정한 결제 및 배송 주소 양식과 결합하여 웹 환경에서 더욱 간단하고 빠르게 온라인으로 체크아웃할 수 있게 되었습니다.
이제 막 출시된 Payment Handler API는 웹 기반 결제 앱을 사용하여 Payment Request 환경 내에서 바로 간편하게 결제할 수 있도록 함으로써 Payment Request의 적용 범위를 넓혀줍니다.
const request = new PaymentRequest([{
// Your custom payment method identifier comes here
supportedMethods: 'https://bobpay.xyz/pay'
}], {
total: {
label: 'total',
amount: { value: '10', currency: 'USD' }
}
});

Payment Request API를 통한 결제. "Pay with BobPay"는 Payment Handler API로 빌드한 맞춤 결제 방법입니다.

사용자가 원치 않는 대상으로 이동하지 않도록 보호 이번 Chrome 버전에서 우리는 사용자 환경 개선을 위해 몇몇 사용자 인터페이스 동작을 변경하고 있습니다.

교차 출처(cross-origin) iframe에서 리디렉션하려면 사용자 동작 필요 sandbox 속성으로 금지하지 않는 한, iframe에 삽입된 콘텐츠는 일반적으로 최상위 검색 컨텍스트를 다른 웹사이트로 안내할 수 있습니다. 이 기능은 SSO(Single-Sign-On) 제공업체와 결제 처리업체를 포함한 많은 유형의 웹사이트에서 사용됩니다. 안타깝게도, 이 동작은 사용자에게 알리지 않거나 사용자 동의 없이 사용자가 원치 않는 대상으로 사용자를 리디렉션하는 수단으로 흔히 악용되기도 합니다.
Chrome 68부터는 iframe에 삽입되는 콘텐츠가 최상위 검색 컨텍스트를 다른 출처로 안내하려면 사용자 동작이 필요합니다. 팝업 차단과 마찬가지로, 이 보호 기능이 트리거되면 사용자가 리디렉션을 허용해야 계속 진행할 수 있는 옵션을 제공하는 Chrome UI가 표시됩니다.
이 동작을 설명해주는 데모가 있습니다. 이 링크 이면에 나오는 데모는 Chrome 67 및 이전 버전에서의 기존 동작을 보여줍니다. 개선된 동작은 Chrome 68에서 작동합니다.

탭 언더 네비게이션 차단 페이지에서 어떤 대상으로 연결되는 팝업이 열리는 동시에 이 오프너 페이지를 타사 콘텐츠로 안내할 때 이를 탭 언더(tab-under)라고 합니다. 이 동작은 보통 사용자를 바라는 대상으로 보내는 동시에 원치 않는 대상을 포함한 또 다른 탭을 만드는 데 사용됩니다. 팝업과 마찬가지로, Chrome에서는 이처럼 원치 않는 네비게이션을 방지하고 그 대신에 사용자가 이 리디렉션을 따라 새로운 방향으로 이동할지 선택할 수 있도록 네이티브 UI를 사용자에게 보여줍니다.

Page Lifecycle API 애플리케이션 수명 주기는 첨단 운영체제에서 리소스를 관리하는 핵심적인 방식입니다. Android, iOS 그리고 최근에는 Windows에서도 플랫폼에서 언제든 앱을 시작하고 중지할 수 있습니다. 따라서 이러한 플랫폼에서는 리소스를 능률적으로 사용하고 사용자에게 가장 이롭게 재할당할 수 있습니다.
웹에서는 지금까지 이러한 수명 주기의 개념이 적용된 적이 없었기에, 앱이 무기한으로 활성 상태로 유지될 수 있습니다. 그래서 다수의 웹 앱과 탭을 실행하다 보면 메모리, CPU, 배터리, 네트워크 같은 중요한 리소스가 초과 구독될 수 있고 이럴 경우 최종 사용자 환경이 나빠지게 됩니다.
Chrome 68에서는 개발자가 새로운 freeze 및 resume 이벤트를 사용하여 백그라운드에서 실행 중인 탭에 대해 시스템이 시작하는 CPU 일시 중단을 수신하고 이에 대응할 수 있습니다. 메모리 보존을 위해 고정된 페이지를 삭제할 필요가 있는 경우, 이제는 document.wasDiscarded 속성을 사용할 수 있으므로 개발자는 사용자가 탭을 다시 포커스하고 페이지를 새로 고칠 때 (freeze 이벤트에 저장된) 뷰 상태를 복원할 수 있습니다. 자체 애플리케이션에서 이런 이벤트를 테스트하려는 개발자는 chrome://discards를 방문하여 페이지 고정, 다시 시작 및 삭제를 시뮬레이션할 수 있습니다.
Page Lifecycle API에 대한 자세한 내용은 사양 또는 GitHub의 설명자를 참조하세요.

이번 릴리스에 포함된 기타 기능 CSS 오버플로 약칭에서 두 개의 값 허용 overflow 약칭은 두 개의 값을 허용하여 수평 및 수직 오버플로를 서로 다른 값으로 설정할 수 있게 합니다. 두 개의 값이 지정되어 있는 경우 첫 번째 값은 overflow-x이고 두 번째 값은 overflow-y입니다. 개발자는 약칭을 변경하여 이전에는 두 개의 명령문이 필요했던 경우에 한 개의 명령문만 지정할 수 있습니다. 세 부분을 포함하는 CSS 위치 값 object-position 및 perspective-origin 속성은 "top right 20%"처럼 세 부분을 포함한 값을 더 이상 허용하지 않습니다. 이는 기본적인 형태와 그라데이션에서 위치에도 적용됩니다. 이제 유효한 위치 값은 항상 1개, 2개 또는 4개의 부분을 가질 것입니다. 3개의 부분으로 이루어진 값은 Chrome 66에서 지원이 중단되었습니다. 해상도 단위로 'x' 지원 CSS 값 및 단위 모듈 레벨 4에서 고해상도 디스플레이 지원을 위해 '픽셀당 도트 수(dot per pixel)'라는 새로운 해상도 단위를 정의합니다. 이러한 변화로 인해 기존 약어 'dppx'에 대한 동의어로서 'x'가 추가됩니다. 커서 속성에 대한 CSS 'grab' 및 'grabbing' 값의 접두사 제거 CSS 값 'grab'과 'grabbing'은 뭔가를 쥘 수 있거나 현재 쥐고 있음을 나타내는 데 흔히 사용되는 편 손 또는 쥔 손 모양으로 마우스 커서를 변경합니다. 이러한 속성의 접두사가 추가된 버전은 Chrome 1 이후로 계속 지원되었습니다. 이번 버전부터는 이러한 값에서 접두사를 제거한 버전을 Chrome에서 기본으로 지원합니다.
게임패드 게임패드용 고해상도 타임스탬프 Gamepad.timestamp는 이제 마이크로초 단위의 해상도를 가진 고해상도 단조 시간인 DOMHighResTimeStamp를 사용합니다. 타임스탬프는 PerformanceTiming.navigationStart 속성에서 오프셋으로 측정됩니다.
맞춤 요소 새로운 customElements.upgrade() 이 함수는 생성자가 아직 명시적으로 호출되지 않은 맞춤 요소를 위한 맞춤 요소 생성자를 호출합니다. 맞춤 요소가 innerHTML setter를 이용해 생성되고 그 상위 노드가 문서에 연결되지 않은 경우에는 연결될 때까지 맞춤 요소 생성자가 호출되지 않습니다. 이 메서드는 연결 여부에 상관없이 맞춤 요소 생성자 호출의 타이밍을 개발자가 완벽하게 제어할 수 있도록 명시적으로 허용합니다.
입력 키보드 잠금 전체 화면에서 이 API를 통해 앱이 일반적으로 Cmd-Tab/Alt-Tab 또는 Esc와 같이 시스템이나 브라우저에서 처리하는 키를 받을 수 있습니다. 사용자는 Esc 키를 2초간 눌러 키보드 잠금과 전체 화면에서 빠져나갈 수 있습니다. PointerEvent.fromElement 및 PointerEvent.toElement를 null로 만들기 다른 브라우저와의 일관성을 향상하기 위해 fromElement 및 toElement 필드를 위한 PointerEvents는 항상 null을 보고함으로써 Pointer Events Level 2 사양을 따르지 않습니다. (PointerEvent가 이들 필드를 상속하는) MouseEvent에서는 fromElement와 toElement가 기본 필드가 아니므로 오랫동안 주요 브라우저 간에 일관성이 없었습니다. 게다가 target과 relatedTarget이라는 일관된 대체 필드가 이미 기본으로 제공됩니다. 통합 터치 조정 터치 조정은 TouchEvent와 그에 상응하는 PointerEvent 대상을 터치 영역 내에서 최상의 대상으로 변경합니다. TouchEvent 좌표는 바뀌지 않습니다. 길게 누르는 동작을 사용자 동작으로 처리 길게 누르는 동작은 사용자와 페이지 간의 상호 작용을 나타내므로 이제는 사용자 동작으로 간주됩니다. 이에 따라 웹 앱은 길게 누르는 동작이 이루어질 때 navigator.vibrate()처럼 제한된 API를 호출하여 네이티브 동작에 일치시킬 수 있습니다.
미디어 WebAudio: AudioParams에 대해 사용자가 선택할 수 있는 자동화 비율 추가 사용자는 AudioParam.automationRate 속성을 사용하여 AudioParam이 'a-rate'인지 'k-rate'인지 선택할 수 있습니다. 전부는 아니지만 대부분의 AudioParam 속성을 통해 사양에 주어진 것처럼 비율을 변경할 수 있습니다. 예를 들어 기본 'a-rate' 자동화를 사용하는 BiquadFilterNode는 매개변수와 필터 계수 사이의 관계가 복잡하므로 계산 비용이 많이 듭니다. 이처럼 빠른 자동화가 필요하지 않을 경우(대부분의 일반적인 경우가 이에 해당), 매개변수를 'k-rate'로 설정할 수 있습니다.
ServiceWorker 서비스 워커 스크립트를 위한 캐시 관리 개선 서비스 워커에 대한 업데이트 요청 시 HTTP 캐시는 무시됩니다. importScripts 요청은 계속 HTTP 캐시를 거칩니다. 하지만 이는 단지 기본 설정일 뿐입니다. 이 동작을 제어할 수 있는 ServiceWorkerRegistration.updateViaCache라는 새로운 등록 옵션을 사용할 수 있습니다. 이전에는 서비스 워커에 대한 업데이트가 있는지 확인하는 HTTP 요청을 기본적으로 HTTP 캐시가 수행했습니다. 서비스 워커에서 Cache-Control 헤더를 무심코 설정한 경우에는 서비스 워커 업데이트를 지연할 수 있었으며, 서비스 워커에 사이트의 다른 자산에 대한 버전 관리 정보가 포함된 경우 해당 업데이트 역시 지연되었습니다.
WebRTC RTCRtpSender.getParameters()/setParameters()가 트랙 인코딩 반환 및 제어 getParameters() 및 setParameters() 메서드는 RTCRtpSender.track 속성이 인코딩되어 원격 RTCRtpReceiver로 전송되는 방식에 대한 RTCRtpSender 객체의 현재 매개변수를 반환하거나 업데이트합니다. 이러한 메서드를 사용하면 SDP 개조 또는 재협상을 전혀 수행하지 않고도 최대 전송 비트 전송률과 같은 WebRTC 스트림의 인코딩 매개변수를 변경할 수 있습니다.

지원 중단 및 상호 운용성 개선 사항 Chrome에서는 가끔 다른 브라우저와의 상호 운용성 증대를 위해 지원 중단, 삭제 또는 변경되는 기능이 있습니다. 이번 Chrome 버전에도 다음과 같이 변경되는 사항이 있습니다. 필터에서 음의 밝기 값 지원 중단 및 삭제 사양을 준수하기 위해 필터의 brightness() 함수는 더 이상 음수 값을 허용하지 않습니다. document.createTouch 삭제 Chrome 48 이후로 Touch() 생성자가 지원되었으므로 document.createTouch() 메서드가 삭제됩니다. Document.selectedStylesheetSet 및 Document.preferredStylesheetSet 삭제 Document.selectedStylesheetSet 및 Document.preferredStylesheetSet 속성은 Chrome과 WebKit에서만 구현되고 기본 속성이 아니므로 삭제됩니다. 이들 속성의 기본 버전은 2016년에 사양에서 삭제되었습니다. WEBGL_compressed_texture_atc 이전에는 Chrome에서 AMD_compressed_ATC_texture 형식을 제공했습니다. 하드웨어 지원이 거의 제로화되는 수준으로 줄었으므로 WebGL Working Group에서 확장을 거부했습니다. 이에 따라 해당 지원 기능이 삭제되었습니다.