XAML이 컴파일 될 때2

지난 포스팅
에서 WPF 애플리케이션이 컴파일될 때 배경에서 일어나는 일들을 알아봤습니다.
가장 중요한 내용은 XAML이 컴파일 될 때 obj/Release (혹은 Debug)폴더에 name.g.cs라는 이름의 컴파일러가 자동으로 생성하는 코드가 작성된다는 것이었죠. 그리고 미처 소개하지 못한 사실이 하나 더 있다고 예고했는데요, 바로 .baml 파일입니다.

마크업의 약점 
대표적인 마크업인 HTML을 생각해보면 마크업이 가질 수밖에 없는 치명적인 약점을 알 수 있는데요, 바로 마크업이 담고 있는 개체들을 렌더링하는 것보다 마크업 자체를 개체화 하기위해 구문을 파싱하는 노력과 시간이 훨씬 더 많이 들어간다는 점이죠.

일반적으로 자료 구조중에 텍스트가 처리하는 데 프로세서, 메모리를 가장 많이 잡아먹고 그 중에서도 문자열 파싱이 특히 그렇다고 해요.

그렇다면 XAML은?
XAML은 이런 마크업의 약점을 보완하기 위해 프로젝트 컴파일시 XAML 파일 역시 컴파일하여 바이너리 형태로 변환합니다. MSDN의 http://msdn2.microsoft.com/en-us/library/aa970678.aspx#The_Windows_Presentation_Foundation_Build_Pipeline 을 보면 컴파일된 XAML 파일(compiled XAML file)이란 표현을 사용하는데요, 이것은 정확하게는 name.baml 파일을 의미하며 BAML의 B는 Binary를 말합니다.

MSDN에서 설명하는 BAML은 미리 분석되어(pre-tokenized) 런타임에 XAML파일보다 빨리 로딩될 수 있다고 하네요.

새 윈도 애플리케이션 프로젝트를 시작하고 빌드한 후 obj\Release 폴더를 보세요.
아마 Window1.baml 이란 파일이 있을거에요. 앞서 말한 바와 같이 이 파일은 바이너리니까 열어봐도 별 소용은 없을거에요.

어쨌든 XAML은 마크업이 가지는 로딩시 파싱 속도의 문제를 미리 컴파일하여 바이너리화 된 BAML 파일을 생성함으로써 극복하고 있다는 걸 알 수 있습니다.

겨우 이거?
WPF의 초기엔 BAML에다가 CAML이란것도 있었어요. Compiled XAML이란 건데, 이건 WPF의 개발 과정에서 BAML이 충분히 CAML의 속도를 따라 잡았고 CAML은 지역화가 불가능한 문제가 있는 등 여러가지 사정으로 CAML은 사라지고 BAML만 남았지요.

롱혼 SDK에는 XAML을 BAML로 컴파일하는 Xamlc.exe란 애플리케이션도 있었는데 지금은 MSBuild 엔진에 모두 통합되어 더이상 사용되지 않는다고 하네요.

또 과거 WPF를 위한 .NET API에서 LoadBAML이란 메소드가 존재했었는데 이것도 지금은 사라지고 LoadComponent란 메소드로 대체되었고 이 LoadComponent는 XAML이건 BAML이건 가리지 않고 제대로 로드하게 되어있다고 하네요.

지난 포스팅을 쓸 때만 해도 아직 이 사실들을 제대로 모르고 BAML이란 숨겨진 요소(?)에 꽤 흥분했었거든요. 그래서 뭔가 재밌는 비밀이 있을 걸로 기대했는데, 결과적으로 최근엔 개발자를 불편하게 하는 차이점은 죄다 통합되고 사라지게 되었네요. 썰렁;

신고
Posted by gongdo


티스토리 툴바