Electron은 HTML, CSS, JavaScript를 사용해 크로스 플랫폼 데스크탑 애플리케이셔을 만들기 위한 오픈 소스라이브러리

크로스 플랫폼을 지원하기 위해 Chromium과 Node.js를 1개의 런타임으로 통합하였고, Mac, Window, 리눅스용으로 패키지 할 수 있습니다.


원래는 텍스트 편집기인 아톰을 만들기 위해 Electron 프레임워크를 개발하였습니다.

아래 히스토리에 나온 것 처럼 Atom Shell이라는 이름으로 프로젝트를 시작하였지만, 이후 Electron이라는 이름으로 변경 되었다고 합니다.


어떤 앱들이 만들어 졌나



카테고리 별로 보면 대충 500~600개 정도에 앱들이 있는걸 알수 있습니다.

옆에 실제 앱들을 보면 잘 알려진 앱들이 많습니다. 스카이프, 깃헙 데스크탑, 디스코드, 아톰, 비쥬얼 스튜디오 코드 등

많이 있습니다. 


https://electronjs.org/apps


Electron Application Architecture


Electron에서 main 스크립트를 실행하는 프로세스를 메인 프로세스라고 부릅니다. 
Electron 앱은 항상 하나의 메인 프로세스를 가지며, 둘 이상이 되는 경우는 없습니다.

Electron은 웹페이지를 보여주기 위해 Chromium을 사용하고 있기 때문에 Chromium의 멀티 프로세스 아키텍쳐 가 그대로 이용되고 있습니다. Electron 안에서 보여지는 각각의 웹페이지는 자신의 프로세스 안에서 동작하는데, 이 프로세스를 렌더러 (renderer) 프로세스라고 부릅니다.

일반적인 브라우저에서 웹 페이지는 보통 샌드박스 환경에서 실행되므로 네이티브 리소스에는 액세스 할 수 없습니다. 
그러나 Electron 을 사용하게 되면 웹페이지가 Node.js APIs 를 이용할 수 있기 때문에, 
보다 로우한 레벨에서 운영체제와 상호작용하는 것이 허용되어 있습니다.

프로세스간에는 IPC(Inter-Process Communication) 통신으로 데이터를 주고 받는다고 합니다.
그것을 위해 ipcRenderer, ipcMain이라는 모듈을 제공 한다고 합니다.

Electron 지원


Electron이 어떤 프레임 워크와 아키텍처에 대해 알아보았고, 어떤 부분을 지원해주는지에 대해 알아보도록 하겠습니다.
공식 페이지에서 보면 자동 업데이트, 기본 메뉴와 알림, 충돌 보고, 디버깅과 프로파일링, 윈도우 설치 프로그램을 지원한다고합니다.
이런 부분들이 앱, 프로그램들을 개발할 시 신경써야 할 중요한 부분들 입니다. 
이 부분들이 제대로 지원이 된다면 개발이 크게 쉬워질것 같아 보입니다.

자동 업데이트



OS별로 자동 업데이트를 살펴보면 MacOS는 Squirrel이라고 불리는 어플리케이션 업데이트 프레임워크를 사용합니다.

윈도우 또한 Squireel.window를 사용하는 방법도 있지만

electron-winstaller, electron-forge라는 패키지를 사용하거나 electron-installer 패키지를 사용하는 것을 권장한다고 합니다.



메뉴/ 알림



먼저 템플릿을 정하고 menu의 스태틱 메서드 buildFormTemplate를 이용하여 템플릿을 만들고 setApplicationMenu를 호출하면 됩니다.


기본적인 기능은 electron에서 기본 제공하는 role에 할당하면 됩니다.

그 외 로직이 필요할 경우에는 role 대신 click을 생성하여 함수를 작성하면 됩니다.

role, click 뿐만 아니라 checked, enable, visible 등 옵션등이 있습니다.


메뉴를 생성하게 되면 사진 처럼 맥용 윈도우용 리눅스용으로 메뉴가 생성되게 됩니다.




Renderer Process에 구현하면 되고, HTML5 API 중 Notification API를 사용합니다.
Icon 옵션을 이용하여 이미지를 포함하거나 하지 않는 방법을 제공합니다.

Electron API Demos

제공되는 API Demo를 사용해서 기본적으로 필요한 기능은 모두 구현 가능해 보입니다.


웹 어셈블리에 대한 관심


