回顾

DDE 在 v15 时期，使用 Mutter 作为带合成器的窗管，以及 Metacity

DDE Qt 6.8 适配说明

Qt 6.8 发布已经有一段时间了，各个发行版尝试移植 DDE 时发现包括 dde-shell 在内的几个组件存在比较明显的问题，DDE 小组进行了相关的紧急修复。由于 DDE 部分项目也在分叉维护的状态，为了方便各位移植人员有效进行移植，故在此罗列相关注意事项。

注：笔者所测试的环境为 Arch Linux，下述为 2024/10/25 testing 仓库状态下的测试结论。若未另行说明，则下述涉及到的项目名称仍然使用了与 DDE 对应项目原始仓库的名称，而非各个发行版下的包名。

[!NOTE] 2024/11/06更新：对于 dde-launchpad、dde-tray-loader、dde-shell 目前均有新的维护分支版本，部分版本中已包含了下述中涉及到的一些 patch 的修复。本博客目前只更新了实机验证可用的新 tag 版本，但你也可以尝试未验证但位于维护分支的新 tag。

分支与 tag 说明

因维护需要，对于部分 DDE 组件（dde-shell、dde-launchpad、dde-tray-loader），我们对 deepin 23 所使用的分支创建了名为 release/beige 的维护分支。也会在维护分支上打对应的维护更新用的 tag。

由于 deepin 现阶段的提测流程需要对提测版本打 tag，故我们对主干（master）分支也会打 tag。为了在不与现行规范冲突的情况下尽可能表示区分，我们使用格式为 x.99.z 的 tag 标记此版本是尚在开发中的版本。开发中的 tag 版本事实上在满足一定条件下也可供外部使用，但我们不保证 x.99.z 中 z 位更新时的兼容性，故仍然建议优先使用 release/beige 上的 tag 版本。

Qt 6 Wayland

由于 dde-shell 的托盘加载部分（dde-tray-loader）使用了 Wayland（即便是 x11 环境也如此）实现应用的嵌入，故对 Qt 6 的 wayland 组件存在依赖。有下述两个 Patch 需要应用到 Qt 6 Wayland 组件之上：

• https://codereview.qt-project.org/c/qt/qtwayland/+/598596
• https://codereview.qt-project.org/c/qt/qtwayland/+/599732

dde-shell

Patch 说明

升级至 Qt 6.8 后，dde-shell 可能存在面板无任何内容的情况，就于此问题，需要应用这个 patch：

https://github.com/linuxdeepin/dde-shell/commit/46871c83cf8ecfcf83bf2fb49e1f09af997eca96

版本建议

• 若目标发行版原本在使用 1.0.0 版本，则建议至少更新到 1.0.2
• 1.0.3 以上版本依赖 treeland-protocols 项目，进行打包即可，建议对齐打包后至少更新 dde-shell 至 1.0.4
  • 由于 treeland-protocols 更新了其 CMake 支持中目标名称的大小写，故你需要打这个小 patch （或者手动进行相应调整）： https://github.com/linuxdeepin/dde-shell/commit/b3f342c094354e4ba87ac1da4cf1a380556b2a3b
• dde-shell 主干分支存在 1.99.1，但包括此版本在内的主干分支已不再在任务栏提供启动器图标，故需要配合启动器主干分支使用（启动器暂无 1.99.z 版本）

tl;dr：建议打包 treeland-protocols 后更新至至少 1.0.4。

treeland-protocols

被 dde-shell 1.0.3 以上版本所依赖。

版本建议

建议打包/更新至 0.4.1。

dde-tray-loader

Patch 说明

任务栏托盘区域的弹出面板（例如点击时间组件后的面板）早期版本有位置不正确的问题，需要应用这个 patch： https://github.com/linuxdeepin/dde-tray-loader/commit/664b093b6a913764fedbac9110927f26978aa8c9 。最新版本（1.0.5 起）中已经修正相关问题。

版本建议

建议更新至 1.0.5。

dde-launchpad

Patch 说明

启动器的维护分支版本应该可以在无任何修改的情况下正常工作，尽管启动器小窗口模式的面板位置可能不对，但位置问题暂不计划在维护分支解决。

启动器主干分支不存在上述问题，但主干分支暂无 1.99.z tag。

版本建议

在之前的移植过程中发现小窗口搜索结果界面可能存在显示错位问题，此问题已在 1.0.6 修复，故建议更新至 1.0.6。

dde-application-manager

Patch 说明

不需要 patch。

版本建议

一个 deepin 23 的所谓“特性”即，父进程启动的子进程一般会被识别归属为父进程，会导致例如在终端启动 vscode，打开的 vscode 窗口会和终端共用相同图标的问题。此问题已经在最新维护版本得到解决。直接更新dde-shell （>= 1.0.4） dde-application-manager(>=1.2.16)版本即刻解决。

建议更新至 1.2.16。

