안드로이드 앱 성능 최적화 #7 네트워크 성능

이 글은 “안드로이드 앱 성능 최적화” 의 일부 내용만 정리한 것입니다.

자세한 내용은 책을 구매하여 보세요~

7.1. 와이파이와 무선 통신망 신호

인터넷에 연결될 때 성능의 제약을 만드는 두 가지 요소는 “대역폭” 과 “지연시간” 이다.

7.1.1. 와이파이

이상적 환경에서 와이파이의 대역폭은 상당히 좋고, 지연시간도 짧다.

또한 대부분의 경우 사용량에 따라 요금이 부과되지도 않는다.

앱이 와이파이 네트워크 연결을 시도할 때는 최소한의 대기시간만 필요하다.

연결되고 나면 무선신호를 전송하기 위해 높은 전력을 사용한다.

이후 데이터가 다 전송되면 무선신호는 거의 바로 꺼진다.

와이파이 무선신호를 켜고 끄는 데는 최소한의 지연시간만 필요하다. ( 측정시, 켤 때는 80ms, 끌 때는 240ms 정도의 시간이 걸린다. )

전력 프로파일에 따르면 와이파이 접속 대기 시는 3mA 를 사용하고, 데이터 전송 시에는 240mA 를 사용한다.

제한된 전력만 사용할 수 있는 기기의 특성상 데이터 전송을 최대한 짧게 하는 것이 중요하다.

7.1.2. 무선 통신망

GPRS : 다운로드 237 Kbps / 지연시간 300~1,000 ms

EDGE : 다운로드 384 Kbps / 지연시간 300~1,000 ms

UMTS : 다운로드 2,000 Kbps / 지연시간 100~500 ms

HSPA : 다운로드 3,600 Kbps / 지연시간 100~500 ms

3.5G

HSPA+ : 다운로드 42 Mbps / 지연시간 100~500 ms

LTE : 다운로드 100 Mbps / 지연시간 < 100 ms

무선통신망에 연결된 네트워크를 유지할 때 사용하는 전력량은 신호의 세기에 따라서 달라진다.

신호가 약한 지역에서는 전력을 좀 더 사용해 네트워크 연결을 유지하려고 노력한다.

무선망에 연결되면 전류는 4.6mA 에서 125mA 로 크게 높아진다.

전류량만 보면 와이파이의 240mA 보다 125mA 가 적어보인다.

하지만 무선 통신망 연결을 유지하는 방식 때문에 일반적으로 무선 통신망이 와이파이보다 더 많은 전력을 사용하게 된다.

7.1.3. RRC 상태 기계 ( Radio Resource Control )

폰에서 데이터 연결이 시작될 때, TCP 연결이 이루어지기 전에 기지국으로 보내지는 초기 무선신호가 있다.

이 신호들로 무선 접속을 설정하는 시간을 500~1000 ms 더 증가시킨다.

이런 대기와 지연시간은 무선 통신망 RRC 상태 기계가 사용하는 모바일 연결에 매우 중요한 요소이다.

각각의 모바일 네트워크는 신규 연결 시 발생하는 연결 지연을 줄이고 전력 소모를 조절하려고 마지막 데이터 전송 이후에도 무선망 연결을 유지하는 RRC 상태 기계를 갖고 있다.

각각의 망 제공자는 다양한 상태와 그 상태가 유지되는 시간을 지정할 수 있는데, 그래서 망마다 그 값들이 조금씩 다르다.

전 세계의 각 네트워크가 다른 값을 가질 수 있기에 정확한 타이밍을 아는 것이 중요한 것은 아니고 RRC 상태 기계의 기초를 확실히 파악해서 무선 통신망의 연결 작동 방식을 이해하는 것이 중요하다.

이를 이해하면 앱이 RRC 상태 기계와 함께 작동하도록 최적화해서 앱이 더 빠르게 동작하고 더 적은 배터리를 사용하도록 만드는 데 도움이 될 수 있다.

또한 상태 기계는 3세대(GSM, CDMA) 와 LTE 네트워크에 따라서도 다르다.

4G (LTE) 상태 기계

