AOSP FRAMEWORK

스레드관련

2020-09-09T00:00:00+00:00

스레드 구조

스레드 - 루퍼 - 핸들러

루퍼와 핸들러로 스레드간의 통신을 한다.

핸들러는 요청을 받아서 큐에넣는다.

루퍼는 큐에서 하나씩 뽑아서

핸들러에게 처리하라고 던져준다

다른스레드 » 핸들러로요청 » 루퍼의QUQUE »핸들러로전달 » 처리

스레드는 하나의 Looper를 가지며

Looper는 하나의 message queue를가짐

스레드에서 looper, handler를 생성할때 둘을 연결함

스레드종류

HandlerThread exends thread «.start를 호출해서 스레드 생성, looper와 handler를 멤버로가짐

Servicethread extends handlerthread « 서비스 스레드 종료되면 안되는것들

UI스레드

모든 UI관련 처리를 하는 singleton 스레드

ui에서 지연이 생기면 상호작용이 멈추기때문에

ui스레드 이외엔 ui에 접근할수없게해놓음

메인스레드 (UI스레드)

frameworks/base/core/java/android/app/ActivityThread.java

activitythread.java 클래스이며

public static void main(string[] args)

메인함수가있음

앱이 시작될때 생성되며,

사용자에게 보여지는 UI 접근, 업데이트를 UI스레드에 요청.

컴포넌트(액티비티, 서비스, 브로드캐스트 리시버, Application) 처리를담당.

다른스레드 클래스들

Displaythread 화면관리 스레드 ,

이 스레드를 사용하는 클래스는 displaymanager, inputmanager , windowmanager 뿐임

Connectivitythread :: 네트워크 관련

Backgroundtheread :: 백그라운드 태스크관련

surfaceview :: view 자체가 스레드인 view

동기화

구현 메서드가 여러 스레드로부터 접근되는경우

주로 원격호출에서 발생

ibinder호출이 binder와 동일한 프로세스이면 호출자의 스레드에서 실행

만약 다른프로세스로부터의 호출이면 다른프로세스의 호출도 현재 스레드에서 실행됨

동기화 자료구조 테스트2

2020-09-02T00:00:00+00:00

스레드 4개를 생성후

자료구조를 바꿔가며 정수 10000개를 add,get

각 스레드들이 연산을 하는데 걸리는시간과

모든스레드가 작업을 완수할때까지의 시간을측정

여러번 실행해서 제일 평균에 가까운값

1.일반 arraylist

2.arraylist 동기화블럭

add를 부르는 method를 동기화처리.

–현재 안드로이드에서 보이는코드

–collection.synchronizedarraylist 는 read작업에도 lock이 걸려서 안쓰는듯함

read는 동기화를 걸지않아서 1번 결과와 다를게없음.

대신에 size를 매번 연산해보기로함

10000개의 원소인데 성능차이가 그렇게 많이안남

3.copyonarraylist

쓰기는 매우느리고

읽기는 멀티스레드 환경에서는 확실히 이점이있음

2번이 일반적인 상황에서 제일 합리적으로보임

copyonarraylist 를 사용하려면 데이터의 갯수가 적지않고

읽기가 많고 매우 정적인 데이터와 관련된 배열을 찾아야 장점을 살릴수있을듯함

copyonarraylist 테스트

2020-08-26T00:00:00+00:00

각각 자료구조 생성후 정수 10000개를

add , get 하는데 걸리는 시간측정

이런 모양으로 자료구조만 바꾸어서 테스트 해보았습니다

매번 오락가락 하지만 대체적으로 읽는 효율이 괜찮고

쓰는효율은 좀 심각합니다

멀티스레드 환경이라면 더 이득이 있을거같지만

쓰기 성능이 너무 느려서 잃는게 더 많을거같아보입니다

화면 회전

2020-08-12T00:00:00+00:00

화면 회전시 컨텐츠 변경방법 조사

앱개발자는 개발시에 xml에 landscape, portrait 2가지 버젼의 app layout을

미리 작성해두어야한다.

그리고 화면구성이 바뀔시에 다른 버젼의 xml로 변경함으로써 회전을핸들.

회전시 실제 일어나는 일과 느린이유?

https://developer.android.com/guide/topics/resources/runtime-changes 에 따르면,

안드로이드는 기본적으로 configuration class에서 회전을 포함한

그 어떤 멤버라도 변화가 생기면 view만 새로 가져오는게아니라