deepin v23 将于 2024 年 8 月 15 日发布，这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。

需注意，本文章是站在 DDE SIG 角度的，倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。若您需要大众化的发布概览，请参阅 deepin 公众号、官方网站等提供的介绍文章。另外，如果你对 DDE 的移植感兴趣，请参阅另一篇侧重于移植相关事项的文章。

不同于 beta3 与 RC 所提供的发布说明，此次将整体介绍 DDE v23 相对 v20 的变化内容。

变化较大的默认组件

dde-dock → dde-shell

虽然观感上对用户的差异是任务栏整体的变化，但 dde-shell 项目所要承载的责任要远超于 dde-dock。dde-shell 旨在提供一个桌面环境级的外壳程序，使编写 DDE 桌面组件变得更轻松。例如它提供了允许你指定组件的层级关系、确定放置的屏幕位置等功能，并确保相应功能在 x11 与 Wayland 环境的表象均一致。这将使得桌面组件不必针对应用编写重复的代码来实现与桌面环境强相关的功能，并使得后续 x11 向 Wayland 切换变得更方便。当前，dde-shell 面向用户呈现的唯一主要组件即任务栏，而预计在后续，OSD、通知中心、剪切板等组件也都会逐渐进行迁移，由 dde-shell 统一管理。

另外，dde-shell 整体也从传统的 QtWidgets 项目变成了 QML 项目，这使得 GPU 加速可以被有效的利用，使得相应的界面交互、动效等更加流畅。关于“任务栏”这个 dde-shell 组件，也存在了较大变化。为了避免插件崩溃时连带整个任务栏组件一起崩溃的问题发生，任务栏区域采用了内嵌 Wayland 合成器的解决方案实现了相关逻辑。

dde-launcher → dde-launchpad

dde-launchpad 事实上是第一个试水 QML 的 DDE 桌面组件，由于 dde-launcher 存在大量的内部 model 状态维护不正确的问题以及界面问题，dde-launchpad 则对其进行了整体重构并将整个界面改用 QML 技术进行构建。如 dde-shell 一节中所述，这将使得整体的流畅度得以提升。

此外，由于 DDE 计划对应用程序进行相关的权限管控，dde-launchpad 也将应用程序列表的获取和管理从原本的 GIO 切换到了新的 dde-application-manager。

dde-application-manager

dde-application-manager 是一个后台服务，为需要获取应用列表以及启动应用程序的组件（文管、启动器、任务栏等）提供与管理相关数据，为启动的应用与组件设置恰当的 cgroup、环境变量等信息。尽管当下而言 dde-application-manager 并无特殊之处，但其为后续实现应用程序权限管控的计划提供了空间。

技术预览组件

我们在 v23 的开发过程中引入了技术预览组件的概念，而原本位于技术预览组件的两个主要项目（启动器与 shell）均已离开了技术预览阶段，现以正式版的形式面向社区发布。而目前仍然位于技术预览阶段的项目即 TreeLand 与 deepin-im 了。

为了使得 v23 顺利发布、尽早发布，我们在 RC 阶段即将精力完全投入在了现有组件的缺陷修复上，TreeLand 与 deepin-im 项目均暂无显著成果可供分享，后续我们会在恰当的时候为大家详细介绍这两个项目。

后续计划

如之前计划所安排，dde-shell 现已走出技术预览并承载了任务栏的显示职责。dde-shell 的初衷之一是使桌面环境更加模块化，在后续，会有更多桌面组件成为 dde-shell 的一部分。我们也欢迎社区开发者开始尝试使用 dde-shell 编写一些自己觉得有趣的东西，并与我们讨论对 shell 相关设计与接口的体验，一同完善 dde-shell。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

接下来，wayland 会话支持也会变成主要目标，treeland 将会逐步继续完善，并在恰当的时机提供给大家。

此外，为了方便非 deepin 发行版的用户和开发者使用 DDE，我们也仍然和上次一样提供了一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，对应的文章现已发布到 DDE 移植小组。如果您感兴趣，可在此阅读。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

deepin v23 RC 将于 2024 年 5 月 15 日发布，这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。

需注意，本文章倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。另外，如果你对 DDE 的移植感兴趣，请参阅另一篇侧重于移植相关事项的文章。

变化较大的默认组件

相比 deepin v23 beta3 而言，在于 deepin v23 RC 发布的 DDE 中，有一个项目得到了较大规模的重构，并随 RC 默认提供给各位用户。即：

• dde-shell

dde-shell 旨在提供一个桌面环境级的外壳程序，使编写 DDE 桌面组件变得更轻松。这个项目在 beta3 阶段为技术预览状态，而现阶段，dde-shell 则走出了技术预览，并取代了原本的 dde-dock 项目来展示任务栏组件。

此外，需要注意的是，dde-launchpad 项目也转而默认提供 dde-shell 插件的形式来提供启动器组件。