데이터가 전송될 때 폰은 유휴 상태(저전력 소모)에서 접속 상태(고전력 소모)로 변한다.

패킷 전송을 다 마쳐도 무선망이 유휴 상태로 바로 전환되지 않는다.

대신 10~15초 동안 많은 전력이 소모되는 상태를 유지하게 된다.

무선망이 즉시 차단되면 뒤따라 연속적으로 전송되는 데이터 패킷을 처리하기 위해 또 다시 연결 대기 시간이 필요하고 이는 사용자 경험에 나쁜 영향을 주기 때문이다.

무선망에 이미 연결되어 있으니 이어지는 패킷들은 초기 지연시간 없이 빠르게 전달된다.

만약 이 시간 동안 패킷 전송이 이루어지지 않으면 전력 소모를 줄이려고 유휴상태로 전환된다.

4G 네트워크 사양은 크게 개선되었는데, 데이터 접속을 맺기 위한 신호체계가 개선되고 초기 지연시간이 3G 망에서의 1/5 ~ 1/10 정도로 줄었다.

4G 의 대역폭 향상도 인상적이지만 대기시간 개선으로 인해 LTE 는 빠른 속도를 느끼게 해준다.

일반적으로 LTE 는 3G 만 연결했을 때보다 더 많은 전력을 소모한다.

만약 대용량 파일을 다운받는다면 빠른 속도의 LTE 를 사용해 더 빨리 전송을 마치는 것이 결과적으로 더 적은 에너지를 사용한다.

그러나 모바일에서 전송되는 파일 중 대용량 파일은 거의 없고 작은 크기의 파일이 많다.

이런 작은 파일들은 LTE 의 전체 대역폭을 제대로 사용하지 못한다.

그래서 일반적으로 LTE 를 사용해서 다운받을 때에는 3G 보다 더 많은 전력이 소모된다고 얘기한다.

무선 연결(Radio Connection)과 데이터 연결(Data Connection)은 미묘한 차이가 있다.

기지국과 전화 간의 물리적인 무선 접속은 전화와 서버 간의 데이터 연결과 다르다.

데이터 연결은 무선 연결을 통해 이루어지고, 무선 연결이 먼저 이루어져야만 데이터 연결을 할 수 있다.

만약 데이터 연결이 추후 전송을 위해 연결되어 있는 상태에서 데이터 연결이 실제로 진행되지 않고 있다면 배터리 절약을 위해 전화와 기지국 간의 무선 연결이 일시적으로 중지될 수 있다.

서버가 기기로 데이터를 전송하려면 기지국은 기기로 무선 신호를 보내 데이터 연결을 완료할 수 있도록 무선 접속을 다시 진행한다.

무선망 네트워크의 접속 개수 제한으로 고아가 된 연결은 5~30분 정도가 지나면 정리된다.

앱이 RRC 상태 기계와 함께 동작하나요?

RRC 상태 기계의 상태 정보를 보면 네트워크 접속이 기존에 생각했던 것보다 더 많은 전력을 사용하게 된다는 것을 알려준다.

접속을 한번에 몰아서 처리해서 무선이 활성화되는 시간을 줄이면 모바일 앱의 성능을 향상시킬 수 있다.

모든 데이터 연결은 최소 10초의 무선 활성 시간만큼의 전력소모를 발생시킨다.

가능한 빠르게 다운받는 것이 성능에 중요한 영향을 미친다고 여겨졌는데, 사실은 다운로드를 빨리 마치고 되도록이면 무선신호를 자주 사용하지 않는 것이 더 중요한 것이란 것이 분명해졌다.

통화 중 데이터 사용

앱이 LTE 를 통해 데이터를 주고 받고 있는 상태에서 전화가 걸려오면 데이터 연결은 3G 모드로 전환된다.

이것은 서킷 대체 전환 때문이다. ( Circuit Switched Fallback )

Voice over LTE(VoLTE, LTE 망을 통한 통화)가 보편화되기 전까지 모든 음성 통화는 3G 를 통해 전달된다.

모든 데이터 연결이 3G 로 전환된다는 이야기이다.

