Android 지식 정리: 메시지 메커니즘 의 Handler

Android 지식 정리: 메시지 메커니즘 의 Looper
http://gqdy365.iteye.com/blog/2137494
1. Handler 류 는 원본 코드 의 android. os 패키지 아래 에 있 습 니 다. 주로 메시지 의 전송 과 처리 에 사 용 됩 니 다. 주의: 여기 있 는 메 시 지 는 스 레 드 일 수 있 습 니 다. 즉, Handler 는 일반 메시지 와 스 레 드 가 있 는 메 시 지 를 처리 할 수 있 습 니 다.
1. 일반 정보 처리:

mHandler.sendMessage(Message msg);
mHandler.sendEmptyMessage(int msg.what);

sendEmptyMessage 에서 메시지 데이터 가 없 는 빈 메 시 지 를 보 냅 니 다.최종 적 으로 Handler 클래스 에 서 는 시스템 의 sendmessage Delayed 방법 을 호출 했 습 니 다.
2. 스 레 드 처리:

mHandler.post(Runnable r);

3. Delayed 또는 AtTime 접미사 가 있 는 방법:
이러한 방법 은 Handler 에서 최종 적 으로 AtTime 에 따라 통일 적 으로 집행 되 고 구체 적 인 처리 방식 은 다음 과 같다.

public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

2. Handler 의 생 성:
1. 구조 방법 은 네 가지 가 있다.

public Handler(){}
public Handler(Callback callback) {}
public Handler(Looper looper) {}
public Handler(Looper looper, Callback callback){}

2. 일반 실현 형식:

	static Handler mHandler = new Handler(Looper.getMainLooper()) {
		public void handleMessage(Message msg) {
			switch (msg.what) {
			case 0:
				Log.i(TAG, "--   ：   Handler--");
				break;
			}
		};
	};

	static Handler mHandler1 = new Handler(new Handler.Callback() {

		@Override
		public boolean handleMessage(Message msg) {
			switch (msg.what) {
			case 0:
				Log.i(TAG, "--   ：      --");
				break;
			}
			return false;
		}
	});
	
	static class MainHandler extends Handler{
		@Override
		public void handleMessage(Message msg) {
			switch (msg.what) {
			case 0:
				Log.i(TAG, "--   ：  Handler ,  handleMessage  --");
				break;
			}
		}
	}

Handler 를 실례 화 할 때 시스템 이 알려 줍 니 다.
The following Handler class should be static or leaks might occur
Handler 는 정적 으로 정의 해 야 한다. 그렇지 않 으 면 누 출 이 발생 할 수 있다.
구체 적 으로 는 이렇다.

if (FIND_POTENTIAL_LEAKS) {
            final Class<? extends Handler> klass = getClass();
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                    (klass.getModifiers() & Modifier.STATIC) == 0) {
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                    klass.getCanonicalName());
            }
        }

설명: 같은 스 레 드 에 있 는 handler 는 looper 대상 을 공유 합 니 다. 메시지 에 handler 에 대한 인용 이 남아 있 습 니 다. 메시지 가 대기 열 에 있 으 면 handler 는 회수 할 수 없습니다. handler 가 static 이 아니라면 Handler 의 Service 와 Activity 를 사용 해도 회수 할 수 없습니다.이것 은 메모리 유출 을 초래 할 수 있다.이게 왜 생 겼 을 까?Message Queue 는 차단 식 이기 때 문 입 니 다. 즉, 하 나 를 처리 하고 나 서 야 다음 을 처리 합 니 다. 만약 에 Message Queue 에서 지연 되 는 동작 이 있 으 면 전체 Message Queue 의 생명 주기 가 길 고 Handler 가 있 는 Service 와 Activity 를 정의 하 는 생명 주 기 를 초과 할 수 있 습 니 다.
3. 정보 처리:
안 드 로 이 드 지식 정리: 메시지 메커니즘 의 Looper (http://gqdy365.iteye.com/blog/2137494) 에서 말 한 바 와 같이 Looper 는 dispatchMessage 를 끊임없이 호출 하여 Handler 에 게 메 시 지 를 보 냅 니 다. 그러면 결국은 Handler 의 handleMessage 방법 으로 메 시 지 를 처리 합 니 다. handleMessage 는 우리 프로그래머 가 다시 쓰 는 방법 이 있 습 니 다.

    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

여기까지 와 서 Handler 는 Handler 가 매우 복잡 하 다 고 느 꼈 는 지, Handler 를 통 해 Message 를 시스템 에 보 냈 다. 시스템 은 마지막 에 우리 가 쓴 handle Message 방법 을 호출 하여 메 시 지 를 전달 하고 우리 에 게 처리 하 라 고 했 는데 이것 은 괜 히 소란 을 피 우지 않 았 습 니까?개인 이해: 시스템 이 통일 적 으로 포장 하고 줄 을 서서 정 보 를 나 누 어 준다.