技术预览组件

非技术用户请慎重启用技术预览功能

deepin v23 beta2 时，我们提供了一个需要用户手动安装的 dcc-insider-plugin 插件，称为技术预览插件。这个组件旨在帮助用户方便的测试 deepin 未来版本中计划提供但仍不稳定的系统组件。需要注意的是，为了加快版本迭代速度，使 v23 首个稳定版可以更快面向用户发布，故这个组件在 RC 阶段并未进行过较多测试，因而可能不会按预期行为工作，故我们目前不建议您使用此插件。

• treeland / ddm
• deepin-im

treeland 与 deepin-im 这两个组件在 beta3 到 RC 的阶段中并无太大显著变化。其中，treeland 项目原本提供了合成器与 DM 两个功能，而现在，treeland 与 DM 也进行了拆分，后者被拆分到了 ddm 仓库之中。

后续计划

如之前计划所安排，dde-shell 现已走出技术预览，但 dde-shell 仍有很多需要进一步完善的地方。一些用户会注意到 dde-shell 版的任务栏缺失了一些原本 dde-dock 项目所提供的功能，此类特性会后续逐步补充上来。另外 dde-shell 也会继续向原本的目标迈进，我们会进一步将其他桌面组件转换为 dde-shell 插件的形式进行维护。使得桌面环境模块化之余，也为 wayland 支持作出更好的准备。

另外，由于 dde-shell 的初衷之一是使桌面环境更加模块化，我们也欢迎社区开发者开始尝试使用 dde-shell 编写一些自己觉得有趣的东西，并与我们讨论对 shell 相关设计与接口的体验，一同完善 dde-shell。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

接下来，wayland 会话支持也会变成主要目标（尽管 v23 首个正式版仍然可能不会提供 wayland 会话支持），treeland 与 ddm 将会逐步继续完善，并在恰当的时机提供给大家。

此外，由于 DDE 在 beta3 与 RC 的变化仍然较大，我们也仍然和上次一样提供了一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，对应的文章现已发布到 DDE 移植小组。如果您感兴趣，可在此阅读。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

技术背景

顾名思义，内存压缩就是压缩内存，节省内存空间。相信对于搞技术的人来说，压缩这个词并不陌生，一想到这个词，我们首先想到的是压缩可以降低占用空间，使同样的空间可以存放更多的东西。 内存无论多大，总是会有不够用的时候，或者说我们总是想在尽量低的成本控制下，达到系统最优，这个时候还是有必要引入诸如内存压缩的功能来优化系统内存占用。当系统内存紧张的时候，会将文件页丢弃或回写回磁盘（如果是脏页），还可能会触发LMK杀进程进行内存回收。这些被回收的内存如果再次使用都需要重新从磁盘读取，而这个过程涉及到较多的IO操作。 就目前的技术而言，IO的速度远远慢于这RAM操作速度。因此，如果频繁地做IO操作，不仅影响flash使用寿命，还严重影响系统性能。内存压缩是一种让IO过程平滑过渡的做法, 即尽量减少由于内存紧张导致的IO，提升性能。

图：内存管理大体框架（内存压缩技术处于内存回收memory reclaim部分中）

主流内存压缩技术

目前linux内核主流的内存压缩技术主要有3种：zSwap, zRAM, zCache。下面我们依次对几种方式进行一个简要的说明

zSwap

zSwap是在memory与flash之间的一层“cache”,当内存需要swap出去磁盘的时候，先通过压缩放到zSwap中去，zSwap空间按需增长。达到一定程度后则会按照LRU的顺序(前提是使用的内存分配方法需要支持LRU)将就最旧的page解压写入磁盘swap device，之后将当前的page压缩写入zSwap。

zswap本身存在一些缺陷或问题:

1. 如果开启当zswap满交换出backing store的功能, 由于需要将zswap里的内存按LRU顺序解压再swap out, 这就要求内存分配器支持LRU功能。
2. 如果不开启当zswap满交换出backing store的功能, 和zRam是类似的。

zRram

zRram即压缩的内存， 使用内存模拟block device的做法。实际不会写到块设备中去，只会压缩后写到模拟的块设备中，其实也就是还是在RAM中，只是通过压缩了。由于压缩和解压缩的速度远比读写IO好，因此在移动终端设备广泛被应用。zRam是基于RAM的block device, 一般swap priority会比较高。只有当其满，系统才会考虑其他的swap devices。当然这个优先级用户可以配置。

zRram本身存在一些缺陷或问题:

1. zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是,配置多大是最合适的呢?
2. 使用zRam可能会在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善?
3. 增大了zRam配置,对系统内存碎片是否有影响?

要利用好zRam功能, 并不是简单地配置了就OK了, 还需要对各种场景和问题都做好处理, 才能发挥最优的效果。

zCache