7.2. 테스트 도구

Wireshark 나 Fiddler 같은 도구가 패킷을 수집하고 문제를 찾고 최적의 방법을 찾기 위한 도구로 사용되어 왔다.

중간자 공격(MITM, Man In The Middle) 도구를 사용하면 HTTPS 를 사용하는 연결도 데이터를 복호화해서 살펴볼 수 있다.

이런 도구들이 모바일 앱 성능 분석의 최전선에 있다.

이와 비슷한 도구로 AT&T 에서 제공하는 ARO( Android Resource Optimizer ) 가 있다.

이는 패킷을 캡처하는 기능에 추가로 휴대폰 데이터를 연결할 때 트래픽을 최적화하는 방법에 대해 여러 개선 방안을 제안하기도 한다.

7.2.1. Wireshark

Wireshark 로 안드로이드 폰을 분석하려면 Wireshark 를 설치한 PC 에 휴대폰을 연결한다.

윈도우즈에서는 Connectify 를 사용하면 노트북에 와이파이 핫스팟을 생성할 수 있다.

안드로이드 기기를 핫스팟에 연결하면 기기의 모든 데이터 트래픽이 컴퓨터를 통과해서 이루어지고 이를 Wireshark 로 살펴 볼 수 있다.

Wireshark 앱에서 무선 인터페이스를 대상으로 캡처를 시작할 수 있다.

7.2.2. Fiddler

Fiddler 는 기기를 통해 들어오는 모든 데이터의 프록시처럼 동작한다.

프록시 역할을 하면서 중간자 공격처럼 HTTPS 트래픽을 복호화해 볼 수 있다.

Wireshark 를 가지고는 HTTPS 패킷이 전송되는 것은 확인할 수 있지만 어떤 내용인지는 알 수 없다.

Fiddler 실행 방법은 Wireshark 와 비슷하다.

Connectify 로 PC 를 와이파이 핫스팟으로 만들고 안드로이드 기기를 연결한다.

그 다음 내 장치의 와이파이 설정에서 Fiddler 프록시를 추가하고 나면 Fiddler 는 이 연결을 사용하는 모든 데이터를 읽을 수 있다.

7.2.3. MITMProxy

MITMProxy 는 Fiddler 와 유사하다.

MITM(Man In The Middle) 을 만들어 네트워크를 통해 전달되는 HTTPS 패킷을 복호화해볼 수 있는 도구이다.

7.2.4. ARO ( AT&T Application Resource Optimizer )

ARO 는 안드로이드와 아이폰 앱의 네트워크 성능 모니터링을 위해 특별히 만들어진 도구이다.

AT&T 에서 제공하는 무료/오픈소스 도구이며, Wireshark 나 Fiddler 와 같은 패킷 캡처 기능의 대부분을 가지고 있다.

Wireshark 나 Fiddler 와는 다르게 ARO 는 무선 통신망을 통해 전달되는 데이터도 캡처가 가능하다.

ARO 는 데이터를 수집하고 나서 개발자에게 친숙한 테이블과 그래프로 데이터를 분석해 보여준다.

트래픽을 25개 모바일 네트워크의 모범 사례에 맞춰 등급을 매기고 성능 향상을 이룰 수 있도록 즉각적인 피드백을 제공한다.

안드로이드 기기용으로 두 가지 버전의 ARO 가 있다.

ARO 데이터 수집기 APK 기기는 TCPdump 를 실행해 모든 패킷을 수집한다.

이 과정을 단순화하려면 루팅된 안드로이드 기기가 필요하다.

루팅이 필요하지 않은 버전도 있다.

루트 권한이 없으면 특정 프로세스로 접속을 할당하는 기능이 동작하지 않아 특정 앱으로 트래픽을 고정하기가 조금 더 어렵다.

ARO 로 데이터를 수집하고 나면 ARO Analyzer 도구로 분석을 시작할 수 있다.

모범 사례들과 문제가 있는 항목들이 구분되어 나오며, 추가적인 정보들을 얻을 수 있다.

Diagnostics(진단) 탭이 앱의 데이터 흐름을 확인 할 수 있는 곳이다.

