30일 만에 Wear OS 앱 출시 (ft AI) #5

5장. 성능·배터리 최적화

 

이 장의 목표는 “빠르고 오래 가는 워치 앱”을 만드는 것입니다. 작은 화면에서 느림은 바로 이탈로 이어지고, 배터리 소모는 곧 별점 하락으로 연결됩니다. 지금은 완벽한 초최적화보다, 체감 품질을 확 끌어올리는 실전 우선순위를 적용하겠습니다.

성능·배터리 최적화의 3대 원칙

• 적게 그리기: 화면을 덜, 간단히, 필요할 때만 갱신합니다.
• 덜 깨우기: 백그라운드 작업·네트워크·센서를 “이벤트 기반”으로 바꾸고 묶어서 처리합니다.
• 일관성 유지: 앱 본문·타일·컴플리케이션·알림이 하나의 상태를 바라보게 해 중복 갱신을 없앱니다.

권장 목표치(초판 기준 가이드)

• 첫 실행 시간 2초 이내, 재실행 1초 이내
• 진행 화면에서 프레임 드롭 체감 없음(스크롤/애니메이션 최소)
• 일반 사용 30분에 배터리 소모 한 자리수(기능 성격에 따라 3~8%대)
• 진행형 알림/타일/컴플리케이션 갱신은 상태 변화 시에만

화면 렌더링 최적화

• 갱신 범위 줄이기: 상태를 잘게 나누기보다, 화면을 “핵심 수치 + 버튼” 중심으로 단순화합니다. 수치 하나만 바뀌면 그 영역만 갱신되게 설계하세요.
• 과도한 애니메이션 금지: 진행 표시 등 꼭 필요한 변화만, 주기·속도를 낮춰 배터리와 눈 피로를 함께 줄입니다.
• 텍스트와 아이콘: 텍스트 대비를 높이고, 아이콘은 단색·벡터 기반으로 단순화합니다. 이미지는 가능한 캐시하고 크기를 고정합니다.
• 목록/카드: 한 화면에 보여줄 항목 수를 최소화하고, 지연 로딩 없이 “필요한 만큼만” 그립니다.

네트워크·데이터 전략

• 이벤트 기반 전송: 실시간 폴링 대신 사용자 행동 이후 혹은 완료 시점에만 전송합니다.
• 배치 전송: 여러 이벤트를 몇 분 단위로 묶어 전송하면 라디오 웨이크업 횟수가 크게 줄어듭니다.
• 캐시·압축: 응답은 반드시 캐시 키와 만료 정책을 정하고, 압축을 기본값으로 둡니다.
• 오프라인 퍼스트: 핵심 기능은 기기 내에서 완결되게 만들고, 동기화는 충전 중/와이파이 우선으로 지연합니다.

센서·백그라운드 사용

• 필요 순간만 활성화: 센서는 사용 흐름이 시작될 때 켜고, 일시정지나 종료 시 즉시 해제합니다.
• 샘플링 간격 완화: 초단위 혹은 그 이상으로 간격을 넓히고, 화면 갱신은 1초 이하 빈도로 제한합니다.
• 필터·스로틀: 미세한 노이즈는 간단한 평균/스로틀로 누르고, UI에는 “의미 있는 변화”만 반영합니다.
• 스케줄 작업: 주기 작업은 최소화하고, 시스템이 허용하는 유휴 시간대/충전 중에 몰아서 실행합니다.

항상 켜짐(앰비언트) 모드

• 정적 레이아웃: 단색, 저대비가 아닌 고대비의 정적 화면으로 전환합니다.
• 저빈도 갱신: 진행 수치가 꼭 필요한 경우에도 분 단위 등 저갱신 정책을 적용합니다.
• 번인 방지: 화면 요소를 약간씩 이동하거나, 밝기를 낮춰 번인 리스크를 줄입니다.

메모리·ANR 예방

• 메인 스레드 청결: 디스크/네트워크/무거운 계산은 절대 메인에서 돌리지 않습니다. 진행 표시도 가벼운 연산만 허용하세요.
• 객체 수명 단순화: 화면 전환·일시정지 시 리소스를 즉시 해제해 누수를 막습니다.
• 로그 레벨 관리: 반복 로그는 릴리즈에서 제거하거나 샘플링해 I/O 부담을 없앱니다.
• 예외 처리 루틴: 실패 시 재시도 폭주를 막기 위해 지수 백오프를 적용하고, 사용자에게는 짧은 원인+해결 행동만 노출합니다.

배터리 드레인 진단 루틴(짧고 효과적인 방법)

• 기준선 만들기: 기능 비활성 상태로 30분 켜두고 소모율 기록(앱 자체 드레인 파악).
• 단계별 비교: 기능 A만 켠 빌드, A+B 켠 빌드로 나눠 20~30분 테스트 후 차이를 기록합니다.
• 웨이크업 점검: 알림·타일·컴플리케이션의 갱신 이벤트 수를 하루 단위로 추정해 과다 여부를 판단합니다.
• 체감 테스트: 야외 밝은 환경에서 가독성을 확인하고, 과한 밝기/애니메이션이 없는지 눈으로 점검합니다.

초간단 승수 효과(1시간 투자로 체감 개선)

• 진행 화면의 애니메이션 주기를 낮추거나 정지합니다.
• 네트워크 전송을 “완료 시 1회 + 배치”로 바꿉니다.
• 타일/컴플리케이션 갱신을 “상태 변화 시”로 제한합니다.
• 불필요한 주기 타이머를 제거하고, 사용자 상호작용 후 짧은 타이머만 사용합니다.
• 큰 이미지/폰트 리소스를 한 번만 로드하고 재사용합니다.

자주 보는 함정과 회피법

• 과한 실시간성 집착: 초판에서 초단위 정확도는 비용 대비 이득이 작습니다. 사용성·안정성을 우선하세요.
• 알림 남발: 진행형 알림이 과도하면 차단률이 올라갑니다. 사용자 제어를 제공하고 기본값은 절제합니다.
• 다중 진입로 불일치: 타일·알림·앱 본문 상태가 어긋나면 혼란과 버그를 동시 유발합니다. 단일 상태 소스 원칙을 지키세요.
• 디버그 옵션 방치: 디버그 빌드 플래그가 릴리즈에 남지 않도록 점검합니다.

테스트 시나리오(체크형)

• 첫 실행/재실행 시간 측정(3회 평균)
• 핵심 플로우(시작→진행→정지) 중 프레임 드랍 체감 여부
• 30분 사용 배터리 소모율 비교(오늘 빌드 vs 이전 빌드)
• 오프라인 상태에서의 정상 동작·지연 동기화 확인
• 항상 켜짐 모드에서 가독성·번인 방지 동작 점검
• 강제 종료 후 상태 복원 일관성 확인

요약 포인트

• 덜 그리고 덜 깨우면 체감 성능과 배터리는 함께 좋아집니다.
• 이벤트 기반 갱신, 배치 전송, 오프라인 퍼스트가 워치에서 특히 강력합니다.
• 단일 상태 소스를 유지하면 성능·안정성·유지보수가 모두 쉬워집니다.

오늘의 수행 미션

• 진행 화면 애니메이션을 줄이고, 수치 1개만 갱신되게 화면을 단순화합니다.
• 타일·컴플리케이션·알림 갱신 조건을 “상태 변화 시”로 통일합니다.
• 30분 배터리 소모 기준선을 만들고, 변경 전/후 수치를 기록합니다.
• 네트워크·센서 사용을 이벤트 기반으로 재구성하고, 배치 전송을 적용합니다.

 

앱 이미지