zCache是oracle提出的一种实现文件页压缩技术，也是memory与block dev之间的一层“cache”,与zswap比较接近，但zcache目前压缩的是文件页，而zSwap和zRAM压缩是匿名页。

zcache本身存在一些缺陷或问题:

1. 有些文件页可能本身是压缩的内容, 这时可能无法再进行压缩了；
2. zCache目前无法使用zsmalloc, 如果使用zbud,压缩率较低；
3. 使用的zbud/z3fold分配的内存是不可移动的, 需要关注内存碎片问题；

内存压缩主流的内存分配器

Zsmalloc

zsmalloc是为ZRAM设计的一种内存分配器。内核已经有slub了，为什么还需要zsmalloc内存分配器？这是由内存压缩的场景和特点决定的。zsmalloc内存分配器期望在低内存的场景也能很好地工作，事实上，当需要压缩内存进行zsmalloc内存分配时，内存一般都比较紧张且内存碎片都比较严重了。如果使用slub分配， 很可能由于高阶内存分配不到而失败。另外，slub也可能导致内存碎片浪费比较严重，最坏情况下，当对象大小略大于PAGE_SIZE/2时，每个内存页接近一半的内存将被浪费。

实测发现，anon pages的平均压缩比大约在1:3左右，所以compressed anon page size很多在1.2K左右。如果是Slub，为了分配大量1.2K的内存，可能内存浪费严重。zsmalloc分配器尝试将多个相同大小的对象存放在组合页（称为zspage）中，这个组合页不要求物理连续，从而提高内存的使用率。

需要注意的是, 当前zsmalloc不支持LRU功能, 旧版本内核分配的不可移动的页, 对内存碎片影响严重, 但最新版本内核已经是支持分配可移动类型内存了。

Zbud

zbud是一个专门为存储压缩page而设计的内存分配器。用于将2个objects存到1个单独的page中。zbud是可以支持LRU的, 但分配的内存是不可移动的。

Z3fold

z3fold是一个较新的内存分配器, 与zbud不同的是, 将3个objects存到1个单独的page中,也就是zbud内存利用率极限是1:2, z3fold极限是1:3。同样z3fold是可以支持LRU的, 但分配的内存是不可移动的。

内存压缩技术与内存分配器组合

结合上面zSwap / zRam /zCache的介绍, 与zsmalloc/zbud/z3fold分别怎样组合最合适呢? 下面总结了一下, 具体原因可以看上面介绍的时候各类型的特点。

zRAM技术原理

zRam内存压缩技术是目前移动终端广泛使用的内存压缩技术。

软件框架

下图展示了内存管理大体的框架， 内存压缩技术处于内存回收memory reclaim部分中。

再具体到zRam, 它的软件架构可以分为3部分：数据流操作，内存压缩算法 ，zram驱动。

实现原理

Zram内存压缩技术本质上就是以时间换空间。通过CPU压缩、解压缩的开销换取更大的可用内存空间。

我们主要描述清楚下面这2个问题： 1.什么时候会进行内存压缩？ 2.进行内存压缩/解压缩的流程是怎样的？

进行内存压缩的时机：

1. Kswapd场景：kswapd是内核内存回收线程， 当内存watermark低于low水线时会被唤醒工作， 其到内存watermark不小于high水线。
2. Direct reclaim场景：内存分配过程进入slowpath, 进行直接行内存回收。

下面是基于4.4内核理出的内存压缩、解压缩流程。 内存回收过程路径进行内存压缩。会将非活跃链表的页进行shrink, 如果是匿名页会进行pageout, 由此进行内存压缩存放到ZRAM中， 调用路径如下：

在匿名页换出到swap设备后， 访问页时， 产生页访问错误, 当发现“页表项不为空， 但页不在内存中”， 该页就是已换到swap区中，由此会开始将该页从swap区中重新读取， 如果是ZRAM， 则是解压缩的过程。调用路径如下：

内存压缩算法

目前比较主流的内存算法主要为LZ0, LZ4, ZSTD等。下面截取了几种算法在x86机器上的表现。各算法有各自特点， 有以压缩率高的， 有压缩/解压快的等， 具体要结合需求场景选择使用。

zRAM技术应用

本节描述一下在使用ZRAM常遇到的一些使用或配置，调试的方法。

如何配置开启zRAM

配置内存压缩算法

下面例子配置压缩算法为lz4

echo lz4 > /sys/block/zram0/comp_algorithm

配置ZRAM大小

下面例子配置zram大小为2GB

echo 2147483648 > /sys/block/zram0/disksize

使能zram

mkswap /dev/zram0

swapon /dev/zram0

zRAM块设备个数设定

如果是编译为内核模块，那么可以在内核模块加载的时候，添加参数：insmod zram.ko num_devices=4

也可直接修改内核源代码，代码地址为： /drivers/block/zram/zram_drv.c

/* Module params (documentation at end) */
static unsigned int num_devices = 1;

