Google for Developers Korea Blog: 안드로이드에서 더욱 똑똑한 애니메이션 만들기

안드로이드에서 더욱 똑똑한 애니메이션 만들기

2019년 9월 16일 월요일

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

<블로그 원문은 이곳에서 확인하실 수 있으며 블로그 번역 리뷰는 양찬석(Google)님이 참여해 주셨습니다>이전 Google I/O에서 반응형 아키텍처 상에서 애니메이션을 잘 구현할 수 있는 기법을 몇 가지 말씀드렸습니다.

tl;dw? 이 32분짜리 동영상을 시청할 마음이 없는 분도 계실 것이므로, 프레젠테이션에서 다룬 주제를 글로 적어 소개해 드립니다. ☕️ #AnimationsMatter 애니메이션은 앱의 사용성에 중요한 역할을 한다고 생각합니다. 애니메이션으로 상태 변화나 전환을 설명하거나, 공간 모델을 확립하거나, 주의를 끌 수 있기 때문입니다. 애니메이션은 사용자가 앱을 올바로 이해하고 원하는 화면으로 이동하는 데 도움이 됩니다. 앱에서의 애니메이션 흐름

앱에서의 애니메이션 흐름

👈 애니메이션이 있는 경우와 없는 경우 👉 위 예제는 애니메이션 여부를 제외하고는 동일한 사용 흐름입니다. 애니메이션이 없으면 무엇이 바뀌었는지에 대한 설명 없이 상태가 갑자기 바뀐다는 느낌이 듭니다.
애니메이션이 중요하다고는 생각하지만, 현대 앱의 아키텍처 방식이 변화함에 따라 애니메이션을 구현하기 더 어려워지고 있다는 생각도 듭니다. 뷰 계층 밖에 있는 대부분의 상태 관리를 (ViewModel과 같은) 컨트롤러로 이동하고 있는데, 이런 컨트롤러는 뷰를 렌더링하는 데 필요한 앱의 현재 상태를 캡슐화하는 상태 객체(예: UiModel)를 게시합니다. 예를 들어 네트워크 요청이나 사용자가 시작한 작업이 완료될 때처럼, 데이터 모델에서 뭔가가 바뀔 때마다 업데이트된 전체 상태를 캡슐화하는 새 UI 모델을 게시합니다. 상태 객체의 스트림을 게시하는 ViewModel

상태 객체의 스트림을 게시하는 ViewModel

상태 객체의 스트림을 게시하는 ViewModel
오늘은 이 패턴이나 그 이점에 초점을 맞추고 싶지 않습니다.이 주제에 관해서는 훌륭한 자료가 많이 있습니다. 단방향 데이터 흐름이나 MVI를 찾아보거나 MvRx 또는 Mobius와 같은 라이브러리를 찾아보세요. 반대로 뷰가 모델 스트림을 관찰하고, UI에 바인딩하는 스트림의 다른 쪽 끝 부분에 초점을 맞추고 싶습니다. 이 부분은 UI에 완전히 바인딩되는 어떤 새로운 상태가 주어지는 순수한 함수 같은 것입니다. UI의 현재 상태에 대해서는 생각하고 싶지 않습니다. 즉, UI에 대한 데이터 바인딩이 상태 비추적(Stateless) 이어야 합니다. 하지만 애니메이션은 상태 저장(Stateful)입니다. 애니메이션은 시간의 경과에 따라 하나의 값에서 다른 값으로 이동하는 것입니다. 이 점에서 본질적이 상충이 있습니다. 요즘 이런 이유로 많은 앱에서 애니메이션이 제거되어 실제로 사용성의 손실로 이어지고 있다는 점이 걱정스럽습니다.
무엇이 문제일까요? 우리가 이런 반응형 환경에서 애니메이션을 유지할 방법과 해결해야 할 과제를 구체적으로 파악하기 위해 살펴볼 수 있는 아주 작은 본보기가 있는데, 바로 로그인 화면입니다. 로그인 버튼과 진행률 표시기가 페이드 인/페이드 아웃 방식으로 나타나거나 사라지는 로그인 화면

로그인 버튼과 진행률 표시기가 페이드 인/페이드 아웃 방식으로 나타나거나 사라지는 로그인 화면

로그인 버튼과 진행률 표시기가 페이드 인/페이드 아웃 방식으로 나타나거나 사라지는 로그인 화면