activity 자체를 완전히 destory한후 다시 start, resume 을 거친다

즉 회전할때마다 사실상 프로세스를 재시작 시키며.

재시작전에 기존의 데이터들을 save 하고 재시작후 restore한다.

이렇게 하는이유는 이것이 변경처리 오류 가능성을 줄이기 떄문이라고한다.

하지만 단점도 있는데 문서의 내용에 따르면,

기존데이터가 복잡하거나, activity에 network, background task가 걸려있으면

그 저장,복구가 오래걸리며, 데이터 손실의 가능성도 있다고한다.

? 아이폰은 액티비티의 재시작없이 처리한다고함.

해결책?

이런 재시작을 막을 방법을 2가지를 제시해줬는데

하나는 재시작을 제한을 미리 선언하는것이다.

그런데 이렇게하면 개발자가 직접 모든 구성변경시 발생가능한 예외를 모조리 직접처리해야하고

하나라도 빼먹으면 회전이 적용되지 않는다고함. 구글은 추천하지않음

둘째는 view model로 재시작은 하지만 데이터를 view 자체에 저장하는 view class인

viewmodel을 이용해서 데이터 저장 - 복구의 오버헤드를 줄이는 방법이다.

화면 회전 관련내용

2020-08-05T00:00:00+00:00

평소에 폰을 사용할때 디스플레이의 방향전환, 회전이 발생할때

뭔가 반응이 느리고 멈추는일이 잦은거같아서 찾아보았습니다

(센서감지callback or 앱 – 프레임워크 메소드호출)

