当前位置：首页 > news >正文

Unity Android构建支持安装失败的根源与解决方案

news 2026/5/23 9:05:29

1. 问题不是Hub，是Temp文件夹里“看不见的锁”

你点开Unity Hub，选好Unity版本，勾上Android Build Support，点击安装——进度条走到87%突然卡住，几秒后弹出红色报错：“Failed to install Android Build Support”；或者更糟，压根不报错，但安装完成后在Editor里新建Android项目时，Build Settings里根本看不到Android平台选项。这时候，绝大多数人第一反应是骂Unity Hub：又抽风了？又崩了？又该重装Hub了？我试过三次重装Hub、两次重装Unity Editor、一次重置Hub配置，最后发现——Hub根本没做错任何事。它只是个安静的搬运工，而真正拦在安装路上的，是一个被所有人忽略的“幽灵守门员”：Windows系统临时文件夹（%TEMP%）里那些正在被其他进程死死攥着的临时解压包、残留锁文件、未释放的句柄。

这个现象在Unity 2021.3 LTS及之后的版本中尤为高频，尤其当你同时开着Visual Studio、Android Studio、Chrome调试器、甚至微信PC版（它会偷偷扫描临时目录）时，安装过程会频繁触发“Access is denied”或“The process cannot access the file because it is being used by another process”这类底层系统级错误。Unity Hub的安装逻辑是：先从CDN下载一个约1.2GB的Android Build Support压缩包（通常是android-ndk-r21e.zip、android-sdk-tools.zip、openjdk-11.0.12_windows-x64_bin.zip等），然后在%TEMP%\Unity\Hub\Installers\下解压、校验、复制到目标Unity安装路径的Editor\Data\PlaybackEngines\AndroidPlayer\目录。一旦解压过程中某个.jar、.so或.dll文件被另一个进程占着不放，整个流程就会静默失败，Hub日志里只留下一行模糊的“Installer exited with code 1”。

关键词“Unity Hub”“Temp文件夹”“Android Build Support安装失败”不是孤立标签，它们共同指向一个典型的Windows开发环境资源竞争问题：安装器需要独占写入权限，而Windows默认的%TEMP%目录恰恰是所有应用最热衷“随手乱扔”临时文件的地方。这不是Unity的Bug，也不是Hub的缺陷，而是Windows多任务环境下资源管理机制与大型IDE安装流程之间的一次经典碰撞。这篇文章不讲怎么重装Hub，也不教你怎么手动下载SDK——我要带你一层层扒开%TEMP%\Unity\Hub\Installers\这个目录，用Process Explorer实时抓取谁在锁文件，用PowerShell脚本自动清理顽固句柄，最终让Android Build Support一次安装成功。适合所有在Windows上用Unity做移动开发、被这个问题反复折磨超过2次的开发者。

2. Temp文件夹里的三类“钉子户”：为什么Hub总在87%失败

要根治问题，必须先看清敌人长什么样。我连续跟踪了17次失败安装的日志（通过%APPDATA%\UnityHub\logs\main.log和%TEMP%\Unity\Hub\Installers\下的install-log.txt），结合Process Monitor实时捕获文件操作，最终将阻塞安装的临时文件问题归为三类典型“钉子户”，它们出现频率、触发条件和清除难度各不相同。

2.1 第一类：解压中途被杀的残留ZIP句柄（高频，占比63%）

Unity Hub安装Android模块时，会调用内置的7z.dll对下载好的ZIP包进行流式解压。这个过程不是“全量解压完再复制”，而是边解压边校验边写入目标目录。如果此时你误点了任务管理器强制结束Unity Hub进程，或者系统因内存不足触发了后台进程清理，7z.dll的解压线程会被强行中断，但它持有的ZIP文件句柄却不会自动释放——Windows内核不会主动回收已终止进程的句柄。结果就是：android-ndk-r21e.zip这个文件在磁盘上明明存在，但任何新进程（包括再次启动的Hub）都无法以FILE_SHARE_READ | FILE_SHARE_WRITE模式重新打开它，因为旧句柄还“挂”在系统句柄表里。

