[치정] [독서노트] 안드로이드 개발 예술 탐구] 제8장 노트

Windows 및 Windows Manager 이해
Window는 추상적인 종류로 구체적인 실현은 PhoneWindow이다.윈도우 관리자는 외부에서 윈도우에 접근하는 입구로 윈도우의 구체적인 실현은 윈도우 관리자 서비스에 있고 윈도우 관리자와 윈도우 관리자 서비스의 상호작용은 IPC 과정이다.안드로이드의 모든 보기는 Window를 통해 보여집니다.Activity,Dialog,Toast를 막론하고 그들의 보기는 실제적으로 Window에 추가되어 있기 때문에 Window는 실제적으로View의 직접 관리자입니다.
8.1 Window 및 Window Manager
윈도우의 작업 메커니즘을 분석하기 위해서는 먼저 코드를 통해 윈도우 관리자를 사용하여 윈도우를 추가하는 방법을 알고 다음 코드는 화면 좌표(100,300)의 위치에 버튼을 추가합니다.

mFloatingButton = new Button(this);
mFloatingButton.setText("test button");
mLayoutParams = new WindowManager.LayoutParams(
        LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT, 0, 0,
        PixelFormat.TRANSPARENT);//0,0    type flags  ，        
mLayoutParams.flags = LayoutParams.FLAG_NOT_TOUCH_MODAL
        | LayoutParams.FLAG_NOT_FOCUSABLE
        | LayoutParams.FLAG_SHOW_WHEN_LOCKED;
mLayoutParams.type = LayoutParams.TYPE_SYSTEM_ERROR;
mLayoutParams.gravity = Gravity.LEFT | Gravity.TOP;
mLayoutParams.x = 100;
mLayoutParams.y = 300;
mFloatingButton.setOnTouchListener(this);
mWindowManager.addView(mFloatingButton, mLayoutParams);

Flags 매개 변수는 Window의 속성을 나타냅니다. 일반적인 옵션은 다음과 같습니다.

FLAG_NOT_FOCUSABLE: Window에 초점을 맞출 필요도, 다양한 입력 이벤트를 받을 필요도 없음을 나타내며, 이 태그는 FLAG 를 동시에 시작합니다.NOT_TOUCH_MODEL, 최종 이벤트는 아래층의 초점 있는 윈도

에 전달됩니다

FLAG_NOT_TOUCH_MODAL: 이 모드에서는 현재 윈도 영역 이외의 클릭 이벤트를 밑에 있는 윈도에 전달하고 현재 윈도 영역 내의 클릭 이벤트는 스스로 처리합니다.이 표시는 매우 중요합니다. 일반적으로 이 표시를 켜야 합니다. 그렇지 않으면 다른 윈도에서 클릭 이벤트를 받을 수 없습니다.

FLAG_SHOW_WHEN_LOCKED: 이 모드를 켜면 잠금 화면에 표시될 수 있음

Type 매개 변수는 윈도의 종류를 나타낸다. 윈도는 세 가지 종류가 있는데 그것이 바로 응용 윈도, 하위 윈도와 시스템 윈도이다.응용 프로그램 클래스 윈도는 Activity에 해당합니다.하위 Window는 단독으로 존재할 수 없습니다. 특정한 아버지 Window에 부속되어야 합니다. 예를 들어 흔히 볼 수 있는 다이얼로그가 하위 Window입니다.시스템 윈도는 성명 권한이 있어야만 만들 수 있는 윈도입니다. 예를 들어 Toast와 시스템 상태 표시줄 등은 모두 시스템 윈도입니다.
윈도는 층으로 나뉘어져 있으며, 모든 윈도에는 대응하는 z-ordered가 있으며, 등급이 가장 큰 것은 등급이 작은 윈도 위에 덮여 있다. 이것은 HTML의 z-index 개념과 완전히 일치한다.세 가지 종류의 윈도에서 응용 윈도의 등급 범위는 1~99이고 하위 윈도의 등급 범위는 1000~1999이며 시스템 윈도의 등급 범위는 2000~2999이다. 이런 등급 속성 범위는 윈도 관리자에 대응한다.LayoutParams의 type 매개변수입니다.
TYPESYSTEM_ERROR, type 매개 변수에 대해 이 레벨만 지정하면 됩니다.
mLayoutParams.type = LayoutParams.TYPE_SYSTEM_ERROR
동시에 사용 권한을 선언합니다.
8.2 Window의 내부 메커니즘
윈도는 추상적인 개념으로 실제 존재하는 것이 아니라 View의 형식으로 존재한다. 모든 윈도는 하나의 View와 하나의 View Root Impl에 대응하고 윈도와 View는 View Root Impl을 통해 연락을 맺는다.실제 사용 중에는 윈도에 직접 접근할 수 없습니다. 윈도에 대한 접근은 윈도 관리자를 통해 해야 합니다.
8.2.1 Window 추가 프로세스
윈도우의 추가 과정은 윈도우 관리자의ddView를 통해 이루어져야 한다. 윈도우 관리자는 하나의 인터페이스이고, 진정한 실현은 윈도우 관리자 Impl 클래스이다.윈도우 관리자의 실현 클래스는ddView, 업데이트View,removeView 방법에 대해 윈도우 관리자 글로벌 클래스에 의뢰합니다.
WindowManagerGlobal의 addView 메서드는 다음과 같습니다.

파라미터가 합법적인지 확인하고 하위 윈도라면 레이아웃 파라미터를 조정해야 한다

ViewRootImpl을 생성하고 목록에 View를 추가

ViewRootImpl을 통해 인터페이스를 업데이트하고 윈도 추가 과정을 완성합니다

