6 posts tagged with "Electron Internals"

지난 몇 주 동안, 새로운 WebView2와 Electron 간의 차이점에 대해 여러 질문을 받았다.

두 팀 모두 데스크톱에서 웹 기술을 최상의 상태로 만드는 것을 목표로 하고 있으며, 공통된 포괄적인 비교가 논의 중이다.

Electron과 WebView2는 빠르게 변화하고 지속적으로 발전하는 프로젝트다. 현재까지의 Electron과 WebView2 간의 유사점과 차이점을 간략히 정리해 보았다.

아키텍처 개요​

Electron과 WebView2는 모두 웹 콘텐츠를 렌더링하기 위해 Chromium 소스를 기반으로 구축되었다. 엄밀히 말하면 WebView2는 Edge 소스를 기반으로 하지만, Edge는 Chromium 소스의 포크를 사용해 개발되었다. Electron은 Chrome과 어떤 DLL도 공유하지 않는다. WebView2 바이너리는 Edge(Edge 90 기준 Stable 채널)와 하드 링크되어 있어 디스크와 일부 작업 세트를 공유한다. 자세한 내용은 Evergreen 배포 모드를 참고하라.

Electron 앱은 항상 개발 시 사용한 정확한 버전의 Electron을 번들로 포함해 배포한다. WebView2는 배포 방식에 두 가지 옵션이 있다. 애플리케이션 개발에 사용한 정확한 WebView2 라이브러리를 번들로 포함할 수도 있고, 시스템에 이미 존재할 수 있는 공유 런타임 버전을 사용할 수도 있다. WebView2는 각 접근 방식에 대한 도구를 제공하며, 공유 런타임이 없는 경우를 대비해 부트스트랩 설치 프로그램도 포함한다. WebView2는 Windows 11부터 기본 제공된다.

프레임워크를 번들로 포함한 애플리케이션은 해당 프레임워크를 업데이트할 책임이 있으며, 보안 릴리즈도 포함된다. 공유 WebView2 런타임을 사용하는 앱의 경우, WebView2는 Chrome이나 Edge와 유사한 자체 업데이터를 제공하며, 이는 애플리케이션과 독립적으로 실행된다. 애플리케이션 코드나 다른 의존성을 업데이트하는 것은 여전히 개발자의 책임이며, 이는 Electron과 동일하다. Electron과 WebView2 모두 Windows Update에 의해 관리되지 않는다.

Electron과 WebView2는 모두 Chromium의 다중 프로세스 아키텍처를 상속받는다. 즉, 하나의 메인 프로세스가 하나 이상의 렌더러 프로세스와 통신한다. 이 프로세스들은 시스템에서 실행 중인 다른 애플리케이션과 완전히 분리되어 있다. 모든 Electron 애플리케이션은 별도의 프로세스 트리로 구성되며, 루트 브라우저 프로세스, 몇 가지 유틸리티 프로세스, 그리고 0개 이상의 렌더러 프로세스를 포함한다. 동일한 사용자 데이터 폴더를 사용하는 WebView2 앱(예: 앱 스위트)은 렌더러 프로세스가 아닌 프로세스를 공유한다. 다른 데이터 폴더를 사용하는 WebView2 앱은 프로세스를 공유하지 않는다.

• ElectronJS 프로세스 모델:

  

• WebView2 기반 애플리케이션 프로세스 모델:

  

WebView2의 프로세스 모델과 Electron의 프로세스 모델에 대해 더 알아보라.

Electron은 메뉴, 파일 시스템 접근, 알림 등 일반적인 데스크톱 애플리케이션 요구 사항을 위한 API를 제공한다. WebView2는 WinForms, WPF, WinUI, Win32와 같은 애플리케이션 프레임워크에 통합되도록 설계된 컴포넌트이다. WebView2는 JavaScript를 통해 웹 표준 외의 운영체제 API를 제공하지 않는다.

Electron은 Node.js와 통합되어 있다. Electron 애플리케이션은 렌더러 프로세스와 메인 프로세스에서 모든 Node.js API, 모듈, 또는 node-native-addon을 사용할 수 있다. WebView2 애플리케이션은 애플리케이션의 나머지 부분이 어떤 언어나 프레임워크로 작성되었는지 가정하지 않는다. JavaScript 코드는 운영체제 접근을 애플리케이션 호스트 프로세스를 통해 프록시해야 한다.

Electron은 Fugu 프로젝트에서 개발된 API를 포함해 웹 API와의 호환성을 유지하려고 노력한다. Electron의 Fugu API 호환성 스냅샷을 참고하라. WebView2는 Edge와의 API 차이점에 대한 유사한 목록을 유지한다.

Electron은 웹 콘텐츠에 대해 전체 접근부터 전체 샌드박스까지 구성 가능한 보안 모델을 제공한다. WebView2 콘텐츠는 항상 샌드박스로 처리된다. Electron은 보안 모델 선택에 대한 포괄적인 문서를 제공한다. WebView2도 보안 모범 사례를 제공한다.

Electron 소스는 GitHub에서 유지 관리되며 공개되어 있다. 애플리케이션은 Electron을 수정해 자신만의 _브랜드_를 구축할 수 있다. WebView2 소스는 GitHub에서 공개되지 않는다.

간단한 요약:

성능 논의​