왼쪽 창에는 분석 내용이, 오른쪽에는 분석과정 중에 찍힌 녹화 화면이 보여진다.

ARO 의 한 가지 단점은 HTTPS 를 통해 전송된 파일의 세부 내용을 확인할 수 없다는 것이다.

앱이 HTTPS 를 사용하는 경우, 수동으로 Fiddler 같은 도구를 사용해 해당 파일을 분석할 수 있다.

7.2.5. 하이브리드 앱과 WebPageTest.org

WebPageTest.org 는 웹사이트를 테스트하는 매우 훌륭한 도구이다.

7.3. 안드로이드를 위한 네트워크 최적화

네트워크 성능 개선의 경향은 가능한 가장 빠르게 모든 걸 다운받게 하는 것이다.

무선 통신에서 재빨리 벗어나 무선망을 빨리 꺼버려야 전력소모를 줄일 수 있다.

"웹 사이트 최적화 기법” 에서 정의한 14가지 성능 규칙은 아래와 같다.

HTTP 요청을 덜 하라.

콘텐츠 전송 네트워크(CDN)을 사용하라

Expires 헤더를 추가하라.

Gzip 으로 압축하라.

스타일 시트는 상단에 넣어라.

스크립트는 하단에 넣어라.

CSS 의 표현식은 피하라.

자바스크립트와 CSS 를 외부로 빼라.

DNS 조회를 줄여라.

자바스크립트를 작게 하라.

리디렉션을 피하라.

중복 스크립트를 제거하라.

ETags 를 설정하라.

AJAX 캐시를 활용하라.

이 중 몇가지는 웹에만 해당되지만 대다수를 안드로이드 앱의 최적화에도 적용할 수 있다.

7.3.1. 파일 최적화

데이터를 빠르게 다운받을 수 있는 가장 기본적인 두 가지 방법은..

요청 횟수를 줄이는 것과 요청 크기를 줄이는 것이다.

텍스트 파일 압축(Gzip 사용하기)

적용하기 가장 쉬운 방법이다.

앱이 텍스트 파일을 주고 받을 때 압축을 하면 파일 크기를 4~8배 줄일 수 있다.

서버와 앱이 주고 받는 파일의 크기가 줄면 왕복 횟수도 줄고 데이터 전송이 더 빨라진다.

보통 기본 Gzip 을 사용하지만, 압축을 최대한 활용하기 위해 노력하고 자주 변경되지 않는 파일들을 많이 전송하는 경우라면 5% 정도 압축률이 더 좋은 Zopfli 알고리즘을 사용해 볼 수 있다.

그러나 파일 압축을 수행하려면 약 100배 시간이 더 걸린다.

Gzip 압축을 사용하려면 앱 변경 없이 서버 설정만 변경해주면 된다.

간단하게 파일 확장자/MIME 타입을 .htaccess 파일에 추가해주면 된다.

파일 크기가 850바이트보다 작은 경우 압축하지 않고도 한 패킷으로 전송할 수 있기 때문에 Gzip 압축/해제에 매우 적은 오버헤드를 가진다고 하더라도 작은 파일은 제외시킬 수 있다.

7.3.2. 텍스트 파일 축소(사우더스의 “자바스크립트를 작게 하라” 항목)

축소는 텍스트의 내용에서 사람이 편하게 읽을 수 있도록 넣어놓은 포매팅 정보를 제거하는 과정이다.

공백, 탭, 주석 같은 부분들이 제거되어 파일 크기가 줄어든다.

복잡도에 따라 20~50% 정도의 파일 크기가 줄어든다.

Gzip + 파일 축소를 둘 다 사용한 것이 Gzip 만 사용한 것과 큰 차이가 없을 수 있다.

약 1~2% 정도 차이가 나곤 하는데 ( 공백 압축률이 높다. ), 그래도 축소화 과정을 꼭 거쳐야 한다.

왜나하면 클라이언트 내에서 차지하는 메모리나 파일 용량이 적어지고, 작은 파일은 메모리에서도 더 빨리 읽혀지기 때문이다.

