[Android]Understanding Battery Usage in your Android App

Understanding Battery Usage in your Android App

Advertisements

[RxAndroid] Basics: Part 1 – (1)

RxJava를 공부하면서 참고한 사이트를 번역(70%) + 나름의 이해한 내용(7%)으로 이루어진 포스팅입니다. 번역하기 애매한 것들이나, 하지 않는 게 더 자연스러울 문장들은 생략하였습니다.

참고한 사이트 : [번역]RxAndroid Basics: Part 1
RxJava with Android -1- RxJava 사용해보기

Welcome friend! So glad to see you! 너는 RxJava에 대해서 그리고, 이것이 Android에서 어떻게 적용되는지 궁금하다. 아마도 너는 이것이 사용되는 것을 몇몇 곳에서 봤겠지만, 너는 여전히 혼란스럽고 설명을 원한다.Well look no further!

내가 처음 RxJava를 접했을 때 나는 대부분 이것에 대해 Cargo coding[코드에 대한 이해없이 복붙]을 했다. 어떤 부분은 이해가 되었지만, 나는 기본 원리들에 대해 깊은 오해를 했다.또한, 나는 도대체 무슨 일이 일어나고 있는 지에 대해서 설명하는 좋은 예시의 부족함에 좌절했다.  RxJava를 완벽하게 이해하기 위해서, 나는 엄청나게 몰두했고, 많은 시도와 오류를 경험해야만 했다.

In an effort to save you, the cherished reader, some leg work, 나는 내가 발견한 것에 기인하여 몇몇의 예시를 서둘러 준비했다.  The hope is these examples will provide you with the necessary knowledge to begin using RxJava in your Android apps.

이 예시들은 완전한 기능을 하는 sample app으로 이곳에서 모두 찾을 수 있다.  각 예시의 처음에, 뒤따르는 code snippets이 있는 명확한 활동을 링크로 걸겠다. 나는 예시를 두 부분으로 나누기로 정했다. 첫번째 부분에서는, 우리는 RxJava의 사용에, 특히 비동기식 data load에, 초점을 맞춘다. 두번째 부분에서는 advanced usage patterns에 대해서 알아본다.

 

Some Concpets

nitty gritty[핵!심!]으로 들어가기에 앞서, 기초적인 개념들부터 시작하자. RxJava는 두가지가 핵심이다: ObservablesObservers. Observables are said to “emit” values. Their counterpart, Observers, watch Observables by “subscribing” to them.Observable들은 값들을 “방출”한다. 그것들에 대응하는 Observer들은 Observable들을 “구독”함으로써 감시한다(지켜본다).

rxJava

Observers는
1. Observable이 값을 방출할 때,
2. 그 Observable이 오류가 발생했다고 할 때,
3. 또는 그 Observable가 더이상 방출할 값이 없다고 할 때,
행동을 취한다. 이 세 가지의 모든 행동들은 Observer interface에서 압축된다. 이에 해당하는 함수들은
onNext(), onError(), and onCompleted() 이다.

위의 내용들을 명심하면서, 몇 개의 예시들을 살펴보자.

Example 1: The Basics

색깔의 목록(list)을(를) 간단하게 보여줄 수 있는 Activity를 만들어보자. 우리는 하나의 값(a list of strings) 을 방출하고, 완료하는 Observable 만들 것이다. 우리는 방출된 값을 목록(list)을(를) 구성하는 데 사용한다. 우리는 이것을 Observable.just() 를 사용해서 한다. This method creates an Observable such that when an Observer subscribes, the onNext() of the Observer is immediately called with the argument provided to Observable.just(). onComplete()Observable이 더 이상 방출할 값이 없기 때문에 불려진다.

ObservableListString listObservable = Observable.just(getColorList());

Note that getColorList() is a non-blocking method call. This may not seem important now, but we’ll come back to it later.

다음으로, 우리는 Observable을 감시하는 Observer를 만든다:

listObservable.subscribe(new ObserverListString() { 

   @Override
   public void onCompleted() { }

   @Override
   public void onError(Throwable e) { } 

   @Override
   public void onNext(ListString colors) {
       mSimpleStringAdapter.setStrings(colors);
  }
});

This is where the magic happens. As mentioned above,  upon subscribing to the Observable with the subscribe() method the following happens immediately, in this order:

Observable을 subscribe()method로 구독하자마자, 아래 내용이 순서대로 즉시 발생한다.

  1. The onNext() method is called and the emitted list of colors is set as the data for the adapter.
  2. Since there is no more data (we only gave our Observable a single value to emit in Observable.just()), the onComplete() callback is called.

나는 용어에 따르면 Observable은 subscription에 달려있음에 대해서 생각하는 것이 유용한 것을 알았다. 사실, Observables는 주로 그들의 subscription에 따른 행동에 의해 정의된다. Let’s take care to remember this, as it will come in handy later. I’m going to state it again since it’s so important:

Observables are primarily defined by their behavior upon subscription.

우리는 onComplete() method를 공백으로 두었기 때문에, 이런 경우에 Observable이 완료되었을 때언제 발생했는지에 대해서는 신경쓰지 않아도 된다. 우리는 onError() method 또한 비어있기 때문에,오류를 받을 방법도 없다.