웹 콘텐츠를 렌더링할 때, Electron, WebView2, 그리고 다른 크로미움 기반 렌더러 간의 성능 차이는 크지 않을 것으로 예상한다. 성능 차이를 조사하고자 하는 사람들을 위해 Electron, C++ + WebView2, 그리고 C# + WebView2를 사용해 앱을 구축하는 스캐폴딩을 만들었다.

웹 콘텐츠 렌더링과는 별개로 몇 가지 차이점이 존재한다. Electron, WebView2, Edge 팀 등 다양한 관계자들이 PWA를 포함한 상세한 비교 작업에 관심을 표명했다.

프로세스 간 통신(IPC)​

우리는 이 차이점을 즉시 강조하고 싶다. 이는 Electron 앱에서 종종 성능 고려 사항이 되기 때문이다.

Chromium에서 브라우저 프로세스는 샌드박스된 렌더러와 시스템의 나머지 부분 사이에서 IPC 브로커 역할을 한다. Electron은 샌드박스되지 않은 렌더 프로세스를 허용하지만, 많은 앱이 추가 보안을 위해 샌드박스를 활성화한다. WebView2는 항상 샌드박스가 활성화되어 있으므로, 대부분의 Electron과 WebView2 앱에서 IPC는 전체 성능에 영향을 미칠 수 있다.

Electron과 WebView2는 유사한 프로세스 모델을 가지고 있지만, 기본 IPC는 다르다. JavaScript와 C++ 또는 C# 간의 통신에는 마샬링이 필요하며, 이는 주로 JSON 문자열로 이루어진다. JSON 직렬화/역직렬화는 비용이 많이 드는 작업이며, IPC 병목 현상이 성능에 부정적인 영향을 미칠 수 있다. Edge 93부터 WV2는 네트워크 이벤트에 CBOR을 사용한다.

Electron은 MessagePorts API를 통해 두 프로세스 간 직접 IPC를 지원하며, 이는 구조화된 복제 알고리즘을 활용한다. 이를 활용하는 애플리케이션은 프로세스 간 객체를 전송할 때 JSON 직렬화 비용을 피할 수 있다.

요약​

Electron과 WebView2는 여러 차이점이 있지만, 웹 콘텐츠를 렌더링하는 방식에서는 큰 차이를 기대하기 어렵다.
결국 앱의 아키텍처와 사용하는 JavaScript 라이브러리/프레임워크가 메모리와 성능에 더 큰 영향을 미친다. 왜냐하면 Chromium은 어디에서 실행되든 Chromium이기 때문이다.

이 글을 검토하고 WebView2 아키텍처에 대한 최신 정보를 제공해 준 WebView2 팀에게 특별히 감사드린다.
그들은 프로젝트에 대한 피드백을 언제든 환영한다.

Electron에서 C++나 Objective-C로 작성된 기능이 어떻게 JavaScript로 전달되어 최종 사용자에게 제공되는지 알아보자.

Electron은 내부적으로 Node.js와 Chromium을 사용한다. Node.js는 C++로 작성된 코어 모듈을 JavaScript로 노출시키는 메커니즘을 제공한다. 이 과정에서 N-API(Node-API) 또는 Native Addons라는 기술을 활용한다.

1. Native Addons 생성: C++로 작성된 코드를 Node.js가 이해할 수 있는 형태로 컴파일한다. 이를 위해 node-gyp라는 빌드 도구를 사용한다. 이 도구는 C++ 코드를 Node.js 바이너리와 호환되는 네이티브 모듈로 변환한다.

2. JavaScript 바인딩: 컴파일된 네이티브 모듈을 JavaScript에서 사용할 수 있도록 바인딩한다. 이를 통해 C++ 함수를 JavaScript 함수처럼 호출할 수 있다.

3. Electron 통합: 이렇게 생성된 네이티브 모듈을 Electron 애플리케이션에 통합한다. Electron은 Node.js 런타임을 포함하고 있기 때문에, 네이티브 모듈을 JavaScript 코드에서 직접 사용할 수 있다.

4. 최종 사용자에게 노출: JavaScript로 래핑된 기능은 Electron 애플리케이션의 API로 제공된다. 이를 통해 최종 사용자는 JavaScript를 통해 C++ 또는 Objective-C로 구현된 기능을 사용할 수 있다.

이 과정을 통해 Electron은 하위 수준의 기능을 JavaScript로 쉽게 노출시킬 수 있다. 이를 통해 개발자는 복잡한 네이티브 코드를 직접 다루지 않고도 강력한 기능을 구현할 수 있다.

배경​

Electron은 플랫폼별 구현에 신경 쓰지 않고도 강력한 데스크톱 앱을 개발할 수 있도록 도와주는 JavaScript 플랫폼이다. 그러나 내부적으로 Electron은 여전히 플랫폼별 기능을 시스템 언어로 작성해야 한다.

실제로 Electron은 네이티브 코드를 직접 처리해 주기 때문에 개발자는 단일 JavaScript API에만 집중할 수 있다.

그렇다면 이 과정은 어떻게 작동할까? C++이나 Objective-C로 작성된 Electron의 기능이 어떻게 JavaScript로 전달되어 최종 사용자에게 제공될까?

이 경로를 추적하기 위해 app 모듈부터 시작해 보자.

lib/ 디렉토리 안에 있는 app.ts 파일을 열면 상단에 다음과 같은 코드를 찾을 수 있다:

const binding = process.electronBinding('app');

