[Android][비동기 프로그래밍] Handler, HandlerThread 이용하기

참고

안드로이드 비동기 프로그래밍 책

http://acornpub.co.kr/book/async-android

안드로이드 비동기 프로그래밍

 

결론

백그라운드에서 작업하고, 작업의 결과를 메인쓰레드로 보내 UI에 출력하는 방법

> 백그라운드 스레드에서의 작업을 Handler를 통해 메인 스레드로 보내기 

 

메인 스레드에서 백그라운드로 작업 보내기, 혹은 백그라운드 스레드에서 다른 스레드로 작업 보내기

> Handler와 HandlerThread를 이용할 수 있다. 

 

설명

루퍼 Looper 등장

루퍼Looper는 무엇인가?

영원히 반복하는 클래스. 큐에 추가되는 메시지Message를 기다리다가 Message를 dispatch한다. 

 

루퍼 스레드는 무엇인가?

스레드 내부에서 루퍼가 있고, 루퍼의 정적 메소드인 prepare와 loop를 호출한다.

핸들러로 루퍼 스레드 안의 큐에 메시지를 추가한다.

 

핸들러는 무엇인가?

1) 루퍼의 큐에 메시지를 추가할 수 있는 인터페이스를 제공한다. 루퍼의 큐에 메시지를 추가하려면 핸들러를 써야한다는 의미로 이해함.

2) 루퍼의 메시지를 dispatch할 때 메시지 처리를 위한 콜백을 구현한다.

 

메인 스레드는 실제로 루퍼 스레드이다.

액티비티 생명주기 콜백에서 발생하는 모든 일은 메인 루퍼가 호출한 dispatchMessage 호출에서 일어난다.

다른 스레드에서 메시지를 메인 스레드로 보낼 수 있다.> 백그라운드 스레드의 작업을 메인 스레드로 보낼 수 있다.

 

백그라운드에서 작업하고, 작업의 결과를 메인쓰레드로 보내 UI에 출력하는 방법 > 백그라운드 스레드에서의 작업을 Handler를 통해 메인 스레드로 보내기

 

1)  메인 스레드에 처리하는 작업을 제출하는 핸들러 만들기. 

메인 루퍼 인스턴스에 대한 참조를 핸들러 생성자에 전달하기.

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Handler handler = new Handler(Looper.getMainLooper);
}

 

2-1) post를 이용하기

handler.post(new Runnable() {
    public void run() {
        // 메인 스레드에서 작업 수행
    }
});

handler.postAtFrontOfQueue(new Runnable() {
    public void run() {
        // 메인 스레드에서 작업 수행
        // 큐에서 무엇보다도 우선시하는 Runnable로, 기존 작업보다 앞서게끔 큐의 맨 앞에 게시함.
    }
});

handler.postDelayed(new Runnable() {
    public void run() {
        //10초 지연 후 메인 스레드에서 작업 수행
    }
}, TimeUnit.SECONDS.toMillis(10));

 

post로 게시하는 Runnable은 Message의 callback으로 참조되고, 이 Runnable이 참조된 메시지가 루퍼의 큐에 추가된다. 메시지를 처리할 때이 Runnable이 실행된다.

//Handler.java 안

public final boolean post(@NonNull Runnable r) {
    return  sendMessageDelayed(getPostMessage(r), 0);
}

//post로 받은 Runnable을 Message의 callback으로 참조한다.
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        //여기가 실행된다.
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

//post로 받은 Runnable의 실행
private static void handleCallback(Message message) {
    message.callback.run();
}

 

2-1-1) 기다리는 Runnable 취소하기

Runnable 콜백을 Queue에서 제거해서 기다리는 작업 취소가 가능하다. 무엇을 제거할지 지정하기 위해 Runnable 인스턴스에 대한 참조를 유지하고 기다리는 작업에만 취소가 적용된다. 이미 실행 중인 Runnable을 중지하지는 않는다.

final Runnable runnable = new Runnable() {
    public void run(){
        // ... 작업 수행
    }
}
handler.postDelayed(runnable, TimeUnit.SECONDS.toMilles(10));
...
handler.removeCallbacks(runnable);

 

2-2) send 이용하기

post로 Runnable로 작업을 보내면, 작업에 대한 사전 정보를 핸들러가 알 수 없다. 작업에 대한 사전 정보를 알고 적절하게 반응할 수 있도록, 핸들러에게 메시지를 보내고, 메시지에 따라 적절하게 반응하는 핸들러를 정의할 수 있다.

 

핸들러를 상속하는 방법

public static class ReactionHandler extends Handler {
    public static final int WOW = 0;
    public static final int OOPS = 1;
    public static final int AWESOME = 2;
    
    @Override
    public void handleMessage(Message msg) {
        switch(msg.what) {
            case WOW:
                sayWord("wow");
                break;
            case OOPS:
                sayWord("oops");
                break;
            case AWESOME:
                sayWord("awesome");
                break;
            default:
                super.handlerMessage(msg);
        }
    }
    
    private void sayWord(String word) {...}
}


private Handler handler;
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    handler = new ReactionHandler(Looper.getMainLooper());
    ...
}

 

Hander.Callack을 상속해 callback으로 조합하는 방법

public static class ReactionCallback implements Handler.Callback {
    public static final int WOW = 0;
    public static final int OOPS = 1;
    public static final int AWESOME = 2;
    
    @Override
    public boolean handleMessage(Message msg) {
        switch(msg.what) {
            case WOW:
                sayWord("wow");
                break;
            case OOPS:
                sayWord("oops");
                break;
            case AWESOME:
                sayWord("awesome");
                break;
            default:
                false;
        }
        return true;
    }
    
    private void sayWord(String word) {...}
}