먼저어셈블리가 뭔지 알아보기 전에 얼마나 브라우저사 또는 IT관련 회사들에서어셈블리에 관심을 가지고 있는지 찾아봤습니다.




기사 제목들만 봐도 많은 관심이 있고, 현재도 계속 진행중인것을 알수 있습니다.

그럼어셈블리가 뭔지 알아보도록 하겠습니다.


웹 어셈블리란?

일단 이름에서도 알수 있듯이 Web과 Assembly에 합성어로 WebAssembly로 불립니다.


웹 브라우저에서 실행 할수 있는 코드 형식이고 성능적인 부분에서 상당한 이점을 가지고 있다고 합니다.

직접 코드를 작성하는 것이 아니고 C/C++,Rust(모질라 리서치에서 개발한 인터넷에서 사용되는 서버와 클라이언트에 적합한 프로그래밍 언어, C/C++과 유사한 모양) 같은 로우레벨 언어를 컴파일 타겟이 되어 컴파일된다고 생각하면됩니다.


이 웹 어셈블리는 상당히 큰 의의를 갖는다고 하고요.

향후 Java, C, C++ 등등 여러 언어로 작성된 코드를 네이티브에 가까운 속도로 웹에서 돌릴 수 있는 길을 제공하고, 프로그램, 앱 환경, 즉 네이티브 환경에서 동작하던 작업들을 웹에서 할수 있게 됩니다.


심지어 웹어셈블리를 작성하는 방법 또한 몰라도 되며, 임포트하여 자바스크립트에서 불릴 수 있도록 제공되고 있습니다.



웹 어셈블리는 구글, 마이크로소프트, 애플, 모질라가 참여하여 웹 어셈블리 커퓨니티 그룹이 웹 성능을 향상시키지 위해 2015년부터 개발하고 있는 표준 포맷으로 2017년 3월부터 도입되어 현재 지원되고 있습니다.


메이저 브라우저 엔진 개발회사들에서 참여하고 있어 큰 의미가 있어 보입니다.




현재 엣지, 파이어폭스, 크롬, 사파리에서 지원되고 있으며,  모바일에서도 ios Safari, Android Chrome 에서도 지원되고 있습니다.

웹 어셈블리 등장 배경

플러그인 지원 중단


웹 어셈블리가 나오게 된 배경을 보면 2014년에 발표되어 점차적으로 크롬, 파이어폭스 브라우저에서 플러그인 지원을 중단하였습니다. 보안적인 이슈와 복잡한 코드 등에 이슈로 중단하게 되었죠

자바 스크립트의 한계

그리고 웹브라우저의 VM은 오직 자바스크립트만 불러올 수 있었습니다. 오늘날의 웹에서 사람들이 겪는 대부분의 문제를 해결하기에 자바스크립트가 충분히 잘 작동했다고 볼 수 있기는 합니다. 하지만 3D 게임이나, 가상/증강현실, 영상처리, 이미지/비디오 편집, 그 외 네이티브 성능을 필요로하는 여러 분야의 사례(웹어셈블리 사용례 참고)에서는 성능상의 문제에 부딪혀 왔습니다.






웹 어셈블리의 발전 배경





웹 어셈블리를 설명하게 되면서 같이 설명되는 것들이 있는대요
먼저 구글 웹 툴킷은 자바스크립트 프론트엔드 애플리케이션을 먼저 자바로 만들고 자바스크립트로 변환/관리할 수 있게 하는 오픈 소스 도구 집합입니다.

성능적인 부분을 향상하기 위함을 목표로 하진 않았지만, 
웹 어셈블리를 설명하는 많은 곳에서 언급되어 있고 이러한 일련의 프로젝트들의 기술들이 축적되어 웹 어셈블리 개발의 밑거름이 되었다고 봅니다.

또하나 무조건 언급되고 있는게 asm.js 입니다.
asmjs란 2013년에 모질라에서 발표하였습니다. 새로운 언어나 코드가 아니고, c나 c++코드를 javascript로 변환하여 웹으로 포팅하는 자바스크립트의 서브셋이라고 설명되어 있고,
Emscripten와 같은 컴파일 라이브러리를 이용합니다.

jQuery 창시자인 존 레식도 트위터에서 모질라에 몸담고 있었기 때문이라고 볼수도 있지만, 자바스크립트 분야에서 가장 흥미로운 일중에 하나라고 Asm.js를 언급하였었다고 합니다.