이 코드는 Electron이 C++/Objective-C 모듈을 JavaScript에 바인딩해 개발자가 사용할 수 있도록 하는 메커니즘을 직접 가리킨다. 이 함수는 ElectronBindings 클래스의 헤더와 구현 파일에 의해 생성된다.

process.electronBinding​

이 파일들은 Node.js의 process.binding과 유사하게 동작하는 process.electronBinding 함수를 추가한다. process.binding은 Node.js의 require() 메서드의 저수준 구현체로, JS로 작성된 다른 코드 대신 네이티브 코드를 require할 수 있게 해준다. 이 커스텀 process.electronBinding 함수는 Electron에서 네이티브 코드를 로드할 수 있는 기능을 제공한다.

최상위 자바스크립트 모듈(예: app)이 이 네이티브 코드를 요청할 때, 해당 네이티브 코드의 상태는 어떻게 결정되고 설정되는가? 메서드와 프로퍼티는 어떻게 자바스크립트에 노출되는가?

native_mate​

현재 이 질문에 대한 답은 native_mate에서 찾을 수 있다. native_mate는 Chromium의 gin 라이브러리를 포크한 것으로, C++과 JavaScript 간의 타입 변환을 더 쉽게 만들어준다.

native_mate/native_mate 디렉토리 안에는 object_template_builder에 대한 헤더 파일과 구현 파일이 있다. 이 파일들은 네이티브 코드에서 JavaScript 개발자가 기대하는 형태로 모듈을 구성할 수 있게 해준다.

mate::ObjectTemplateBuilder​

모든 Electron 모듈을 object로 본다면, object_template_builder를 사용해 이를 구성하려는 이유를 더 쉽게 이해할 수 있다. 이 클래스는 V8 위에 구축되어 있다. V8은 Google이 C++로 개발한 오픈소스 고성능 JavaScript 및 WebAssembly 엔진이다. V8은 JavaScript(ECMAScript) 사양을 구현하므로, 네이티브 기능 구현을 JavaScript 구현과 직접적으로 연결할 수 있다. 예를 들어, v8::ObjectTemplate은 전용 생성자 함수와 프로토타입 없이 JavaScript 객체를 제공한다. 이는 Object[.prototype]을 사용하며, JavaScript에서는 Object.create()와 동등하다.

이를 실제로 확인하려면 app 모듈의 구현 파일인 atom_api_app.cc를 살펴보자. 파일 하단에는 다음과 같은 코드가 있다.

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

위 코드에서 .SetMethod는 mate::ObjectTemplateBuilder 인스턴스에 호출된다. .SetMethod는 ObjectTemplateBuilder 클래스의 모든 인스턴스에서 호출할 수 있으며, JavaScript의 Object 프로토타입에 메서드를 설정한다. 사용법은 다음과 같다.

.SetMethod("method_name", &function_to_bind)

이는 JavaScript에서 다음과 동등하다.

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

이 클래스는 또한 모듈에 속성을 설정하는 함수를 포함한다.

.SetProperty("property_name", &getter_function_to_bind)

또는

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

이것은 JavaScript의 Object.defineProperty 구현과 동등하다.

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

그리고

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

개발자가 기대하는 대로 프로토타입과 속성으로 구성된 JavaScript 객체를 생성할 수 있으며, 이 낮은 시스템 수준에서 구현된 함수와 속성에 대해 더 명확히 이해할 수 있다!

주어진 모듈 메서드를 어디에 구현할지 결정하는 것은 복잡하고 종종 비결정적인 문제이다. 이에 대해서는 추후 게시글에서 다룰 예정이다.

Electron은 Google의 오픈소스 프로젝트인 Chromium을 기반으로 한다. Chromium은 원래 다른 프로젝트에서 사용하기 위해 설계된 것은 아니다. 이 글은 Chromium이 어떻게 Electron에서 사용할 수 있는 라이브러리로 구축되었는지, 그리고 빌드 시스템이 시간이 지나며 어떻게 발전해 왔는지를 소개한다.

CEF 사용하기​

Chromium Embedded Framework(CEF)는 Chromium을 라이브러리로 변환하고, Chromium 코드베이스를 기반으로 안정적인 API를 제공하는 프로젝트다. Atom 에디터와 NW.js의 초기 버전은 CEF를 사용했다.

안정적인 API를 유지하기 위해 CEF는 Chromium의 모든 세부 사항을 숨기고 Chromium의 API를 자체 인터페이스로 감싼다. 따라서 웹 페이지에 Node.js를 통합하는 것과 같이 Chromium의 내부 API에 접근해야 할 때, CEF의 장점이 오히려 방해 요소가 되었다.

결국 Electron과 NW.js는 Chromium API를 직접 사용하는 방식으로 전환했다.

Chromium의 일부로 빌드하기​

Chromium은 공식적으로 외부 프로젝트를 지원하지 않지만, 코드베이스가 모듈식으로 구성되어 있어 최소한의 브라우저를 쉽게 구축할 수 있다. 브라우저 인터페이스를 제공하는 핵심 모듈은 Content Module이라고 한다.

Content Module을 사용해 프로젝트를 개발하려면, Chromium의 일부로 프로젝트를 빌드하는 것이 가장 간단한 방법이다. 이를 위해 먼저 Chromium의 소스 코드를 체크아웃한 다음, 프로젝트를 Chromium의 DEPS 파일에 추가한다.

NW.js와 초기 버전의 Electron은 이 방식을 사용해 빌드했다.