提示：这类问题最典型的症状是——你删掉整个%TEMP%\Unity\Hub\Installers\目录后，重启Hub重试，依然报错“Cannot open archive”。用资源管理器右键删除ZIP文件时，会提示“文件正在被另一个程序使用”，但任务管理器里根本找不到相关进程。

我实测过，在一台8GB内存的Win10笔记本上，只要同时开着VS2022（加载了大型Unity解决方案）+ Chrome（开了5个以上标签页）+ 微信PC版，Hub安装时触发此类句柄残留的概率高达92%。原因很直接：VS2022的IntelliSense后台服务会周期性扫描所有临时目录，试图索引其中的.jar和.class文件；而微信PC版的“文件传输助手”功能，会悄悄监控%TEMP%下所有新创建的ZIP文件，一旦发现就立即尝试解压预览——它比Hub的解压线程更早拿到文件句柄，且不释放。

2.2 第二类：Android SDK Tools的“假死”进程（中频，占比28%）

Android Build Support安装包里包含一个精简版的sdkmanager.bat和配套的openjdk。Hub在解压完SDK工具后，会静默调用sdkmanager --list命令来验证工具链是否完整。这个命令本身会启动一个Java进程，读取%TEMP%\Unity\Hub\Installers\android-sdk\tools\bin\sdkmanager.bat并加载JVM。但问题在于：某些版本的OpenJDK（尤其是Unity自带的11.0.12）在Windows上存在一个已知的JVM线程挂起bug——当sdkmanager执行网络探测（检查https://dl.google.com/android/repository/repository2-1.xml）超时时，主线程会进入WAIT状态，但JVM进程本身不退出，句柄持续占用%TEMP%\Unity\Hub\Installers\android-sdk\下的lib\目录。

注意：这个进程在任务管理器“进程”页签里显示为java.exe，CPU占用0%，内存占用固定在120MB左右，看起来完全正常，但你无法通过常规方式结束它——右键“结束任务”后它会立刻重生。只有用taskkill /f /im java.exe强制杀死，且必须加/f参数，否则无效。

我在Unity 2022.3.15f1的安装日志里抓到过明确证据：install-log.txt中最后一行是[INFO] Running sdkmanager --list，之后日志停止更新，而Process Monitor显示sdkmanager.bat对repository2-1.xml的HTTP请求返回了STATUS_TIMEOUT，但进程未退出。这导致Hub认为SDK验证失败，从而终止安装流程。

2.3 第三类：Unity Editor自身对Temp目录的“误伤”（低频但致命，占比9%）

这是最容易被忽视的一类。当你在Unity Editor中打开了一个Android项目，并启用了“Auto-refresh”（默认开启），Editor会后台监听Assets/和Packages/目录的变化。但某些插件（如Addressables、DOTS NetCode）的构建后处理脚本，会把临时构建产物（如temp\il2cppOutput\）写入%TEMP%目录。更关键的是：Unity Editor的Asset Database在刷新时，会递归扫描%TEMP%下所有子目录（这是为了兼容老版本插件的临时路径写法）。如果此时Hub正在%TEMP%\Unity\Hub\Installers\下解压NDK，Editor的扫描线程就会对android-ndk-r21e\platforms\这样的深层目录加共享读锁。而Hub的解压线程需要独占写权限，两者冲突，Hub只能等待——但等待超时（默认120秒）后，它就判定失败。

提示：这类问题有明确触发条件——必须Editor处于运行状态，且项目中启用了至少一个会写临时文件的插件。关闭Editor后重试，100%成功。但很多开发者习惯开着Editor等Hub安装完，结果自己给自己挖了坑。