public void setRequestedOrientation(@ActivityInfo.ScreenOrientation int requestedOrientation) {

5759 if (mParent == null) {

5760 try {

5761 ActivityManager.getService().setRequestedOrientation(

5762 mToken, requestedOrientation);

5763 } catch (RemoteException e) {

5764 // Empty

5765 }

5766 } else {

5767 mParent.setRequestedOrientation(requestedOrientation);

5768 }

5769 } ` 액티비티 매니저의 setrequested orientation 호출

그후에 activityrecord 의 setRequestedOrientation 호출

2193 void setRequestedOrientation(int requestedOrientation) {

2194 final int displayId = getDisplayId();

2195 final Configuration displayConfig =

2196 mStackSupervisor.getDisplayOverrideConfiguration(displayId);

2197

2198 final Configuration config = mWindowContainerController.setOrientation(requestedOrientation,

2199 displayId, displayConfig, mayFreezeScreenLocked(app));

2200 if (config != null) {

2201 frozenBeforeDestroy = true;

2202 if (!service.updateDisplayOverrideConfigurationLocked(config, this,

2203 false /* deferResume */, displayId)) {

2204 mStackSupervisor.resumeFocusedStackTopActivityLocked();

2205 }

2206 }

2207 service.mTaskChangeNotificationController.notifyActivityRequestedOrientationChanged(

2208 task.taskId, requestedOrientation);

2209 }

여기서 display (출력 device) 의 config를 변경한후에

config를 적용하도록 하는듯 보입니다.

275 public Configuration setOrientation(int requestedOrientation, int displayId,

276 Configuration displayConfig, boolean freezeScreenIfNeeded) {

277 synchronized(mWindowMap) {

278 if (mContainer == null) {

279 Slog.w(TAG_WM,

280 “Attempted to set orientation of non-existing app token: “ + mToken);

281 return null;

282 }

283

284 mContainer.setOrientation(requestedOrientation);

285

286 final IBinder binder = freezeScreenIfNeeded ? mToken.asBinder() : null;

287 return mService.updateOrientationFromAppTokens(displayConfig, binder, displayId);

288

289 }

290 }

윈도우 매니저 서비스 디렉토리에있는

AppWindowContainerController.java 에서..

2574 boolean updateOrientationFromAppTokensLocked(boolean inTransaction, int displayId) {

2575 long ident = Binder.clearCallingIdentity();

2576 try {

2577 final DisplayContent dc = mRoot.getDisplayContent(displayId);

2578 final int req = dc.getOrientation();

2579 if (req != dc.getLastOrientation()) {

2580 dc.setLastOrientation(req);

2581 //send a message to Policy indicating orientation change to take

2582 //action like disabling/enabling sensors etc.,

2583 // TODO(multi-display): Implement policy for secondary displays.

2584 if (dc.isDefaultDisplay) {

2585 mPolicy.setCurrentOrientationLw(req);

2586 }

2587 if (dc.updateRotationUnchecked(inTransaction)) {

2588 // changed

2589 return true;

2590 }

2591 }

2592

2593 return false;

2594 } finally {

2595 Binder.restoreCallingIdentity(ident);

2596 }

2597

윈도우매니저 서비스에서…

뒤에도 같은 클래스내의 함수인데 lock이 걸린함수를 부르는걸로보아

완전히 회전이 완료되기전까지 앱을 freeze 하는듯 보입니다.

이런 멈춤을 최소화하려면 회전된 비트맵을 빨리 그려야할거같습니다.

혹은중간 과정을 줄여야 할거같습니다.

ㅡㅡ아이디어?

만약 기존 비트맵처럼 그린다면..

1.코드의 비트맵을 그릴떄,

2.회전상태, 반전상태에 따라서 if 문을 사용함

3.그리고 getpixel,setpixel 의 메소드를 사용해서 오버헤드가 걸림

회전4가지 상태에 그 반전으로 8가지이고

역행렬,좌우반전,상하반전 이렇게 3가지를 flag로 두면

if문 없이도 8가지 상태를 표현할수 있을거같았음.

if문의 오버헤드를 줄이고,

90도의 rotation과

vertical, horizontal flip ,

transpose

관련된 함수를 하나로 합칠수있을것으로보임.

+getpixel, setpixel 함수호출의 오버헤드를 없앨수있음

이 호출은 확실히 성능에 안좋다.

단점:

빨라질지의문 =(if문의 오버헤드 가 true false boolean혹은 bit 연산의 오버헤드보다 큰게맞는가?)

코드를 알아보기 힘들어짐.

만약에 식을 이렇게

2개의 플래그를 두고 8개의 상태를표현하면

,, 각각 flag의 이름은 ft,fw,fh

기본 = f f f

좌우 = f t f

상하 = f f t

대칭 = f t t

TP = t f f

좌우 = t t f

상하 = t f t

대칭 = t t t

즉 높이H , 너비W 인 비트맵이미지에서

for (i<H-1 …h++)

for(i<W-1 …w++) // 메모리접근은 0부터 세므로 각각 -1

h*row + w

의 반복으로 모든 픽셀을 순회한다면

!ft & ( (W+1) * (fh(H-2 * h)+h) + fw(W-2 * w)+w )

ft & ( (H+1) * (fh(W-2 * w)+w) + fw(H-2 * h)+h )

ft에 따라서 w h 변환 여부 결정 (flag 설정시 w,h를 미리 교환해야할거같다)

fw에 따라서 좌우반전

fh에 따라서 상하반전 여부가 결정

적용해보려면 실제로 비트맵을 그리는 코드를 찾아야할거같습니다

조사

2020-07-29T00:00:00+00:00

PointlessBooleanExpression 바이트코드

to 바이트코드

if문 부터 print 까지 동일한 구조로 컴파일되어

컴파일러가 미리 최적화를 해줌을 알수있었습니다

arraylist for loop

viewrootimpl . setwindowstopped 의 경우

mwindowstoppedcallbacks.size()를 매번 호출

mWindowstoppedcallbacks 는 WindowStoppedcallback의 arraylist

windowstoppedcallback은 인터페이스로 바로위에 정의됨

windowstoppedcallback은 surfaceview의 interface이며

(=surface가 callback의구현)

interface의 함수 windowstopped를 override 구현

updatesurface호출시 surfaceview 객체의 msurface를 release

ㅡㅡ호출

activity의 perforstop 메소드에서

windowmanagerglobal.setstoppedstate 호출시.

에서 root.setwinodwstooped를호출

작동==activity가 stop되었을떄,

activity에 해당하는

window(=viewrootimpl)객체의 view를 render하는

메인renderer thread를 stop한후

메인과 따로도는 surfaceview 의 renderer를

window가 가진 surface갯수 (mwindowstoppedcallbacks.size())

만큼 돌면서 전부 종료

결론== arraylist의 synchronize를위한 코드로보입니다

일단 호출한 메소드에서 synchronize(mlock)을 걸고, 다른 호출진입지점이 없어보이므로

size를 매번구하지 않아도 될거같지만 activity작성 하기에따라 예외가 발생할수도있어보입니다.

그리고 window는 빠르게 화면을 업데이트해야 하는경우 아니면

surfaceview를 사용하지않고 하더라도 많아야 2개를 사용하는점으로보아

최적화를 한다해도 그 영향이 크지않을것으로 보입니다.

다른 size() 함수들도 거의다 arraylist의 concurrency 때문에

이렇게 작성된듯 보입니다.

의심가는부분

2020-07-22T00:00:00+00:00

성능의심가는 부분들최대한 찾아보기

supresswarnings 관련자료

viewrootimpl.java

@SuppressWarnings(
{ 
"EmptyCatchBlock", "PointlessBooleanExpression"
} 
)

java.lang.SuppressWarning : 어노테이션을 사용하여 컴파일 단위의 서브세트와 관련된 컴파일 경고를 사용하지 않도록 설정할 수 있게 해주는기능.

-여기서는 2가지의 경고를 제외했는데

어떤경우에 뜨는 경고들을 억제하는 것인지 정적 코드 분석 도구 Checkstyle 소스포지 (checkstyle – Checkstyle 8.34) 에서 관련 경고내용이 실려있습니다.

EmptyCatchBlock

// Such empty blocks would be both suppressed: 

try {
  throw new RuntimeException();
} catch (RuntimeException expected) {
}
try {
  throw new RuntimeException();
} catch (RuntimeException ignore) {
}
      

주석만있거나

빈블럭

주요 클래스에서 약 20개정도 발견할수있었습니다

###### 2.PointlessBooleanExpression 부분

     boolean method (string string) {
            return string.endswith ("a") == true;   // violation
      }      

 boolean method (string string) {
        return string.endswith ("a");
    }

“a” == true.fasle 등 true.false로 끝나는 의미없는 expression

발생이유는 자동리팩터링 혹은 , 프로그래머가 알아보기쉬우려고 if(boolean == false)꼴로 풀어쓴것

위 코드 최적화시 바이트 코드 5byte를 절약가능하다고 합니다.

viewrootimpl.java   ㅡ
  
      private void reportNextDraw() {
        if (mReportNextDraw == false) {
            drawPending();
        }
        mReportNextDraw = true;
        }

주요 클래스 검색결과 3개의 경우를 발견할수있었습니다

반복문 관련

viewrootimpl.java
   
   private final ArrayList<WindowStoppedCallback> mWindowStoppedCallbacks =  new ArrayList<>();
	
	
	
	
    void addWindowStoppedCallback(WindowStoppedCallback c) 
	{ 
        mWindowStoppedCallbacks.add(c);
		
	} 
	
    void removeWindowStoppedCallback(WindowStoppedCallback c) 
	{ 
        mWindowStoppedCallbacks.remove(c);
		
	}  
   
      void setWindowStopped(boolean stopped) {
        if (mStopped != stopped) {
            mStopped = stopped;
            final ThreadedRenderer renderer = mAttachInfo.mThreadedRenderer;
            if (renderer != null) {
                if (DEBUG_DRAW) Log.d(mTag, "WindowStopped on " + getTitle() + " set to " + mStopped);
                renderer.setStopped(mStopped);
            }
            if (!mStopped) {
                scheduleTraversals();
            } else {
                if (renderer != null) {
                    renderer.destroyHardwareResources(mView);
                }
            }

            for (int i = 0; i < mWindowStoppedCallbacks.size(); i++) {
                mWindowStoppedCallbacks.get(i).windowStopped(stopped);
            }
        }
    }

setWindowStopped이란 메소드의 끝부분 for문에서 .size()를 호출함.

private final ArrayList mWindowStoppedCallbacks = new ArrayList<>(); //WindowStoppedCallback 의 arraylist

public class SurfaceView extends View implements ViewRootImpl.WindowStoppedCallback { //WindowStoppedCallback은 SurfaceView 클래스로 구현됨

호출은 windowmanager global

  public void setStoppedState(IBinder token, boolean stopped) {
        synchronized (mLock) {
            int count = mViews.size();
            for (int i = 0; i < count; i++) {
                if (token == null || mParams.get(i).token == token) {
                    ViewRootImpl root = mRoots.get(i);
                    root.setWindowStopped(stopped);
                }
            }
        }
    }

ViewRootImple 객체인 mRoot를 돌면서 전부 정지?? .. 정말 필요해서 size를 매번 구하는건지 좀더 파악해야 알수있을것같습니다

view 디렉토리 내 주요 java클래스에서 검색한결과

if문

2020-07-02T00:00:00+00:00

확인방법: 바이트코드

if(a && b && c && d && e && f && g)

if(a)
 if(b)
  if(c)
   if(d)
    if(e)
     if(f)
      if(g)

:둘다 동일한 바이트코드로 컴파일됨.

boolean a=true, b=true, c=true, d=true, e=true, f=true, g=true;
iconst_1
istore_1
iconst_1
istore_2
iconst_1
istore_3
iconst_1
istore        4
iconst_1
istore        5
iconst_1
istore        6
iconst_1
istore        7

if(a && b && c && d && e && f && g) {}
iload_1
ifeq          45
iload_2
ifeq          45
iload_3
ifeq          45
iload         4
ifeq          45
iload         5
ifeq          45
iload         6
ifeq          45

if(a) if(b) if(c) if(d) if(e) if(f) if(g) {}
iload_1
ifeq          72
iload_2
ifeq          72
iload_3
ifeq          72
iload         4
ifeq          72
iload         5
ifeq          72
iload         6
ifeq          72

최적화

1.스위치문

public int calculate(int a, int b, String operator) {
    int result = Integer.MIN_VALUE;
 
    if ("add".equals(operator)) {
        result = a + b;
    } else if ("multiply".equals(operator)) {
        result = a * b;
    } else if ("divide".equals(operator)) {
        result = a / b;
    } else if ("subtract".equals(operator)) {
        result = a - b;
    }
    return result;
}

public int calculateUsingSwitch(int a, int b, String operator) {
    switch (operator) {
    case "add":
        result = a + b;
        break;
    // other cases    
    }
    return result;
}

장점 : 간단, 유지보수용이 단점 : 복잡한논리엔 부적합

리팩토링

3.1 팩토링클래스 ::원하는 타입 객체를 반환

연산 인터페이스

public interface Operation {
    int apply(int a, int b);
}

구현

public class Addition implements Operation {
    @Override
    public int apply(int a, int b) {
        return a + b;
    }
}

구현클래스들의 hashmap소유 클래스 //map으로 두면 더빠름

public class OperatorFactory {
    static Map<String, Operation> operationMap = new HashMap<>();
    static {
        operationMap.put("add", new Addition());
        operationMap.put("divide", new Division());
        // more operators
    }
 
    public static Optional<Operation> getOperation(String operator) {
        return Optional.ofNullable(operationMap.get(operator));
    }

숫자, 연산자를 받아 , 팩터링클래스에 넘긴후 객체를 return받기

public int calculateUsingFactory(int a, int b, String operator) {
    Operation targetOperation = OperatorFactory
      .getOperation(operator)
      .orElseThrow(() -> new IllegalArgumentException("Invalid Operator"));
    return targetOperation.apply(a, b);
}

3.2 Enums

logic에 enum 부여 ,if , switch , factor의 조건으로 사용

연산 label 지정

public enum Operator {
 ADD, MULTIPLY, SUBTRACT, DIVIDE
}

구현

ADD {
    @Override
    public int apply(int a, int b) {
        return a + b;
    }
},
// other operators
 
public abstract int apply(int a, int b);

3.라우터

public int calculate(int a, int b, Operator operator) {
    return operator.apply(a, b);
}

Operator#valueOf() method 로 String 을 operator로 변환해서 사용

@Test
public void whenCalculateUsingEnumOperator_thenReturnCorrectResult() {
    Calculator calculator = new Calculator();
    int result = calculator.calculate(3, 4, Operator.valueOf("ADD"));
    assertEquals(7, result);
}

3.3명령패턴

명령을받는 Calculator#calculate which can be executed on the inputs. //중첩 if 개선

1.커맨드

public interface Command {
    Integer execute();
}

2.add커맨드

public class AddCommand implements Command {
    // Instance variables
 
    public AddCommand(int a, int b) {
        this.a = a;
        this.b = b;
    }
 
    @Override
    public Integer execute() {
        return a + b;
    }
}

3.command를 받는 method

public int calculate(Command command) {
    return command.execute();
}

4.AddCommand객체생성, Calculator#calculate method에 보내기:

@Test
public void whenCalculateUsingCommand_thenReturnCorrectResult() {
    Calculator calculator = new Calculator();
    int result = calculator.calculate(new AddCommand(3, 7));
    assertEquals(10, result);
}

3.4룰엔진

중첩 if문 평가 규칙 규칙과 입력에따라 반환 복잡성제거

1.rule

public interface Rule {
    boolean evaluate(Expression expression);
    Result getResult();
}

2.rule engine

public class RuleEngine {
    private static List<Rule> rules = new ArrayList<>();
 
    static {
        rules.add(new AddRule());
    }
 
    public Result process(Expression expression) {
        Rule rule = rules
          .stream()
          .filter(r -> r.evaluate(expression))
          .findFirst()
          .orElseThrow(() -> new IllegalArgumentException("Expression does not matches any Rule"));
        return rule.getResult();
    }
}

RuleEngine은 Expression object를받아 결과반환 Expression:

public class Expression {
    private Integer x;
    private Integer y;
    private Operator operator;        
}        //두 정수와 연산의 expression

addrule

public class AddRule implements Rule {
    @Override
    public boolean evaluate(Expression expression) {
        boolean evalResult = false;
        if (expression.getOperator() == Operator.ADD) {
            this.result = expression.getX() + expression.getY();
            evalResult = true;
        }
        return evalResult;
    }    
}

호출: engin.process(expression)

@Test
public void whenNumbersGivenToRuleEngine_thenReturnCorrectResult() {
    Expression expression = new Expression(5, 5, Operator.ADD);
    RuleEngine engine = new RuleEngine();
    Result result = engine.process(expression);
 
    assertNotNull(result);
    assertEquals(10, result.getValue());
}

assert문:: //jdk1.4 이상

assert expression1; //참:pass 거짓:AssertionError

assert expression1: expression2; //exp1참 : pass 거짓 : exp2출력

출처::

https://www.baeldung.com/java-replace-if-statements

윈도우 매니저

2020-05-13T00:00:01+00:00

SurfaceFlinger::

여러 개의 Surface를 하나의 Surface로 만들고 만든 화면을 프레임 버퍼 드라이버와 연계하여 프레임 버퍼로 만들고, (프레임버퍼에 등록?)LCD 화면에 표시하는 역할

surface :: 창

새창추가 = 새 surface할당

WindowManager :: 애플리케이션과 WindowManagerSerivce 간의 소통interface

ViewManager를 상속하여 구현됨

public interface ViewManager{
    / / Add View
    public void addView(View view, ViewGroup.LayoutParams params);
    / / Update View
    public void updateViewLayout(View view, ViewGroup.LayoutParams params);
    / / Delete View
    public void removeView(View view);
}Copy code

1.Add 2.Update 3.Delete ㅡ3개의 method를 가짐

WindowManager 의 구현클래스 = WindowManagerImpl

WindowManagerImpl의 기능구현클래스 = WindowManagerGlobal

public final class WindowManagerGlobal {
 
     public void addView(View view, ViewGroup.LayoutParams params,
                Display display, Window parentWindow) {
            / / Check the validity of the parameters
            ...
 
            //ViewRootImpl encapsulates the interaction between View and WindowManager
            ViewRootImpl root;
            View panelParentView = null;
 
            synchronized (mLock) {
                // Start watching for system property changes.
                if (mSystemPropertyUpdater == null) {
                    mSystemPropertyUpdater = new Runnable() {
                        @Override public void run() {
                            synchronized (mLock) {
                                for (int i = mRoots.size() - 1; i >= 0; --i) {
                                    mRoots.get(i).loadSystemProperties();
                                }
                            }
                        }
                    };
                    SystemProperties.addChangeCallback(mSystemPropertyUpdater);
                }
 
                int index = findViewLocked(view, false);
                if (index >= 0) {
                    if (mDyingViews.contains(view)) {
                        // Don't wait for MSG_DIE to make it's way through root's queue.
                        mRoots.get(index).doDie();
                    } else {
                        throw new IllegalStateException("View " + view
                                + " has already been added to the window manager.");
                    }
                    // The previous removeView() had not completed executing. Now it has.
                }
 
                // If this is a panel window, then find the window it is being
                // attached to for future reference.
                if (wparams.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
                        wparams.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
                    final int count = mViews.size();
                    for (int i = 0; i < count; i++) {
                        if (mRoots.get(i).mWindow.asBinder() == wparams.token) {
                            panelParentView = mViews.get(i);
                        }
                    }
                }
 
                / / Build ViewRootImpl through the context
                root = new ViewRootImpl(view.getContext(), display);
 
                view.setLayoutParams(wparams);
 
                //mViews stores all View objects corresponding to Window
                mViews.add(view);
                //mRoots stores all ViewRootImpl objects corresponding to Window
                mRoots.add(root);
                //mParams stores all WindowManager.LayoutParams objects corresponding to Window
                mParams.add(wparams);
            }
 
            // do this last because it fires off messages to start doing things
            try {
                / / Call the ViewRootImpl.setView () method to complete the addition of Window and update the interface
                root.setView(view, wparams, panelParentView);
            } catch (RuntimeException e) {
                // BadTokenException or InvalidDisplayException, clean up.
                synchronized (mLock) {
                    final int index = findViewLocked(view, false);
                    if (index >= 0) {
                        removeViewLocked(index, true);
                    }
                }
                throw e;
            }
        }
 
}Copy code

중요멤버

mViews view 객체 저장

mRoots ViewRootImpl 객체 저장

mParams WindowManager.LayoutParams 객체 저장

ViewRootImpl 클래스:: View와 WindowManager간 상호작용을 캡슐화하는 래퍼클래스

ViewRootImpl.setView() 호출 :::창의 추가와 업데이트완료를 위해

바인더 관련

2020-04-08T00:00:01+00:00

바인더

원래 IPC(Inter Process Communication) 도구이지만 안드로이드에서는 다른 프로세스에 있는 함수를 마치 현재 프로세스에 존재하는 함수처럼 사용할 수 있게 해주는 RPC(Remote Procedure Call)를 지원하는 데 주로 이용

안드로이드에서 바인더 드라이버를 추가해서 프로세스 간 통신을 수행하는 이유?

리눅스의 뛰어난 메모리 관리 기법을 그대로 채용함으로써 커널 공간을 통한 데이터 전달시 데이터의 신뢰성을 확보

사용자 공간에서 접근할 수 없는 공간인 커널 공간을 이용해 데이터를 주고 받기 때문에 IPC 간의 보안 문제도 동시에 해결

카메라앱의 바인더호출

Camera 서비스의 내부 동작

Camera.cpp는 Camera::getCameraService()를 통해서 ICameraService 를 호출한다.

실제는 BpCameraService가 호출될 때 이루어진다. BpCameraService는 binder를 통해서 두 프로세스 사이의 BnCameraService 통신채널을 생성한다. BpCamera Service의 connect()함수에서는 다음과 같이 BnCamera Service를 연결시키는 부분이 있다.

remote()->transact(BnCameraService::CONNECT, data, &reply);

Camera server로의 서비스 요청

카메라 서비스로의 접속은 서비스 매니저로부터 Camera Service를 담당하는 binder class인 ICamera Service를 get함으로써 이루어진다. 물론, 그 전에 ICameraClient 형의 Camera class를 생성함으로써 Camera client로부터 Camera server(카메라 서비스)로의 Binder 연결이 이루어진다.

CONNECT command를 통해서 카메라 서비스로 접속을 하게 되면 카메라 서비스 쪽에서는 server에서 client로 접속되는 ICamera 형의 client class를 생성해서 Camera client 쪽으로 할당해 준다. ICameraService를 이용한 Binder interface는 CONNECT command외에 다른 command는 존재하지 않는다. 이 Class는 오직 connect를 받아서 새로운 Binder를 생성(server에서 client로의 data 통로를 여는)하기만 할 뿐이다.

위의 메커니즘 설명은 이러한 부분에 대한 기술적인 설명을 하는 부분이 된다. IPC인 Binder 부분은 실제 호출되는 부분과 실행되는 부분이 감추어져 있기 때문에 코드에 대한 추적이 어렵다.

즉, ICameraService.cpp의 BpCameraService의 connect()를 통해, CameraService.cpp의 Camera

Service::onTransact() 로 아래의 내용을

status_t err = BnCameraService::onTransact(code, data, reply, flags);

호출함으로써 두 개의 프로세스간 BnCameraService()통신채널을 구성하게 된다. 실제 BpCameraService의 구현은 CameraServicce에서 이루어진다고 보면 된다. Camera.cpp는 다른 프로세스로 동작 하지만, 그 인터페이스는 ICameraService의 connect()를 호출함으로써 CameraService의 ICamera class인 CameraService:: Client를 획득할 수 있게 된다. Camera에 관련된 함수들은 CameraService:: Client 가 생성되면서 실제로 구현된다.

출처 : 테크월드(http://www.epnc.co.kr)