하지만 Chromium은 매우 큰 코드베이스이기 때문에 강력한 머신이 필요하다. 일반적인 노트북에서는 5시간 이상 걸릴 수 있다. 이는 프로젝트에 기여할 수 있는 개발자 수를 크게 제한하고, 개발 속도도 느리게 만든다.

Chromium을 단일 공유 라이브러리로 빌드하기​

Content Module을 사용하는 Electron은 대부분의 경우 Chromium 코드를 수정할 필요가 없다. 따라서 Electron 빌드를 개선하는 명확한 방법은 Chromium을 공유 라이브러리로 빌드한 다음, Electron에서 이를 링크하는 것이다. 이 방식은 개발자가 Electron에 기여할 때 Chromium 전체를 빌드할 필요가 없게 해준다.

이러한 목적으로 @aroben이 libchromiumcontent 프로젝트를 만들었다. 이 프로젝트는 Chromium의 Content Module을 공유 라이브러리로 빌드하고, Chromium 헤더와 사전 빌드된 바이너리를 다운로드할 수 있게 제공한다. libchromiumcontent 초기 버전의 코드는 이 링크에서 확인할 수 있다.

brightray 프로젝트도 libchromiumcontent의 일부로 탄생했으며, Content Module 주변에 얇은 레이어를 제공한다.

libchromiumcontent와 brightray를 함께 사용하면 개발자는 Chromium 빌드의 세부 사항에 깊이 들어가지 않고도 빠르게 브라우저를 빌드할 수 있다. 또한 이 방식은 프로젝트 빌드를 위해 빠른 네트워크와 강력한 머신이 필요하지 않게 해준다.

Electron 외에도 Breach browser와 같은 다른 Chromium 기반 프로젝트들도 이 방식으로 빌드되었다.

내보낸 심볼 필터링​

Windows에서는 하나의 공유 라이브러리가 내보낼 수 있는 심볼의 수에 제한이 있다. Chromium 코드베이스가 커지면서 libchromiumcontent에서 내보내는 심볼의 수가 이 제한을 넘어섰다.

이 문제를 해결하기 위해 DLL 파일을 생성할 때 필요하지 않은 심볼을 필터링하는 방법을 도입했다. 이 방법은 링커에 .def 파일을 제공한 후, 특정 네임스페이스 아래의 심볼을 내보낼지 여부를 판단하는 스크립트를 사용해 구현했다.

이 접근 방식을 통해 Chromium이 새로운 내보낸 심볼을 계속 추가하더라도, libchromiumcontent는 더 많은 심볼을 제거함으로써 공유 라이브러리 파일을 생성할 수 있었다.

컴포넌트 빌드​

libchromiumcontent의 다음 단계를 설명하기 전에, 먼저 Chromium의 컴포넌트 빌드 개념을 소개하는 것이 중요하다.

Chromium은 거대한 프로젝트이기 때문에 빌드 시 링크 단계에서 많은 시간이 소요된다. 일반적으로 개발자가 작은 변경을 가할 때, 최종 결과물을 확인하려면 10분 이상 걸릴 수 있다. 이를 해결하기 위해 Chromium은 컴포넌트 빌드를 도입했다. 이 방식은 Chromium의 각 모듈을 별도의 공유 라이브러리로 빌드하여, 최종 링크 단계에서 소요되는 시간을 거의 없앤다.

원시 바이너리 배포​

Chromium이 계속 성장하면서, Chromium에서 내보내는 심볼이 너무 많아져 Content Module과 Webkit의 심볼도 제한을 초과했다. 단순히 심볼을 제거해서 사용 가능한 공유 라이브러리를 생성하는 것은 불가능했다.

결국, Chromium의 원시 바이너리를 배포하는 방법을 선택했다. 단일 공유 라이브러리를 생성하는 대신 이 방식을 채택했다.

앞서 소개한 것처럼 Chromium에는 두 가지 빌드 모드가 있다. 원시 바이너리를 배포하게 되면서, libchromiumcontent에서 두 가지 다른 바이너리 배포판을 제공해야 했다. 하나는 static_library 빌드로, Chromium의 일반 빌드에서 생성된 각 모듈의 정적 라이브러리를 모두 포함한다. 다른 하나는 shared_library 빌드로, 컴포넌트 빌드에서 생성된 각 모듈의 공유 라이브러리를 모두 포함한다.

Electron에서는 Debug 버전이 libchromiumcontent의 shared_library 버전과 링크된다. 이 버전은 다운로드 크기가 작고, 최종 실행 파일을 링크하는 데 시간이 적게 걸리기 때문이다. 반면 Release 버전은 libchromiumcontent의 static_library 버전과 링크된다. 이렇게 하면 컴파일러가 디버깅에 중요한 전체 심볼을 생성할 수 있고, 링커가 필요한 오브젝트 파일을 정확히 알고 있기 때문에 더 나은 최적화를 수행할 수 있다.

일반적인 개발 과정에서는 개발자가 Debug 버전만 빌드하면 된다. 이 버전은 네트워크나 강력한 머신이 필요하지 않다. Release 버전은 더 좋은 하드웨어가 필요하지만, 더 최적화된 바이너리를 생성할 수 있다.

gn 업데이트​

세계에서 가장 큰 프로젝트 중 하나인 Chromium을 빌드하기에는 일반적인 시스템이 적합하지 않다. Chromium 팀은 자체 빌드 도구를 개발했다.