修改num_devices为你想要的zram个数即可

压缩流的最大个数设定

这个是 3.15 版本及以后的 kernel 新加入的功能，3.15 版本之前的 zram 压缩都是使用一个压缩流（缓存 buffer 和算法私有部分）实现，每个写（压缩）操作都会独享压缩流，但是单压缩流如果出现数据奔溃或者卡住的现象，所有的写（压缩）操作将一直处于等待状态，这样效率非常低；而多压缩流的架构会让写（压缩）操作可以并行去执行，大大提高了压缩的效率和稳定性。

查看压缩流个数：默认是1，可以直接向proc文件写入，也可以直接更改代码方式来改变默认压缩流个数

cat /sys/block/zram0/max_comp_streams

设定压缩流个数：

echo 3 > /sys/block/zram0/max_comp_streams

其他参数

swappiness含义简述

swappiness参数是内核倾向于回收匿名页到swap（使用的ZRAM就是swap设备）的积极程度， 原生内核范围是0~100， 参数值越大， 表示回收匿名页到swap的比例就越大。如果配置为0， 表示仅回收文件页，不回收匿名页。默认值为60。可以通过节点“/proc/sys/vm/swappiness”配置。

zRam相关的技术指标

zRAM大小及剩余空间

Proc/meminfo 中可以查看相关信息 SwapTotal：swap 总大小, 如果配置为ZRAM, 这里就是ZRAM总大小 SwapFree：swap 剩余大小, 如果配置为ZRAM, 这里就是ZRAM剩余大小

当然， 节点 /sys/block/zram0/disksize 是最直接的。

zRAM压缩率

/sys/block/zram/mm_stat 中有压缩前后的大小数据， 由此可以计算出实际的压缩率 orig_data_size：压缩前数据大小， 单位为bytes compr_data_size ：压缩后数据大小， 单位为bytes

换出/换入swap区的总量

proc/vmstat 中中有相关信息 pswpin:换入总量， 单位为page pswout:换出总量， 单位为page

zRam相关优化

上面提到zRam的一些缺陷, 怎么去改善呢?

1. zRam大小是可灵活配置的, 那是不是配置越大越好呢? 如果不是配置多大是最合适的呢? zRam大小的配置比较灵活, 如果zRam配置过大, 后台缓存了应用过多, 这也是有可能会影响前台应用使用的流畅度。另外, zRam配置越大, 也需要关注系统的内存碎片化情。因此zRam并不是配置越大越好,具体的大小需要根据内存总大小及系统负载情况考虑及实测而定。

2. 使用zRam,可能会存在低内存场景由于频繁的内存压缩导致kswapd进程占CPU高, 怎样改善? zRam本质就是以时间换空间, 在低内存的情况下, 肯定会比较频繁地回收内存, 这时kswapd进程是比较活跃的, 再加上通过压缩内存, 会更加消耗CPU资源。改善这种情况方法也比较多, 比如, 可以使用更优的压缩算法, 区别使用场景, 后台不影响用户使用的场景异步进行深度内存压缩, 与用户体验相关的场景同步适当减少内存压缩, 通过增加文件页的回收比例加快内存回收等等。

3. 增大了zRam配置,对系统内存碎片是否有影响? 使用zRam是有可能导致系统内存碎片变得更严重的, 特别是zsmalloc分配不支持可移动内存类型的时候。新版的内核zsmalloc已经支持可移动类型分配的， 但由于增大了zRam,结合android手机的使用特点, 仍然会有可能导致系统内存碎片较严重的情况,因些内存碎片问题也是需要重点关注的。解决系统内存碎片的方法也比较多, 可以结合具体的原因及场景进行优化。

参考资料

Linux内存压缩浅析之原理

zRAM内存压缩技术原理与应用

deepin v23 beta3 将于 2024 年 1 月 31 日发布（注：因存在部分临时设计变动，延期发布，仍计划在当周发布），这里为大家简要描述本次更新中，DDE 所涉及的变更，以及我们的进一步计划。另需注意，本文章倾向于对 DDE 项目整体的技术内容进行描述，面向 DDE 开发者和对 DDE 开发感兴趣的读者，并非面向最终用户的特性概览文章。

变化较大的默认组件

相比 deepin v23 beta2 而言，在于 deepin v23 beta3 发布的 DDE 中，有两个项目得到了较大规模的重构，并随 beta3 默认提供给各位用户。这两个项目分别是：

• dde-application-manager (>= 1.2)
• dde-launchpad (取代 dde-launcher)

dde-application-manager 承载了 DDE 下应用程序的启动与管理等职责，在早期版本中存在诸多架构不合理以及实现问题，影响到了 dde-launcher、dde-dock、dde-grand-search 等项目启动应用与管理应用功能的正常使用。于是我们对 dde-application-manager 进行了大规模的重构，也重新设计了此项目的对外 D-Bus 接口。在 beta3 中，你将不再会遇到类如应用频繁集体闪退的问题，对应用 desktop 文件的支持变得更加完整。在未来，也会对实时调整应用缩放等功能预留支持的空间。