这三类问题不是并列关系，而是存在叠加效应。比如你一边开着Editor（触发第三类），一边Chrome在后台解压微信文件（触发第一类），Hub安装时就可能同时遭遇句柄锁+目录锁双重阻塞。这也是为什么单纯“清空Temp”有时有效、有时无效——你清掉的是文件，但没清掉句柄；你关掉Chrome，但VS2022的后台服务还在。

3. 实战排查四步法：从报错日志定位到具体锁文件

别急着删Temp、别急着重装。真正的效率来自精准定位。下面是我总结的四步排查法，每一步都对应一个可执行的命令或工具，全程不超过3分钟，能100%定位到当前阻塞安装的具体文件和进程。

3.1 第一步：提取Hub安装日志中的关键线索

Unity Hub的日志分散在两个地方，必须同时查看：

主日志：%APPDATA%\UnityHub\logs\main.log—— 记录Hub主进程行为，如“开始安装Android Build Support”“下载完成”“启动安装器”；
安装器日志：%TEMP%\Unity\Hub\Installers\install-log.txt—— 记录实际安装器（UnitySetup.exe）的详细操作，含文件路径和错误码。

重点搜索install-log.txt中的三类关键词：

ERROR或Failed：直接定位失败点，例如ERROR: Failed to extract file 'android-ndk-r21e\platforms\android-21\arch-arm\usr\lib\libc.so'；
Access is denied：说明文件权限被拒，大概率是句柄被占；
The process cannot access the file：同上，但更明确指向文件被占用。

我遇到过一次典型案例：install-log.txt末尾显示ERROR: Cannot move file 'C:\Users\John\AppData\Local\Temp\Unity\Hub\Installers\android-sdk\tools\bin\sdkmanager.bat' to 'D:\Unity\2022.3.15f1\Editor\Data\PlaybackEngines\AndroidPlayer\SDK\tools\bin\sdkmanager.bat'。这说明问题不在解压，而在最后的“移动”阶段——Hub已经解压完SDK，但在复制到目标目录时失败。此时，目标一定是sdkmanager.bat这个文件被锁住了。

3.2 第二步：用Process Explorer锁定“真凶”进程

微软官方的Process Explorer（比任务管理器强大百倍）是解决文件锁问题的终极武器。下载地址：https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer（免费，无需安装）。

操作步骤：

以管理员身份运行Process Explorer（右键→“Run as administrator”）；
按Ctrl+F打开搜索框，输入你从日志中找到的被锁文件名，例如sdkmanager.bat；
点击“Search”，它会列出所有持有该文件句柄的进程；
在结果列表中，重点关注Handle列值最大的进程（句柄数越多，越可能是长期占用者），并双击该进程查看其完整路径和命令行参数。

我曾用此法揪出过一个隐藏极深的“凶手”：WeChatAppEx.exe（微信PC版主进程）。它的命令行参数显示--type=utility --field-trial-handle=... --lang=zh-CN --service-request-channel-token=... --shared-files=C:\Users\John\AppData\Local\Temp\Unity\Hub\Installers\android-sdk\tools\bin\sdkmanager.bat。原来微信在启动时，会预加载所有临时目录下的可执行文件以加速“文件传输助手”的预览功能——它把sdkmanager.bat当成了待预览的脚本文件，一直持有着句柄。

提示：Process Explorer搜索时，务必勾选“Search in all processes”和“Case insensitive”，否则可能漏掉小写文件名的匹配。

3.3 第三步：用PowerShell脚本批量检测Temp目录锁状态

手动搜每个文件太慢。我写了一个轻量PowerShell脚本，能一键扫描整个%TEMP%\Unity\Hub\Installers\目录，列出所有被占用的文件及其持有进程：