이전 버전의 Chromium은 gyp를 빌드 시스템으로 사용했지만, 속도가 느리고 복잡한 프로젝트에서는 설정 파일을 이해하기 어려웠다. 수년간의 개발 끝에 Chromium은 더 빠르고 명확한 구조를 가진 gn으로 빌드 시스템을 전환했다.

gn의 개선점 중 하나는 source_set을 도입한 것이다. source_set은 오브젝트 파일 그룹을 나타낸다. gyp에서는 각 모듈이 static_library나 shared_library로 표현되었고, Chromium의 일반적인 빌드에서 각 모듈은 정적 라이브러리를 생성한 후 최종 실행 파일에 함께 링크되었다. gn을 사용하면 이제 각 모듈이 오브젝트 파일 묶음을 생성하고, 최종 실행 파일이 모든 오브젝트 파일을 함께 링크한다. 따라서 중간 정적 라이브러리 파일은 더 이상 생성되지 않는다.

이러한 개선은 libchromiumcontent에게 큰 문제를 일으켰다. libchromiumcontent는 실제로 중간 정적 라이브러리 파일이 필요했기 때문이다.

이 문제를 해결하기 위한 첫 번째 시도는 gn을 패치하여 정적 라이브러리 파일을 생성하게 하는 것이었다. 이 방법은 문제를 해결했지만, 적절한 해결책과는 거리가 멀었다.

두 번째 시도는 @alespergl이 오브젝트 파일 목록에서 커스텀 정적 라이브러리를 생성하는 방법을 제안한 것이다. 이 방법은 더미 빌드를 먼저 실행해 생성된 오브젝트 파일 목록을 수집한 후, 그 목록을 gn에 제공해 실제로 정적 라이브러리를 빌드하는 트릭을 사용했다. 이 방법은 Chromium의 소스 코드를 최소한으로 변경했고, Electron의 빌드 구조를 그대로 유지할 수 있었다.

요약​

Chromium을 일부로 포함해 Electron을 빌드하는 방식과 Chromium을 라이브러리로 빌드하는 방식을 비교해 보면, 후자가 더 많은 노력과 지속적인 유지보수를 필요로 한다. 하지만 Chromium을 라이브러리로 빌드하면 강력한 하드웨어 없이도 Electron을 빌드할 수 있어, 더 많은 개발자가 Electron을 빌드하고 기여할 수 있게 된다. 이러한 노력은 충분히 가치가 있다.

가비지 컬렉션을 지원하는 언어인 자바스크립트는 사용자가 직접 리소스를 관리할 필요가 없다. 하지만 Electron은 이러한 환경을 호스팅하기 때문에 메모리와 리소스 누수를 방지하는 데 각별히 주의해야 한다.

이 글에서는 약한 참조(weak reference)의 개념과 Electron에서 리소스를 관리하기 위해 어떻게 활용하는지 소개한다.

약한 참조(Weak References)​

자바스크립트에서 객체를 변수에 할당하면 해당 객체에 대한 참조가 추가된다. 객체에 대한 참조가 남아 있는 한, 객체는 메모리에 계속 유지된다. 객체에 대한 모든 참조가 사라지면, 즉 객체를 저장하는 변수가 더 이상 없으면, 자바스크립트 엔진은 다음 가비지 컬렉션에서 해당 메모리를 회수한다.

약한 참조(Weak Reference)는 객체를 가져올 수 있도록 하면서도, 가비지 컬렉션 여부에 영향을 미치지 않는 참조 방식이다. 또한 객체가 가비지 컬렉션될 때 알림을 받을 수 있어, 자바스크립트로 리소스를 관리하는 것이 가능해진다.

Electron의 NativeImage 클래스를 예로 들면, nativeImage.create() API를 호출할 때마다 NativeImage 인스턴스가 반환되고, 이 인스턴스는 C++에서 이미지 데이터를 저장한다. 인스턴스를 더 이상 사용하지 않고 자바스크립트 엔진(V8)이 객체를 가비지 컬렉션하면, C++ 코드가 호출되어 메모리의 이미지 데이터를 해제한다. 따라서 사용자가 이를 수동으로 관리할 필요가 없다.

또 다른 예로는 윈도우 사라짐 문제가 있다. 이 예제는 윈도우에 대한 모든 참조가 사라졌을 때 윈도우가 어떻게 가비지 컬렉션되는지를 시각적으로 보여준다.

Electron에서 약한 참조 테스트하기​

자바스크립트는 약한 참조를 직접 할당할 수 있는 방법을 제공하지 않기 때문에, 순수 자바스크립트에서는 약한 참조를 직접 테스트할 방법이 없다. 자바스크립트에서 약한 참조와 관련된 유일한 API는 WeakMap이지만, 이 API는 약한 참조 키만 생성하기 때문에 객체가 가비지 컬렉션(Garbage Collection)되었는지 알 수 없다.

Electron v0.37.8 이전 버전에서는 내부 v8Util.setDestructor API를 사용해 약한 참조를 테스트할 수 있다. 이 API는 전달된 객체에 약한 참조를 추가하고, 객체가 가비지 컬렉션되면 콜백을 호출한다:

// 아래 코드는 Electron < v0.37.8 버전에서만 실행 가능.
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
  console.log('The object is garbage collected');
});

// 객체에 대한 모든 참조를 제거.
object = undefined;
// 수동으로 GC를 실행.
gc();
// 콘솔에 "The object is garbage collected" 출력.

