네트워크 액세스 최적화

무선 라디오를 사용하여 데이터를 전송하는 것은 잠재적으로 앱의 가장 중요한 배터리 소모 원인 중 하나입니다. 네트워크 활동과 관련된 배터리 소모를 최소화하려면 연결 모델이 기본 무선 하드웨어에 미치는 영향을 이해하는 것이 중요합니다.

이 섹션에서는 무선 라디오 상태 머신을 소개하고 앱의 연결 모델과 상호작용하는 방법을 설명합니다. 그런 다음 앱의 데이터 소비가 배터리에 미치는 영향을 최소화하는 데 도움이 되는 몇 가지 기법을 제공합니다.

무선 통신 상태 시스템

사용자 기기의 무선 라디오에는 소모되는 배터리 전력의 양을 최소화하는 데 도움이 되는 절전 기능이 내장되어 있습니다. 완전히 활성화되면 무선 라디오는 상당한 전력을 소모하지만 비활성 상태이거나 대기 상태일 때는 무선 통신이 전력을 거의 소비하지 않습니다.

기억해야 할 중요한 요소 중 하나는 무선 통신이 대기 모드에서 완전히 활성화되는 즉시 전환할 수 없다는 것입니다. 무선 '전원 켜기'와 관련된 지연 시간이 있습니다. 따라서 배터리는 무선 '전원 켜기'와 관련된 지연 시간을 최소화하려고 하면서 사용하지 않을 때 전력을 절약하기 위해 높은 에너지 상태에서 낮은 에너지 상태로 천천히 전환됩니다.

일반적인 3G 네트워크 무선 통신의 상태 시스템은 세 가지 에너지 상태로 구성됩니다.

  • 전체 전력: 연결이 활성 상태일 때 사용되며, 기기에서 가능한 최고 속도로 데이터를 전송할 수 있습니다.
  • 저전력: 배터리 전력 소모를 약 50% 줄이는 중간 상태입니다.
  • 대기: 네트워크 연결이 활성화되지 않은 최소 전력 소모 상태입니다.

저전력 및 대기 상태에서는 배터리 소모가 훨씬 적지만 네트워크 요청에 상당한 지연 시간이 발생합니다. 저전력 상태에서 최대 전력으로 복귀하는 데는 약 1.5초가 걸리며, 대기 상태에서 최대 전력으로 전환하는 데 2초 이상 걸릴 수 있습니다.

지연 시간을 최소화하기 위해 상태 시스템은 지연을 사용하여 낮은 에너지 상태로의 전환을 연기합니다. 그림 1은 AT&T의 일반적인 3G 무선 통신 타이밍을 나타냅니다.


그림 1. 일반적인 3G 무선 통신 상태 시스템

각 기기의 무선 상태 머신, 특히 관련 전환 지연 ('테일 타임') 및 시작 지연 시간은 사용되는 무선 무선 기술 (3G, LTE, 5G 등)에 따라 다르며 기기가 작동하는 이동통신사 네트워크에 의해 정의 및 구성됩니다.

이 페이지에서는 AT&T에서 제공한 데이터에 기반하여 일반적인 3G 무선 라디오의 대표적인 상태 시스템에 관해 설명합니다. 그러나 일반 원칙과 그에 따른 권장사항은 모든 무선 라디오 구현에 적용됩니다.

이 접근 방식은 사용자가 웹을 탐색하는 동안 원치 않는 지연 시간을 방지하므로 일반적인 모바일 웹 탐색에 특히 효과적입니다. 상대적으로 낮은 테일 타임은 탐색 세션이 끝나면 무선 통신이 더 낮은 에너지 상태로 이동할 수 있음을 보장합니다.

안타깝게도 이 접근 방식을 사용하면 앱이 포그라운드 (지연 시간이 중요한 경우)와 백그라운드 (배터리 수명에 우선순위가 높은 위치)에서 모두 실행되는 Android와 같은 최신 스마트폰 운영체제에서 앱의 효율성이 떨어질 수 있습니다.

앱이 무선 상태 머신에 미치는 영향

새 네트워크 연결을 만들 때마다 무선 통신이 최대 전력 상태로 전환됩니다. 앞에서 설명한 일반적인 3G 무선 상태 시스템의 경우 전송 시간 동안 최대 전력으로 유지되고 추가로 5초의 테일 시간이 발생한 후 저에너지 상태에서 12초가 소요됩니다. 따라서 일반적인 3G 기기의 경우 모든 데이터 전송 세션은 무선 통신이 최소 18초 동안 에너지를 소비하도록 합니다.

실제로 이는 분당 3회 1초의 데이터 전송을 실행하는 앱이 무선 라디오를 영구적으로 활성 상태로 유지하여 대기 모드로 전환되는 것처럼 고전력으로 다시 이동한다는 것을 의미합니다.


그림 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에 대해서도 배웁니다.