사용자가 로그인 버튼을 누르면 로그인 버튼을 숨기고 진행률 표시기를 표시하고 싶지만, 이때 로그인 버튼을 페이드 아웃하고 진행률 표시기를 페이드 인하는 방식으로 처리하고 싶다고 해봅시다. 이 화면과 (정적) 바인딩 로직에 대한 상태 객체는 다음과 같은 모습일 수 있습니다.

이런 변화를 애니메이션 으로 표현하고 싶을 경우 최초의 시도는 다음과 같은 모습일 수 있으며, 여기서 알파 속성을 애니메이션하고 마지막으로 페이드 아웃하는 경우 표시 유형 값을 설정합니다.

하지만 이는 다음과 같이 예기치 않은 결과로 이어질 수 있습니다.
반응형 앱에 애니메이션을 추가할 때 발생할 수 있는 문제

반응형 앱에 애니메이션을 추가할 때 발생할 수 있는 문제

반응형 앱에 애니메이션을 추가할 때 발생할 수 있는 문제
여기서는 키를 누를 때마다 새로운 UI 모델이 게시되지만, 예상과는 달리 진행률 표시기가 계속 표시되는 것을 볼 수 있습니다! 또는 (데모를 위해 애니메이션 지속 시간을 과하게 늘린 상태에서) 제출 버튼을 누르면 결국 버튼과 진행률 표시기가 둘 다 사라져버리는 잘못된 상태로 이어질 수 있습니다. 이는 애니메이션에 올바로 처리되지 않는 종료 리스너와 같은 역효과가 있기 때문입니다.
이 반응형 환경에서 애니메이션을 작성할 때 애니메이션 코드에 필요한 몇 가지 특성이 있습니다. 이런 특성을 다음과 같이 분류해봤습니다.

재진입

연속

매끄러움

재진입 재진입은 애니메이션을 언제든지 중단했다가 다시 호출할 수 있어야 한다는 의미입니다. 새로운 상태 객체가 게시되는 경우, 애니메이션이 실행 중인 동안에도 새로운 상태에 맞는 애니메이션이 바인딩될 수 있도록 애니메이션을 준비해야 합니다. 이를 위해서는 실행 중인 애니메이션을 취소 또는 다시 타게팅할 수 있거나, 잠재적인 역효과(예: 리스너)를 모두 없앨 수 있어야 합니다.
연속 연속성은 애니메이션되는 값에 갑작스러운 변화가 생기지 않도록 하는 것입니다.이 속성을 입증하려면 누르거나 놓을 때 크기와 색상에 애니메이션 효과를 주는 뷰를 고려하세요. 누를 때 크기와 색상에 애니메이션 효과 부여

누를 때 크기와 색상에 애니메이션 효과 부여

누를 때 크기와 색상에 애니메이션 효과 부여
애니메이션을 끝까지 실행하면 모든 모습이 보기 좋지만, 그러지 않고 빠르게 탭하면 애니메이션의 크기와 색상이 불연속적으로 변합니다. 이는 바인딩 코드에서 가정을 한 결과입니다(예: 페이드 애니메이션은 항상 0 알파에서 시작하는 것으로 가정함).
매끄러움 이 속성을 이해하려면 다음과 같이 뷰가 어떤 이벤트에 대한 반응으로 상단 왼쪽이나 오른쪽으로 움직이는 예를 생각해보세요. 더듬거리는 애니메이션

더듬거리는 애니메이션

더듬거리는 애니메이션
뷰를 상단 오른쪽으로 두 차례 연속으로 빠르게 보내는 경우 뷰가 중간에서 멈춘 후에 목적지를 향해 계속 천천히 움직입니다. 이동 중간에 목적지를 바꾸면 뷰가 다시 멈추었다가 갑자기 방향을 바꿉니다. 이런 종류의 갑작스러운 정지나 방향 변화는 부자연스러워 보입니다. 현실 세계에서는 이런 식으로 움직이지 않기 때문입니다. 따라서 애니메이션을 계속 매끄럽게 유지하려면 이런 종류의 동작을 피하도록 해야 합니다.
Fixme 이제 바인딩 함수로 돌아가서 이런 문제를 수정해 봅시다. 먼저 연속성을 살펴봅시다. 알파 애니메이션은 항상 초기값부터 최종값까지(예: 페이드 인을 위해 0부터 1까지) 실행된다는 점을 알 수 있습니다. 그 대신에 초기값을 생략하고 최종값만 제공할 수 있습니다.