이 API를 사용하려면 --js-flags="--expose_gc" 커맨드 스위치와 함께 Electron을 실행해 내부 gc 함수를 노출시켜야 한다.

이 API는 이후 버전에서 제거되었다. V8은 실제로 소멸자에서 자바스크립트 코드를 실행하는 것을 허용하지 않으며, 이후 버전에서 이를 사용하면 무작위로 크래시가 발생할 수 있기 때문이다.

remote 모듈에서의 약한 참조​

Electron은 C++로 네이티브 리소스를 관리할 뿐만 아니라, 자바스크립트 리소스를 관리하기 위해 약한 참조(weak reference)도 필요로 한다. 대표적인 예가 Electron의 remote 모듈이다. 이 모듈은 원격 프로시저 호출(Remote Procedure Call, RPC)을 가능하게 하여, 렌더러 프로세스에서 메인 프로세스의 객체를 사용할 수 있도록 한다.

remote 모듈에서 가장 큰 도전은 메모리 누수를 피하는 것이다. 렌더러 프로세스에서 사용자가 원격 객체를 획득하면, remote 모듈은 렌더러 프로세스에서의 참조가 사라질 때까지 메인 프로세스에서 해당 객체가 계속 살아있도록 보장해야 한다. 동시에, 렌더러 프로세스에서 더 이상 참조가 없을 때 객체가 가비지 컬렉션될 수 있도록 해야 한다.

예를 들어, 적절한 구현이 없다면 다음 코드는 빠르게 메모리 누수를 일으킬 것이다:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.nativeImage.createEmpty();
}

remote 모듈의 리소스 관리 방식은 간단하다. 객체가 요청될 때마다 메인 프로세스로 메시지를 보내고, Electron은 해당 객체를 맵에 저장한 후 ID를 할당하고, 이 ID를 렌더러 프로세스로 보낸다. 렌더러 프로세스에서는 remote 모듈이 이 ID를 받아 프록시 객체로 감싸고, 프록시 객체가 가비지 컬렉션되면 메인 프로세스로 객체를 해제하라는 메시지를 보낸다.

remote.require API를 예로 들면, 간략화된 구현은 다음과 같다:

remote.require = function (name) {
  // 메인 프로세스에 모듈의 메타데이터를 요청한다.
  const meta = ipcRenderer.sendSync('REQUIRE', name);
  // 프록시 객체를 생성한다.
  const object = metaToValue(meta);
  // 프록시 객체가 가비지 컬렉션될 때 메인 프로세스에 객체를 해제하라고 알린다.
  v8Util.setDestructor(object, function () {
    ipcRenderer.send('FREE', meta.id);
  });
  return object;
};

메인 프로세스에서는 다음과 같이 처리한다:

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
  const object = require(name);
  // 객체에 대한 참조를 추가한다.
  map[++id] = object;
  // 객체를 메타데이터로 변환한다.
  event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
  delete map[id];
});

약한 값을 가진 맵​

이전의 간단한 구현에서는 remote 모듈의 모든 호출이 메인 프로세스에서 새로운 원격 객체를 반환한다. 각 원격 객체는 메인 프로세스에 있는 객체에 대한 참조를 나타낸다.

이 디자인 자체는 문제가 없지만, 동일한 객체를 여러 번 받기 위해 여러 번 호출할 경우 여러 프록시 객체가 생성된다. 복잡한 객체의 경우 이는 메모리 사용량과 가비지 컬렉션에 큰 부담을 줄 수 있다.

예를 들어, 다음 코드를 보자:

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
  remote.getCurrentWindow();
}

이 코드는 먼저 프록시 객체를 생성하는 데 많은 메모리를 사용하고, 그 후 가비지 컬렉션과 IPC 메시지 전송을 위해 CPU를 점유한다.

명백한 최적화 방법은 원격 객체를 캐싱하는 것이다: 동일한 ID를 가진 원격 객체가 이미 있다면, 새로운 객체를 생성하는 대신 이전 객체를 반환한다.

이는 JavaScript 코어의 API로는 불가능하다. 일반적인 맵을 사용해 객체를 캐싱하면 V8이 객체를 가비지 컬렉션하는 것을 막는다. 반면에 WeakMap 클래스는 객체를 약한 키로만 사용할 수 있다.

이 문제를 해결하기 위해, 값이 약한 참조인 맵 타입이 추가되었다. 이는 ID를 가진 객체를 캐싱하는 데 완벽하다. 이제 remote.require는 다음과 같이 동작한다:

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
  // 메인 프로세스에 모듈의 메타 데이터를 반환하라고 요청한다.
  ...
  if (remoteObjectCache.has(meta.id))
    return remoteObjectCache.get(meta.id)
  // 프록시 객체를 생성한다.
  ...
  remoteObjectCache.set(meta.id, object)
  return object
}

remoteObjectCache는 객체를 약한 참조로 저장하기 때문에, 객체가 가비지 컬렉션될 때 키를 삭제할 필요가 없다.

네이티브 코드​

Electron에서 약한 참조(weak references)의 C++ 코드에 관심이 있다면 다음 파일에서 확인할 수 있다.

setDestructor API 관련 파일:

• object_life_monitor.cc
• object_life_monitor.h

createIDWeakMap API 관련 파일:

• key_weak_map.h
• atom_api_key_weak_map.h

이 글은 Electron의 내부 구조를 설명하는 시리즈의 두 번째 포스트다. 아직 보지 않았다면 이벤트 루프 통합에 관한 [첫 번째 포스트][event-loop]를 먼저 확인해 보자.