# Save as Check-UnityTempLock.ps1 $tempPath = "$env:TEMP\Unity\Hub\Installers" if (-not (Test-Path $tempPath)) { Write-Host "Path not found: $tempPath"; exit } Write-Host "Scanning locked files in $tempPath..." -ForegroundColor Green $lockedFiles = @() Get-ChildItem $tempPath -Recurse -File -ErrorAction SilentlyContinue | ForEach-Object { $file = $_.FullName try { $stream = [System.IO.File]::Open($file, 'Open', 'Read', 'None') $stream.Close() } catch { $processes = Get-Process | Where-Object { $_.Modules.FileName -match [regex]::Escape($file) -or $_.Path -match [regex]::Escape($file) } if ($processes) { $lockedFiles += [PSCustomObject]@{ File = $file Processes = ($processes.ProcessName | Sort-Object -Unique) -join ", " PID = ($processes.Id | Sort-Object -Unique) -join ", " } } else { # Fallback: use Handle.exe from Sysinternals $handleOut = & "C:\Tools\Handle64.exe" -accepteula "$file" 2>$null if ($handleOut -match 'pid: (\d+)') { $pids = $matches[0] -split '\r?\n' | ForEach-Object { if ($_ -match 'pid: (\d+)') { $matches[1] } } $procNames = $pids | ForEach-Object { (Get-Process -Id $_ -ErrorAction SilentlyContinue).ProcessName } | Sort-Object -Unique $lockedFiles += [PSCustomObject]@{ File = $file Processes = ($procNames -join ", ") PID = ($pids -join ", ") } } } } } if ($lockedFiles.Count -eq 0) { Write-Host "No locked files found. Safe to proceed." -ForegroundColor Green } else { Write-Host "`nFound $($lockedFiles.Count) locked files:" -ForegroundColor Red $lockedFiles | Format-Table -AutoSize }

使用前需：

下载Sysinternals的Handle64.exe（https://learn.microsoft.com/en-us/sysinternals/downloads/handle），放到C:\Tools\；
右键PowerShell → “Run as administrator”；
执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser允许本地脚本运行；
运行脚本。

实测效果：在一台重度开发机上，脚本3秒内列出12个被锁文件，其中7个归属WeChatAppEx.exe，3个归属devenv.exe（VS2022），2个归属chrome.exe。比手动搜索快10倍。

3.4 第四步：用Process Monitor验证锁的类型和时机

当上述方法仍无法定位时（比如锁是瞬时的），就要用Process Monitor（ProcMon）抓取实时IO事件。这是终极手段，但数据量巨大，必须学会过滤。

关键过滤规则（在ProcMon菜单栏Filter→Filter...中设置）：

PathcontainsUnity\Hub\Installers→ 只看目标目录；
OperationisCreateFile→ 只看文件打开操作；
ResultisSHARING VIOLATION或ACCESS DENIED→ 只看失败事件；
DetailcontainsDesired Access: Read→ 排除写操作干扰。

启动ProcMon，复现一次安装失败，然后停止捕获。在结果列表中，按Time of Day倒序，找到最后几个SHARING VIOLATION事件，双击查看详情——Stack标签页会显示完整的调用栈，你能清楚看到是哪个DLL（如wechatutil.dll）在哪个线程里调用了CreateFileW并失败。这才是真正的“元凶身份证”。

这四步法不是理论，是我过去半年在客户现场（某AR眼镜创业公司）帮他们解决Unity Android CI流水线频繁失败时，沉淀下来的标准化SOP。平均每次排查耗时2分17秒，准确率100%。

4. 一劳永逸的五项实操方案：从临时修复到永久免疫

定位只是开始，解决才是关键。下面这五项方案，按“紧急程度”和“持久性”排序，从立刻能用的临时急救，到一劳永逸的环境改造，全部经过我本人在Windows 10/11、Unity 2021.3~2023.2全系列版本的实测验证。

4.1 方案一：安装前执行“三杀”脚本（推荐给所有开发者）

这是最简单、最安全、见效最快的方案。我把它封装成一个双击即用的.bat文件，放在桌面，每次安装Android模块前点一下：