초기값을 생략하면 애니메이터가 현재 값을 읽고 그곳부터 시작합니다.이것이 바로 정확히 우리가 원하는 바로, 애니메이션 처리되는 속성에서 갑작스러운 변화를 방지해 줍니다. 이제는 함수를 재진입 가능하게 만들어 언제든 안심하고 다시 호출할 수 있도록 해봅시다.먼저 수행할 필요가 없는 작업은 어떤 것도 수행하지 않도록 해두면 안심할 수 있을 것입니다. 뷰가 이미 목표 값에 있는 경우에는 일찍 돌아올 수 있습니다.

다음으로, 실행 중인 애니메이터와 리스너를 저장하여 새 애니메이션을 시작하기 전에 이들을 취소할 수 있도록 해야 합니다. 이를 저장할 논리적 위치는 뷰 자체 내에 있지만, View는 이미 이를 수행하기 위한 편리한 메커니즘인ViewPropertyAnimator를 제공합니다. 이 메커니즘은 View.animate()에 대한 호출로 반환되는 객체로, 어떤 속성에 대해 새 애니메이션을 시작할 경우 그 속성에서 현재 실행 중인 모든 애니메이션을 자동으로 취소합니다. 대단하죠! 또한 ViewPropertyAnimator는 애니메이션이 끝까지 정상적으로 실행되는 경우에만 실행되고 애니메이션이 취소되는 경우에는 실행되지 않는 withEndAction 메서드도 제공합니다.이 역시 정확히 우리가 원하는 동작으로, 새로 입력된 목표 값으로 인해 애니메이션이 취소되는 경우 어떤 역효과(예: 표시 유형 변경)도 실행되지 않을 것이라는 뜻입니다. ViewPropertyAnimator로의 전환은 함수를 재진입 가능하게 만듭니다.

ViewPropertyAnimator는 같은 속성에 대해 실행 중인 애니메이션을 취소하고 새 애니메이션을 시작할 것이라 말씀드렸습니다. 이는 부드러움 속성에 위배되고 앞서 본 것처럼 한 애니메이션이 갑자기 멈추고 다른 애니메이션이 시작되는 부자연스러운 애니메이션 문제로 이어질 수 있습니다(거리는 더 짧아지지만 지속 시간은 같음). 이 문제를 해결하기 위해 애니메이션 라이브러리를 살펴볼 수 있는데, 이 라이브러리에 익숙한 개발자가 많지 않다고 생각합니다.
Springterlude 스프링은 ‘동적 애니메이션’ Jetpack 라이브러리의 일부입니다. 많은 사람이 매우 탄력있는 애니메이션 예시를 보면서 이 라이브러리를 그냥 건너뛰었을지도 모른다고 생각합니다. 이 효과를 유용하게 활용할 수도 있지만, 늘 필요하거나 바람직한 것은 아니라서 그럴 겁니다. 하지만 이런 탄력성은 비활성화하고 애니매이션을 중단하고 다시 시작하는 기능 및 일반적인 애니메이션에 유용한 여러 가지 속성을 가진 물리 애니메이션 시스템으로 사용할 수 있습니다.
이전의 예로 다시 돌아가 스프링 애니메이션으로 다시 구현하면 부드러움 문제가 생기지 않는다는 점을 확인할 수 있습니다. 대신에 목적지 변경과 반복되는 시작 문제를 처리하여 현재의 속도를 지킴으로써 부드러운 애니메이션을 생성합니다. 리타게팅 시 속도를 유지하는 스프링 기반 애니메이션

리타게팅 시 속도를 유지하는 스프링 기반 애니메이션

리타게팅 시 속도를 유지하는 스프링 기반 애니메이션
SpringAnimation 작성은 일반적인 애니메이터와 많은 면에서 흡사해 보이는데, start()를 호출하는 게 아니라 animateToFinalPosition 메서드를 사용하는 점이 큰 장점입니다. 이 메서드는 애니메이션이 아직 시작되지 않은 경우 애니메이션을 시작하는 역할을 하지만, 애니메이션이 실행 중인 경우에는 애니메이션을 새 목적지로 리타게팅하여 갑자기 변경하지 않고 모멘텀을 유지한다는 점이 중요합니다.
View.animate처럼 스프링을 사용하기에 편리한 View API가 없다는 점이 아쉽긴 하지만(Jetpack에서만 지원됨), 다음과 같이 확장 함수로 빌드해 사용할 수 있습니다.

