진쓰의 프로그래밍 지식저장소

성능을 위해 구조화된 Application

 안드로이드 디바이스는 동시 여러 작업을 처리할 수 있는 멀티프로세서 시스템입니다. 하지만 응용애플리케이션의 성능을 최적화하기 위해 작업을 동시에 실행하도록 보장하는것은 각각의 애플리케이션에 달려있습니다.

만약 앱이 동시적으로 분할된 동작을 하지않고, 길게 하나의 작업을 실행하는 것을 선호한다면, 하나의 CPU만을 이용할 수 있고 이는 차선의 성능으로 이어지게 됩니다. 분할되지 않은 작업은 동기적으로 실행해야하지만, 분할된 작업은 비동기적으로 실행할 수 있습니다.

*동기적(동시에), 비동기적(순서대로)

 여러개의 독립적인 Task가 가능한 앱은 비동기 실행을 사용하도록 구성해야합니다.

 한가지 방법은, 응용프로그램 실행을 여러 프로세스에 분리시키는 방법입니다. 

여러개의 독립된 작업이 동시에 실행될 수 있기 때문입니다. 그러나 모든 프로세스는 자신의 기본적 자원을 위해 메모리를 할당하므로 여러프로세스에서 응용프로그램을 실행하는 것은 하나의 프로세스에서 응용프로그램을 실행하는 것보다 많은 메모리를 사용하게 됩니다.

 또한, 프로세스 간의 시작과 통신이 느리며, 비동기 실행을 하는 효과적인 방법이 아닙니다. 물론 여러 프로세스가 유효한 디잔일 수 있지만, 이 결정은 성능과는 독립적이어야 합니다. 

 높은 처리량과 더 나은 성능을 만들기 위해 어플리케이션은 각각의 프로세스내에서 여러 스레드를 사용해야 합니다.

스레드를 통한, 반응성 있는 앱 구현

 앱은 여러개의 CPU에서 높은 처리량을 가진 비동기 실행이 가능하지만, 반응성 있는 앱을 보증하지는 않습니다. 

*반응성: 상호작용하는 동안, 사용자가 앱을 인식하는 방식을 말합니다.

 UI가 버튼 클렉이 신속하게 반응 혹은, 부드러운 애니메이션등, 신속하게 반응하는것 등에 주안점을 둡니다. 기본적으로 사용자 경험의 관점에서 성능은 앱이 얼마나 빠르게 UI구성요소를 업데이트하는지로 결정됩니다.

 UI 컴포넌트를 update 하는 역할은 시스템이 UI구성요소 업데이트를 유일하게 허용하는 UI Thread가 존재합니다.

 반응성있는 앱을 위해서라면, 오래걸리는 태스크를 UI스레드에서 실행하면 안됩니다. 만약 UI스레드에서 그런 테스크를 실행하면, 해당 스레드의 다른 모든 실행이 지연되게 됩니다. 일반적으로 UI스레드에서 오래 걸리는 테스크를 실행하면, 생기는 첫번째 증상은 UI가 응답하지않고, ANR을 내게 되는것입니다.

 런타임은 네트워크 내려받기와 같이 시간이 오래 걸리는 특정작업을 UI스에드에서 실행하는 것을 금지합니다.

그래서 아래와 같이 긴 작업은 백그라운드 스레드에서 처리되어야 합니다. 오래 걸리는 태스크는 보통 다음아래와 같습니다.

안드로이드 앱에서, 스레드는 구성요소중 어느 것만큼이나 핵심적입니다. 안드로이드 컴포넌트(구성요소)와 시스템 콜백은 다른 언급이 없는한, UI스레드에서 실행되며, 더 오래 걸리는 태스크는 Background의 Thread를 사용해야 합니다.

오래걸리는 Task?

사실 명확한 오래걸리는 테스크에대한 기준은 없습니다. 사용자가 UI를 느리다고 인식하다면, 테스크를 UI스레드에서 실행하기에는 너무 길다는 신호입니다. 인간이 부자연스럽다고 생각하는 부분은 백그라운드 테스크에서 처리하는게 바람직합니다.

마무리

 안드로이드 앱은, 리눅스 프로세스에 포함된 달빅 런타임 내의 리눅스 OS위에서 실행됩니다. 

안드로이드는 가장 낮은 우선순위의 앱을 종료시키시 위해, 실행중인 각 응용프로그램의 중요성을 따져 프로세스 순위 시스템을 적용합니다.

성능향상을 위해 앱은 코드를 동시실행 하기 위해 여러 Thread 작업을 나눠야 합니다. 

모든 리눅스 프로세스는 UI Update를 책임지는 특정한 스레드인 UI스레드를 포함합니다.

오래 걸리는 작업은 모두 UI Thread에서 분리하여 다른 스레드에서 실행해야 합니다.