Electron Desktop App Development · 강의

백그라운드 프로세스 및 워커

무거운 계산을 백그라운드 프로세스와 웹 워커로 분산하여 메인 UI의 반응성과 성능을 유지합니다.

레슨 2/411개 단계

백그라운드 프로세스 및 워커은(는) CoddyKit의 무료 Electron Desktop App Development 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Electron Desktop App Development 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Electron Desktop App Development 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Keep Your App Responsive

Imagine your desktop app freezing when you click a button or perform an action. Frustrating, right?

A responsive UI (User Interface) means your application remains smooth and interactive, even when doing heavy work in the background.

This lesson explores how to offload tasks to keep your Electron app feeling snappy and fast for your users.

The Single-Threaded UI

In web browsers and Electron's renderer processes, JavaScript typically runs on a single thread. This is often called the main thread.

This thread handles everything: rendering the UI, responding to user input, and running your JavaScript code.

If a long-running computation happens on the main thread, it "blocks" it, making your app unresponsive and causing the UI to freeze.

Meet Web Workers

To avoid freezing the UI, we can use Web Workers. They allow you to run scripts in the background, separate from the main thread.

Think of a Web Worker as a separate JavaScript execution environment that doesn't interfere with your UI.

They are perfect for CPU-intensive tasks that don't need direct access to the webpage's DOM (Document Object Model).

Your First Web Worker

Let's see a simple example of offloading a "heavy" calculation to a Web Worker.

First, you'd create a file named worker.js containing the worker's logic:

// worker.js content
onmessage = function(e) {
  let result = 0;
  for (let i = 0; i < e.data; i++) {
    result += i;
  }
  postMessage(result); // Send result back to main thread
};

Now, in your Electron renderer process (e.g., within your index.html's <script> or a linked renderer.js), you'd use this code:

Try running this example:

const myWorker = new Worker('./worker.js'); // Path to your worker.js file

myWorker.onmessage = (event) => {
  console.log('Worker finished calculation. Result:', event.data);
  // In a real app, you'd update an HTML element:
  // document.getElementById('resultDisplay').innerText = `Result: ${event.data}`;
};

myWorker.onerror = (error) => {
  console.error('Worker error:', error.message);
};

const dataToSend = 500000000; // A large number for a noticeable delay
console.log('Sending task to worker with input:', dataToSend);
myWorker.postMessage(dataToSend);

console.log('UI thread is free and responsive!');
// This message will appear immediately, proving the UI thread is not blocked.

Talking to Workers

Web Workers communicate with the main thread using a simple message-passing system:

postMessage(): Used by both the main thread and the worker to send data.
onmessage event handler: Used by both sides to receive data. The data is available in event.data.

Messages are copied, not shared, meaning complex objects are serialized and deserialized. This ensures data integrity between threads.

What Workers Can't Do

While powerful, Web Workers have some limitations:

No DOM Access: Workers cannot directly manipulate the webpage's Document Object Model (HTML elements).
Limited APIs: They don't have access to some browser APIs like window, document, or parent.
Local File Access: Direct access to local files (e.g., using Node.js fs module) is not available in a standard Web Worker.

For tasks requiring these, you might need a different approach or to pass data back to the main thread.

Node.js Worker Threads

Electron's main process, and renderer processes with Node.js integration, can use Node.js Worker Threads.

These are different from Web Workers:

They have full Node.js API access (e.g., fs, http).
They can be used in the main process to prevent blocking the *entire* Electron app.
They are ideal for CPU-bound Node.js tasks.

Worker Threads are crucial when your background tasks need Node.js capabilities.

Node.js Worker in Action

Here's how you might use a Node.js Worker Thread to perform a heavy computation that also uses a Node.js feature (like reading a file, though we'll simplify for the example).

First, create worker_node.js:

// worker_node.js content
const { parentPort } = require('worker_threads');

parentPort.on('message', (data) => {
  let result = 0;
  for (let i = 0; i < data; i++) {
    result += i;
  }
  parentPort.postMessage(result);
});

Then, in your main process or a renderer with Node.js integration:

Try running this example:

const { Worker } = require('worker_threads');
const path = require('path');

// Path to your Node.js worker script (assuming it's in the same directory)
const workerPath = path.join(__dirname, 'worker_node.js');

// Create a new Node.js Worker Thread
const worker = new Worker(workerPath);

// Listen for messages from the worker
worker.on('message', (result) => {
  console.log('Node.js Worker finished. Result:', result);
  worker.terminate(); // Terminate the worker when done
});

// Listen for errors
worker.on('error', (err) => {
  console.error('Node.js Worker error:', err);
});

// Listen for worker exit
worker.on('exit', (code) => {
  if (code !== 0) {
    console.error(`Node.js Worker stopped with exit code ${code}`);
  }
});

// Send data to the worker to start computation
const dataForWorker = 500000000;
console.log('Sending task to Node.js Worker with input:', dataForWorker);
worker.postMessage(dataForWorker);

console.log('Main/Renderer thread is free!');

Web Worker vs. Node.js Worker

How do you decide which type of worker to use?

Web Workers:
- Best for CPU-bound tasks in the renderer process.
- Cannot access DOM or Node.js APIs.
- Good for calculations, data processing that doesn't need system access.
Node.js Worker Threads:
- Best for CPU-bound tasks in the main process or renderer process with Node.js integration.
- Can access all Node.js APIs (e.g., file system, network).
- Good for heavy Node.js operations without blocking the UI or main app logic.

Worker Knowledge Check

You've learned about different ways to offload tasks in Electron. Let's test your understanding!

인터랙티브 레슨에서 답해보세요

Recap: Keeping Electron Responsive

Great job! You've learned how to keep your Electron applications responsive:

The main thread handles UI and can be blocked by heavy tasks.
Web Workers run JavaScript in the background, separate from the UI, for CPU-bound tasks without DOM access.
Node.js Worker Threads also run in the background but provide full Node.js API access, suitable for main process or Node.js-integrated renderer tasks.

By effectively using these tools, you can build Electron apps that feel fast and smooth!

무료로 시작

AI 튜터와 함께 JavaScript을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 12
레슨: 47

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“백그라운드 프로세스 및 워커” 강의는 무료인가요?

네 — “백그라운드 프로세스 및 워커” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Electron Desktop App Development 강의 전체를 잠금 해제할 수 있습니다. Electron Desktop App Development 강의에는 총 4개의 강의가 포함되어 있습니다.

“백그라운드 프로세스 및 워커”에서 뭘 배우나요?

무거운 계산을 백그라운드 프로세스와 웹 워커로 분산하여 메인 UI의 반응성과 성능을 유지합니다. 브라우저에서 직접 실행하는 실습 코드로 Electron Desktop App Development을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Electron Desktop App Development을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Electron Desktop App Development은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“백그라운드 프로세스 및 워커” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Electron Desktop App Development 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Electron Desktop App Development 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Electron Desktop App Development(으)로 돌아가기