ProcHub v0.5.0：用构建标识区分 App Store 行为，并重整进程管理界面

预计阅读时间：8 分钟

ProcHub v0.5.0 的变化不只是一组界面调整。这次发布引入 isAppStoreBuild 标识，通过 VITE_APPSTORE_BUILD 环境变量识别 App Store 发布构建，并据此隐藏版本检测按钮、关闭启动时自动版本检测。同时，设置页被拆分成多个职责明确的子组件，进程弹窗也完成重构并加入概览统计卡片。

这些改动集中解决了两个常见的桌面应用工程问题：同一套代码如何适配不同发布渠道，以及功能增长后如何控制组件复杂度。

用构建标识隔离发布渠道差异

桌面应用进入应用商店后，更新流程通常由商店接管。如果商店版本仍展示独立的版本检测入口，或者在启动时访问自建更新服务，可能造成重复体验，也可能与发布渠道的审核要求冲突。

ProcHub v0.5.0 将这个差异前移到构建阶段：

普通发行构建保留版本检测能力。
App Store 构建隐藏手动检测按钮。
App Store 构建不执行启动时自动检测。
业务组件通过统一的 isAppStoreBuild 标识判断渠道，不直接散落读取环境变量。

这种处理比运行时猜测安装来源更稳定，因为发布产物在构建时就已经确定了能力边界。

从 VITE_APPSTORE_BUILD 的命名看，项目构建链路使用或兼容 Vite。类似项目可以这样实践。需要注意，Vite 注入的环境变量是字符串，不能直接用 Boolean(import.meta.env.VITE_APPSTORE_BUILD) 转换，因为字符串 "false" 也会得到 true。

// src/config/build.ts
export const isAppStoreBuild =
  import.meta.env.VITE_APPSTORE_BUILD?.trim().toLowerCase() === "true";

补充环境变量类型声明：

// src/vite-env.d.ts
/// <reference types="vite/client" />

interface ImportMetaEnv {
  readonly VITE_APPSTORE_BUILD?: "true" | "false";
}

interface ImportMeta {
  readonly env: ImportMetaEnv;
}

然后在界面和启动逻辑中复用同一个标识：

import { isAppStoreBuild } from "./config/build";

export async function checkVersionOnStartup(): Promise<void> {
  if (isAppStoreBuild) return;

  await fetch("/api/releases/latest", {
    headers: { Accept: "application/json" },
  });
}

构建时显式指定渠道：

# 普通发行版
VITE_APPSTORE_BUILD=false npm run build

# App Store 发行版
VITE_APPSTORE_BUILD=true npm run build

Windows PowerShell 可以使用：

$env:VITE_APPSTORE_BUILD="true"
npm run build

环境变量只负责选择构建行为，不应被当成安全边界。前端产物中的变量和值都可能被查看；涉及更新签名、授权或服务端访问控制时，仍需在后端或原生层执行校验。

设置页拆分的价值在于职责清晰

v0.5.0 将设置页拆分为主题、语言、自启、版本和关于等独立子组件。对桌面应用来说，这些区域虽然都属于“设置”，但依赖和副作用并不相同：

主题设置需要修改并持久化外观状态。
语言设置会触发国际化资源切换。
自启设置通常需要调用桌面运行时或操作系统接口。
版本区域包含当前版本展示与更新检测。
关于区域以静态信息和外部链接为主。

拆分之后，App Store 的渠道条件可以被限制在版本子组件内部，避免整个设置页充满条件分支。一个可改造的组件组织方式如下：

src/
├── config/
│   └── build.ts
└── settings/
    ├── SettingsPage.tsx
    ├── ThemeSettings.tsx
    ├── LanguageSettings.tsx
    ├── AutostartSettings.tsx
    ├── VersionSettings.tsx
    └── AboutSettings.tsx

版本组件可以只决定是否渲染检测入口：

import { isAppStoreBuild } from "../config/build";

export function VersionSettings() {
  return (
    <section>
      <h2>版本</h2>
      {!isAppStoreBuild && (
        <button type="button" onClick={() => void checkForUpdates()}>
          检查更新
        </button>
      )}
    </section>
  );
}

async function checkForUpdates(): Promise<void> {
  const response = await fetch("/api/releases/latest");
  if (!response.ok) throw new Error("版本检测失败");
}

这里的接口地址只是可替换示例，并非 ProcHub 已公开的具体 API。实际桌面应用还应处理离线状态、超时、重复点击以及组件卸载后的异步回调。

进程弹窗从操作面板变成信息入口

本次发布还重构了进程弹窗，并增加进程概览统计卡片。相比只展示进程列表，概览信息可以让用户先判断系统当前状态，再决定是否搜索、筛选或终止某个进程。

统计卡片适合展示可快速扫描的数据，例如当前进程总数、活跃进程数量或资源占用汇总。不过统计口径必须明确：总数是否包含系统进程，CPU 数据是瞬时值还是采样平均值，内存使用的是常驻集还是其他指标。若缺少说明，精确到小数点后的数字反而容易制造误解。

实现时还要避免每张卡片各自读取一次进程列表。更稳妥的做法是由上层完成一次采样，再把同一份快照传给概览区和明细区，这样可以减少系统调用，并保证两个区域显示的是同一时刻的数据。

升级与验证清单

准备采用 v0.5.0 或借鉴这套设计时，可以重点检查以下项目：

在 CI 中分别生成普通版和 App Store 版，避免依赖开发者本机的临时环境变量。
为 true、false、变量缺失和大小写异常补充构建标识测试。
确认 App Store 产物中既没有版本检测按钮，也不会在启动阶段发起检测请求。
验证主题、语言和自启设置在组件拆分后仍能正确持久化。
检查进程概览与列表是否共享同一次数据采样，并观察高频刷新带来的 CPU 开销。
保留普通发行版的更新失败提示和离线降级路径。

ProcHub v0.5.0 展示的是一次偏工程化的迭代：渠道差异进入明确的构建配置，设置页按职责拆开，进程弹窗则补上更易扫描的状态摘要。真正落地时，关键不是多写一个环境变量判断，而是把渠道规则集中管理、加入自动化验证，并让统计界面建立在一致且成本可控的数据快照之上。

ProcHub v0.5.0：用构建标识区分 App Store 行为，并重整进程管理界面

用构建标识隔离发布渠道差异

设置页拆分的价值在于职责清晰

进程弹窗从操作面板变成信息入口

升级与验证清单

相关推荐

建议反馈