# 什么是进程间通信（IPC）？
进程间通信（IPC） 是在不同进程之间传递数据和消息的机制。在 Electron 中，主进程和渲染进程各自运行在独立的进程中，需要通过 IPC 来交换信息。



重要性：

+ 数据交换： IPC 允许主进程和渲染进程交换数据，实现功能协作。
+ 安全性： 通过限制直接访问，IPC 确保了应用的安全性，防止潜在的安全漏洞。

# Electron 中的 IPC 实现
Electron 提供了两个主要模块来实现进程间通信：

1. ipcMain（主进程）：

接收来自渲染进程的消息，并发送响应。

使用示例：

```javascript
// 主进程代码
const { ipcMain } = require('electron');

ipcMain.on('channel-name', (event, arg) => {
  // 处理消息
  event.reply('channel-name-reply', 'Response Data');
});
```
2. ipcRenderer（渲染进程）：

向主进程发送消息，并接收响应。

使用示例：

```javascript
// 渲染进程代码
const { ipcRenderer } = require('electron');

// 发送异步消息
ipcRenderer.send('channel-name', 'Message Data');

// 接收主进程的响应
ipcRenderer.on('channel-name-reply', (event, response) => {
  console.log(response); // 处理响应数据
});
```
> [进程间通信](https://www.electronjs.org/zh/docs/latest/tutorial/ipc)

Electron的进程间通讯(IPC)

在学习 Electron 时，首先需要理解其基本的进程模型，因为 Electron 应用由两个主要的进程组成：主进程（Main Process）和渲染进程（Renderer Process）。每个进程承担不同的职责，而且它们之间的通信方式也决定了应用的架构和安全性。




# Electron 的进程模型
Electron 是一个跨平台的桌面应用框架，使用 Web 技术（HTML、CSS、JavaScript）来构建用户界面，但它的架构与传统的 Web 应用有所不同。Electron 的应用由两个主要进程组成：
1. 主进程（Main Process）：

    主进程负责整个应用的生命周期管理，比如创建窗口、处理用户交互、管理文件等。它是 Electron 应用的核心。在主进程中，你可以访问 Node.js 的 API、操作系统资源、创建系统通知等。

2. 渲染进程（Renderer Process）：

    渲染进程负责呈现和管理用户界面，它通常是运行网页内容的进程（也就是 HTML、CSS、JavaScript）。渲染进程与主进程不同，它不能直接访问 Node.js API，出于安全性考虑，渲染进程的功能被限制。

这两个进程各自独立运行，它们之间通过 IPC（进程间通信） 进行通信。主进程负责创建和管理应用窗口，而渲染进程则负责渲染 UI 和执行应用逻辑。

```mermaid
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#4C9AFF", "edgeLabelBackground":"#ffffff"}}}%%
graph TD
  A[Electron 进程模型] --> B[主进程]
  A --> C[渲染进程]
  B --> D[创建和管理窗口]
  B --> E[访问 Node.js 和 Electron API]
  C --> F[渲染网页内容]
  C --> G[无法直接访问 Node.js 和 Electron API]
  B --> H[预加载脚本]
  H --> I[在渲染进程加载前执行]
  H --> J[通过 contextBridge 暴露安全 API]
  H --> K[实现主进程与渲染进程的通信]
  H --> L[增强渲染进程功能]
  H --> M[确保应用安全性]

```
# 渲染进程的限制

由于渲染进程运行的是网页内容，并且可能会加载不可信的第三方内容，因此 Electron 出于安全性考虑，默认情况下不允许渲染进程直接访问 Node.js API 或 Electron 的核心功能。这就意味着，在渲染进程中，开发者不能像在主进程中那样直接使用文件系统、操作系统功能等。

为了让渲染进程能够执行特定的 Node.js 操作，Electron 提供了一种安全的方式——预加载脚本。

# 预加载脚本

预加载脚本（Preload Script）是运行在渲染进程与主进程之间的一种特殊脚本。它的作用是让主进程将某些安全的 Node.js 或 Electron API 暴露给渲染进程，而不直接暴露所有的核心 API，从而保障应用的安全性。

## 为什么要使用预加载脚本？
默认情况下，渲染进程无法访问 Node.js 或 Electron API，直接使用 require 或 import 语句会抛出错误。通过预加载脚本，你可以将一些受控且安全的 API 暴露给渲染进程，让渲染进程能够安全地与主进程进行交互，同时避免暴露系统级功能和潜在的安全风险。

### 1. 创建预加载脚本

预加载脚本通常是一个 JavaScript 文件，里面使用 contextBridge 将某些 API 暴露给渲染进程。contextBridge 确保渲染进程只能访问你允许的功能，而不是整个 Node.js 环境。

```Javascript
// preload.js
const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  // 通过 ipcRenderer 与主进程通信
  sendMessage: (message) => ipcRenderer.send('message', message),
  onMessage: (callback) => ipcRenderer.on('message', (event, data) => callback(data)),
});
```

在上面的代码中，我们使用 contextBridge.exposeInMainWorld 来将 sendMessage 和 onMessage 函数暴露到渲染进程的 window.electron 对象上。这样，渲染进程就可以通过 window.electron.sendMessage 和 window.electron.onMessage 来与主进程进行通信。

### 2. 配置主进程使用预加载脚本

在主进程中创建 BrowserWindow 时，指定 preload 选项来加载你的预加载脚本：
```Javascript
// main.js
const { app, BrowserWindow } = require('electron');
const path = require('path');

function createWindow() {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'), // 指定预加载脚本
      nodeIntegration: false, // 禁用 nodeIntegration，增加安全性
      contextIsolation: true, // 启用上下文隔离，确保渲染进程安全
    }
  });

  win.loadURL('https://your-app-url.com');
}

app.whenReady().then(createWindow);
```

这样，Electron 会在渲染进程加载前执行 preload.js，并允许渲染进程访问你通过 contextBridge 暴露的 API。

### 3. 在渲染进程中使用暴露的 API

在渲染进程中，你可以通过 window.electron 对象访问预加载脚本暴露的功能：
```Javacript
// renderer.js
window.electron.sendMessage('Hello from renderer');
window.electron.onMessage((data) => {
  console.log('Received message:', data);
});
```
通过这种方式，渲染进程与主进程之间的通信既保持了安全性，又能够实现功能扩展。

# 关键安全概念
1. contextBridge： 通过 contextBridge，你可以精确控制暴露给渲染进程的 API，避免暴露不必要的 Node.js 或 Electron 功能。它能够将你希望暴露的 API 安全地引入渲染进程。
2. contextIsolation： 启用上下文隔离可以确保渲染进程中的 JavaScript 代码与主进程和 Node.js 环境分隔开来，从而避免潜在的安全问题。
3. 禁用 nodeIntegration： 关闭 nodeIntegration 进一步确保渲染进程无法直接访问 Node.js API，提高应用的安全性。

理解 Electron 的进程模型与预加载脚本

当项目逐渐变大，或需要考虑加载速度的问题时，就会考虑到分包问题。

一般来说，项目中的代码可分为业务代码和第三方库，常常会变化的都是业务代码部分，而非第三方库的代码，所以在项目更新的时候，每次都全量更新对于运维部署和客户使用来说都造成了不必要的浪费。




我们都知道，在打包的时候，vite会将我们的代码合并到几个文件中，并以name-hash名字进行命名，一般来说代码没更新时，hash值也不会变，那么我们的思路就是：将不经常变的第三方库代码打包到一个文件中，项目的业务代码打包到一个文件中，从而实现部分更新。

# rollup配置

因为vite的底层还是使用的Rollup，所以查阅rollup的文档，通过output.manualChunks可实现自定义的chunk。

[配置选项 | Rollup 中文文档](https://cn.rollupjs.org/configuration-options/#output-manualchunks)

## 简单模式
```javascript
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          lodash: ['lodash']
        }
      }
    }
  }
```
当配置成上述格式时，则会将value数组中所有的第三方包全部放到一个lodash的chunk 中。

配置前：
![image.png](/static/img/bd3453119ef33a7c5a9f87bc71645f09.image.webp)

配置后：
![image.png](/static/img/2d39fdc637ab742faa49f04b78f3f0f5.image.webp)

以上是配置前后的打包结果对比，可以发现我们指定的第三方库的代码都打包到了一个chunk中，而且业务代码的变更并不会引起lodash的chunk的变化。


## 函数模式
简单模式虽然简单，但是如果一个项目的第三方库很多，那么配置在一个数组里面也不现实，所以这个时候需要使用函数模式，我们已知所有的依赖都会存在于node_modules文件夹中，所以，可以利用这个特性来完成。
```javascript
  build: {
    rollupOptions: {
      output: {
        manualChunks: (id) => {
          if (id.includes('node_modules')) {
            return 'vendor'
          }
          return undefined
        }
      }
    }
  }
```
通过这种方式，所有的第三方库都会打包放在vendor的chunk中.

![image.png](/static/img/0c2309ec2bba04d6275bd0c0bfdadc7a.image.webp)

vite打包-控制第三方包分包

## 方法1：配置Docker守护进程
配置Docker守护进程以使用代理是最全局的方法之一，适用于所有通过守护进程启动的容器和构建操作。您可以通过编辑/etc/systemd/system/docker.service.d/http-proxy.conf文件来设置环境变量，为Docker守护进程指定代理：



```conf
[Service]
Environment="HTTP_PROXY=http://your-proxy-address:port/"
Environment="HTTPS_PROXY=http://your-proxy-address:port/"
```
注意：HTTPS_PROXY既可以使用https的地址，也可以使用http的地址。

记得之后重新加载守护进程配置并重启Docker服务：
```bash
sudo systemctl daemon-reload
sudo systemctl restart docker
```
## 方法2：为单个容器配置网络代理
如果您只希望为特定的Docker容器配置网络代理，可以在运行容器时通过--env参数指定：
```bash
docker run -it --env HTTP_PROXY="http://your-proxy-address:port" --env HTTPS_PROXY="http://your-proxy-address:port" ubuntu bash
```
这种方法的优势在于其灵活性，允许您为不同的容器指定不同的代理配置。
## 方法3：在Dockerfile中配置代理
当您在构建自己的镜像时，可以在Dockerfile中设置环境变量，让构建过程使用代理。这对于在构建过程中需要下载外部依赖的情况非常有用：
```conf
ARG HTTP_PROXY="http://your-proxy-address:port/"
ARG HTTPS_PROXY="http://your-proxy-address:port/"

ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
```
在构建镜像时，使用--build-arg参数来确保这些设置被应用：
```bash
docker build --build-arg HTTP_PROXY="http://your-proxy-address:port/" --build-arg HTTPS_PROXY="http://your-proxy-address:port/" -t your-image-name .
```
## 方法4：使用Docker Compose配置代理
Docker Compose是处理多容器Docker应用的一个工具。您可以在docker-compose.yml文件中为服务设置代理环境变量：
```yaml
version: '3'
services:
  your-service:
    image: your-image
    environment:
      - HTTP_PROXY=http://your-proxy-address:port/
      - HTTPS_PROXY=http://your-proxy-address:port/
```
这种方法简化了复杂应用的代理配置过程，只需一次性设置即可应用于所有相关服务。
## 方法5：使用systemctl edit修改Docker服务的网络代理
对于那些使用systemd管理Docker服务的系统，systemctl edit命令提供了一种直接且安全的方式来修改Docker服务的配置，尤其是对于配置网络代理这一需求。这种方法不需要直接修改Docker服务的主配置文件，避免了手动操作带来的风险。

步骤：
### 打开Docker服务的覆盖编辑器
使用下面的命令来开启Docker服务的系统编辑器：
```bash
sudo systemctl edit docker.service
```
这将打开一个空的文件（如果是第一次执行此操作），等待您输入需要覆盖的配置。

如果需要更换编辑器为vim，可以：
```bash
sudo EDITOR=vim systemctl edit docker.service
```
### 添加HTTP/HTTPS代理环境变量
在打开的编辑器中，您需要指定代理配置。请添加如下配置以设置HTTP和HTTPS代理：
```conf
[Service]
Environment="HTTP_PROXY=http://your-proxy-address:port/"
Environment="HTTPS_PROXY="http://your-proxy-address:port/"
```
替换http://your-proxy-address:port/为您实际的代理服务器地址。
### 保存并关闭编辑器
完成编辑后，保存文件并退出编辑器。systemd将自动创建一个名为/etc/systemd/system/docker.service.d/override.conf的文件，其中包含您添加的配置。

### 重新加载daemon并重启Docker服务
为了让刚才的更改生效，需要重新加载systemd daemon并重启Docker服务：
```bash
sudo systemctl daemon-reload
sudo systemctl restart docker.service
```
这个方法的优点是，通过使用systemctl edit命令，您可以避免直接编辑Docker的主配置文件，而是通过创建一个特定的覆盖文件来实现您的配置。这样做的好处是，原始配置文件保持不变，方便将来的升级和维护，并且您的自定义配置也不会在软件包更新时被覆盖。

### 取消网络代理
```bash
rm  /etc/systemd/system/docker.service.d/http-proxy.conf -rf
systemctl daemon-reload
systemctl restart docker
systemctl show docker --property Environment
```

> [若干种设置Docker的网络代理方法](https://cloud.tencent.com/developer/article/2423782)

设置Docker的网络代理

# 使用label-studio半自动标记yolo数据集

最近在做yolo物体识别，需要标记很多图片，开始是用`labelImg`标记，但是在标记过程中，经常需要增加标签或者增加新的图片，很多时候是在重复标记，所以就想有没有办法，通过已经训练好的模型自动标记，自己只需要做新的标记和调整。

后面查了下相关资料，发现`labelImg`的升级版`label-studio`正好满足我的要求，以下是在做的过程中的相关记录。



## 安装label-studio和简单使用

### 在docker中安装

```shell
docker pull heartexlabs/label-studio:latest
docker run -it -p 8080:8080 -v $(pwd)/mydata:/label-studio/data heartexlabs/label-studio:latest
# 后台运行
docker run -d -p 8080:8080 -v $(pwd)/mydata:/label-studio/data heartexlabs/label-studio:latest
```

### 通过pip安装

```shell
# Requires Python >=3.8
pip install label-studio

# Start the server at http://localhost:8080
label-studio
```

### 创建yolo标注项目

安装完成后，打开地址http://localhost:8080 ，打开此界面则安装成功，首先需要注册一个账号然后登陆


![image-20230813223636318.png](/static/img/3446b45f0603d4e2379aded51f9b6e38.image-20230813223636318.webp)

进入到主页，因为目前还没有项目，所以是空白的，我们点击`Create Project`

![image-20230813223751804.png](/static/img/577210e5a81e318ea566f0a9d779c565.image-20230813223751804.webp)
在第一页，填写项目的名称和描述，然后第二页是导入数据，可以暂时先不导入，第三页是选择项目模版，因为是物体识别项目，所以我们选中`Bounding Boxes`，然后选择完成后，点击`Sava`

![image-20230813223915974.png](/static/img/fe1ffad44cad7b3cb268754795358a10.image-20230813223915974.webp)

![image-20230813224043260.png](/static/img/ab98ca50ed1f86a54a3312c72aa3b907.image-20230813224043260.webp)

### 导入数据

进入到项目主页，点击`Import`导入图片，

![image-20230813224133747.png](/static/img/21b05e25220d9a785dda3b322fff7f2e.image-20230813224133747.webp)

![image-20230813224229798.png](/static/img/17da5298b83de8b9e2b8ab90184ebd32.image-20230813224229798.webp)

![image-20230813224240911.png](/static/img/81a15f6d5714cb9f9586bc1458609be7.image-20230813224240911.webp)

![image-20230813224251134.png](/static/img/e8b215104b376b2c530dcb3a6f9cc2df.image-20230813224251134.webp)

### 标签设置

在标记图片之前，我们需要先录入标签，点击右上角的`Settings` ，然后点击`Labeling Interface`，在`Add labels names` 中添加标签，一行一个

在项目主页，点击第一个图片，开始标记，标记完成后，点击`submit`提交
![image-20230813225315648.png](/static/img/b4e6bf9aa98018fbc19df2f92ddee7eb.image-20230813225315648.webp)

### 导出数据

点击右上角的`Export`，选择YOLO，则可以导出YOLO所需要的数据集

## 编写YOLO推理后端

### 安装Label-studio ML SDK

```shell
pip install -U label-studio-ml -i https://mirrors.aliyun.com/pypi/simple/
```

### 安装一些其他依赖

```
pip install redis re ultralytics -i https://mirrors.aliyun.com/pypi/simple/
```

### 编写model推理文件

```python
import logging

import cv2
from label_studio_ml.model import LabelStudioMLBase
from label_studio_ml.utils import get_image_size, \
    get_single_tag_keys, DATA_UNDEFINED_NAME
from ultralytics import YOLO

logger = logging.getLogger(__name__)


class YOLOMLBase(LabelStudioMLBase):

    def __init__(self,score_threshold=0.3, **kwargs):
        """
        :param kwargs: can contain endpoint_url in case of non amazon s3
        """
        super(YOLOMLBase, self).__init__(**kwargs)
        self.from_name, self.to_name, self.value, self.labels_in_config = get_single_tag_keys(
            self.parsed_label_config, 'RectangleLabels', 'Image')
        self.labels_in_config = set(self.labels_in_config)
        self.score_thresh = score_threshold
        self.model = YOLO('best.pt')

    def _inference_detector(self, image_path):
        i = cv2.imread(image_path)
        return self.model(i)

    def _get_image_url(self, task):
        image_url = task['data'].get(self.value) or task['data'].get(DATA_UNDEFINED_NAME)
        return image_url

    def predict(self, tasks, **kwargs):
        assert len(tasks) == 1
        task = tasks[0]

        image_url = self._get_image_url(task)
        # image_path = image_url
        image_path = self.get_local_path(image_url, "/Users/chenchuan/mydata/media")

        model_results = self._inference_detector(image_path)
        results = []
        all_scores = []
        img_width, img_height = get_image_size(image_path)
        for boex in model_results[0].boxes:
            output_label = model_results[0].names[int(boex.cls)]
            if output_label not in self.labels_in_config:
                print(output_label + ' label not found in project config.')
            x, y, w, h = boex.xywh.tolist()[0][:4]
            score = float(boex.conf)
            if score < self.score_thresh:
                continue
            results.append({
                'from_name': self.from_name,
                'to_name': self.to_name,
                'type': 'rectanglelabels',
                'value': {
                    'rectanglelabels': [output_label],
                    'x': x / img_width * 100,
                    'y': y / img_height * 100,
                    'width': w / img_width * 100,
                    'height': h / img_height * 100
                },
                'score': score
            })
            all_scores.append(score)
        avg_score = sum(all_scores) / max(len(all_scores), 1)
        return [{
            'result': results,
            'score': avg_score
        }]

```



### 生成推理后端项目

在上述`model.py`文件中执行下面命令，生成项目

```
label-studio-ml init yolo_ml_backend
```

如果执行成功，在当前目录下，会创建一个`yolo_ml_backend`文件夹，此时的文件结构如下

```shell
├── best.pt
├── model.py
└── yolo_ml_backend
    ├── Dockerfile
    ├── README.md
    ├── _wsgi.py
    ├── docker-compose.yml
    ├── model.py
    └── requirements.txt
```

`best.pt`是推理模型

### 执行

```shell
label-studio-ml start ./yolo_ml_backend
```

执行成功后，终端会打印后端地址，将地址填写到下图处即可

![image-20230813233143487](/Users/chenchuan/Nutstore Files/.symlinks/坚果云/学习笔记/yolo/assets/image-20230813233143487.png)

此时再打开标注图片时，会先通过推理后端进行预测，我们就只需要进行调整即可了。

> https://labelstud.io/guide/ml_create
>
> https://github.com/HumanSignal/label-studio-ml-backend/