이렇게 하면 주어진 ViewProperty(평행이동, 회전 등)에 대한 스프링을 생성하거나 불러와 뷰의 태그에 저장할 수 있습니다.그러면 손쉽게 animateToFinalPosition 메서드를 사용하여 실행 중인 애니메이션을 업데이트할 수 있습니다.다음과 같이 이를 표시 유형 바인딩 함수에 사용합니다.

또한 종료 작업에서 스프링 애니메이션 종료 리스너를 사용하도록 전환해야 합니다. 이 gist에서 이에 대한 전체 코드를 찾을 수 있습니다. 또한 애니메이션을 어느 정도 구성할 수 있었으면 하는 생각도 들 것입니다. 지속 시간과 보간기를 지정하는 일반 애니메이션과는 달리, 스프링은 강성 및 감쇠비 설정을 통해 구성할 수 있습니다. 호출 사이트를 쉽게 구성할 수 있도록 하되, 실용적인 기본값을 제공하기 위해 적절한 매개변수를 허용하도록 확장 함수를 개선할 수 있습니다. 좀 더 완전한 구현에 대한 설명은 여기를 참조하세요.
바인딩 함수가 재진입, 연속성, 매끄러움이라는 특성을 지니도록 만들었습니다.이런 목적을 달성하기 위해 이 모든 바인딩 함수가 관련되어 있는 것처럼 보일 수 있지만, 실제로는 그중 몇 가지만 있으면 애플리케이션 전체에 사용할 수 있습니다. 여기에서 이 스프링 기법을 쉽게 사용할 수 있도록 패키지로 묶은 라이브러리를 찾을 수 있습니다.
Item Animator 이런 종류의 애니메이션을 사용하는 또 다른 예를 살펴봅시다. 이번에는 이런 원리를 RecyclerView.ItemAnimator에 적용해 봅니다. DefaultItemAnimator와 스프링 기반 ItemAnimator

DefaultItemAnimator와 스프링 기반 ItemAnimator

👈 DefaultItemAnimator와 스프링 기반 ItemAnimator 👉
이 예에서는 애니메이션이 셔플 버튼을 사용하여 실행 중인 동안 데이터 세트에 발생하는 업데이트를 시뮬레이션합니다. 버튼을 두 번 연속으로 빠르게 누를 때 스프링 기반 애니메이터의 매끄러움이 큰 차이를 만들어낸다는 점에 주목하세요.왼쪽에서는 상자가 잠시 멈춘 다음에 방향을 바꾸지만,오른쪽에서는 매끄럽게 방향을 바꿉니다. 대부분의 앱이 아마도 네트워크의 많은 소스로부터 정보를 로드하여 RecyclerView에 표시할 것이라 장담합니다.이런 종류의 유연한 애니메이션을 사용하면 애플리케이션의 완성도가 더욱 높아져 훨씬 더 부드러운 사용 환경을 만들어 줄 것입니다. 여기에서 Plaid 샘플에 이런 종류의 애니메이터를 추가하는 PR을 찾을 수 있습니다. 더욱 똑똑한 애니메이션 이 글에서 설명한 원리가 반응형 앱에서 자연스럽게 애니메이션을 적용해 사용성을 개선하는 데 도움이 되기를 바랍니다. 실제로 설명한 원리에는 중요도에 차이가 있습니다.. 애니메이션 요구사항의 계층 구조

애니메이션 요구사항의 계층 구조

@crafty의 애니메이션 요구사항의 계층 구조
재진입은 정확성에 관한 속성입니다. 이 속성이 없으면 애니메이션이 단절될 수 있습니다.ViewPropertyAnimator를 사용하거나 애니메이션 코드에 주의를 기울여 애니메이션이 중단되었다가 다시 호출될 수도 있는 상황을 적절히 처리하세요. 연속성은 갑작스러운 변화나 이동을 방지함으로써 사용자 환경의 개선에 도움이 됩니다.이는 애니메이션 코드에서 섣부른 가정을 피하고 애니메이션 간의 손쉬운 이전을 보장하는 문제입니다. 매끄러움까지 더하면 금상첨화일 것입니다 🎂. 이를 통해 애니메이션이 더욱 자연스럽게 느껴지고 역동적인 변화, 중단, 리타게팅이 가능합니다. 애니메이션이 앱을 더욱더 즐겁고 재미있게 사용할 수 있도록 해 줄 뿐 아니라, 더욱더 쉽게 이해할 수 있도록 해주는 요소라 믿어 의심치 않습니다. 이런 기법을 습득하여 앱에 애니메이션을 훌륭하게 활용하실 수 있기를 바랍니다.