WiFi Enable process 분석 - StateMachine이란 ? (1)

나는 디바이스 제조 기업에서 무선통신 기능을 구현하는 Wireless team Engineer로 근무중이다.

티스토리 블챌이 시작되서 참여하는김에 안드로이드 프레임워크의 Wifi 기능 코드를 분석한 내용을 리뷰하겠다.

코드 분석한 내용은 'WiFi를 사용자가 켰을때 어떤 동작이 수행되는가'로 초점하였다.

---

사용자가 Wifi를 켜는 순간 실행되는 코드

 

 

Wifi의 toggle이 onClick 이벤트를 발생시켜 STATE_ENABLE 상태로 전환된다.

 

그리고 Android의 wifiManager를 통해 setWifiEnabled가 실행된다.

 

 

 

WifiManager는 Binder를 통해 곧장 Framework layer의 WifiServiceImpl과 연결되어 있다.

 

이 연결 과정은 총 두가지인데, Manager - Service / Service - Hal 이다.

이 과정은 추후의 포스팅으로 Binder 원리를 설명하겠다.

 

이 WifiServiceImpl 클래스에서는 AutoJoin 모드를 활성화 하여 와이파이 자동 연결 모드로 전환하고,

ActiveModeWarden 클래스의 wifiToggled 메소드를 실행한다.

 

앞으로 이 과정에서는 이 WifiToggled 메소드 내에서 수행하는 것처럼 메시지를 주고 받아 처리하는 흐름으로 이어가는 경우가 많다.

 

이는 사용자에게 매끄러운 UI를 제공하기 위해 UI 쓰레드와 내부 요청 쓰레드의 동작을 분리하여 비동기로 처리하기 위함이고, 따라서 사용자는 Scan 과정 중에도 매끄럽게 디바이스의 다른 상호작용을 수행할 수 있다.

 

아무튼 sendMessage로 다시 돌아와서

이 메소드는 WifiController의 State Machine이라는 클래스를 가동시키는 역할을 한다.

 

여기서 StateMachine이 무엇인지 알아보고 가자.

 

State Machine? 

State Machine이란 State 상태를 관리하는 독립적인 객체이다.

 

EventListener가 sendMessage같은 이벤트를 받아 Queue에 넣으면

독립적으로 돌아가고 있는 ThreadLooper가 이 Queue에서 꺼내 Handler에서 상황에 맞는 동작을 수행한다.

 

처음엔 이 StateMachine이 무엇이고 어떻게 동작하는지 몰라서 정말 헤맸었는데,

코드를 분석하며 답을 찾을 수 있었던 것 같다.

 

State Machine은 개발자가 사용하는 것이기 때문에 목적이 있다.

 

State Machine을 사용하면 사용자의 여러가지 시나리오에 대해 추상적인 state를 두어서

설계한 패턴대로 맞물려 동작하게 할 수 있다.

 

마치 개발자가 클래스를 상속하고 정리하는 것처럼

해당 Machine에도 계층이 있어서 state의 유기적인 동작 묶음을 간편하게 정리할 수 있다.

 

이러한 처리는 각각 모두 비동기 쓰레드에 의해 비동기로 처리되지만, 모든 활동은 현재의 state에 기인하여 처리된다.

 

 

StateMachine 생성

 

 

stateMachine을 사용하는 방법은 위와 같다.

여기서는 WifiController가 StateMachine을 사용한 방법을 보겠다.

 

먼저 StateMachine을 상속받은 후,

각 state를 선언하고 addState로 상태계층을 생성한다.

 

여기서 생성한 결과는 오른쪽 상단의 트리모양과 같다.

 

그리고 초기 상태를 정의하고, start()를 수행하면 Looper 스레드가 생성되어 동작이 시작된다.

 

 

왜 State는 계층구조로 연결되어있는가?

State의 계층구조는 State를 사용하는데 있어 아주 중요한 요소이다.

 

왜냐하면 계층구조에 따라 다르게 동작하기 때문이다.

 

Transition To Other State

 

먼저 상태를 전환하는 과정을 알아보면 다음과 같다.

 

초기 Disabled 상태에서 enabledState로 transitionTo 메소드를 통해 전환되면 오른쪽 흐름으로 동작한다.

 

먼저 Disabled의 Exit() 메소드가 호출되며 약속된 동작이 수행된 후,

Default 상태로 전환되고,

 

이후 Enabled의 Enter() 메소드가 호출된다.

 

여기서 포인트는 Default는 Exit를 수행하지 않았다는 것이다.

그 이유는 계층 상태의 관계가 아래 벤다이어그램과 같이 부분 집합화 되어 있기 때문이다.

 

 

enabled로 진입하기 위해 disabled에서 exit하지만, 이는 default 상태 내부이다.

 

따라서 default는 enabled와 독립된 상태가 아닌 부분집합 내의 자식 상태이므로,

default에서 벗어나지 않고 enabled 내부의 enter를 수행하게 된다.

 

Send & Process Message 

위에서 stateMachine에 sendMessage로 명령을 전달한 흐름을 보았었다.

이처럼 sendMessage를 받으면 stateMachine은 해당 state에 정의되어있는 processMessage 메소드를 수행한다.

 

이때 계층간의 관계가 어떻게 동작에 연관되는지 살펴보자.

 

 

Enabled 상태에서 만약 Handle하지 못하는 CMD_RECOVERY_DISABLE_WIFI를 전달받았다고 가정하자.

 

그렇게되면 case문에서 벗어나, NOT_HANDLED를 반환한다.

 

 

그렇게 반환되면 Enabled에서 수행이 종료되는 것이 아니라 부모에게 이 메시지 처리를 업무를 위임한다.

 

따라서 같은 계층에 있는 상태들이 동일한 업무를 수행하는 경우

부모에서 처리하도록 설계하면 유동적인 수행이 가능해진다.