7.3.3. 이미지

다양한 화면 크기에 모두 대응하기 위해 이미지 버킷을 만들어 두고, 이미지가 필요할 때 앱에서 자신의 화면 크기를 함께 전송하게 하면 화면에 적합한 이미지만 다운받을 수 있다.

메타데이터가 꼭 필요하지 않다면 메타데이터를 다 제거해버리는 방법도 있다.

cf) WebP 는 구글이 개발한 새로운 이미지 포맷이다.

일반적으로 유사한 품질의 JPEG 보다 용량이 20% 정도 작다.

WebP 지원은 브라우저와 기기에 걸쳐 점차 증가하고 있다. ( 안드로이드는 4.0 이상 지원 )

이미지 파일 크기를 줄이려고 시도 중이라면 WebP 사용을 고려할만하다.

7.3.4. 파일 캐싱

각 파일에 대한 캐싱 시간은 파일을 다운받을 때 헤더에 지정되어 있다.

서버에서 캐싱 매개변수를 설정할 때 고려해야 할 몇 가지 사항이 있다.

일반적으로 파일은 일정 시간 동안 캐시되도록 설정되고, 그 파일이 시간 안에 다시 요청되면, 디바이스 캐시에서 읽어온다.

시간이 만료되면 서버에서 파일이 변경되었는지를 확인한다.

파일이 변경되지 않았으면 HTTP 304 (수정사항 없음 ) 을 응답하고 캐시 타이머는 초기화된다.

파일이 다를 경우에는 새 파일을 다운받는다.

Cache Control ( 헤더에 만료시간 추가 ) : 캐싱과 관련해서 가장 자주 사용되는 헤더

Private/Public

보통 네트워크의 CDN 캐시에서 사용한다. 이 값은 이 파일들이 공개타입거나 특정 사용자만 사용될 수 있는지를 의미한다.

no-store

이 파일은 캐시되면 안 된다는 것을 의미한다.

따라서 매번 다운받아야 한다.

no-cache

no-cache 로 지정된 파일은 실제로는 캐시될 수 있고 사용 전에 재확인되어야만 한다.

max age=X

파일이 얼마동안 캐시될 수 있는지를 나타낸다.

일반적으로 사용되는 값으로 0 (no-cache 와 동일), 60, 300, 600, 3,600(1시간), 86,400(하루), 3,153,600(1년) 이 있다.

ETags

고유한 랜덤 문자열이다.

매번 파일이 캐시에서 사용될 때 ETag 값의 유효성을 서버에서 인증받아야 한다.

로컬의 문자열이 서버에 있는 문자열과 일치하면 서버는 304(수정사항 없음)를 응답하고 로컬 파일이 그대로 사용된다.

ETags 가 다른 경우에는 새로운 파일을 다운받아 캐시에 새롭게 저장된다.

no-cache 나 max-age=0 의 경우도 동일하게 동작한다.

주기적으로 만료되는 파일의 경우라면 ETag 는 로컬 파일의 유효성을 확인할 수 있는 매우 유용한 방법이다.

반면 거의 변하지 않는 파일의 경우라면 ETag 는 성능 측면에서 매우 비싼 동작이다.

파일을 실제 다운받지 않더라도 일단 서버와 연결되어야 하고 여기에 파일 처리 시간도 추가된다.

Expires

Cache-Control 이나 ETag 만큼은 아니지만 Expires 도 많이 사용된다.

이 헤더는 파일이 얼마만큼의 시간 동안 유효한지에 대한 정보 대신 정확하게 언제 이 파일이 만료되는지에 대한 날짜/시간 정보를 알려준다.

Expire 헤더는 Cache-Control:max-age 에 지정된 값과 일치해야 한다.

앱이 처음 구동될 때 콘텐츠를 많이 다운받고 이를 오랫동안 캐시해야 한다면, 초기 시작 시간이 고객 만족의 가장 중요한 분기점이 된다는 사실을 기억하고, 이미지와 아이콘을 앱 안의 리소스로 포함시키는 방법을 고려해보자.

