출처: http://huewu.blog.me/110150046116
http://huewu.blog.me/110151107647
http://huewu.blog.me/110151893489
Optimizing Downloads for Efficient Network Access
안드로이드 개발자 문서 중, 네트워크 사용 중에 배터리 소모를 최소화 할 수 있는 기법들에 관한 내용을 세 번에 걸쳐 정리해 보겠습니다. 원본 내용은 아래 링크를 참고하시면 좋겠네요.
http://developer.android.com/training/efficient-downloads/efficient-network-access.html
어플리케이션이 무선 망을 통해 데이타를 주고 받을 때 많은 배터리가 소모됩니다. 배터리 소모를 최소화 하기 위하여 여러분의 앱이 데이타를 주고 받는 방식과 실제 폰의 통신 관련 하드웨어 사이에 어떤 관계가 있는지 알아두면 좋습니다.
The Radio State Machine
최대 파워로 동작하는 통신칩은 배터리를 많이 사용합니다. 배터리 소모를 줄이기 위하여 무선 데이터가 사용되지 않는 경우, 통신칩의 상태가 변경됩니다.
일반적으로 통신 칩은 다음의 3가지 상태를 갖습니다.
- 최대 파워(Full Power): 커넥션이 활성화된 상태에서 사용됩니다. 디바이스가 데이타를 최대 속도로 전송할 수 있습니다.
- 낮은 파워(Low Power): 중간 상태입니다. 풀 파워에 비해 50% 의 전력을 소모합니다.
- 대기(Standby): 대기 상태입니다. 최소한의 배터리만 사용하며, 네트워크 커넥션이 없는 경우에 사용됩니다.
낮은 파워 혹은 대기 상태의 경우 훨씬 적은 배터리를 사용하지만, 네트워크 요청이 있는 경우 최대 파워 상태로 변경될 때 까지 요청을 처리하는데 지연 시간이 발생 하게 됩니다. 일반적으로 낮은 파워 단계에서 최대 파워 단계로 전이 되는데 1.5초가, 대기 상태에서 최대 파워 상태로 전이되는데는 2초가 소모됩니다. 이러한 지연시간을 최소화하기 위해, 낮은 파워 혹은 대기 상태로 전이 되기 전에 일정 시간의 딜레이가 주어집니다.
(통신 칩의 상태가 전환될 때 까지 대기하는 시간이나 다시 네트워크 연결이 될 때 까지 걸리는 지연 시간 등은 사용되는 무선 기술(2G, 3G, LTE) 와 망 사업자와 관련이 있습니다. 이 문서에서 사용된 수치들은 AT&T 에서 제공하는 데이타를 기반으로 3G 무선망에 기반한 것입니다. 하지만 통신칩에 관한 일반적인 내용과 배터리 소모를 최소화 하기 위한 원칙들은 모든 경우에 적용될 수 있습니다.)
사용자가 인터넷 브라우저 등을 사용하는 경우라면, 상태를 변경하기 전에 약간의 딜레이를 갖는 방식이 효과를 발휘할 수 있습니다. 웹 브라우징을 하는 동안에는 통신칩이 최대 파워 상태를 유지하여 빠른 네트워크 속도를 보장하고, 브라우저 사용을 종료하면 잠시 후에 대기 상태로 전환되어 배터리 사용을 최소활 할 수 있습니다.
하지만 이 방식은 안드로이드 OS 와 같이, 어플리케이션이 포그라운드 상태(사용자가 직접 조작할 수 있는)에서 최대 네트워크 파워로 동작하면서 동시에, 다른 어플리케이션이 백그라운드 상태에서도 동작할 수 있는 경우에는 문제가 될 수 있습니다.
How Apps Impact the Radio State Machine
어플리케이션이 새로운 네트워크 요청을 할 때 통신 칩에는 어떤 일이 발생할까요? 데이타가 전송되는 동안 풀파워 상태로 유지된 후, 추가로 약 5초간 풀파워 상태를 유지합니다. 그 후 12초간 낮은 파워 상태를 유지하고 그 이 후에야대기 상태로 전환됩니다. 따라서 어플리케이션이 새로운 네트워크 요청을 할 때 마다, 약 20 여초간 상당한 배터리가 소비됩니다.
이론 상 디바이스 상에서 어떤 어플리케이션이 18초 마다 한 번씩 1초간 데이타를 전송하고 있다면, 통신칩이 막 대기 상태로 전환되려고 할 때마다 다시 풀파워 상태로 전환되는 일이 반복될 것 입니다. 따져보자면, 1분 중에 18초간을 최대 파워 상태로 나머지 42초간 저파워 상태로 남게 될 것이며 결과적으로 엄청난 배터리를 사용하겠지요. (첫 번째 다이어그램)
반대로 만일 어플리케이션이 1분마다 약 3초간 데이터 전송을 한다면, 1분중 오직 8초간 풀파워 상태로 12초간은 저파워 상태로 있을 것 이며, 나머지 40초간은 대기 상태로 남아 있을 것 입니다. 배터리 소모가 크게 줄어들 것 입니다. (두 번째 다이어그램)
결국, 배터리를 최소한으로 사용하도록 네트워크 어플리케이션을 작성하기 위해서는 데이터 커넥션의 횟수를 줄이는 노력이 필요하며, 이를 위해 필요한 데이터를 미리 가져오고, 전송할 데이터를 묶어서 보내는 방식등이 적용될 수 있습니다. 다음으로 이어질 포스트에서 이와 관련된 내용을 다루어 보도록 하겠습니다.
안드로이드 개발자 문서 중, 네트워크 사용 중에 배터리 소모를 최소화 할 수 있는 기법들에 관한 내용을 세 번에 걸쳐 정리해 보겠습니다. 이 포스트는 두 번째 포스트 입니다. 원본 내용은 아래 링크를 참고하시면 좋겠네요.
|
http://developer.android.com/training/efficient-downloads/efficient-network-access.html |
이전 포스트에서 살펴 본 봐와 같이, 실재 전송되는 데이터 크기와는 관계없이 새로운 커넥션 연결을 열 때마다 일정량의 배터리가 소모됩니다. 통신 상태가 대기 상태에서 풀파워 상태로 변경되면 혹시 모를 사용자의 추가적인 네트워크 요청에 대비하여, 일정 시간이 지난 후 대기 상태로 전환 되기 때문입니다. 따라서, 배터리를 절약하기 위해서는 필요한 데이터를 한번에 많이 수신하고, 전/송할 데이터를 묶어서 보내고, 데이터 커넥션은 최소화 할 필요가 있습니다.
데이터 프리패칭(Prefetching) 필요한 데이터를 그때 그때 가져오는 대신, 한 번의 커넥션으로 앞으로 필요한 데이터를 미리 가져옵니다. 통신 칩이 풀파워/로우파워 상태로 유지되는 전체 시간을 줄이고, 대기 상태에서 풀파워 상태로 전환되는 시간 또한 줄어들기 때문에 평균 다운로드 속도도 향상됩니다. (어디서나 배치 작업이 효율적인 법이조.) 또한, 필요한 데이터를 미리 준비해두면 사용자가 해당 컨텐츠를 요청했을 때 별도의 로딩없이 화면 상에 바로 표시할 수 있게되며, 사용자 경험이 향상 될 수 있습니다. 하지만 부작용도 있습니다. 사용되지 않는 데이터를 너무 많이 다운로드 하는 경우, 오히려 배터리를 더 소모하고, 다운로드 쿼터(요금제등과 연계된)를 낭비하게 만들 수 있습니다. 또한, 프로그램 시작시 과도한 프리패칭은 앱의 로딩 타임을 증가 시켜 앱이 너무 느리다고 생각하게 될 지도 모릅니다. 이런 경우라면 앱 기동에 필요한 최소한의 데이터는 별도로 다운로드 하거나 앱을 시작하는데 필수적인 데이터는 미리 처리하는 등의 작업이 필요할 것 입니다. 그럼 어느정도의 데이터릴 미리 다운받는 것이 좋을까요? 이는 데이터의 크기와 해당 데이터가 사용될 가능성에 따라 달라질 수 있습니다. 만일, 위 다이어 그램과 같은 상태 머신을 따르면, (그리고 풀파워 시 배터리 사용량이 100% 이고 로우파워 시 50% 라면...) 해당 데이타가 사용될 확률이 50% 정도 되는 경우 약 6초간(1~2MB 정도) 수신 할 수 있을 만큼의 데이터를 미리 다운받는 편이 배터리 절약에 도움이 됩니다.
배치 전송(Batch Transfers)과 커넥션
데이터를 전송 할 때 기억해야할 핵심 원칙은 바로 한 번의 전송 세션 중에 최대한 많은 데이터 전송 작업을 처리하여, 필요한 전송 세션의 수를 최소한으로 줄이는 것 입니다.
앞서 이야기하 것 처럼, 3G 상황에서 새로운 데이터 커넥션이 열리면 실재로 오가는 데이터의 양과는 무관하게 약 20초간 배터리가 소모됩니다. 예를들어, 어떤 어플리케이션이 20초에 한 번씩 자신이 살아있다는 것을 알려주기 위해 혹은 업데이트 정보가 있는지 확인하기 위해 서버 측으로 간단한 시그널을 보내고 있다면, 실제 데이터 전송은 거의 없는대도 불구하고 엄청난 배터리를 소모하게 될 것 입니다. 즉, 데이터를 필요할 때 마다 그때 그때 전송하기 보다, 전송할 데이터를 큐에 저장해 둔 후, 짧은 시간 안에 묶어서 동시에 전송하는 편이 좋습니다.
이를 위해, 어느 정도의 지연시간이 허용되는 데이터 전송, 업데이트, 데이터 프래패칭등의 작업은 큐에 저장해두고, 시간에 민감한 데이터 전송이 요구되는 순간이나 아니면 지정된 시간 주기에 맞춰 큐에 저장해둔 작업이 일괄적으로 처리되도록 구현 하면 좋습니다.
또한, 주기적인 업데이트 체크등 서버 측 데이터를 확인해야 하는 경우, 구글에서 제공하는 GCM(Google Cloud Messaging) 서비스를 적극적으로 활용하는 편이 좋습니다.
커넥션(Reduce Connections) 줄이기
일반적으로 이미 열려있는 네트워크 커넥션을 사용하는 것이 새로운 커넥션을 여는 것 보다. 더 효율적입니다. 데이터를 다운로드 하기 위해 여러개의 커넥션을 동시에 열거나, 연속적으로 여러번의 GET 요청을 사용하는 것 보다는, 가능한 여러 요청을 하나의 GET 요청으로 묶어서 전달 하는 편이 더 효율 적 입니다.
예를 들어 뉴스 어플리케이션을 생각해 보면, 각각의 뉴스 카테고리마다 개별적으로 기사를 요청하는 대신, 뉴스 기사 정보를 한번의 GET 요청으로 가져올 수 있도록 하는 편이 더 효율 적 입니다. TCP 스택의 구조 상 한번 열린 연결은 상대방의 종료 신호(FIN) 을 받기 전까지 열린 상태로 남아있게 됩니다. 따라서, 이미 사용이 완료된 연결은 종료시켜 주는 편이 좋습니다. 하지만 연결을 너무 빨리 닫아버리면, 이후 연속적인 다른 요청을 수행할 때 해당 커넥션을 재사용 할 수 있는 기회를 막아버릴 수도 있습니다. 따라서, 어플리케이션의 구현 방법에 따라 적당한 시점(더이상 해당 주소로 커넥션이 일어나지 않을 것이라고 판단되는 시점)에 가능한 빨리 커넥션을 종료시켜 주는 편이 좋습니다.
이와 관련해서 HTTP 의 Persistent Connection 관련 스펙을 참고하시면 이해에 도움이 될 듯 하네요.
뉴스 리더 앱을 어떻게 효과적을 구현할까?
많은 뉴스 앱들이 밴드위스 사용량을 줄이기 위해 노력합니다. 카테고리가 선택된 후에 해드라인만 다운로드 하고, 전체 아티클은 사용자가 해당 기사를 읽으려고 할 때만 다운로드 합니다. 기사에 포함된 썸네일 이미지는 스크롤이 일어나는 경우에만 다운로드 됩니다.
지금까지 살펴본 봐와 같이, 이러한 접근 방식은 사용자가 뉴스를 읽거나 스크롤 하거나 카테고리를 변경하는 등 앱을 사용하는 내내 무선 하드웨어가 오랫동안 활성화된 상태로 남아게 만듭니다. 무선칩의 상태가 자주 변경됨에 따라 지연 시간이 발생하기도 합니다.
이보다 좋은 방법은 합리적인 수준에서 뉴스 헤드라인과 썸네일을 포함하여, 최대한 많은 데이터를 한번에 로드하는 것 입니다. 최초 로딩 시간이 너무 길어지지 않게 조절하고, 백그라운드 상에서 나머지 내용들을 지속적으로 다운로드 할 수 있습니다.
혹은, 헤드라인 기사, 썸네일을 포함하여 본문 내에 포함된 모든 이미지를 주기적으로 다운로드 받도록 구현할 수도 있습니다. 단, 이런 방식은 결코 사용되지 않을 데이터를 다운로드 하는데 배터리와 대역폭을 낭비할 여지가 있기 때문에 주의를 기울여야 합니다..따라서, Wi-Fi 에 연결되어 있고 디바이스가 충전 중인 상황에서만 전체 컨텐츠를 다운로드 할 수 도 있습니다. 네트워크 연결 상태에 관한 내용은 이어지는 다음 포스트에서 다루어 보도록 하겠습니다.
또 한가지, 뉴스리더 앱은사용자의 사용 패턴을 분석하고, 새로운 기사가 나온 경우 이를 반영하기 위해 서버로부터 주기적으로 업데이트된 내용을 체크해야 합니다. 체크합니다. 이런 경우 서버로 전달된 사용자 분석 정보는 생성 시점에서 서버로 전달되는 것이 아니라 큐에 저장되어야 합니다.
저장된 배치 작업들은 주기적인 업데이트 시점 혹은 기사 내의 이미지 다운로드와 같이 즉시 이루어져야하는 데이타 연결이 있을 경우 한번에 이루어집니다. 그리고 다음 예정 작업은 지정된 일정 시간이 지난 후에 이루어 져야 합니다. 이런 방식으로 구현되면, 주기적인 업데이트로 인해 발생할 수 있는 비용을 최소화 시킬 수 있습니다.
두 번의 포스트를 통해, 배터리를 절약하는 네트워크 어플리케이션을 작성하기 위해 알아둬야할
배경 지식과 기억해야할 원칙에 관하여 살펴 보았습니다. 마지막으로 안드로이드 개발자 블로그에서 제안하고 있는, 실재 어플리케이션을 구현할 때 유용하게 사용할 수 있는 팁들을 번역해보았습니다.
원문: http://developer.android.com/training/efficient-downloads/index.html
GCM(Google Cloud Messaging)을 활용한 푸쉬 서비스 구현
일반적인 3G 환경에서, 어플리케이션이 서버에 업데이트를 확인하기 위해 신호를 보내게 되면 단말의 무선 상태가 활성화되며 약 20초간 불필요하게 배터리를 낭비하게 됩니다.
주기적으로 서버에 데이터를 송신 하는 풀링 방식 대신, 서버 측에서 변동 사항이 있는 경우에만 해당 사실을 어플리케이션으로 전달하도록 구현할 수 있습니다. 폴링 방식과 비교할 때, 이러한 푸쉬 메카니즘을 사용하면 불필요한 네트워크 커넥션을 줄일 수 있고, 어플리케이션은 업데이트 된 데이타를 지연 시간 없이 빠르게 전달 받을 수 있습니다.
구글 클라우드 메세징 서비스(GCM)를 활용하면 푸쉬 서비스를 손쉽게 구현할 수 있습니다. 또한, 이미 구글 마켓등의 구글 어플리케이션에서 사용하고 있는 TCP/IP 커넥션을 공동으로 사용하게 됩니다. (무료에 쿼터 제한도 없습니다~! ) 푸쉬 서비스를 여러분이 직접 구현할 수도 있겠지만, 항상 연결되어 있어야 하는 TCP/IP 커넥션의 숫자를 줄이기 위해서도 GCM 을 사용하는 것을 권장드립니다.
주기적인 폴링 작업을 효과적으로 처리하기
어플리케이션 특성에 따라 주기적인 폴링 기능이 필요할 수 있습니다. 이 경우 사용자 경험이 유지되는 한도 내에서 가능한 드물게 업데이트를 하는 편이 좋습니다. 가장 간편한 방법은 사용자가 직접 업데이트 주기를 지정할 수 있게 기능을 제공하는 것 입니다. 하지만, 좀 더 나아가 어플리케이션인 얼마나 자주 사용되는 가를 기준으로 업데이트 주기를 변경 할 수도 있습니다.
이 경우, 업데이트 주기를 결정하기 위해 지수적으로 증감하는 Exponential back-off 패턴을 사용 하는 것이 일반적입니다. 만일 어플리케이션이 이전 업데이트 이 후로 사용되지 않았다면, 업데이트 주기를 계속 해서 두 배로 늘리고, 한 번이라도 사용된 후에는 다시 기본 업데이트 주기로 설정합니다.
SharedPreferences sp = context.getSharedPreferences(PREFS, Context.MODE_WORLD_READABLE); boolean appUsed = sp.getBoolean(PREFS_APPUSED, false); long updateInterval = sp.getLong(PREFS_INTERVAL, DEFAULT_REFRESH_INTERVAL); if (!appUsed) if ((updateInterval *= 2) > MAX_REFRESH_INTERVAL) updateInterval = MAX_REFRESH_INTERVAL; Editor spEdit = sp.edit(); spEdit.putBoolean(PREFS_APPUSED, false); spEdit.putLong(PREFS_INTERVAL, updateInterval); spEdit.apply(); rescheduleUpdates(updateInterval); executeUpdateOrPrefetch();
이와 유사한 방법을 커넥션 오류나 다운로드 에러를 처리할 때도 응용해서 사용할 수 있습니다. 네트워크 커넥션을 생성하는 비용은 실재로 서버와의 연결에 성공했는지 그렇지 않은지 관계없이 동일합니다. 따라서, 연결 실패시 연속적으로 서버와의 연결을 재 시도하기 보다는 재시도 할 때 까지 대기하는 지연 시간을 적절히 조절 하여, 배터리 소모를 최소화 할 수 있습니다.
private void retryIn(long interval) { boolean success = attemptTransfer(); if (!success) { retryIn(interval*2 < MAX_RETRY_INTERVAL ? interval*2 : MAX_RETRY_INTERVAL); } }
AlarmManager 를 이용하여 주기적인 업데이트 작업을 수행하는 경우 알아두어야 할 점이 있습니다. 반복 작업을 설정할 때, 'setRepeating' 메서드 대신, 'setInexactRepeating' 메서드를 사용하는 편이 좋습니다. 만일 시스템 상에 설정된 여러 알람 작업들이 거의 비슷한 시간에 수행되도록 예정되어 있다면, 모든 알람이 한 번에 수행되도록 시간이 조절됩니다. 결과적으로 예약된 작업이 배치 형식으로 수행되며, 무선 상태가 변경되는 것을 최소화 하고 배터리를 절약할 수 있게 됩니다.
int alarmType = AlarmManager.ELAPSED_REALTIME; long interval = AlarmManager.INTERVAL_HOUR; long start = System.currentTimeMillis() + interval; alarmManager.setInexactRepeating(alarmType, start, interval, pi);
또한 알람 시간을 설정할 때, _WAKEUP 속성이 붙지 않은 ELAPSED_REALTIME, RTC 값을 사용하는 것이 좋습니다. _WAKEUP 속성이 사용된 경우, 알람이 울릴 때 마다 폰이 대기 상태에서 깨어남으로 배터리를 낭비할 수 있습니다.
동일한 내용을 두 번 다운로드 받지 않기
다운로드 하는 데이터를 줄이기 위한 핵심 원칙은 필요한 데이터만을 다운로드 받는 것 입니다. REST API 를 구현할 때, 정확히 필요한 데이터만 쿼리 할 수 있도록 API 를 설계하거나 이미지를 다운로드 하는 경우, 정확히 필요한 사이즈로 리사이즈된 이미지를 다운 받도록 구현 할 수 있습니다.
다른 한가지 중요한 원칙은 중복된 데이터를 다운로드 하지 않는 것 입니다. 바로 캐쉬를 적극적으로 사용하는 것 입니다. 정적인 리소스는 항상 캐쉬하는 편이 좋습니다. 풀 사이즈 이미지 처럼 사용자 요청에의해 다운 받게 되는 리소스들도 여유가 허락하는 한 캐쉬를 활용하면 좋습니다. 단 이런, 리소스들은 별도의 저장 공간에 관리하여 주기적으로 캐쉬 사이즈를 유지 시켜 주어야 합니다.
캐쉬된 데이터가 너무 오래된 것이 아닌지 확인 할 필요가 있습니다. HTTP 에 정의된 프로토콜을 사용하면, 간단한 HTTP 요청을 통해 이미 만료된 리소스인 경우 필요에 따라 관련된 데이터를 다시 다운 받을 수 있습니다.
long currentTime = System.currentTimeMillis()); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); long expires = conn.getHeaderFieldDate("Expires", currentTime); long lastModified = conn.getHeaderFieldDate("Last-Modified", currentTime); setDataExpirationDate(expires); if (lastModified < lastUpdateTime) { // Skip update } else { // Parse update }
민감하지 않은 데이터는 외부 캐쉬 디렉토리 공간을 활용할 수 있으며, 데이터의 성격에 따라 해당 어플리케이션만 접근 가능한 내부 캐쉬 공간을 활용할 수 도 있습니다. 하지만, 내부 캐쉬 공간은 시스템이 사용 가능한 저정 공간이 부족해지면 자동으로 삭제될 수 있습니다. 캐쉬 파일이 어느 곳에 저장되었던 간에, 어플리케이션이 삭제될 때 해당 캐쉬 파일도 같이 삭제됩니다.
Context.getExternalCacheDir(); Context.getCache();
HttpURLConnection Response Cache 사용하기
안드로이드 4.0 에서 HttpResponseCache 클래스가 추가되었습니다. 플랫폼에서 이를 지원하는 경우 다음과 같이 간편하게 HTTP Response Cache 를 적용할 수 있습니다.
private void enableHttpResponseCache() { try { long httpCacheSize = 10 * 1024 * 1024; // 10 MiB File httpCacheDir = new File(getCacheDir(), "http"); Class.forName("android.net.http.HttpResponseCache") .getMethod("install", File.class, long.class) .invoke(null, httpCacheDir, httpCacheSize); } catch (Exception httpResponseCacheNotAvailable) { Log.d(TAG, "HTTP response cache is unavailable."); } }
캐쉬가 설치된 후 HttpURLConnection 클래스를 이용하여 네트워크 요청을 하는 경우, 해당 요청에 대한 응답이 캐쉬됩니다. 이 후, 온전히 캐쉬된 HTTP 요청(캐쉬 수명이 만료되지 않은 경우)은 네트워크 연결을 전혀 사용하지 않고 로컬 캐쉬로부터 바로 응답을 받을 수 있으며, 조건부로 캐쉬된 HTTP 응답의 경우 여전히 캐쉬의 수명을 체크하기 위하여 서버와의 통신이 필요하지만, 리소스를 다운로드 받는데 필요한 대역폭은 절약할 수 있습니다.
( 안드로이드 4.0 이전 버전의 경우, 4.0 의 캐쉬 구현을 기반으로 작성된 HttpResponseCache 오픈 소스 라이브러리를 사용 할 수 있습니다. 한 가지, 캐쉬를 사용하는 경우 최초 캐쉬 인스톨 단계에서 저장된 캐쉬 파일을 로드할 때 일정 시간의 지연 시간이 발생 하고, 최초 네트워크 요청시응답을 캐쉬로 저장하는 지연 시간이 발생 할 수 있다는 점을 유의해야 합니다.)
네트워크 작업 시, 연결되어있는 커넥션의 종류에 따라 배터리 소모량이 달라 질 수 있습니다. Wi-Fi 가 무선 통신망에 비해 훨씬 적은 배터리를 사용할 뿐만 아니라, 배터리에 영향을 끼치는 무선 기술 자체가 다릅니다. (구동되는 드라이버 및 하드웨어 자체가 다릅니다.)
여러분은 현재 어떤 무선 통신 기술이 사용되고 있는지 Connectivity Manager 를 통해 확인 할 수 있으며 미리 다운로드 받는 로직을 이에 맞추어 변경할 수 있습니다.
ConnectivityManager cm = (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE); TelephonyManager tm = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); int PrefetchCacheSize = DEFAULT_PREFETCH_CACHE; switch (activeNetwork.getType()) { case (ConnectivityManager.TYPE_WIFI): PrefetchCacheSize = MAX_PREFETCH_CACHE; break; case (ConnectivityManager.TYPE_MOBILE): { switch (tm.getNetworkType()) { case (TelephonyManager.NETWORK_TYPE_LTE | TelephonyManager.NETWORK_TYPE_HSPAP): PrefetchCacheSize *= 4; break; case (TelephonyManager.NETWORK_TYPE_EDGE | TelephonyManager.NETWORK_TYPE_GPRS): PrefetchCacheSize /= 2; break; default: break; } break; } default: break; }
'IT_Programming > Android_Java' 카테고리의 다른 글
| [펌] Android In-App Billing (IAB Version 3) 보안 완벽 정리 (0) | 2014.07.16 |
|---|---|
| [펌] Android Support Library 를 안정감 있게 사용하는 3가지 방법. (0) | 2014.06.18 |
| Android Layout Tricks: Efficiency (0) | 2014.06.17 |
| Faster screen orientation change (0) | 2014.06.17 |
| Window Backgrounds & UI Speed (0) | 2014.06.17 |