모든 것이 지나치게(overkill) 보일 수도 있다. We could have just set the color list on our adapter directly. But with this in mind, let’s take a look at something a little more interesting.

[Front-end] HTML5를 활용한 성능 개선

성능이란 무엇인가?

*The RAIL Performance Model

RAIL.png

오늘은 Loading에 대해서만 이야기 합니다.

*로딩 과정의 이해

loading.png

*Connect/Request/Response [자원 요청에 대한 과정]

rr.png

-Stalled : Browser waiting
-TTFB : Server Time

*Waterfall Chart

waterfall


 

*Front End 성능 개선이란?
== Waterfall Chart를 어떻게 개선할 것인가?

1.요청수 최소화 하기
== Waterfall Chart의 높이 줄이기

자원의 Merge
   1. JS, CSS의 Merge : Grunt, gulp와 같은 자동화 퉆을 이용한 자동 merge
2. IMAGE의 Merge[CSS Sprite]

sprite

불필요한 자원의 제거

자원의 재사용( Cache) < LocalStorage 이용 : 클라이언트의 Database를 이용하여 Request수를 줄인다.
_!브라우저 캐쉬를 사용하면 안되는가? : 안된다! 왜냐하면, 브라우저 캐시는 제한이 있다. 제한을 초과한 경우, 기존 캐싱 자원이 삭제된다. 또한 LocalStorage는 빠르다. 예를 들어, 스마트 폰의 경우 최대 5배까지 Native Cacher 보다 빠르다.

local.png

_ JS,CSS의 LocalStorage를 이용한 캐싱 : 자주 변경이 되지 않는 파일에 대해서는 LocalStorage를 이용해 확실하게 캐싱되도록 처리
_ LocalStorage Flow Chart

flowchart
_ LocalStorage 캐싱을 지원하는 오픈 소스 : basket.js

초기 로딩 속도에 필요 없는 자원 나중에 로딩

 

2. 요청 크기 최소화 하기
== Waterfall Chart의 폭 줄이기
== HTTP Request 양 줄이기

자원의 크기를 최소화
_1. Minify와 Obfuscation : 주석제거,공백제거 / 변수명 난독화 , Grunt, gulp와 같은 자동화 툴을 이용한 HTML, CSS minified와 JS minified, obfuscation
_2. 이미지 크기 줄이기 : 이미지의 크기를 결정하는 요인[포맷 / 사이즈] 줄이기
_2-1. 이미지 포맷 기준

imageformat
_2-2. 이미지 사이즈 산출 = Pixel 수(width * height) * 표현할 수 있는 컬러 수
_! 고해상도 (레티나) 대응을 위해, 실제 표현하는 사이즈보다 2배 이상으로 사이즈 조정
_3. HTML5를 이용한 반응형 이미지

srcsstpicture

HTTP Request Header 줄이기

Gzip compress

 

3. 렌더링 줄이기
== Waterfall Chart 간격 줄이기

-브라우저 렌더링 과정 : TTFB[Time To First Bytes] 이후, 병렬로 렌더링 한다.

rendering

-자원의 위치에 따른 렌더링
HTML.png_A : head 안의 모든 자원 로딩 후 body 파싱. First Paint Time을 결정한다.
_B : 병렬 렌더링 불가 : 스크립트는 다양한 작업을 수행하는 코드로 이루어져 있고, DOM을 변경하는 작업들이 포함되어 있을 수 있기 때문에, 블록 된다.
b1
_! HTML5를 이용한 스크립트 로딩
_B-1. defer를 이용 : HTML 파싱이 완료된 이후에, 스크립트를 실행
defer

_B-2. async를 이용 : 스크립트를 실행할 때만, HTML 파싱이 중단
async = false일 경우, 순서 보장 (기본값은 true)async
_B-3. defer와 async의 적절한 사용 : DOM 제어와 관련이 있는 스크립트는 defer / DOM 제어와 관련이 없고, 의존성이 없는 스크립트는 async
da
_C : body 렌더링이 완료된 이후

-적절한 자원의 위치 선정
_1. 시각적으로 빠른 화면을 제공하기 위해, head에는 레이아웃 구성에 꼭 필요한 CSS FILE만 넣는다.
_2. body 태그 안에는 CSS나 Script를 넣지 않는다.
_! 전체 렌더링이 잠시 중단된다.
_3. Script는 body 태그 닫기 전에 넣는다.

 

4. 결론
*Front End 성능 개선이란?
==Waterfall Chart를 어떻게 개선할 것인가?

conclusion.png

 


 

출처: HTML5를 활용한 Front-End 성능 개선

회사의 홈페이지를 만들다가 고해상도의 이미지들 때문에 로딩하는 시간이 길어졌다. 앞으로를 위해서도 해결방법을 알아야 할 것 같아서 찾던 중에 이 자료를 공부하게 되었다. 이제 2개월.  공부에는 끝이 없다는 사실을 다시금 깨닫는다.

지금 당장 적용할 수 있는 건 Image를 sprite 형식으로 쪼개서 사용하는 방법.
규모가 큰 프로젝트 일 경우 css/js를 minimize 할 것.
적용하기 위해 더 공부가 필요한 부분은 LocalStorage,  캐싱, 파싱 …