처음 앱이 시작할 때 이미지나 파일을 다운받으면서 설정에 오랜 시간이 걸리면 고객들이 앱을 한번만 쓰고 다시는 안 쓸 것이다.

물론 앱 용량이 커질 수 있지만, 초기 로딩 속도를 개선할 수 있다.

HTTP 캐시 스팩에서는 아무런 캐시 관련 헤더 정보가 없을 경우 24시간 동안 캐시된다고 나와 있다.

진정 캐시가 되지 않기를 바란다면 명시적으로 헤더를 넣어주는 것이 좋다.

7.3.5. 파일을 넘어서

7.3.6. 연결의 그룹화

광고 SDK 들이 들어있으면 앱을 효율적으로 동작시키기 위해 가능한 연결을 큰 버킷으로 나누어 구성하는 것도 방법이다.

7.3.7. 앱에서 무선망 사용 여부 감지하기.

7.3.8. 좋은 것에도 끝이 있는 법 : 연결 종료

7.3.9. 반복되는 핑

7.3.10. 네트워킹 보안(HTTP 대 HTTPS)

7.4. 전 세계 무선 통신망 적용 범위

중요한 변수 중 하나는 고객의 네트워크 속도이다.

고객이 어떤 네트워크로 앱을 사용할지 제어할 수 없다.

GSMA 인텔리전스에 따르면 2014년 기준 스마트폰의 40% 가 무선망을 통해 연결되어 있다고 하며, 2020년까지 65% 성장이 예상된다.

2014년 3분기 기준 4G 는 5% 이하이고 3G 는 약 30% 가 살짝 넘는다.

2G 네트워크만 사용하는 스마트폰 사용자도 상당 수 있다.

2013년 바이두는 중국에 2억 7천만명의 안드로이드 사용자가 있고 그 중 31% 가 2G 를 사용하는 사람들이라고 한다.

느린 네트워크를 사용하는 스마트폰이 미국과 유럽 외의 지역에 한정되는 문제가 아니다.

심지어 선진국에서도 LTE 서비스가 되지 않는 곳이 많다.

7.4.1. CDN

무선 통신망의 가장 큰 걸림돌은 대기시간이다.

지연을 줄이기 위해 고객이 가장 빠르게 데이터에 접근할 수 있도록 전 세계의 데이터센터에 콘텐츠를 미러링해놓는 콘텐츠 전송 네트워크(CDN, Content Delivery Network)를 사용하는 것도 고려할 수 있다.

7.4.2. 느린 네트워크에서 앱 테스트하기

느린 네트워크에서 테스트를 진행하려면 먼저 앱이 사용되는 모든 장소로 세계 여행을 예약해야 한다.

그러나 세계여행 없이도 통계 데이터를 신중하게 분석해보면 지역이나 국가에 따른 지연이나 대역폭 같은 문제를 충분히 찾아낼 수 있다.

7.4.3. (파산을 막기 위헤) 느린 네트워크 에뮬레이션

통신사들은 격리된 환경을 테스트하기 위해 특별히 제작된 안테나를 사용한다.

그러나 이런 환경을 구축하기에는 상당한 비용이 든다.

와이파이 스로틀링

테스트를 위해 와이파이 라우터를 사용하고 있다면 라우터에 OpenWRT 를 설치할 수 있다.

여기에 wshaper 플러그인을 설치하면 다운로드와 업로드의 속도 조절을 할 수 있다.

에뮬레이터

안드로이드 에뮬레이터에는 네트워크 속도를 조절하는 기능이 있다.

손으로 만든 패러데이 새장

패러데이 새장은 철사로 된 박스로 외부의 모든 전자기파로부터 내부 공간을 분리해주는 장비이다.

이 녀석을 이용해 전화에 도달하는 신호량을 감소시킬 수 있다.

어떤 개발자들은 오래된 전자레인지를 이용해 부분적으로 전파를 차단하는 환경을 구축하기도 하지만, 이는 실험의 가변성으로 인해 재현하기는 어렵지만, 정성적 테스트로는 적절하다.

네트워크 감쇠기(Network Attenuator)

