how

애플리케이션을 네이티브로 만들면 운영체제에 직접적으로 명령을 하는 것과 같다
버튼이나 인풋 등의 요소를 코드로 만들면 그 것을 운영체제에 요청하고
운영체제는 안드로이드나 iOS 상의 엘리먼트를 만든다

플러터는 운영체제와 직접적으로 소통하지는 않는다
플러터에서는 안드로이드나 iOS 의 엘리먼트를 직접 만들지 않는다
다른 크로스 플랫폼 프레임워크와 동작하는 방식이 다르다

조금 더 비디오 게임 엔진과 비슷하게 동작한다

다트와 플러터로 짜여진 코드는 프레임워크 밖에 존재하고 프레임워크에서 이용된다
플러터 프레임워크는 애니메이션, 페인팅, 제스쳐 등의 요소를 포함하고 있다

이 것들을 화면을 뿌려줄 때는 바로 운영체제와 직접 대화하는 것이 아니다
여기서 바로 대화를 하는 것은 네이티브 언어
플러터는 크로스 플랫폼을 지원하기 때문에 다르게 동작한다

중간에 C/C++ 로 짜여진 엔진을 사용하게 된다
플러터 엔진은 실제 UI를 렌더링 하는 것을 담당한다

비디오 게임 엔진인 유니티 등은 이와 비슷하게 동작한다
유니티로 만든 게임은 앱을 다운 받으면 유니티를 실행시킨다
플러터도 받은 앱이 플러터 엔진을 구동시킨다

플러터는 이와 같은 이유로 네이티브 위젯을 사용하지 않는다
엔진이 모든 것을 그려주기 때문이다
운영체제는 엔진을 실행시키는 역할만 한다

운영체제가 엔진을 동작시키고 엔진이 플러터를 동작하게 한다
그리고 엔진이 UI를 그린다

유저가 애플리케이션을 실행하면 플러터 엔진을 동작시키는 runner 프로젝트를 실행하고
엔진이 코드를 실행시킨다
엔진은 하나의 가상 머신이라고 생각해도 좋다
플러터는 가상 머신 위에서 동작하는 캔버스 같은 느낌

단점

플러터는 네이티브 위젯을 사용하지 않는다는 문제점을 가지고 있다
그래서 조금씩 모양이 다르다
모든 것이 플러터의 렌더링 엔진에 의해 그려지기 때문이다
플러터의 애플리케이션은 모두 가상의 위젯을 사용하는 것이다

하지만 오히려 이 부분 덕분에 플러터로 통제할 수 있는 것이 더 많아지기도 한다
네비게이션, 애니메이션 등 화면 상의 모든 것을 통제할 수 있다

애플리케이션의 호스트(운영체제)에 의존할 필요가 없다
운영체제에 어떠한 것도 의존하지 않는다
덕분에 모든 OS 에서 같은 화면을 보여줄 수 있다

이러한 점 때문에 많은 사람들이 플러터를 싫어하지만
그나마 자연스럽게 만드는 방법이 존재한다

다른 크로스 플랫폼은 운영체제와 직접 소통하는 방식을 택했다

Embedder

Embedder 는 특정 플랫폼에 특화된 것을 이야기 한다
엔진을 가동시키는 runner 프로젝트를 가리키고 있다
각 OS의 호스트 플랫폼 상에서 엔진을 가동시키는 역할을 한다

하도 엔진 엔진 하니까 설국열차가 떠오른다
플러터야말로 진정한 의미에서의 크로스 플랫폼이 아닐까 싶다