Electron Internals 요약

1. http://electron.atom.io/blog/2016/07/28/electron-internals-node-integration

Node와 GUI programming을 같이 사용하는 경우 Node 자체의 event message loop(libuv를 사용한다.)와 GUI 자체의 event loop 두개가 있게 되는 문제가 있다.  main thread는 한 loop에서만 동작해야 하기 때문이다.
이의 해결을 위한 첫 시도는 크로미움의 main process와 renderer process의 message loop를 libuv로 변경하는 것이었다. renderer process의 message loop를 변경하는 것은 간단했으나 main process의 message loop를 변경하는 것은 매우 어려웠다. 각각의 플랫폼마다 다른 message loop를 사용하기 때문에 이를 libuv에 전달해주는 것이 간단하지 않았다. 결국 매우 작은 주기의 timer를 GUI message loop에 추가하는 방법으로 문제를 해결하고자 하였다.
하지만, libuv가 발전하면서 backend fd라는 개념이 도입이 되었고 이것을 polling함으로서 libuv에서의 event에 노티를 받는 것이 가능해졌다. 그래서 backend fd를 polling하여 event가 발생하면 이를 크로미움의 message loop에 전달해주는 별도의 쓰레드를 만드는 것으로 변경하였다. 이 방법을 사용함으로서 크로미움과 노드의 코드를 변경할 필요가 없게 되었다.

2. http://electron.atom.io/blog/2016/08/08/electron-internals-using-node-as-a-library

- Node와 Electron은 빌드 시스템으로 GYP를 사용한다.
- Electron은 node의 빌드를 위해 node의 configure script를 사용하지 않고 자체 빌드 스크립트를 사용한다.
- Electron은 node를 shared library로 사용하고 node의 v8은 사용하지 않는다.
- Electron은 과거에는 node를 static library했다가 지금은 shared library로 빌드한다.
- Node의 native module들은 V8의 심볼이 필요한데 Electron은 node의 V8을 사용하지 않기 때문에 문제가 있다. 그래서 크로미움의 V8의 심볼들은 외부로 expose 하는게 필요하다.
- Electron은 node를 두가지 모드로 시작할 수 있다. standalone mode와 embedded mode

3. http://electron.atom.io/blog/2016/09/20/electron-internals-weak-references

Weak reference는 object가 가비지 콜렉트 되는 것과 상관없이 object를 사용할 수 있도록 해주는 object에의 reference이다.
자바스크립트에서 weak reference와 관련된 것은 WeakMap이다.
Remote module: RPC를 사용하여 render process에서 main process의 object를 사용할 수 있도록 해준다.
-- renderer process에서 object를 요청하면 main process에 메시지를 보낸다.
-- 메시지를 받은 main process는 map에 object를 생성하고 ID를 생성한다. 이 ID를 renderer process에 돌려준다.
-- remote module은 ID를 받으면 이것을 proxy object로 감싼다. renderer process는 이 proxy object를 사용한다. 사용이 끝나면 proxy object가 가비지 콜렉트 될 때 메시지를 main process에 보내 할당된 object도 가비지 콜렉트 될 수 있도록 한다.

같은 object를 여러번 요청하는 경우 메모리 낭비의 문제가 생길 수 있다. - 이의 해결책은?
- Cache: 같은 ID의 object가 이미 있는 경우 새로 생성하지 않고 기존의 object를 리턴한다.
- 이를 위해 WeakMap을 사용한다.