Mac 上的 amsondevicestoraged 是什么进程？

最后更新: 2026-07-31

它是什么

amsondevicestoraged 是 Apple 签名的每用户后台服务，归属于 Apple Media Services 使用的私有 OnDeviceStorage 框架。macOS 自带的可执行文件放在受系统保护的框架目录内，代码签名标识为 com.apple.amsondevicestoraged。这里说的是代码签名标识；它本身是一个独立的 Mach-O 可执行文件，不能简单当成普通 App 的 bundle 来理解。

它处理的是获授权系统客户端留下的本机结构化数据。数据会加密保存，其中包括 SQLite 数据库。服务还要管理访问凭据、存储容量上限、数据表行数上限，以及数据从创建到删除的整个周期。

清理也属于它的职责，但范围很明确。数据超过有效期后，它可以按照 TTL 规则删除；空间或行数达到限制时，可以按照最近使用情况执行 LRU 清理；某个 App 被卸载后，它还会清除对应的注册数据。这些操作只针对它管理的容器和数据表。

名字里的 “On-Device Storage” 很容易让人联想到歌曲、电影或其他媒体文件。现有证据不支持这种解释。能够确认的是数据库、访问控制、配额和数据生命周期管理，而不是 Apple Music 歌曲、Apple TV 视频或 App 安装包的下载与缓存。它也不是面向整个 Mac 的磁盘清理工具。

它为什么要联网

launchd 为 amsondevicestoraged 注册了在线维护任务。其中一项任务的目标间隔大约是每天一次，另有一项需要联网的维护任务，目标间隔大约是每周一次。这里的“每天”和“每周”只是调度目标，不代表进程一定会在固定时刻发起连接。何时真正执行，由 macOS 根据当时的系统状态决定。

已经核实的代码路径包括获取 Apple Media Services 的配置 “bag”。这类 bag 用来提供服务配置。看到进程连接相关服务，只能说明它可能在读取配置，不能据此断定它在上传个人媒体、浏览记录或其他具体内容。

另一个明确用途是更新已撤销访问凭据列表。amsondevicestoraged 要为系统客户端管理受保护的数据存储，因此需要知道哪些访问凭据已经失效。更新不及时，可能让依赖这套存储的功能晚些拿到最新的访问控制状态。

可执行文件里还存在提交数据库运行指标的路径，但这条路径有条件。它会先检查“诊断与用量”是否获得允许，还要确认当前设备是否命中相应抽样。不能因为代码里存在这条路径，就说每台 Mac 都会持续上传数据库指标。

目前能够稳妥确认的连接对象只有类别：Apple Media Services 的配置服务、凭据服务，以及在用户允许并命中抽样时使用的分析指标服务。哪一项后台任务对应哪一个具体请求，还没有完全验证。完整主机名和网络 payload 同样未验证，因此不能列出一个看似精确的域名表，也不能猜测每次请求里包含什么数据。

正常流量应该是多少

Apple 没有公布 amsondevicestoraged 的可靠流量基线。现有调研也没有一份能够复核的长期抓包结果，所以无法给出“每天多少 KB”“每月多少 MB”之类的数字。没有测量依据时，写出具体范围只会制造一种虚假的确定性。

从已核实的代码路径看，它在大多数时间里应该没有流量。在线维护被触发后，主要传输服务配置、已撤销凭据列表，以及符合条件时产生的少量诊断事件。这些属于低频控制流量，通常应该远小于下载歌曲、视频或 App 更新产生的流量。

“通常较小”只是根据已知用途作出的量级判断，并不是字节数承诺。单次请求究竟多大、不同系统上的累计值是多少、异常峰值能到什么程度，目前都没有得到验证。进程还有按周安排的维护任务，只观察几分钟或几个小时，也未必能看到有代表性的结果。

因此，不能只凭某一次连接就判断正常或异常，也不能因为当时没有流量就认定它永远不联网。更可靠的做法是保留足够长的观察窗口，再看本机实际记录。

能不能关掉

Apple 没有提供关闭 amsondevicestoraged 的系统设置开关，也就不存在一条可供用户进入的关闭路径。

强制卸载服务、反复结束进程，或者按进程彻底阻断网络，可能拖延 Apple Media Services 配置和已撤销凭据列表的更新。依赖这套本机存储机制的 App Store 或其他 Apple Media Services 功能也可能受到影响。它由 launchd 管理，手动结束后仍可能再次启动，所以结束一次并不等于永久关闭。

“Apple 菜单 > 系统设置 > 隐私与安全性 > 分析与改进 > 共享 Mac 分析”是另一个容易混淆的设置。关闭它，只会控制获得许可后才能发送的分析数据。amsondevicestoraged 仍会继续管理本机数据库，也仍然承担其他在线维护工作。

目前同样没有可靠流量基线能够证明，强制关闭它可以节省一笔值得关注的网络用量。与可能影响共享存储和凭据维护相比，把 pkill、launchctl 或进程级阻断当成日常省流量方案，缺少事实依据，也不是 Apple 提供的操作方式。

常见的误解

1. “名字没见过，所以是恶意软件。” macOS 自带的系统副本位于受保护的 Apple 私有框架中，经过 Apple 签名，代码签名标识为 com.apple.amsondevicestoraged。进程名难懂，只能说明它是面向系统内部使用的组件，不能单独证明它有恶意行为。

2. “它负责下载或保存 Apple Music、Apple TV 的歌曲和视频。” 目前没有可靠依据。已经确认的功能集中在结构化数据库、访问凭据、容量限制、行数限制和数据清理。现有证据没���把它指向媒体文件传输，也没有把它指向歌曲或视频缓存。

3. “它会替整个 Mac 清理磁盘空间。” 它确实会删除数据，但只处理自己管理的容器和注册数据表。配额清理、TTL 到期清理、LRU 清理，以及 App 卸载后的所有权清理，都有明确范围。它不会像通用磁盘清理工具那样扫描和整理整台 Mac。

4. “它连接 Apple 的 bag 主机，说明它在上传个人媒体或做广告追踪。” 单凭一次连接，推不出这些结论。可执行文件明确需要配置 bag，因此连接可能只是为了读取 Apple Media Services 配置。另有诊断指标路径，但那条路径会检查用户是否允许共享诊断信息。实际网络 payload 还没有验证，不能把未知内容直接解释成个人媒体或广告追踪数据。

5. “用 pkill 或 launchctl 永久关掉，就能安全省流量。” 这种说法没有依据。Apple 没有提供受支持的关闭开关，正常流量也没有可引用的量化基线。强制停止可能干扰 Apple Media Services 共用的本机存储、服务配置和凭据维护，而且 launchd 可能重新启动进程。

6. “关闭共享 Mac 分析，就会一起关闭 amsondevicestoraged。” 两者不是同一个开关。这个设置只影响符合条件的分析数据发送。进程仍要处理本机存储、容量与行数限制、数据清理，以及配置和凭据相关的在线维护。

怎么看它到底用了多少

如果网络监视器里出现 amsondevicestoraged，下一步应先记录实际用量，不要根据名字猜测。可以用 Bytetally 查看它的逐进程统计，并把观察窗口覆盖到每天和每周的维护周期。由于没有可靠的公开基线，本机长期记录比未经验证的固定数字更有参考价值。

相关进程

常见问题