대부분의 사람들은 Node를 서버 측 애플리케이션에 사용한다. 하지만 Node의 풍부한 API와 활발한 커뮤니티 덕분에, Node는 내장 라이브러리로도 적합하다. 이 글에서는 Electron에서 Node가 어떻게 라이브러리로 사용되는지 설명한다.

빌드 시스템​

Node와 Electron 모두 빌드 시스템으로 GYP를 사용한다. 앱 내부에 Node를 포함시키려면, 여러분도 GYP를 빌드 시스템으로 사용해야 한다.

GYP가 처음이라면, 이 글을 계속 읽기 전에 [이 가이드][gyp-docs]를 먼저 읽어보는 것이 좋다.

Node의 빌드 플래그​

Node 소스 코드 디렉토리에 있는 node.gyp 파일은 Node가 어떻게 빌드되는지 설명한다. 이 파일에는 Node의 어떤 부분을 활성화할지, 특정 설정을 열어둘지 여부를 제어하는 여러 GYP 변수들이 포함되어 있다.

빌드 플래그를 변경하려면 프로젝트의 .gypi 파일에서 변수를 설정해야 한다. Node의 configure 스크립트는 일반적인 설정을 자동으로 생성해 준다. 예를 들어, ./configure --shared를 실행하면 Node를 공유 라이브러리로 빌드하도록 지시하는 변수들이 포함된 config.gypi 파일이 생성된다.

Electron은 자체 빌드 스크립트를 사용하기 때문에 configure 스크립트를 사용하지 않는다. 대신, Electron의 루트 소스 코드 디렉토리에 있는 common.gypi 파일에서 Node의 설정을 정의한다.

Electron에서 Node.js 연결하기​

Electron에서는 GYP 변수인 node_shared를 true로 설정하여 Node.js를 공유 라이브러리로 연결한다. 이로 인해 Node.js의 빌드 타입은 실행 파일(executable)에서 공유 라이브러리(shared_library)로 변경되며, Node.js의 main 진입점을 포함한 소스 코드는 컴파일되지 않는다.

Electron은 Chromium과 함께 제공되는 V8 라이브러리를 사용하기 때문에, Node.js 소스 코드에 포함된 V8 라이브러리는 사용되지 않는다. 이를 위해 node_use_v8_platform와 node_use_bundled_v8 변수를 모두 false로 설정한다.

공유 라이브러리와 정적 라이브러리​

Node와 링크할 때는 두 가지 옵션이 있다. Node를 정적 라이브러리로 빌드해 최종 실행 파일에 포함시키거나, 공유 라이브러리로 빌드해 최종 실행 파일과 함께 배포하는 방법이다.

Electron에서는 오랫동안 Node를 정적 라이브러리로 빌드했다. 이 방식은 빌드 과정을 단순화하고 최적의 컴파일러 최적화를 가능하게 하며, 추가적인 node.dll 파일 없이 Electron을 배포할 수 있게 했다.

하지만 Chrome이 [BoringSSL][boringssl]을 사용하도록 변경된 후 이 상황이 바뀌었다. BoringSSL은 [OpenSSL][openssl]의 포크 버전으로, 사용되지 않는 여러 API를 제거하고 기존 인터페이스를 많이 변경했다. Node는 여전히 OpenSSL을 사용하기 때문에, 두 라이브러리를 함께 링크하면 충돌하는 심볼로 인해 컴파일러가 수많은 링크 오류를 발생시켰다.

Electron은 Node에서 BoringSSL을 사용하거나 Chromium에서 OpenSSL을 사용할 수 없었기 때문에, 유일한 선택지는 Node를 공유 라이브러리로 빌드하고 각 컴포넌트에서 [BoringSSL과 OpenSSL 심볼을 숨기는][openssl-hide] 것이었다.

이 변경은 Electron에 몇 가지 긍정적인 부작용을 가져왔다. 이전에는 네이티브 모듈을 사용하는 경우 Windows에서 Electron 실행 파일의 이름을 변경할 수 없었다. 실행 파일 이름이 임포트 라이브러리에 하드 코딩되어 있었기 때문이다. Node가 공유 라이브러리로 빌드된 후에는 모든 네이티브 모듈이 node.dll에 링크되었고, 이 파일의 이름을 변경할 필요가 없어졌기 때문에 이러한 제약이 사라졌다.

네이티브 모듈 지원하기​

Node의 네이티브 모듈은 Node가 로드할 수 있는 진입 함수를 정의한 다음, Node에서 V8과 libuv의 심볼을 검색하는 방식으로 동작한다. 하지만 이 방식은 임베더에게 다소 번거로운 문제를 일으킬 수 있다. 기본적으로 Node를 라이브러리로 빌드할 때 V8과 libuv의 심볼이 숨겨져 있기 때문에, 네이티브 모듈이 심볼을 찾지 못해 로드에 실패할 수 있다.

따라서 네이티브 모듈이 정상적으로 동작하도록 하기 위해, Electron에서는 V8과 libuv의 심볼을 노출시켰다. V8의 경우 Chromium의 설정 파일에서 모든 심볼을 강제로 노출하는 방식을 사용했다. libuv의 경우에는 BUILDING_UV_SHARED=1 정의를 설정하여 이를 달성했다.

앱에서 Node 시작하기​

