앱 MVP Android 화면 주사율: 요청·스케줄러·실제 표시를 나누는 5가지 기준
앱 MVP Android 화면 주사율: 요청·스케줄러·실제 표시를 나누는 5가지 기준
직접 답변: Android MVP에서 화면 주사율을 다룰 때는 “앱이 어떤 프레임 레이트를 요청했는가”, “Android 스케줄러가 실제로 어떤 표시 모드를 택했는가”, “콘텐츠가 그 표시 조건에서 어떤 프레임을 제출했는가”, “특정 기기에서 무엇을 관찰했는가”를 분리해야 합니다. setFrameRate() 호출이나 설정 화면의 숫자만으로 부드러움·배터리·출시 품질이 확인됐다고 보지 마세요.
Android Developers는 frame rate API가 앱의 의도한 프레임 레이트를 플랫폼에 알리도록 하며 Android 11(API 30) 이상을 대상으로 한다고 설명합니다. 동시에 스케줄러는 여러 요인을 고려하므로 앱이 요청한 프레임 레이트를 받을 보장은 없습니다. 이 글은 특정 기기의 주사율, 영상 품질, 게임 성능, 배터리 사용량 또는 출시 승인을 약속하지 않는 출시 전 점검 가이드입니다.
기준 1: “요청”은 실제 표시 결과가 아니라 플랫폼에 주는 힌트입니다
Surface.setFrameRate()와 관련 API는 surface가 의도하는 프레임 레이트를 Android에 전달합니다. 공식 가이드는 기기가 지원하는 표시 모드를 앱이 미리 고르지 않아도, 앱이 선호하는 정확한 프레임 레이트를 전달할 수 있다고 안내합니다. 더 나은 일치가 없는 기기는 현재 표시 주사율을 유지할 수 있습니다.
따라서 출시 기록에는 “요청한 값”, “요청이 이루어진 surface와 시점”, “앱이 그 값을 선택한 근거”를 남기고, 실제 표시 모드의 변화와 분리하세요. 예를 들어 영상이 24Hz라는 사실과 화면이 어느 모드로 바뀌었는지, 앱이 체감상 더 매끄럽다고 느낀다는 평가는 서로 다른 증거입니다.
기준 2: 시스템의 표시 모드 결정은 앱 밖의 조건에도 좌우됩니다
Android 문서는 더 높은 우선순위 surface, 배터리 절약 모드 같은 조건 때문에 기기가 앱이 지정한 프레임 레이트로 표시를 전환하지 않을 수 있다고 설명합니다. 또한 분할 화면이나 picture-in-picture처럼 여러 surface가 공존하는 상황에서 플랫폼은 호환 가능한 선택을 고려합니다.
분리할 기록 | 확인할 질문 | 완료로 보지 않을 것 |
|---|---|---|
앱 요청 | 어느 surface에 어떤 정확한 값을 전달했는가? | API 호출 코드가 있는 상태 |
시스템 결정 | 표시 변경 알림 또는 기기 관찰에서 무엇이 확인됐는가? | 요청값과 같은 숫자를 기대한 상태 |
콘텐츠 제출 | 영상·애니메이션·렌더 루프는 어떤 시점으로 프레임을 냈는가? | 표시 모드만 바뀐 상태 |
사용자 조건 | 배터리 절약, 다중 창, 다른 앱 surface가 있었는가? | 한 기기의 기본 설정 결과 |
출시 판단 | 대체 조건에서도 핵심 흐름이 정상인가? | 한 번의 시연 성공 |
같은 빌드라도 기기·OS·절전 상태·다른 앱의 surface에 따라 관찰이 달라질 수 있습니다. 시스템이 바꾸지 않은 경우에도 앱이 정상적으로 동작해야 한다는 공식 원칙을 출시 조건에 포함하세요.
기준 3: 콘텐츠 프레임과 디스플레이 주사율을 같은 말로 묶지 않습니다
Android의 frame rate 문서는 24Hz 영상처럼 콘텐츠 프레임 레이트와 표시 주사율이 다를 수 있음을 예로 듭니다. 시스템이 콘텐츠에 맞는 주사율로 전환할 수 있지만, 전환 여부와 방법은 기기 조건에 따라 다릅니다. 영상 source의 프레임과 현재 display refresh rate를 같은 필드에 기록하면 원인 확인이 어려워집니다.
게임에서는 프레임 제출 시점도 별도입니다. Android Frame Pacing 문서는 게임의 로직·렌더 루프와 표시 하드웨어 사이의 동기화를 frame pacing으로 설명하며, 새 프레임이 늦으면 이전 프레임이 다시 표시될 수 있다고 안내합니다. 즉 요청값을 전달한 사실은 렌더 시간, 프레임 제출, 입력 지연, 화면 관찰을 대신하지 않습니다.
기준 4: 값은 정확히 전달하되 매 프레임마다 바꾸지 않습니다
공식 가이드는 앱이 정확한 프레임 레이트를 전달하는 편이 좋다고 설명합니다. 예를 들어 29.97Hz 콘텐츠를 정수 30으로 반올림하지 않는 방식입니다. 반면 setFrameRate()를 매 프레임 또는 초당 여러 번 호출하지 말라고도 안내합니다. 전환이 프레임 드롭을 유발할 수 있기 때문입니다.
따라서 MVP의 최소 기록은 “콘텐츠 또는 렌더링 의도”, “한 번 적용할 surface”, “변경·해제 조건”, “전환이 보일 수 있는 화면”, “관찰 방법”으로 나누는 편이 낫습니다. 멈춘 영상 surface가 계속 보이는 경우 frame rate 설정을 0으로 되돌리는 공식 예외처럼, 화면이 보이는 상태와 실제 사용 상태도 따로 점검하세요.
기준 5: 실제 전환 여부는 알림·실기기·핵심 흐름으로 확인합니다
Android는 DisplayManager.registerDisplayListener() 또는 refresh-rate callback으로 표시 변경을 관찰할 수 있는 경로를 제시합니다. 이는 앱의 요청과 별개로 실제 표시 상태를 확인하는 방법입니다. 단, 콜백 하나만으로 사용자 화면이 항상 같은 품질이었다고 해석하지 말고, 기기·OS·절전 상태·다중 창·콘텐츠 종류·관찰 시점을 함께 남기세요.
영상이라면 시작·일시정지·끝난 뒤의 visible surface 상태를, 애니메이션이라면 진입·스크롤·복귀를, 게임이라면 핵심 입력·로딩·재개를 별도 시나리오로 확인합니다. 릴리스 빌드·테스트 기기·측정 조건 자체를 정리하려면 앱 MVP Android 성능 측정: 릴리스 빌드·기기 조건·결과 해석을 나누는 기준도 함께 참고할 수 있습니다.
출시 전 5분 체크리스트
요청 프레임 레이트와 요청 surface·시점을 별도 기록했는가?
시스템이 실제로 바꾼 표시 상태를 관찰 가능한 경로로 확인했는가?
콘텐츠 프레임, 렌더 제출, 디스플레이 주사율을 같은 지표로 합치지 않았는가?
절전·다중 창·다른 surface처럼 전환이 달라질 수 있는 조건을 남겼는가?
변경되지 않은 상태에서도 핵심 사용자 흐름이 정상인지 실기기에서 확인했는가?
이 체크리스트는 특정 앱의 화면 부드러움, 프레임 수치, 배터리, 기기 호환성, 품질 또는 출시 승인을 보장하지 않습니다. 배포 전에는 현재 Android 공식 문서와 실제 앱의 콘텐츠·렌더링 설계, 지원 기기에서 관찰한 결과를 다시 대조하세요.
자주 묻는 질문
setFrameRate()를 호출하면 원하는 주사율이 항상 적용되나요?
아닙니다. Android 문서는 스케줄러가 여러 요인을 고려하므로 요청한 프레임 레이트가 보장되지 않는다고 설명합니다. 호출 성공과 실제 표시 모드 변경은 별도로 관찰하세요.
기기가 지원하는 주사율 목록을 먼저 골라야 하나요?
그럴 필요는 없습니다. Android 문서는 앱이 선호하는 정확한 프레임 레이트를 전달하고, 더 나은 일치가 없는 기기는 현재 표시 주사율을 유지할 수 있다고 안내합니다.
배터리 절약 모드에서 표시가 달라지면 요청을 바꿔야 하나요?
아닙니다. 공식 문서는 배터리 절약 모드나 더 높은 우선순위의 surface 때문에 시스템이 바꾸지 않을 수 있으며, 앱은 실제 변경이 없을 때도 정상 동작해야 한다고 설명합니다.
프레임 레이트 요청이 곧 끊김 없는 화면을 뜻하나요?
아닙니다. 요청은 플랫폼에 의도를 알리는 신호입니다. 게임이나 영상의 프레임 제출 시점, 콘텐츠 프레임, 실제 디스플레이와 기기 조건은 별도 검증 항목입니다.
내 앱 MVP의 주사율 요청·표시 결과를 분리해 점검하기