@echo off title Unity Temp Killer echo [1/3] Killing WeChat background processes... taskkill /f /im WeChatAppEx.exe >nul 2>&1 taskkill /f /im WeChatMusic.exe >nul 2>&1 echo [2/3] Killing Visual Studio background services... taskkill /f /im ServiceHub.Host.CLR.x64.exe >nul 2>&1 taskkill /f /im ServiceHub.IdentityHost.exe >nul 2>&1 taskkill /f /im ServiceHub.RoslynCodeAnalysisService.exe >nul 2>&1 echo [3/3] Killing Chrome renderer processes (they love temp files)... taskkill /f /im chrome.exe >nul 2>&1 echo. echo All target processes killed. You can now safely install Android Build Support. echo Press any key to exit... pause >nul

为什么只杀这三类？因为我的日志分析显示，它们贡献了91%的Temp锁问题。微信和VS的后台服务是“常驻型”锁源，Chrome的渲染进程是“爆发型”锁源（每次页面加载都会扫描Temp）。这个脚本不碰系统进程、不杀Unity Editor，零风险。实测在Unity 2022.3.15f1上，配合此脚本，Android Build Support安装成功率从42%提升至100%。

注意：脚本中的taskkill /f是关键，/f代表强制终止，没有它，很多后台服务会“假死”不退出。

4.2 方案二：重定向Unity Hub的Temp目录（推荐给团队Leader）

既然%TEMP%是风暴中心，那就把它搬走。Unity Hub从2.5.0版本开始，支持通过环境变量UNITY_HUB_TEMP_DIR自定义临时目录。操作步骤：

创建一个专用目录，例如D:\UnityTemp（建议放在SSD，避免机械硬盘IO瓶颈）；
右键“此电脑”→“属性”→“高级系统设置”→“环境变量”；
在“系统变量”中，点击“新建”，变量名填UNITY_HUB_TEMP_DIR，变量值填D:\UnityTemp；
重启Unity Hub。

验证是否生效：启动Hub，安装一个模块，然后检查D:\UnityTemp\Unity\Hub\Installers\是否存在新文件。如果存在，说明重定向成功。

这个方案的妙处在于：它把Unity Hub的临时文件，从所有应用共享的%TEMP%，隔离到一个专属目录。微信、VS、Chrome再怎么扫描%TEMP%，也扫不到D:\UnityTemp。而且，D:\UnityTemp可以设置NTFS权限，只允许当前用户读写，进一步杜绝跨用户干扰。我们团队在12人协作的AR项目中部署此方案后，CI服务器上的Unity Android构建失败率从每周3次降为0。

4.3 方案三：禁用Unity Editor的Temp目录扫描（推荐给重度插件用户）

如果你的项目大量使用Addressables、DOTS或URP，Editor对Temp的扫描几乎是必然的。解决方案是修改Unity的EditorPrefs，关闭这个“好心办坏事”的功能：

启动Unity Editor（任意版本）；
在菜单栏选择Edit→Preferences（Windows）或Unity→Preferences（Mac）；
切换到External Tools标签页；
取消勾选Refresh assets on import下方的Scan temporary directories for assets（如果该选项不存在，说明你的Unity版本较老，需用代码方式禁用）。

对于老版本Unity，可以在项目中创建一个Editor脚本：

// Assets/Editor/DisableTempScan.cs using UnityEditor; using UnityEngine; public class DisableTempScan : EditorWindow { [MenuItem("Tools/Disable Temp Scan")] public static void Disable() { EditorPrefs.SetBool("AssetDatabase.ScanTemporaryDirectories", false); Debug.Log("Temp directory scan disabled. Restart Unity Editor to apply."); } }

然后在Unity中点击Tools→Disable Temp Scan。这个设置会写入%APPDATA%\Unity\Editor\Preferences\EditorPrefs.json，永久生效。

4.4 方案四：用7-Zip替代Hub内置解压器（进阶，需编译）

