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