무선 라디오를 사용하여 데이터를 전송하는 것은 잠재적으로 앱에서 가장 중요한 배터리 소모 원인 중 하나일 수 있습니다. 네트워크 활동과 관련된 배터리 소모를 최소화하려면 연결 모델이 기본 무선 하드웨어에 미치는 영향을 이해하는 것이 중요합니다.
이 섹션에서는 무선 라디오 상태 시스템을 소개하고 앱의 연결 모델이 앱과 상호작용하는 방법을 설명합니다. 그런 다음 앱의 데이터 소비가 배터리에 미치는 영향을 최소화하는 데 도움이 되는 몇 가지 기법을 제공합니다.
무선 통신 상태 시스템
사용자 기기의 무선 라디오에는 소모되는 배터리 전력의 양을 최소화하는 데 도움이 되는 절전 기능이 내장되어 있습니다. 완전히 활성화되면 무선 라디오는 상당한 전력을 소모하지만 비활성 또는 대기 상태일 때는 전력을 거의 소비하지 않습니다.
기억해야 할 중요한 요인 중 하나는 무선이 대기 모드에서 완전 활성 상태로 즉시 전환될 수 없다는 것입니다. 라디오 '전원 켜기'와 관련된 지연 시간이 있습니다. 따라서 무선 '전원 켜기'와 관련된 지연 시간을 최소화하려고 시도하면서 사용하지 않을 때 전력을 절약하기 위해 배터리가 높은 에너지 상태에서 낮은 에너지 상태로 천천히 전환됩니다.
일반적인 3G 네트워크 무선 통신의 상태 시스템은 세 가지 에너지 상태로 구성됩니다.
- 최대 전력: 연결이 활성 상태일 때 사용되며 기기가 가능한 가장 빠른 속도로 데이터를 전송할 수 있습니다.
- 저전력: 배터리 전력 소모를 약 50% 줄이는 중간 상태입니다.
- 대기: 활성화된 네트워크 연결이 없는 최소 전력 소모 상태입니다.
저전력 및 대기 상태는 배터리를 훨씬 적게 소모하지만 네트워크 요청에 상당한 지연 시간을 초래합니다. 저전력 상태에서 최대 전력으로 돌아가는 데는 약 1.5초가 걸리며 대기 모드에서 전체 전력으로 전환하는 데는 2초 이상 걸릴 수 있습니다.
지연 시간을 최소화하기 위해 상태 시스템은 지연을 사용하여 낮은 에너지 상태로의 전환을 연기합니다. 그림 1은 AT&T의 일반적인 3G 무선 통신 타이밍을 나타냅니다.
그림 1. 일반적인 3G 무선 통신 상태 시스템
각 기기의 무선 상태 시스템, 특히 관련 전환 지연 ('테일 타임') 및 시작 지연 시간은 사용된 무선 라디오 기술 (3G, LTE, 5G 등)에 따라 달라지며 기기가 작동하는 이동통신사 네트워크에서 정의 및 구성합니다.
이 페이지에서는 AT&T에서 제공한 데이터를 기반으로 일반적인 3G 무선 라디오의 대표적인 상태 시스템을 설명합니다. 그러나 일반 원칙과 그에 따른 권장사항은 모든 무선 라디오 구현에 적용됩니다.
이 접근 방식은 사용자가 웹을 탐색하는 동안 원치 않는 지연 시간을 방지하므로 일반적인 모바일 웹 브라우징에 특히 효과적입니다. 테일 타임이 비교적 짧기 때문에 탐색 세션이 완료되면 라디오가 낮은 에너지 상태로 전환될 수 있습니다.
불행히도 이러한 접근 방식은 앱이 포그라운드 (지연 시간이 중요한 경우)와 백그라운드 (배터리 수명이 우선시되어야 함)에서 모두 실행되는 Android와 같은 최신 스마트폰 운영체제에서 비효율적인 앱으로 이어질 수 있습니다.
앱이 무선 상태 머신에 미치는 영향
새 네트워크 연결을 만들 때마다 무선이 최대 전력 상태로 전환됩니다. 앞에서 설명한 일반적인 3G 무선 상태 시스템의 경우 전송 기간 동안 최대 전력으로 유지되며 추가로 5초의 테일 타임이 지속되고, 뒤이어 저에너지 상태에서 12초가 유지됩니다. 따라서 일반적인 3G 기기의 경우 모든 데이터 전송 세션으로 인해 무선 통신은 최소 18초 동안 에너지를 소비합니다.
실제로 이는 1분에 3번 1초의 데이터 전송을 하는 앱이 무선 라디오를 영구적으로 활성 상태로 유지하여 대기 모드로 전환될 때 고전력 상태로 다시 이동시키는 것을 의미합니다.
그림 2. 1분마다 3회 실행되는 1초 전송의 상대 무선 무선 전력 사용량 실행 간의 '파워업' 지연 시간은 그림에서 제외됩니다.
반면 동일한 앱이 데이터 전송을 번들로 묶어 매분 3초의 단일 전송을 실행하는 경우 무선 통신은 분당 총 20초에 해당하는 고전력 상태로 유지됩니다. 이렇게 하면 무선이 매분 40초 동안 대기 상태로 유지되어 배터리 소모가 크게 줄어듭니다.
그림 3. 1분마다 한 번씩 실행되는 3초 전송의 상대 무선 무선 전력 사용량
최적화 기법
이제 네트워크 액세스가 배터리 수명에 미치는 영향을 이해했으므로 빠르고 원활한 사용자 환경을 제공하면서 배터리 소모를 줄이는 데 도움이 되는 몇 가지 방법을 살펴보겠습니다.
번들 데이터 전송
이전 섹션에서 언급했듯이 더 많은 데이터를 적게 전송하도록 데이터 전송을 번들로 묶는 것이 배터리 효율성을 개선하는 가장 좋은 방법 중 하나입니다.
물론 앱이 사용자 작업에 응답하여 즉시 데이터를 수신하거나 전송해야 하는 경우 항상 가능하지는 않습니다. 이 문제를 예상하고 데이터를 미리 가져와 완화할 수 있습니다. 로그 또는 분석을 서버에 전송 및 기타 긴급하지 않은 앱에서 시작된 데이터 전송과 같은 다른 시나리오는 일괄 처리 및 번들링에 매우 적합합니다. 백그라운드 네트워크 전송 예약에 관한 도움말은 앱에서 시작한 작업 최적화를 참고하세요.
데이터 미리 가져오기
데이터 미리 가져오기는 앱이 실행하는 독립적인 데이터 전송 세션 수를 줄이는 또 다른 효과적인 방법입니다. 미리 가져오기를 사용하면 사용자가 앱에서 작업을 실행할 때 앱에서 다음 일련의 사용자 작업에 필요할 가능성이 가장 높은 데이터를 예상하고 단일 연결을 통해 최대 용량으로 한 번에 데이터를 가져옵니다.
전송을 프런트로드하면 데이터를 다운로드하는 데 필요한 무선 활성화 수를 줄일 수 있습니다. 따라서 배터리 수명을 보존할 뿐 아니라 지연 시간을 개선하고 필요한 대역폭을 낮추며 다운로드 시간을 줄일 수 있습니다.
또한 미리 가져오기를 사용하면 작업을 실행하거나 데이터를 보기 전에 다운로드가 완료되기를 기다리면서 발생하는 인앱 지연 시간을 최소화하여 사용자 환경을 개선할 수 있습니다.
다음은 실제 예입니다.
뉴스 리더
많은 뉴스 앱에서는 카테고리가 선택된 후에만 헤드라인을 다운로드하고, 사용자가 읽으려고 할 때만 전체 기사를 다운로드하고, 스크롤하여 볼 때에만 썸네일을 다운로드하여 대역폭을 줄이려고 합니다.
이 접근 방식을 사용하면 대부분의 사용자가 헤드라인을 스크롤하고, 카테고리를 변경하고, 기사를 읽을 때 라디오가 뉴스 읽기 세션 동안 활성 상태로 유지되어야 합니다. 그뿐만 아니라 에너지 상태 간의 지속적인 전환은 카테고리를 전환하거나 기사를 읽을 때 상당한 지연 시간을 초래합니다.
더 나은 방법은 시작 시 적절한 양의 데이터를 미리 가져오는 것입니다. 첫 번째 뉴스 헤드라인과 미리보기 이미지 집합부터 시작하여 지연 시간이 짧은 시작 시간을 보장하고 나머지 헤드라인과 썸네일은 물론 최소한 기본 헤드라인 목록에서 사용할 수 있는 각 기사의 기사 텍스트까지 계속 가져올 수 있습니다.
또 다른 대안은 일반적으로 미리 정해진 일정에 따라 모든 헤드라인, 썸네일, 기사 텍스트, 전체 기사 사진까지 미리 가져오는 것입니다. 이 접근 방식은 사용되지 않는 콘텐츠를 다운로드하는 데 상당한 대역폭과 배터리 수명을 소비할 위험이 있으므로 신중하게 구현해야 합니다.
추가 고려사항
데이터 미리 가져오기는 많은 이점이 있지만 너무 적극적으로 미리 가져오기를 사용하면 사용하지 않는 데이터를 다운로드하여 배터리 소모와 대역폭 사용, 다운로드 할당량이 증가할 위험이 있습니다. 앱이 미리 가져오기가 완료되기를 기다리는 동안 미리 가져오기로 인해 애플리케이션 시작이 지연되지 않도록 하는 것도 중요합니다. 실질적으로 데이터를 점진적으로 처리하거나 애플리케이션 시작에 필요한 데이터가 먼저 다운로드되고 처리되도록 연속 전송을 우선순위로 시작할 수 있습니다.
데이터를 미리 가져오는 정도는 다운로드되는 데이터의 크기와 사용 가능성에 따라 달라집니다. 대략적으로 앞서 설명한 상태 머신에 따르면 현재 사용자 세션 내에서 사용 가능성이 50% 인 데이터의 경우 일반적으로 약 6초(약 1~2MB) 동안 미리 가져올 수 있으며, 이 기간이 지나면 미사용 데이터를 다운로드하는 데 드는 잠재적 비용이 해당 데이터를 다운로드하지 않을 때의 잠재적 절감 효과와 일치하게 됩니다.
일반적으로 2~5분마다 1~5MB 정도의 다른 다운로드를 시작하도록 데이터를 미리 가져오는 것이 좋습니다.
이 원칙에 따라 동영상 파일과 같은 대용량 다운로드는 일정한 간격 (2~5분마다)으로 청크로 다운로드하여 다음 몇 분 내에 볼 수 있는 동영상 데이터만 효과적으로 미리 가져와야 합니다.
한 가지 해결책은 Wi-Fi에 연결되어 있을 때만 그리고 가능하면 기기가 충전될 때만 전체 다운로드가 발생하도록 예약하는 것입니다. WorkManager API는 정확히 이 사용 사례를 지원하므로 기기가 개발자가 지정한 기준을 충족할 때까지(예: 충전, Wi-Fi 연결) 백그라운드 작업을 제한할 수 있습니다.
요청하기 전에 연결 확인
셀 신호 검색은 휴대기기에서 전력을 가장 많이 소모하는 작업 중 하나입니다. 사용자가 시작한 요청에 관한 권장사항은 연결 상태 및 연결 측정 모니터링에 표시된 대로 ConnectivityManager를 사용하여 먼저 연결을 확인하는 것입니다.
네트워크가 없으면 무선 통신 기능이 검색하지 않아도 앱이 배터리를 절약할 수 있습니다. 그러면 연결이 이루어질 때 요청을 다른 요청과 함께 일괄적으로 예약하고 수행할 수 있습니다.
풀 연결
일괄 처리와 미리 가져오기 외에도 유용한 또 다른 전략은 앱의 네트워크 연결을 풀링하는 것입니다.
일반적으로 새 네트워크 연결을 시작하는 것보다 기존 네트워크 연결을 재사용하는 것이 더 효율적입니다. 또한 연결을 재사용하면 네트워크가 정체 및 관련 네트워크 데이터 문제에 더 지능적으로 대응할 수 있습니다.
HttpURLConnection 및 대부분의 HTTP 클라이언트(예: OkHttp)는 기본적으로 연결 풀링을 사용 설정하고 여러 요청에 동일한 연결을 재사용합니다.
요약 및 향후 계획
이 섹션에서는 무선 라디오에 관해 자세히 알아보고 배터리 소모를 줄이면서 빠르고 반응성 높은 사용자 환경을 제공하기 위해 광범위하게 적용할 수 있는 몇 가지 전략을 배웠습니다.
다음 섹션에서는 대부분의 앱에서 공통적인 세 가지 유형의 네트워크 상호작용을 자세히 살펴보겠습니다. 이러한 각 유형의 동인과 이러한 상호작용을 효율적으로 관리하기 위한 최신 기술 및 API에 대해 알아봅니다.