systemd-analyze time可拆解启动各阶段耗时，含firmware、loader、kernel、initrd、userspace五部分；userspace是唯一可优化环节，需结合blame、critical-chain和plot进一步定位瓶颈。
查看系统启动各阶段耗时详情
银河麒麟V10系统启动慢时，需定位是内核加载拖慢、initrd解压卡顿，还是systemd服务启动堆积导致延迟，不能只看总时间——必须拆解每个环节的实际耗时才能精准优化。
在终端中执行：systemd-analyze time。
该命令直接调用systemd内置计时器，输出形如“Startup finished in 2.345s (firmware) + 1.678s (loader) + 4.567s (kernel) + 12.890s (initrd) + 8.901s (userspace)”的分段耗时，其中括号内为各阶段名称，数值为真实秒数。注意：firmware和loader阶段耗时由BIOS/UEFI固件决定，Linux系统无法干预；kernel和initrd阶段反映内核镜像与初始内存盘加载效率；userspace才是systemd服务启动总耗时，也是唯一可优化的部分。
分析具体服务启动延迟
当userspace耗时明显偏高（如超过15秒），说明某些服务拖慢了整体启动流程，必须逐个排查。
执行：systemd-analyze blame。
输出按耗时从高到低列出所有已启动unit，例如“12.345s NetworkManager-wait-online.service”表示该服务等待网络就绪花了12秒多——这通常是默认启用但实际不需要的冗余依赖。
若发现某个服务耗时异常（如 >5s），可用 systemd-analyze critical-chain 服务名 追踪其依赖链，例如 systemd-analyze critical-chain lightdm.service 会显示从kernel启动到lightdm就绪之间的完整路径及各环节耗时，帮你确认是上游依赖（如dbus.socket）卡住，还是lightdm自身初始化缓慢。
生成可视化启动流程图
文字列表难以直观把握并行与串行关系，尤其当多个服务相互依赖时，一张图能立刻暴露瓶颈点。
第一步：安装Graphviz渲染工具：sudo apt install graphviz。
第二步：生成启动流程SVG图像：systemd-analyze plot > /tmp/startup.svg。
第三步：用文件管理器打开/tmp/startup.svg，或执行 firefox /tmp/startup.svg 查看。图中横向为时间轴，纵向为服务单元，箭头表示依赖关系，颜色越深代表耗时越长。重点关注最右侧延伸最长的服务条——它就是拖慢整条启动链的“关键路径”终点。
注意：systemd-analyze plot 生成的是矢量图，缩放不失真，但需确保/tmp目录有写入权限；若提示“Permission denied”，请先运行 chmod 755 /tmp。
对比两次启动耗时差异
修改GRUB参数或禁用某服务后，需要验证是否真正缩短了启动时间，而不是仅减少userspace数值却延长了kernel阶段。
方法一：记录本次完整启动耗时快照：systemd-analyze --no-pager > /tmp/boot-before.txt。
方法二：完成优化操作（如systemctl disable bluetooth）后，重启系统。
方法三：重启后立即执行：systemd-analyze --no-pager > /tmp/boot-after.txt。
方法四：用diff命令比对差异：diff /tmp/boot-before.txt /tmp/boot-after.txt | grep -E "(time|blame|critical)"。该命令只筛选出含关键字段的变动行，避免被大量重复unit信息干扰判断。