웹 어셈블리의 목표

웹 어셈블리의 목표는 빠르고, 이식성이 좋도록 하여 여러종유의 플랫폼 위에서 거의 네이티브에 가까운속도로 실행될 수 있도록 하는 것

읽기 쉽고, 디버깅이 가능하도록 하는 것, 보안적으로도 안전함을 유지하도록 하는 것과 하위호환성을 관리 할수 있도록 설계하여 웹을 망가뜨리지 않는 것이라고 합니다.


웹 어셈블리의 컨셉



웹 어셈블리는 모듈, 메모리, 테이블, 인스턴스라는 핵심 컨셉을 가지고 개발되어 있으며 그에 대한 설명입니다.

자바스크립트 API에 반영되어 웹 어셈블리 모듈, 메모리, 테이블, 인스턴스를 생성할 수 있는 방법을 제공합니다. 
자바스크립트 코드에서 웹어셈블리 인스턴스에 접근하면 일반 자바스크립트 함수의 형태로 노출시킨 익스포트 함수를 동기적으로 호출할 수 있습니다. 뒤에서 실제로 해보도록 하겠습니다.

웹어셈블리 코드 또한, 웹어셈블리 인스턴스의 임포트 형식으로 넘겨받은 임의의 자바스크립트 함수를 동기적으로 호출할 수 있습니다.


웹 어셈블리 사용 방법





먼저 C코드를 작성하게 되고, EmScripten 툴을 통해 컴파일 하여 wasm 파일을 가져오게 됩니다.
그 후 glue code라고 불리는 javascript문법(?)을 통해 wasm파일을 로드하여 사용하면 됩니다.

속도 비교


실행 속도는 다음과 같다고 합니다. ASM.JS를 웹 어셈블리의 속도와 비슷하다고 생각되어 첨부하였습니다.

이 표는 3D에서 피부를 입히는 스키닝, zlib 압축 라이브러리, 물리 엔진인 불릿을 파이어폭스, 크롬, asm.js Native로 돌렸을 때 퍼포먼스를 표로 나타낸 것입니다.

네이티브 코드를 1로 보았을 때 비교 입니다.

마찬가지로 보시면 Native보다는 아직 성능적으로 부족하나 기존 자바스크립트보다는 월등한 속도인걸 알수 있으며 asm.js는 파이어폭스에서 시작한 프로젝트인 만큼 파이어폭스에 특화된걸 볼 수 있습니다.


웹 어셈블리 데모

Sobel은 윤곽선을 추출하는 알고리즘입니다. 웹 어셈블리로 데모를 제공하(WASMSobel)여 javascript와 속도를 비교 할수 있도록 제공





게임에 적용된어셈블리 데모(데모 사이트)



openCV를 웹 어셈블리로 제공(데모 사이트)




얼굴 인식 데모 사이트


참고

  • https://caniuse.com/
  • https://developer.mozilla.org/ko/docs/WebAssembly/Concepts
  • https://github.com/mdn/webassembly-examples/tree/master/wasm-sobel
  • http://webassembly.org
  • https://www.websightjs.com/
  • https://www.devpools.kr/2017/01/21/webassembly-binaryen-emscripten/
  • https://blog.outsider.ne.kr/927



Chrome Autoplay policy

  • 2018년 4월 부터 적용될 예정이라고 선언했으며, 적용 되었음
  • 사용자 경험을 개선하기 위해 엄격한 자동재생 정책으로 시행
  • 몇가지 조건 일 경우에만 자동 재생 허용
    • 무음인 영상일 경우 자동 재생 허용
    • 사용자 인터렉션(클릭, 탭, 터치) 등이 있었을 경우 자동 재생 허용
    • 데스크탑에서 MEI(Media Emgagement Index)가 임계치를 넘었을 경우
      • chrome://media-engagement ← 여기서 MEI 확인 가능
    • 상단 프레임에서 허용을 iframe으로 전달하여 허용

  • video tag로 부터 play promise를 받을 경우 에러 발생
    • "play() failed because the user didn't interact with the document first. name : "NotAllowedError"



  • 참고


'HTML5' 카테고리의 다른 글

#크롬 자동재생 정책, Chrome Autoplay Policy  (0) 2018.05.13
[HTML5] #Video Tag  (0) 2017.10.09

+ Recent posts

티스토리 툴바