dde-launchpad 则是对 dde-launcher 的完整重写。一方面，dde-launcher 对旧的 dde-application-manager 具有很高的偶合度，另一方面，旧的 dde-launcher 架构使得维护此组件变得非常困难。dde-launchpad 是目前 DDE 的首个基于 QML 的组件，且基于最新的 Qt 6。得益于 QML 技术，launchpad 将会有效利用 GPU 绘制界面，使交互体验更加流畅。不过由于 dde-launchpad 是完全重写版本，故尚有部分功能未在当前的 dde-launchpad 中提供。

技术预览组件

非技术用户请慎重启用技术预览功能

deepin v23 beta2 时，我们提供了一个需要用户手动安装的 dcc-insider-plugin 插件，称为技术预览插件。这个组件旨在帮助用户方便的测试 deepin 未来版本中计划提供但仍不稳定的系统组件。在 beta2 时，技术预览组件仅包含了 dde-launchpad 一项。而在 beta3 中，dde-launchpad 走出了技术预览阶段，而有更多的组件进入了技术预览阶段：

• treeland
• dde-shell
• deepin-im

treeland 是 deepin 的下一代 wayland 窗口合成器，且可以同时提供会话管理功能。由于 treeland 会替换 deepin-kwin 并同样会接管 lightdm，故切换 treeland 时需要格外留意。

切换到 treeland 后，将会进入的 DDE 会话也会与原本有差异。treeland 会话中会使用 dde-shell 而非原本的 dde-dock、dde-widgets 等组件。尽管 dde-shell 可以独立使用，但目前 dde-shell 是作为与 treeland 共同配合进入技术预览阶段的桌面组件。dde-shell 提供了与 wayland 会话下的桌面环境的相关功能集成，今后的 dock 等组件也均会作为 dde-shell 的插件存在，以便提供更深度的集成。

deepin-im 是新的输入法组件，作为目前各种底层输入法框架的抽象层存在，以便用户更方便的管理输入法而无需关注底层的配置细节。deepin-im 并不与 treeland 绑定，可以单独启用。

后续计划