8.2.2 Window 삭제 프로세스
추가 과정과 마찬가지로 Window Manager Impl을 먼저 통과한 다음에 Window Manager Global을 통해 이루어진다.뷰를 실제로 삭제하는 논리는 디스패치 Detached From Window 방법의 내부에서 이루어집니다.dispatchDetachedFromWindow 방법은 주로 네 가지 일을 합니다.

쓰레기 회수 작업, 예를 들어 데이터와 메시지를 제거하고 리셋을 제거한다.

Session의remove 방법을 통해 윈도, m윈도 Session을 삭제합니다.remove (m Window), 이것은 같은 IP C 프로세스로, 최종적으로 Window Manager 서비스의 remove Window 방법을 호출합니다

View의dispatchDetachedFromWindow 방법을 호출하고 내부에서View의onDetachedFromWindow () 와onDetachedFromWindow 인터넷 () 을 호출합니다.

윈도 관리자 글로벌의doRemoveView 방법을 호출하여 데이터를 갱신합니다. mRoots, mParams, mDyingViews를 포함하여 현재 윈도와 관련된 이 세 가지 대상을 목록에서 삭제해야 합니다.

8.2.3 Window 업데이트 프로세스
먼저 View의 LayoutParams를 업데이트하고 오래된 LayoutParams를 교체한 다음에 ViewRootImpl의 LayoutParams를 업데이트해야 한다. 이 단계는 ViewRootImpl의 setLayoutParams 방법을 통해 이루어진다.ViewRootImpl에서는 측정, 레이아웃, 다시 그리기 등 세 가지 프로세스를 포함하여 scheduleTrversals 방법으로 View를 다시 레이아웃합니다.View 자체의 재그림을 제외하고 View Root Impl은 윈도 세션을 통해 윈도의 보기를 업데이트할 것이다. 이 과정은 최종적으로 윈도 관리자 서비스의relayout 윈도 ()로 구체적으로 이루어진다. 마찬가지로 IPC 과정이다.
Window 작성 프로세스
8.3.1 Activity Window 작성 프로세스
1. Activity의 시작 과정은 매우 복잡하다. 최종적으로Activity Thread의performLaunchActivity()로 전체 시작 과정을 완성한다. 이 방법 내부에서 클래스 로더를 통해Activity의 실례 대상을 만들고 그attach 방법을 호출하여 관련 운행 과정에서 의존하는 일련의 상하문 환경 변수를 호출한다.
2. Activity는 윈도의 Callback 인터페이스를 실현하고 윈도가 외부의 상태 변화를 받아들일 때Activity의 방법을 사용한다. 예를 들어onAttachedToWindow,onDetachedFromWindow,dispatchTouchEvent 등이다.
3. Activity의 Window는 Policy Manager가 만든 것이다. 그의 진정한 실현은 Policy 클래스이고 Phone Window 대상을 새로 만들 것이다.Activity의 setContent View의 실현은 Phone Window에서 이루어진다.PhoneWindow 메서드는 다음과 같은 몇 가지 단계를 따릅니다.

DecorView가 없으면 생성

DecorView의 mContentParent에 View 추가

Activity를 리셋하는 onCreateChanged 방법은Activity 보기가 변경되었음을 알립니다

8.3.2 Dialog의 Window 작성 프로세스
Dialog의 Window 작성 프로세스는 Activity와 유사하며 다음 단계를 수행합니다.

윈도 만들기: Diolog에서 윈도 만들기는 Policy Manager의makeNew 윈도 방법을 통해 이루어진 것이고 만든 대상은 실제로Phone 윈도이다.

DecorView를 초기화하고 Dialog의 보기를 DecorView에 추가

DecorView를 Window에 추가하고 표시합니다: 일반적인 Dialog는 Activity의 Context를 사용해야 하는데 Application의 Context를 사용하면 오류가 발생합니다.Token을 사용하면 Activity만 가지고 있기 때문에, 여기에는 Activity가 Context로 대화상자를 표시하기만 하면 됩니다.

8.3.3 Toast의 윈도 작성 과정
Toast 내부에는 두 가지 IPC 프로세스가 있는데 첫 번째 클래스는 Toast가 Notification Manager 서비스에 접근하는 것이고 두 번째 클래스는 Notification Manager Service가 Toast의 TN 인터페이스를 리셋하는 것이다.
Toast는 시스템 윈도에 속합니다. 내부 보기는 두 가지 방식으로 지정됩니다. 하나는 시스템의 기본 프레젠테이션이고, 다른 하나는 setView 방법을 통해 사용자 정의 View를 지정합니다.
토스트는 타이밍 취소 기능이 있어 핸들러를 적용했다.Toast의 표시와 숨김은 IPC 프로세스로 Notification Manager 서비스(NMS)가 필요합니다. Toast와 NMS가 IPC 프로세스를 진행할 때 NMS는 프로세스를 뛰어넘어 Toast의 TN 클래스를 리셋하는 방법입니다. TN 클래스는 Binder 클래스로 Binder 스레드 풀에서 실행되기 때문에 Handler를 통해 현재 발송된 Toast 요청이 있는 스레드로 전환해야 합니다.그래서 Toast는 Looper가 없는 라인에서 팝업할 수 없습니다.
비시스템 애플리케이션의 경우 mToastQueue가 최대 50개의 ToastRecord를 동시에 존재할 수 있는데, 이는 DOS(Denial of Service, 서비스 거부)를 방지하기 위한 것이다.어떤 앱이 너무 많은 토스트를 팝업하면 다른 앱이 토스트를 팝업할 기회가 없기 때문이다.