무선 네트워크를 사용하여 데이터를 전송하는 것은 앱에서 배터리를 가장 많이 소모하는 원인 중 하나일 수 있습니다. 네트워크 활동과 관련된 배터리 소모를 최소화하려면 연결 모델이 기본 무선 하드웨어에 미치는 영향을 이해해야 합니다.
이 섹션에서는 무선 상태 시스템을 소개하고 앱의 연결 모델이 이 시스템과 상호작용하는 방식을 설명합니다. 그런 다음 앱의 데이터 소비가 배터리에 미치는 영향을 최소화하는 데 도움이 되는 몇 가지 기법을 제공합니다.
무선 통신 상태 시스템
사용자 기기의 무선 전파에는 배터리 전력 소모량을 최소화하는 데 도움이 되는 절전 기능이 내장되어 있습니다. 완전히 활성화된 경우 무선 전파는 상당한 전력을 소모하지만 비활성 상태이거나 대기 상태인 경우 전파는 전력을 거의 소모하지 않습니다.
기억해야 할 중요한 요소는 무선이 대기 상태에서 완전히 활성 상태로 즉시 전환될 수 없다는 것입니다. 무선 전원을 켜는 것과 관련된 지연 시간 기간이 있습니다. 따라서 배터리는 사용하지 않을 때 전력을 절약하기 위해 높은 에너지 상태에서 낮은 에너지 상태로 천천히 전환하는 동시에 무선 '전원 켜기'와 관련된 지연 시간을 최소화하려고 합니다.
일반적인 3G 네트워크 무선 통신의 상태 시스템은 세 가지 에너지 상태로 구성됩니다.
- 최대 전력: 연결이 활성 상태일 때 사용되며 기기가 가능한 최대 속도로 데이터를 전송할 수 있습니다.
- 저전력: 배터리 전력 소비를 약 50% 줄이는 중간 상태입니다.
- 대기: 네트워크 연결이 활성화되지 않은 최소 전력 소비 상태입니다.
낮음 및 대기 상태는 배터리 소모가 훨씬 적지만 네트워크 요청에 상당한 지연 시간이 발생합니다. 낮은 상태에서 최대 전력으로 돌아가는 데는 약 1.5초가 걸리고 대기 상태에서 최대 전력으로 전환하는 데는 2초 이상 걸릴 수 있습니다.
지연 시간을 최소화하기 위해 상태 시스템은 지연을 사용하여 더 낮은 에너지 상태로의 전환을 연기합니다. 그림 1은 AT&T의 일반적인 3G 무선 통신 타이밍을 나타냅니다.
그림 1. 일반적인 3G 무선 통신 상태 시스템
각 기기의 무선 상태 시스템, 특히 관련 전환 지연 ('테일 타임') 및 시작 지연 시간은 사용되는 무선 기술 (3G, LTE, 5G 등)에 따라 달라지며 기기가 작동하는 이동통신사 네트워크에 의해 정의되고 구성됩니다.
이 페이지에서는 AT&T에서 제공한 데이터를 기반으로 일반적인 3G 무선 라디오의 대표적인 상태 머신을 설명합니다. 하지만 일반적인 원칙과 그에 따른 권장사항은 모든 무선 구현에 적용할 수 있습니다.
이 접근 방식은 사용자가 웹을 탐색하는 동안 원치 않는 지연 시간을 방지하므로 일반적인 모바일 웹 탐색에 특히 효과적입니다. 또한 상대적으로 짧은 테일 타임은 브라우징 세션이 완료되면 무선이 더 낮은 에너지 상태로 전환될 수 있도록 합니다.
안타깝게도 이 접근 방식은 Android와 같은 최신 스마트폰 운영체제에서 비효율적인 앱을 만들 수 있습니다. Android에서는 앱이 포그라운드 (지연 시간이 중요함)와 백그라운드 (배터리 수명이 우선시되어야 함)에서 모두 실행되기 때문입니다.
앱이 무선 상태 머신에 미치는 영향
새 네트워크 연결을 만들 때마다 무선이 최대 전력 상태로 전환됩니다. 앞서 설명한 일반적인 3G 무선 상태 머신의 경우 전송 시간 동안 최대 전력 상태를 유지하고, 여기에 5초의 테일 시간이 추가된 후 12초 동안 저에너지 상태를 유지합니다. 따라서 일반적인 3G 기기의 경우 모든 데이터 전송 세션에서 무선이 최소 18초 동안 에너지를 소모합니다.
실제로 이는 1초 데이터 전송을 1분에 3번 실행하는 앱이 무선 전파를 영구적으로 활성 상태로 유지하여 대기 모드로 전환될 때마다 고전력으로 다시 전환한다는 것을 의미합니다.
그림 2. 1분마다 3회 실행되는 1초 전송의 상대적인 무선 전력 사용량입니다. 실행 간의 '전원 켜기' 지연 시간은 수치에서 제외됩니다.
이와 비교하여 동일한 앱이 데이터 전송을 번들로 묶어 1분마다 3초 동안 단일 전송을 실행하는 경우 무선은 1분마다 총 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에 대해 알아봅니다.