在未来，首要计划即使 dde-shell 可以走出技术预览阶段并配合 treeland 达成真正稳定可用的 wayland 会话，这意味着 treeland 与 dde-shell 相关的项目还有比较多的相关工作需要持续进行。也是我们的主要努力方向。另外，尽管 dde-shell 相关的 API 可能仍会存在一些变动，但我们计划在随后提供一些必要的文档来帮助开发者更好的了解 dde-shell 的目的与作用，以便帮助开发者参与到项目之中来。如果你对这相关的话题感兴趣，欢迎加入 DDE SIG 的 Matrix 群聊 (#dde:matrix.org) 之中来。

另外，由于 DDE 在 beta2 与 beta3 的变化较大，我们也计划提供一篇移植注意事项博客。笔者也是 DDE 移植 SIG 的成员，于是对应的文章计划会发布到 DDE 移植小组。如果您感兴趣，请考虑订阅 <planet.deepin.org> 的 RSS 更新。如果你本身在参与 DDE 的移植工作，那么也欢迎你加入 DDE 移植小组（#dde-port:deepin.org 或 https://t.me/ddeport）。

最后，感谢你读到这里。如有任何问题，欢迎在我们的开发者群（#deepin-community:deepin.org）进行讨论。

简述

在上一篇浅析Linux电源配置之后，我们一直在深入探索如何进一步优化我们系统的续航和性能表现，今天它来了：

TLP 是适用于 Linux 的功能丰富的命令行实用程序，无需深入研究技术细节即可节省笔记本电脑电池电量。之前我们的系统使用的laptopmode,但是相较于TLP还有有部分劣势：比如tlp脚本是被动唤醒，可以以较小的开销完成电源管理相关内容。而且TLP文档支持非常完善，所以可以方便用户自行调整相关配置。以下是TLP官方文档内容的和我自己的理解的结合，各位系统用户可以结合自己的实际情况diy自己的电源策略文件，也可以将好的电源配置在deepin 论坛中分享。

工作原理

• TLP 基本上所做的是调整影响功耗的内核设置，内核态的配置文件存储在RAM中，所以并不具备持久性。TLP将配置存储在用户态中，在内核启动时对其进行配置
• TLP 处理的大多数内核设置都作为 sysfs 节点导出到用户空间，即 /sys/ 下的文件。tlp-stat 的输出将显示路径。
• TLP 提供两组独立的设置，称为配置文件，一组用于电池 （BAT），另一组用于交流操作。这意味着 TLP 不仅在启动时，而且在每次电源更改时都必须应用适当的配置文件（可以据此实现AC BT切换电源调度状态）

TLP触发事件（信号）

• 充电器插入（交流供电）：应用AC配置文件
• 充电器已拔下（电池供电）： 应用BAT配置文件
• 已插入 USB 设备：激活设备的 USB 自动挂起模式（可以在配置文件设置例外或拒绝连接）
• 系统启动（boot）：应用与当前电源 AC/BAT 相对应的设置配置文件。应用充电阈值并根据您的个人设置切换蓝牙、Wi-Fi 和 WWAN 设备（在默认配置中禁用）
• 系统关机 (power off)：保存或切换蓝牙、Wi-Fi 和 WWAN 设备状态，并根据您的个人设置禁用 USB 自动挂起（在默认配置中禁用）
• 系统重启： 相当于关机再启动
• 系统挂起到 ACPI 睡眠状态 S0ix（空闲待机）、S3（挂起到 RAM）或 S4（挂起到磁盘）：保存蓝牙、Wi-Fi 和 WWAN 设备状态，并根据您的个人设置关闭可移动光盘驱动器的电源（在默认配置中禁用）。
• 系统从 ACPI 睡眠状态 S0ix（空闲待机）、S3（挂起到 RAM）或 S4（挂起到磁盘）恢复： 应用与当前电源 AC/BAT 相对应的设置配置文件。恢复充电阈值以及蓝牙、Wi-Fi 和 WWAN 设备状态，具体取决于您的个人设置（在默认配置中禁用）。
• LAN、Wi-Fi、WWAN 连接/断开连接或笔记本电脑插接/未插接：根据您的个人设置启用或禁用内置蓝牙、Wi-Fi 和 WWAN 设备（在默认配置中禁用）

除了上述事件之外，TLP 不会对设置进行动态或自适应更改 特别是，TLP 绝不会因 CPU 负载、电池电量或其他原因而调整设置（如果我们需要去实现这一部分，则可以，则可以通过添加一个信号的方式来实现）

安装

sudo apt install tlp

使用

启动

安装后TLP将在系统启动的时候自动启动，如果你不想重启系统，可以使用sudo tlp start来启动tlp，也可以使用此命令来应用更改。

状态

tlp-stat -s TLP是bash脚本，所以不存于daemon进程

命令行

TLP：

sudo tlp bat 应用电池配置文件并进入手动模式 手动模式意味着对电源的更改将被忽略，直到下一次重新启动或发出 tlp start 以恢复自动模式

sudo tlp ac应用交流配置文件并进入手动模式

sudo tlp usb 对所有的ubs设备应用自动挂起

sudo tlp bayoff 关闭 MediaBay/Ultrabay 中的光驱电源

sudo tlp setcharge [<START_CHARGE_THRESH> <STOP_CHARGE_THRESH>] [BAT0|BAT1|BAT<x>|CMB0|CMB1] 可以设定对指定电池开始充电百分比和结束充电的百分比，以达到养护电池的目的（如果不带参数 会重置电池管理方案）（命令只能暂时更改，如果需要持久化更改 需要修改配置文件）

sudo tlp fullcharge [BAT0|BAT1|BAT<x>|CMB0|CMB1] 设定电池充满

tlp diskid 显示已经配置驱动器的磁盘ID

以下部分为ThinkPad专属

sudo tlp chargeonce [BAT0|BAT1] 将电池充电至停止充电阈值一次，这个阈值是使用setcharge设置的

sudo tlp discharge [BAT0|BAT1] 让电池在交流电源下完全放电

sudo tlp recalibrate [BAT0|BAT1]校准电池

TLP-RDW

sudo tlp-rdw [ enable | disable ] 启用或关闭无线电管理功能

bluetooth [ on | off | toggle ]
nfc [ on | off | toggle ]
wifi [ on | off | toggle ]
wwan [ on | off | toggle ]

启用、禁用、切换或检查内置蓝牙、NFC、Wi-Fi 和 WWAN（3G/UMTS、4G/LTE 或 5G）无线电的状态，如果不带参数则为当前硬件状态（硬件需要支持rfkill）

TLP-STAT

sudo tlp-stat 查看TLP配置信息，系统信息和内核省电设置以及电池数据

sudo tlp-stat [-b /--battery] 查看电池信息，部分电池加-v参数可以查看电压

sudo tlp-stat [-c /--config]查看配置信息

sudo tlp-stat --cdiff 查看默认配置和用户配置之间的差异

sudo tlp-stat [-d /--disk] 查看硬盘配置信息

sudo tlp-stat [-e/ --pcie] 查看Pcie配置信息

配置

TLP最重要的就是其配置文件，可以说，TLP是否节电的关键。 TLP 使用两个根据电源自动应用的设置配置文件：

• 以_AC结尾的参数在连接交流电源的时候生效
• 以_BAT结尾的参数在使用电池的时候有效
• 既不以 _AC 结尾也不以 _BAT 结尾的参数适用于这两个配置文件

配置文件

按指定顺序从以下文件中读取设置：

• Intrinsic defaults 固有默认值（这个配置为TLP自带，不可被更改）
• /etc/tlp.d/*.conf：插入式自定义片段，按词法（字母顺序）顺序读取，不过建议可以使用一般配置命名方法（00_xxxx.conf)
• /etc/tlp.conf：用户配置

如果多个参数相同，但在同一文件中也存在相同的参数，则最后一个匹配项优先，这也意味着，/etc/tlp.conf 中的参数将覆盖其他任何内容，因为它是最后读取的 默认的/etc/tlp.conf 中的所有参数都被禁用，删除前导 # 以激活您的更改 /etc/tlp.d/ 目录中的配置文件由用户创建： * 文件名必须以 .conf 结尾，否则文件将被忽略 * 00-template.conf 作为示例提供

参数默认值

配置中有两种参数，一种是具有默认值的，会在本文档中说明，并且在/etc/tlp.conf中有Default前缀。还有一种没有默认值的。

参数语法

配置文件由参数和注释行组成。

参数行

PARAMETER=value

如果value包含空格，则需要使用双引号

key="111 1111 1111"

注释行

以#开头，在1.6版本后可以在参数行后接#作为注释

禁用功能

• 没有默认值：使用注释或者删除即可
• 有默认值： 赋空值即可 eg：key=""

使用+=追加配置

和bash的环境变量一样，支持使用+=作为追加配置

使用root权限编辑配置文件，在保存更改后可以使用重启，拔插ac电源或者使用sudo tlp start命令激活配置

配置详解

基础操作

音频

注释： SOUND_POWER_SAVE_ON_AC/BAT 指的是SOUND_POWER_SAVE_ON_AC 和 SOUND_POWER_SAVE_ON_BAT

电池保养

这些参数用于设置笔记本电脑主/内部电池（BAT0）和辅助电池（BAT1）的充电阈值。启动充电阈值表示在连接充电器时，电池充电水平低于该值时将开始充电。停止充电阈值表示在充电器连接时，电池充电水平超过该值时将停止充电。这些阈值始终具有较低的可用电池容量，因此默认情况下禁用这些设置，并且必须通过删除前导 # 来显式启用这些设置。

光驱

硬盘

注释：DISK_IOSCHED 如果使用是NVME设备时，最好使用无IO调度程序来减少CPU开销（none和noop）

文件系统

图形显卡

这些参数允许用户调整 Intel GPU 和 AMD GPU 在交流电和电池模式下的性能和电源管理行为。在配置这些参数时，建议参考硬件规格和运行 tlp-stat -g 查看可用频率。

kernel

不建议关闭watchdog 否则可能导致内核崩溃后无法自动重启和内核调试

网络

这些参数允许用户配置Wi-Fi的电源保存模式和控制Wake-on-LAN（LAN唤醒）功能。

平台

其实如果能使用S3休眠那就更好，不过现在很多厂商并不支持S3,所以如果能用S2那就用S2吧。

处理器

这些参数允许用户配置 CPU 的性能和功耗特性，包括缩放驱动程序操作模式、调节器、频率范围、能耗/性能策略、P 状态范围、提升功能以及 HWP 动态提升功能。

部分电脑的BIOS会干预PState 所以需要检查自己的CPU是否支持

无线设备

这些参数允许用户配置在系统启动、关闭或更改电源状态时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。可通过设置禁用或启用这些设备，以及在何种条件下执行这些操作。

无线配置向导（自动化配置）

这些参数允许用户配置在特定事件触发时如何处理内置的蓝牙、Wi-Fi 和 WWAN 设备。用户可以根据 LAN、Wi-Fi 或 WWAN 的连接状态、对接或取消对接等事件来启用或禁用这些设备。

PCIE电源配置

这些参数允许用户配置与 PCIe 设备相关的运行时电源管理和 ASPM 等功能。用户可以根据电源来源、设备地址、驱动程序等来调整这些设置，以实现更好的功耗管理。（建议不要对nvidia驱动进行调整，可能会引发意外）

USB

Trace Mode

TLP_DEBUG="arg bat disk lock nm path pm ps rf run sysfs udev usb"

结语

我们对于系统的优化不仅于此，现阶段tlp的配置策略仅对于部分有能力的用户公开，后续经过充分的测试和调优之后，会提供几份默认的配置给普通用户使用。并将来将这些配置文件GUI化，集成于深度定制项目中，为用户提供更为方便直观的操作体验。

从这一阶段对于电源优化的探索可以看出，deepin系统的电源管理方案优化不仅是为了解决用户反馈的问题，更是一种对用户需求的回应和尊重。在未来，deepin系统将继续秉持用户至上的原则，不断提升系统的性能和用户体验，为广大用户提供更加优秀的操作系统产品。