저것도 마찬가지로 Looper 에게 던져서 UI 핸들링 하도록 해주는 메쏘드입니다.

그리고 그런 방식은 유지보수성이 극도로 떨어지므로 가급적 삼가하세요..

저도 그런거 자주 썼다가 욕 먹고 안써요 - _-

delay 를 사용하고 있기 때문에 runOnUiThread() 은 검토하지 않았었습니다. 

좋은 의견이긴 한데 지금에 와서 적용할 수 있는지는 모르겠네요 ㅠㅠ

runOnUiThread는 좀 틀려요. UI쓰레드에서 호출시에는 메시지 안보내고 바로 실행하고, 백그라운드 스레드에서 호출시에만 메인으로 메시지를 보냅니다. .

ㅎㅎ 그렇군요

근데 코드 유지보수성때문에 쓰지를 않는다는게 문제죠

내부로 들어가면 iMessage를 가지고 IPC를 하는거 같은데 기역이 가물가물 하는군요..

아무튼 Looper가 추가되면 성능상에 문제가 발생되는지 모르겠네요..

조금 느려지는거 같은데 꼭 이거다 단정짓기 뭐하니 말입니다.

그냥 핸들러를 많이 사용해서 그런가? 하는 의문도 들어서 물어보게 되었네요 

그래서 Handler.obtainMessage 로 메세지를 생성하는 이유가

Looper 를 물고 있는 메세지를 계속 사용하기 위함으로 알고 있습니다.

전 Handler.obtainMessage 를 사용하지 않았습니다.

왜냐하면 대부분이 sendEmptyMessage 혹은 sendEmptyMessageDelay 라서...

Queue의 순서만 사용하게 된 셈이라서요..

Handler.obtainMessage 는 메모리와 상관이 크지 않을까요?

하긴 생성하고 지우는것도 프로세서가 힘들어하겠군요..

제가 예전에 원본 소스를 까본 기억으로는 sendEmptyMessage 도 결국엔 obtainMessage 로 메세지 생성해서 처리했던 것 같은데..

아닌가요 -ㅅ-?

/**
     * Sends a Message containing only the what value.
     *  
     * @return Returns true if the message was successfully placed in to the 
     *         message queue.  Returns false on failure, usually because the
     *         looper processing the message queue is exiting.
     */
    public final boolean sendEmptyMessage(int what)
    {
        return sendEmptyMessageDelayed(what, 0);
    }

    /**
     * Sends a Message containing only the what value, to be delivered
     * after the specified amount of time elapses.
     * @see #sendMessageDelayed(android.os.Message, long) 
     * 
     * @return Returns true if the message was successfully placed in to the 
     *         message queue.  Returns false on failure, usually because the
     *         looper processing the message queue is exiting.
     */
    public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
        Message msg = Message.obtain();
        msg.what = what;
        return sendMessageDelayed(msg, delayMillis);
    } 

원본 소스입니다 :)

좀 깨지긴 하지만 여튼 위와 같이 처리되네요

저도 그럴거라 생각해요

간혹 Message 에 여러가지 타입을 전송하지만 간혹 배열 을 전송하기도 하거든요..