Electron Desktop App Development · 课时

后台进程与工作线程

利用后台进程和 Web Worker 分担繁重计算，同时保持主用户界面的响应速度与性能

后台进程与工作线程 是 CoddyKit 上的免费 Electron Desktop App Development 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 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 导师）并解锁 Electron Desktop App Development 课程的其余内容，请升级到 CoddyKit PRO。 Electron Desktop App Development 课程共包含 4 节课。

「后台进程与工作线程」这节课中我会学到什么？

利用后台进程和 Web Worker 分担繁重计算，同时保持主用户界面的响应速度与性能你通过在浏览器中直接运行的动手代码来练习 Electron Desktop App Development，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Electron Desktop App Development 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Electron Desktop App Development 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「后台进程与工作线程」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Electron Desktop App Development 课中编写并运行代码吗？

能。每节 Electron Desktop App Development 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Electron Desktop App Development