previous preparation error: The developer disk image could not be unmounted on the device;An unknow

这个错误:

previous preparation error: The developer disk image could not be unmounted on the device; An unknown error message 'internalError'; was from the device. 

是 Xcode 在真机运行 / 调试时挂载 Developer Disk Image (DDI) 失败的典型情况,主要原因是 设备调试环境卡住或残留


1️⃣ 主要原因

  1. 之前调试挂载的 Developer Disk Image 没被正确卸载
    • 比如上次调试时直接拔了线,或者设备崩溃/重启了。
  2. Xcode 和 iOS 系统版本不匹配
    • Xcode 版本太低,找不到匹配的 DDI。
  3. 设备端锁定或后台挂载进程占用
    • 某个调试进程在 iPhone 上还没退出。

2️⃣ 解决方法

方法 1:重启设备 & Xcode(最简单)

  1. 拔掉数据线。
  2. 重启 iPhone(长按电源 → 滑动关机 → 再开机)。
  3. 退出 Xcode(Cmd+Q)。
  4. 重新打开 Xcode,插回设备。

方法 2:手动卸载 Developer Disk Image

  1. iPhone 上进入 设置 → 通用 → iPhone 储存空间,看看有没有挂载残留(一般不可见,依赖重启清除)。

或者直接用 ideviceimagemounter 工具卸载:

brew install libimobiledevice ideviceimagemounter -u <你的设备UUID> -u 

-u 表示卸载当前 Developer Disk Image。


方法 3:检查 Xcode 对应的 iOS 支持文件

  1. 确认有你设备的 iOS 版本文件夹,比如 17.5 (21F79)
    • 如果没有,就要升级 Xcode 或安装对应版本的 DDI(可从其他 Xcode 拷贝)。

找到 DeveloperDiskImage.dmg

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/ 

方法 4:关闭可能占用调试的进程

在 Mac 上执行:

ps aux | grep -i usb kill -9 <PID> 

或者干脆重启 Mac,确保 USB 调试链路干净。


💡 我遇到过几次这种情况,最快的方法是:设备重启 + Xcode重启 + 数据线重新插拔,90% 的情况能恢复。

Read more

前端如何写出优秀的 AI Agent Skills

前端如何写出优秀的 AI Agent Skills

背景 用 Cursor 写代码的时候,明明团队有自己的组件规范,但 AI 生成出来的代码风格完全对不上号,每次都要手动改半天——这不是 AI 不够聪明,而是你没"教"过它。 从 Cursor、Claude Code 到 GitHub Copilot,AI 编码工具正在从"对话助手"进化成能「自主执行任务」的 Agent。在这个趋势下,「Agent Skills」 悄然成为标配——简单说,它就是你写给 AI 的"操作手册",教会它一项技能,它就能在合适的场景自动调用。 这篇文章,我会讲清楚 Skills 是什么、

前端计算机基础

前端计算机基础

进程和线程的区别 简单记:进程是 “独立的容器”,线程是 “容器里干活的人”,多人共享容器资源,效率更高但也更容易互相影响。 进程:独立可运行的程序,比如微信,留言及,VSCODE 进程是操作系统资源分配的最小单位(资源包括内存、CPU 时间片、文件句柄等),每个进程都有自己独立的内存空间,进程之间互不干扰。 线程:是进程的执行单位,一个进程可以包含多个县城,比如微信进程中,有接收消息线程,渲染界面线程 线程是调度执行的最小单位 ,同一进程内的线程共享进程的内存和资源。 类比:进程像一家 “独立的公司”,有自己的办公场地(内存)、资金(系统资源);线程像公司里的 “员工”,共享公司的场地和资金,各自做不同的工作,协作完成公司整体任务。 维度进程线程资源分配系统资源分配的最小单位资源调度 / 执行的最小单位内存空间每个进程有独立的内存空间共享所属进程的内存空间通信方式复杂(需 IPC:管道、套接字、共享内存等)简单(直接读写进程内共享变量)创建

前端TypeScript高级技巧:让你的代码更安全

前端TypeScript高级技巧:让你的代码更安全 毒舌时刻 前端TypeScript?这不是增加工作量吗? "JavaScript就够了,为什么要用TypeScript"——结果类型错误频发,调试困难, "TypeScript太严格了,我写起来很麻烦"——结果代码质量差,维护困难, "我只在关键地方用TypeScript,其他地方用any"——结果失去了TypeScript的意义。 醒醒吧,TypeScript不是负担,而是提高代码质量的利器! 为什么你需要这个? * 类型安全:在编译时发现类型错误 * 代码提示:提供更好的IDE智能提示 * 重构安全:重构代码时更加安全 * 可读性:代码更加清晰易懂 * 可维护性:减少运行时错误,提高代码可维护性 反面教材 // 反面教材:过度使用any function processData(data: any) { // 没有类型检查,容易出错 return data.name.toUpperCase(

深入理解前端防抖(Debounce)与节流(Throttle):原理、区别与实战示例

深入理解前端防抖(Debounce)与节流(Throttle):原理、区别与实战示例

深入理解前端防抖(Debounce)与节流(Throttle):原理、区别与实战示例 📌 引言 在前端开发中,我们经常需要处理高频事件(如输入框输入、滚动、窗口调整大小等)。如果不加限制,浏览器会频繁触发回调函数,导致性能问题,甚至页面卡顿。 防抖(Debounce) 和 节流(Throttle) 是两种优化方案,可以有效控制事件触发的频率,提高应用的性能和用户体验。 本篇文章将详细解析 防抖和节流的原理、适用场景及代码实现,帮助你更好地优化前端应用。 1. 什么是防抖(Debounce)? 📝 概念 防抖是一种在事件触发后延迟执行的技术,如果在延迟期间事件被再次触发,计时器会重置,重新计算延迟时间。 核心思想:短时间内多次触发,只执行最后一次。 📌 适用场景 * 搜索框输入(防止用户每次输入都发送请求) * 窗口调整大小(resize)(防止短时间内多次触发计算) * 表单输入验证(用户停止输入后再进行验证) ✅ 代码实现 functiondebounce(fn,