이 페이지는 Cloud Translation API를 통해 번역되었습니다.

프로세스 및 스레드 개요

애플리케이션 구성요소가 시작되고 애플리케이션에 다른 구성요소가 없을 때 Android 시스템은 단일 스레드의 스레드를 가지고 애플리케이션을 위한 새로운 Linux 프로세스를 실행할 수 있습니다 기본적으로 같은 애플리케이션의 모든 구성 요소는 같은 프로세스와 스레드에서 실행됩니다. 기본 스레드라고 합니다.

애플리케이션 구성요소가 시작되고 이미 프로세스가 있는 경우 다른 구성 요소가 이미 시작되었기 때문에 해당 구성 요소가 이미 시작되었기 때문에 해당 프로세스 내에서 시작되고 동일한 실행 스레드를 사용합니다. 그러나 잔여 노출수의 애플리케이션에서 여러 구성요소를 별도의 프로세스에서 실행할 수 있고, 추가 애플리케이션이나 사용할 수 있습니다.

이 문서는 프로세스와 스레드가 Android 애플리케이션에서 작동하는 방식을 설명합니다.

프로세스

기본적으로 애플리케이션의 모든 구성 요소는 같은 프로세스에서 실행되며, 대부분의 애플리케이션은 바꾸지 마세요. 하지만 어떤 프로세스를 제어해야 할지 판단해야 하는 경우에는 매니페스트 파일에서 만들 수 있습니다.

각 구성요소 요소 유형(<activity>, <service>, <receiver>, <provider>)의 매니페스트 항목은android:process 프로세스 내에서 구성 요소가 실행되는 프로세스를 나타냅니다 이 속성을 설정하면 각 구성요소가 어떤 구성 요소는 프로세스를 공유하지만 다른 구성 요소는 공유하지 않도록 해야 합니다.

또한 android:process: 서로 다른 애플리케이션의 구성요소가 동일한 환경에서 실행되도록 합니다. 단, 애플리케이션이 동일한 Linux 사용자 ID를 공유하고 동일한 인증서가 생성됩니다

<application> 요소는 또한 android:process 속성을 지원합니다. 이 속성은 모든 구성요소에 적용되는 기본값입니다.

Android는 특정 시점에 프로세스를 종료하기로 결정할 수도 있는데, 이때 리소스가 다른 프로세스에서 더 빠르게 요청할 수 있습니다 용도 따라서 종료된 프로세스에서 실행 중인 모든 구성 요소는 소멸됩니다. 프로세스가 시작됨 해당 구성 요소가 해야 할 작업이 있을 때 해당 구성 요소에 다시 한 번 더 사용합니다.

종료할 프로세스를 결정할 때 Android 시스템은 있습니다. 예를 들어 더 이상 사용되지 않는 활동을 호스팅하는 프로세스를 더 쉽게 종료할 수 있습니다. 가시적 활동을 호스팅하는 프로세스와 비교하여 화면에 가시적일 수 있습니다. 클라우드 컴퓨팅을 할지에 대한 결정은 그 프로세스에서 실행 중인 구성 요소의 상태에 따라 달라집니다.

프로세스 수명 주기 및 애플리케이션 상태와의 관계에 대한 자세한 내용은 프로세스 및 앱 수명 주기.

스레드

애플리케이션이 시작되면 시스템은 애플리케이션의 실행 스레드를 생성하고 기본 스레드라고 합니다. 이 스레드는 스레드에 이벤트를 전달하는 역할을 맡기 때문에 적절한 사용자 인터페이스 위젯을 지원합니다. 또한 애플리케이션이 구성 요소와 상호 작용하는 스레드는 거의 항상 Android UI 도구 키트의 android.widget 및 패키지 android.view개 이러한 이유로 기본 스레드가 UI 스레드라고 합니다. 하지만 특별한 상황에서 앱의 기본 스레드가 UI 스레드가 아닐 수 있습니다. 자세한 내용은 스레드를 참조하세요. 주석

시스템은 구성요소의 각 인스턴스에 별도의 스레드를 생성하지 않습니다. 전체 같은 프로세스에서 실행되는 구성 요소가 UI 스레드에서 인스턴스화되고 각 구성 요소가 그 스레드에서 발송됩니다. 결과적으로 시스템에 응답하는 방법은 콜백(예: onKeyDown()) 수명 주기 콜백 메서드를 보고할 수 있습니다. 이 메서드는 항상 프로세스의 UI 스레드에서 실행됩니다.

예를 들어 사용자가 화면의 버튼을 터치하면 앱의 UI 스레드가 터치 이벤트를 위젯에 전달합니다. 그러면 이 위젯은 눌린 상태를 설정하고 있습니다. UI 스레드가 요청을 대기열에서 제거하고 위젯에 다시 그리도록 알립니다. 있습니다.

애플리케이션을 제대로 구현하지 않는 한 이 단일 스레드 모델은 앱이 사용자 상호작용에 대한 응답으로 집약적인 작업을 수행할 때 성능이 저하될 수 있습니다. UI 스레드에서 네트워크 액세스, 전체 UI를 차단합니다. 스레드가 차단되면 어떤 이벤트도 디스패치되지 않으며, 추가할 수 있습니다.

사용자의 관점에서 보면 표시됩니다. 게다가 UI 스레드가 몇 초 이상 차단되면 사용자에게 '애플리케이션이 제대로 작동하지 않음' 응답" (ANR) 대화상자가 표시됩니다. 그러면 사용자는 애플리케이션을 종료하거나 있습니다.