AT&T 는 네트워크 감쇠기라는 도구를 출시했다.

네트워크 감쇠기는 루팅을 하고 AT&T 가 제공하는 커스텀 ROM 을 설치하면 된다.

앱은 모바일 네트워크 속도를 느리게 할 수 있는 스위치처럼 동작한다.

7.4.4. 네트워크에 따라 반응하는 앱 만들기

탄력적으로 네트워크를 인식하는(FNA, Flexibly Network Aware) 아키텍처를 사용하는 앱들이 좋은 앱이다.

네트워크가 빠르거나 보통이거나 느린 상황에 따라 모바일 사용자 경험을 다르게 제공해주려 한다고 생각해보자.

포함된 비디오를 빼거나 이미지 개수를 줄이는 것이 가장 간단한 방법일 수 있다.

TelephonyManager 의 getNetworkType() 을 통해 네트워크 값을 얻어 올 수 있다.

FNA 앱은 주기적으로 네트워크 상태를 조회해서 현재 상태에 따라 적절히 성능을 조정한다.

지연시간(RTT)을 측정할 때 값의 변화 폭은 상당히 크다.

기지국과의 거리, 혼잡도, 다른 무선망의 간섭 등의 영향을 많이 받는다.

그래서 한두 번의 측정 결과에 의존하는 것은 좋지 않고 평균을 사용하는 것이 좋다.

7.4.5. 지연시간에 대한 회계

7.4.6. 마지막 마일 지연

7.5. 기타 무선신호

7.5.1. GPS

안드로이드에서는 GPS 를 켜지 않아도 사용할 수 있는 Coarse Location 을 제공한다.

주변 기지국과 와이파이 정보를 바탕으로 대략적인 위치를 찾는다.

7.5.2. 블루투스

블루투스를 통해 전달되는 트래픽도 Wireshark 를 통해 수집할 수 있다.

킷캣 이상의 기기에서는 개발자 옵션에서 Bluetooth HCI snoop log 를 남기게 할 수 있다.

이 옵션을 체크하면 블루투스 인터페이스를 통해 전송되는 모든 패킷이 수집되며, /sdcard/btsnoop_hci.log 에 저장된다.

이 파일은 Wireshark 로 열어 볼 수 있다. 대부분의 데이터가 암호화되어 있지만, 두 장치 사이의 트래픽 패턴에 대한 통찰력 정도는 얻을 수 있다.

7.6. 결론

무선 장치는 화면 다음으로 배터리 소모의 주범이기 때문에 신중하게 사용하는 게 중요하다.

더구나 대부분의 사용자는 매달 정해진 무선 데이터 사용량이 있기 때문에 사용하는 파일이 전송에 최적화되어 있는지를 잘 확인해야 한다.

스마트폰 데이터 트래픽 비용과 더불어 높은 지연 시간과 느린 속도는 꼭 고려해야 한다.

데이터 전송이 사용 가능한 모든 네트워크에 최적화되어 있다면 고객이 세계 어디에 있든지, 네트워크 상황이 좋든지, 나쁘든지 간에 앱은 빛날 것이다.

RRC 상태 기계와 고객의 위치에 따라 데이터 트래픽을 최적화하면 고객의 배터리 수명도 늘어나고 전 세계 사용자 경험도 강화해 줄 것이다.

저작자표시 비영리 변경금지

'프로그래밍 놀이터 > 안드로이드, Java' 카테고리의 다른 글

[android] Shared Element Transition Tutorial ( with transparent bg ) (0)	2018.09.28
[도서 정리] 안드로이드 앱 성능 최적화 #8 최종 사용자 모니터링 (0)	2018.06.29
[도서 정리] 안드로이드 앱 성능 최적화 #6 CPU 와 CPU 성능 최적화 (0)	2018.06.27
[도서 정리] 안드로이드 앱 성능 최적화 #5 메모리 성능 (0)	2018.06.26
[도서 정리] 안드로이드 앱 성능 최적화 #4 화면과 UI 성능 개선하기 (0)	2018.06.25

[도서 정리] 안드로이드 앱 성능 최적화 #7 네트워크 성능