private Handler handler;
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    handler = new Handler(Looper.getMainLooper(), new ReactionCallback());
    ...
}

 

두 방법을 둘 다 사용할 수도 있다.

 

메시지 보내는 방법

handler.sendEmptyMessage(AWESOME);


// Handler.java 안

public final boolean sendEmptyMessage(int what)
{
    return sendEmptyMessageDelayed(what, 0);
}

//sendEmptyMessage로 받은 int 값이 Message의 what으로 넣어져 큐에 추가된다.
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageDelayed(msg, delayMillis);
}

 

기다리는 메시지 취소하는 방법

handler.removeMessage(AWESOME);

취소하기를 원하는 메시지의 참조를 유지할 필요가 없다. what 변수로 메시지를 그냥 취소할 수 있다.

 

 

메시지 전송 vs Runnable 전송 비교

실행 시간 차이 : 효율성의 문제

핸들러가 원할 때마다 Runnable의 새로운 인스턴스를 생성하면 가비지 컬렉션 과부하를 수반하게 된다.

메시지 전송은 application-wide pool에서 재사용 가능한 메시지 인스턴스를 공급한다.

 

개발 시간 차이

Runnable을 사용하면 Runnable.run 코드로 사용하기 쉽다... 시간이 적게 걸린다...고 책에서 말하는 거 같다. 

메시지 사용시, 단일 위치(Handler.handleMessage)에서 준비 작업을 정의해야 하는데 시간이 걸린다.

 

애플리케이션이 프로토타입이고, 소규모 단발성으로 사용한다면 Runnable 게시가 빠르고 쉽다.

애플리케이션의 규모가 커지면 메시지 전송이 좋다고 한다. 메시지가 가비지 최소화를 유지하고 앱을 부드럽게 실행하기 위한 플랫폼으로 통용되기 때문이라고 한다.

 

메인 스레드에서 백그라운드로 작업 보내기, 혹은 백그라운드 스레드에서 다른 스레드로 작업 보내기 > Handler와 HandlerThread를 이용할 수 있다. 

 

Handler에 HandlerThread의 루퍼를 사용하는 것.

HandlerThread thread = new HandlerThread("bg", Process.THREAD_PRIORITY_BACKGROUND);

thread.start(); // 반드시 필요

Handler handler = new Handler(thread.getLooper());

handler.post(new Runnable() {
   public void run() {
       //...백그라운드 스레드에서 작업 수행
   }
});

 

특정 액티비티를 위한 백그라운드 작업을 하기 위해, 자원 누수를 막기 위해 액티비티의 생명주기에 가깝게 HandlerThread의 생명주기와도 묶기

HandlerThread.quit을 호출하는 것. HandlerThread를 종료시켜서 큐의 작업을 더 이상 처리하지 못하게 함.

API 레벨 18에서 추가된 quitSafety()는 종료하기 전에 HandlerThread가 남아있는 모든 작업을 처리하도록 한다. 종료된 다음에는 어떤 작업도 받지 않는다.

private HandlerThread thread;
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstatnceState);
    thread = new HandlerThread(...);
}

protected void onPause() {
    super.onPause();
    if ((thread != null) && (isFinishing())) {
        thread.quite();
    }
}

 

Handler를 사용하면서 나오는 이슈

암시적 참조 누수

발생 예

//액티비티 내부에서 핸들러 사용
final Runnable runnable = new Runnable() {
    public void run() {
        // ...작업 수행
    }
};

handler.postDelayed(runnable, TimeUnit.SECONDS.toMillis(10));

 

액티비티가 10초 안에 끝나면 Runnable을 가비지를 수집할 수 없다. Runnable의 암시적 참조는 라이브 객체live object가 여전히 액티비티에 접근함을 의미하기 때문이다.

 

해결책

• 방법 1: 비정적 내부 클래스 사용을 피하는 것이다. Runnable을 최상위 클래스로 선언하거나, 액티비티 서브클래스에서 정적 클래스(static)로 선언하는 것. 참조를 명시적으로 만드는 것이다. 
• 방법 2:  onPause()와 같은 액티비티 생명주기 콜백에서 기다리는 작업은 취소하기
• 방법 3 : HandlerThread 인스턴스의 경우에는 액티비티를 종료할 때 차후 실행을 막고 가비지 컬렉션을 위해 Runnable 객체와 메시지 객체를 풀어주는 quit을 반드시 확인하기

 

명시적 참조 누수

 

사용자 인터페이스와 상호작용하는 중에, 뷰 계층의 객체로 인한 참조로 참조 누수가 일어날 수 있다.

 

발생 예

static class MyRunnable implements Runnable {
    private View view;
    public MyRunnable(View view) {
        this.view = view;
    }
    
    public void run() {
        //  ... 뷰와 함께 작업 수행
    }
}

뷰에 대한 참조를 유지하기 때문에 Runnable이 뷰보다 더 오래 생존한다면 잠재적 메모리 누수 대상이 된다.

 

해결책

 

• 방법 1 : 약한 참조를 사용하되, 참조된 뷰를 사용하기 전에 널을 확인한다.

static class MyRunnable implements Runnable {
    private WeakReference<View> view;
    public MyRunnable(View view) {
        this.view = new WeakReference<View>(view);
    }
    
    public void run() {
        View v = view.get(); // 널을 반환할 수도 있음
        if(v != null) {
            //  ... 뷰와 함께 작업 수행
        }
    }
}

 

 

• 방법 2 : 메시지 전송을 이용한다면, onResume과 onPause에서 핸들러를 붙이고 떼내기

private static class MyHandler extends Handler {
    private TextView view;
    public void attach(TextView view) {
        this.view = view;
    }
    publci void detach() {
        view = null;
    }
    @Override
    public void handleMessage(Message msg) {
        //...
    }
}