Node를 빌드하고 연결하는 모든 작업을 마친 후, 마지막 단계는 앱에서 Node를 실행하는 것이다.

Node는 다른 앱에 자신을 포함시키기 위한 공개 API를 많이 제공하지 않는다. 일반적으로 [node::Start와 node::Init][node-start]을 호출해 Node의 새 인스턴스를 시작할 수 있다. 하지만 Node를 기반으로 복잡한 앱을 구축하는 경우, node::CreateEnvironment와 같은 API를 사용해 각 단계를 정밀하게 제어해야 한다.

Electron에서는 Node가 두 가지 모드로 시작된다. 하나는 메인 프로세스에서 실행되는 독립 실행 모드로, 공식 Node 바이너리와 유사하다. 다른 하나는 Node API를 웹 페이지에 삽입하는 임베디드 모드이다. 이에 대한 자세한 내용은 추후 포스트에서 설명할 예정이다.

이 글은 Electron의 내부 구조를 설명하는 시리즈의 첫 번째 포스트이다. 이 글에서는 Node의 이벤트 루프가 Chromium과 어떻게 통합되는지 소개한다.

GUI 프로그래밍을 위해 Node를 사용하려는 여러 시도가 있었다. 예를 들어 GTK+ 바인딩을 위한 node-gui와 QT 바인딩을 위한 node-qt가 있다. 하지만 이들은 프로덕션 환경에서 작동하지 않았다. GUI 툴킷은 자체 메시지 루프를 가지고 있는 반면, Node는 libuv를 사용해 자체 이벤트 루프를 돌리기 때문이다. 메인 스레드는 동시에 하나의 루프만 실행할 수 있다. 따라서 Node에서 GUI 메시지 루프를 실행하는 일반적인 방법은 매우 짧은 간격으로 타이머를 사용해 메시지 루프를 돌리는 것이다. 이 방법은 GUI 인터페이스의 반응 속도를 느리게 만들고 CPU 리소스를 많이 차지한다.

Electron을 개발하는 과정에서 우리는 비슷한 문제에 직면했다. 단, 반대 상황이었다: Node의 이벤트 루프를 Chromium의 메시지 루프에 통합해야 했다.

메인 프로세스와 렌더러 프로세스​

메시지 루프 통합에 대한 자세한 내용을 살펴보기 전에, 먼저 Chromium의 멀티 프로세스 아키텍처에 대해 설명한다.

Electron에는 두 가지 타입의 프로세스가 있다: 메인 프로세스와 렌더러 프로세스(이 설명은 상당히 단순화된 것이다. 전체적인 그림을 보려면 멀티 프로세스 아키텍처를 참고한다). 메인 프로세스는 윈도우 생성과 같은 GUI 작업을 담당한다. 반면 렌더러 프로세스는 웹 페이지 실행과 렌더링만 처리한다.

Electron은 JavaScript를 사용해 메인 프로세스와 렌더러 프로세스를 모두 제어할 수 있다. 이는 두 프로세스 모두에 Node를 통합해야 함을 의미한다.

Chromium의 메시지 루프를 libuv로 교체하기​

첫 번째 시도는 Chromium의 메시지 루프를 libuv로 재구현하는 것이었다.

렌더러 프로세스는 비교적 쉬웠다. 렌더러 프로세스의 메시지 루프는 파일 디스크립터와 타이머만 감시하기 때문에, libuv와의 인터페이스만 구현하면 됐다.

그러나 메인 프로세스는 훨씬 더 어려웠다. 각 플랫폼마다 고유한 GUI 메시지 루프가 존재한다. macOS의 Chromium은 NSRunLoop를 사용하고, Linux는 glib를 사용한다. 나는 네이티브 GUI 메시지 루프에서 기본 파일 디스크립터를 추출해 libuv에 전달하는 다양한 방법을 시도했지만, 여전히 작동하지 않는 예외 상황이 발생했다.

결국 나는 작은 간격으로 GUI 메시지 루프를 폴링하는 타이머를 추가했다. 이로 인해 프로세스가 일정한 CPU 사용량을 유지하게 되었고, 특정 작업에서 긴 지연이 발생했다.

별도의 스레드에서 Node의 이벤트 루프 폴링하기​

libuv가 성숙해지면서 새로운 접근 방식이 가능해졌다. libuv는 이벤트 루프를 위해 폴링하는 파일 디스크립터(또는 핸들)인 backend fd 개념을 도입했다. 따라서 backend fd를 폴링하면 libuv에 새로운 이벤트가 발생했을 때 알림을 받을 수 있다.

Electron에서 나는 별도의 스레드를 생성해 backend fd를 폴링하도록 했다. libuv API 대신 시스템 호출을 사용해 폴링했기 때문에 이 방식은 스레드 안전했다. libuv의 이벤트 루프에 새로운 이벤트가 발생할 때마다 Chromium의 메시지 루프에 메시지를 전송했고, libuv의 이벤트는 메인 스레드에서 처리됐다.

이 방식을 통해 Chromium과 Node에 패치를 적용하지 않아도 됐고, 동일한 코드를 메인 프로세스와 렌더러 프로세스 모두에서 사용할 수 있었다.

코드 구현​

메시지 루프 통합 구현은 electron/atom/common/ 디렉토리 내 node_bindings 파일에서 확인할 수 있다. Node를 통합하려는 프로젝트에서 쉽게 재사용할 수 있다.

업데이트: 구현이 electron/shell/common/node_bindings.cc로 이동되었다.