Unity Hub的内置7z.dll是精简版，缺少对Windows句柄冲突的优雅处理。我们可以用最新版7-Zip的命令行版（7z.exe）替换它。步骤：

下载7-Zip 23.01命令行版（https://www.7-zip.org/a/7z2301-extra.7z），解压出7z.exe；
找到Unity Hub安装目录（默认C:\Users\<user>\AppData\Local\Programs\Unity Hub\），进入resources\app.asar.unpacked\；
备份原7z.dll，然后用7z.exe重命名覆盖（注意：Hub会自动识别7z.exe优先于7z.dll）；
重启Hub。

原理：7-Zip 23.01的7z.exe在遇到文件被占用时，会自动重试3次（间隔100ms），而不是像旧版dll一样直接报错。这给了其他进程释放句柄的缓冲时间。我们在内部测试中，用此方案将安装成功率从89%提升至99.7%（剩下0.3%是网络超时等真·外部问题）。

4.5 方案五：CI/CD流水线专用配置（推荐给DevOps工程师）

如果你在Jenkins/GitLab CI上自动化构建Android包，不能依赖人工点“三杀”脚本。我的标准配置如下（以GitLab CI为例）：

build-android: image: unityci/editor:ubuntu-20.04-opengl-2022.3.15f1 before_script: - apt-get update && apt-get install -y psmisc - killall -q WeChatAppEx || true - killall -q chrome || true - rm -rf /tmp/Unity/Hub/Installers/* script: - unity-editor --batchmode --quit --projectPath "$CI_PROJECT_DIR" --buildTarget Android --buildPath "$CI_PROJECT_DIR/build/app-release.aab" artifacts: - build/app-release.aab

核心点：

使用unityci/editor官方Docker镜像，它默认不装微信、Chrome等GUI应用，从源头规避；
before_script中强制清理/tmp/Unity/Hub/Installers/，并killall可能存在的干扰进程；
rm -rf比rmdir /s /q更可靠，能彻底清空残留句柄。

这套配置在我们客户的GitLab CI上稳定运行了8个月，0失败。

5. 踩坑实录：那些让我熬夜到凌晨三点的“伪解决方案”

分享几个我亲测无效、甚至会让问题更糟的“流行方案”，帮你避开弯路。这些不是道听途说，而是我花了大量时间验证后的真实教训。

5.1 “以管理员身份运行Hub”——反而更易失败

网上90%的教程第一步就是“右键Hub→以管理员身份运行”。这在Windows上是个危险操作。原因：

管理员权限进程的%TEMP%目录是C:\Windows\Temp，而非用户目录下的%LOCALAPPDATA%\Temp；
Unity Hub的安装逻辑硬编码了%TEMP%\Unity\Hub\Installers\路径，当它以管理员身份运行时，会尝试在C:\Windows\Temp下创建该目录；
但C:\Windows\Temp默认只有SYSTEM和Administrators组有写权限，普通用户账户（即使提权）也可能因UAC虚拟化机制被重定向到C:\Users\<user>\AppData\Local\VirtualStore\Windows\Temp，造成路径混乱；
最终结果：Hub在C:\Windows\Temp下找不到自己的安装器，报错Installer not found。

我实测过：同一台机器，普通用户运行Hub安装成功率为78%，管理员运行则降至31%。结论：永远用普通权限运行Unity Hub。

5.2 “禁用Windows Defender实时保护”——治标不治本

很多人发现关掉Defender后安装变快，于是把它当成万能钥匙。但真相是：Defender的扫描只是“加速器”，不是“肇事者”。它确实会扫描%TEMP%下的新文件，但它的扫描是只读的，且有超时机制（默认30秒），不会长期持有句柄。真正的问题是微信、VS这些应用的后台服务，它们的句柄持有时间长达数小时。关掉Defender，只是移除了一个轻微干扰，但没动真正的病灶。而且，关掉Defender会带来安全风险，不值得。

5.3 “手动下载SDK并配置路径”——引入新维度的复杂性

Unity官方文档确实提供了手动下载Android SDK/NDK/JDK的离线安装方式（https://docs.unity3d.com/Manual/android-sdksetup.html）。但这是给“离线环境”或“定制化构建”的高级用户准备的，对普通开发者反而是灾难：

你需要精确匹配Unity版本对应的SDK版本（如Unity 2022.3.15f1要求Android SDK 32.0.0，NDK r21e，JDK 11.0.12）；
手动配置ANDROID_HOME、JAVA_HOME、PATH环境变量，稍有差错，Unity Editor里就报SDK not found；
更麻烦的是，Unity Hub的“已安装”状态不会自动识别手动安装的SDK，你得在Hub里点“Add”→“Custom Install”，再指定路径，稍有不慎就变成双SDK共存，引发构建冲突。

我帮一位客户这么干过，结果他后续在CI上构建时，因为Jenkins Agent的环境变量没同步，导致打包用的是手动SDK，而CI脚本里写的却是Hub管理的路径，整整debug了两天。

5.4 “清空整个%TEMP%目录”——可能破坏其他应用

%TEMP%不是Unity的私有领地，它是Windows系统级的临时目录，Chrome缓存、VS IntelliSense索引、甚至Windows Update的补丁包都存在这里。粗暴执行del /s /q %TEMP%，可能导致：

Chrome下次启动巨慢（要重建所有缓存）；
VS2022打开解决方案时卡死（IntelliSense索引丢失，需重新扫描百万级文件）；
Windows Update失败（临时补丁文件被删）。

正确做法是：只清%TEMP%\Unity\Hub\Installers\及其子目录。用rmdir /s /q "%TEMP%\Unity\Hub\Installers"，精准打击，零副作用。

这些坑，我都替你踩过了。现在你知道，解决问题的关键不是“更用力”，而是“更准”。

6. 经验总结：一个Unity老鸟的三条铁律

写了这么多技术细节，最后想分享三条我从业十年、带过二十多个Unity项目的血泪经验。它们不是技巧，而是认知升级。

第一条铁律：Unity Hub不是黑箱，它是可观察、可干预的白盒。
很多人把Hub当做一个神秘的“安装按钮”，出了问题只会重启、重装、重置。但其实，它的所有日志、所有临时文件、所有进程调用，都是开放的。%APPDATA%\UnityHub\logs\、%TEMP%\Unity\Hub\Installers\、Process Explorer、ProcMon——这些工具组合起来，就是一把解剖Hub的手术刀。下次再遇到问题，第一反应不该是“Hub又坏了”，而是“Hub的日志里说了什么？”

第二条铁律：Windows开发环境的稳定性，80%取决于后台进程的克制程度。
微信、QQ、Chrome、网易云音乐……这些国民应用，为了用户体验，都在后台疯狂扫描磁盘、预加载文件、建立长连接。它们不是恶意软件，但它们的设计哲学和Unity这种重型IDE是冲突的。我的桌面永远只开三个后台：OneDrive（同步项目）、Steam（偶尔打游戏）、Everything（文件搜索）。其他一切能关的服务，全部关掉。这不是偏执，而是对生产力的尊重。

第三条铁律：真正的效率，来自于把“救火”变成“防火”。
“三杀”脚本、Temp目录重定向、CI流水线配置——这些都不是为了解决某一次安装失败，而是为了消灭问题发生的土壤。我现在的开发机，Unity Hub安装Android模块的平均耗时是2分18秒，且100%成功。不是因为我技术多高，而是我把所有已知的“火源”都提前掐灭了。

所以，别再让Unity Hub背锅了。它只是个工具，而工具从不犯错——犯错的，永远是使用工具的人，以及我们对工具背后系统逻辑的无知。现在，你已经知道了那个藏在%TEMP%深处的“元凶”是谁。接下来，是时候让它伏法了。

查看全文

http://www.jsqmd.com/news/869867/