Android UI 도구 키트는 스레드로부터 안전하지 않습니다. 그러니 조작하지 말고 작업자 스레드에서 UI를 생성합니다. UI에서 사용자 인터페이스 조작을 모두 처리 스레드가 필요합니다. Android의 단일 스레드 모델에는 두 가지 규칙이 있습니다.

UI 스레드를 차단하지 않습니다.
UI 스레드 외부에서 Android UI 도구 키트에 액세스하지 마세요.

작업자 스레드

이 단일 스레드 모델 때문에 작업의 응답성에 UI 스레드를 차단하지 않아야 합니다. 수행해야 할 작업이 있는 경우 이러한 작업은 별도의 백그라운드에서 실행하거나 worker 스레드를 지원합니다. 이 스레드가 아닌 다른 스레드에서는 UI를 업데이트할 수 없다는 점에 유의하세요. 기본 스레드에 해당합니다.

이러한 규칙을 따를 수 있도록 Android는 다른 기기에서 UI 스레드에 액세스하는 몇 가지 방법을 제공합니다. 스레드가 필요합니다. 다음은 몇 가지 유용한 메서드 목록입니다.

다음 예에서는 View.post(Runnable)를 사용합니다.

Kotlin

fun onClick(v: View) {
    Thread(Runnable {
        // A potentially time consuming task.
        val bitmap = processBitMap("image.png")
        imageView.post {
            imageView.setImageBitmap(bitmap)
        }
    }).start()
}

자바

public void onClick(View v) {
    new Thread(new Runnable() {
        public void run() {
            // A potentially time consuming task.
            final Bitmap bitmap =
                    processBitMap("image.png");
            imageView.post(new Runnable() {
                public void run() {
                    imageView.setImageBitmap(bitmap);
                }
            });
        }
    }).start();
}

백그라운드 작업이 별도의 스레드에서 실행되므로 이 구현은 스레드로부터 안전합니다. 반면 ImageView는 항상 UI 스레드에서 조작됩니다.

그러나 작업이 복잡해질수록 이러한 종류의 코드는 더 복잡해질 수 있고 유지 관리가 까다로울 수 있습니다 더 복잡한 상호작용을 작업자 스레드로 처리하려면 다음을 고려해 보세요. 작업자 스레드에서 Handler 사용 UI 스레드에서 전달된 메시지를 처리합니다. Kubernetes에서 백그라운드 스레드에서 작업을 예약하고 UI 스레드와 다시 통신할 수 있습니다. 자세한 내용은 백그라운드 작업 개요.

스레드로부터 안전한 메서드

구현하는 메서드가 둘 이상의 스레드에서 호출되는 경우가 있습니다. 따라서 스레드로부터 안전하게 작성되어야 합니다.

주로 바인드된 서비스의 메서드와 같이 원격으로 호출할 수 있는 메서드에 해당합니다. 통화 중에 IBinder에 구현된 메서드는 IBinder가 실행 중이면 메서드가 호출자의 스레드에서 실행됩니다. 그러나 호출이 다른 프로세스에서 시작되면 이 메서드는 시스템이 IBinder와 동일한 프로세스에서 유지관리하는 스레드 풀 프로세스의 UI 스레드에서 실행되지 않습니다.

예를 들어 서비스의 onBind() 메서드는 서비스의 프로세스, onBind()가 반환하는 객체에 구현된 메서드(예: 리모트 프로시져 콜 (RPC) 메서드를 구현하는 서브클래스가 스레드로부터 호출됨 있습니다. 한 서비스에 클라이언트가 둘 이상 있을 수 있으므로 둘 이상의 풀 스레드가 관여할 수 있음 같은 IBinder 메서드를 동시에 사용하므로 IBinder 메서드는 다음과 같아야 합니다. 스레드로부터 안전하게 구현됩니다.

마찬가지로 콘텐츠 제공자는 다른 프로세스에서 발생한 데이터 요청을 수신할 수 있습니다. ContentResolver 및 ContentProvider 클래스는 프로세스 간 통신 (IPC)이 관리되는 방식에 대한 세부 정보를 숨깁니다. 그러나 이러한 요청에 응답하는 ContentProvider 메서드는 query(), insert(), delete(), update(), 및 getType()—다음 UI가 아니라 콘텐츠 제공자 프로세스의 스레드 풀에서 호출됩니다. 해야 할 수도 있습니다. 이러한 메서드는 동시에 스레드로부터 안전하게 구현되어야 합니다.

프로세스 간 통신

Android는 RPC를 사용하는 IPC 메커니즘을 제공하며, 여기서 메서드는 활동 또는 다른 애플리케이션에 의해 호출됩니다. 다른 프로세스에서 원격으로 실행되어 모든 결과가 있습니다. 여기에는 메서드 호출과 그 데이터를 운영 체제가 사용할 수 있는 수준으로 분해하는 작업이 수반됩니다. 로컬 프로세스와 주소 공간에서 원격 프로세스로 전송하고 다시 결합하고 그곳에서 호출을 다시 생성합니다.

그러면 반환 값은 반대 방향으로 전송됩니다 Android는 이러한 IPC를 실행하기 위한 모든 코드를 제공함 따라서 개발자는 RPC 프로그래밍 인터페이스를 정의하고 구현하는 데 집중할 수 있습니다.

IPC를 수행하려면 애플리케이션이 bindService()를 사용하여 서비스에 결합되어야 합니다. 자세한 내용은 서비스 개요를 참고하세요.