安卓性能绝版2:Android卡顿掉帧问题分析之实战篇2-系统负载异常

安卓性能绝版：Android卡顿掉帧问题分析之实战篇1-流程执行异常

，老东家的同事分享一些流程执行异常的性能问题案例，今天继续分析性能问题之系统负载异常。

系统负载异常

CPU、GPU、内存、磁盘等都是系统内各个进程任务的运行所必需的公共系统资源。这就涉及到一个复杂的资源调度与分配的问题，实现将系统资源与各个不同进程的需求进行合理的匹配，以保证进程任务能够流畅的运行。这就涉及到两个问题：

• 这些系统公共资源是否充足。比如当进程需要时，当前 CPU 核心的运行主频算力是否足够高，系统剩余内存是否足够大，磁盘的读写速度是否足够快。
• 这些系统资源的分配是否合理。比如当前优先级更高的前台应用进程相对于后台进程是否能获得更多的 CPU 调度运行时间片和 I/O 带宽等资源，以保证界面的流畅运行。

从软件的角度出发，每个应用任务进程都希望自己获得无限的 CPU 算力、无限的内存资源分配等能力，以保证其能够流畅的运行。但是从硬件的角度出发，各种系统的公共资源配置都是有限的，不可能无限的提供给每个任务进程，且在移动设备上还要考量功耗与发热的问题，需要限制各种系统资源的供给。所以如何协调这种供需关系之间的矛盾，将宝贵的系统资源合理的分配给当前最需要的任务进程，以最小的资源开销保证系统的流畅运行，就是考验操作系统的设计者和性能优化工程师的功力的问题，弄不好就可能出现应用任务进程的运行受限于系统运行资源的分配而出现各种性能问题。

2.1 CPU调度引起卡顿

一、理论分析

CPU 算力资源绝对是系统内最重要的公共资源之一，每个应用程序的正常运行都需要 CPU 的调度执行。目前的主流移动设备搭载的 CPU 基本上都是采用多核心架构设计，按照算力的大小设置有多颗 CPU 运算核心（以高通最新的骁龙 8 gen 1 处理器为例，其拥有 8 颗 CPU 运算核心，包含四个小核、三个中核和一个大核，算力依次递增，功耗也逐渐增大）。

!CPU架构

且 Linux 操作系统内核中会有相应的 scheduler 和 governor 调度器，来管理每颗 CPU 核心上当前运行的任务的排程，以及每颗 CPU 核心当前运行的主频（每颗 CPU 核心都有一个运行主频参数可以支持在一定的范围内动态调节，主频越高算力越强，相应的功耗也就越大）、节能状态等参数，以达到最佳的性能与功耗的平衡。但是很多时候由于 CPU 运行核心上的任务排布不合理，或运行主频过低导致的算力过低，无法满足应用进程的需求，就可能导致应用出现卡顿掉帧等性能问题。常见的一些原因如下：

• 后台应用进程任务持续运行抢占 CPU 运行资源，或者处于功耗管控直接关核，导致前台应用的 UI 线程任务无法及时的获得 CPU 运行算力执行，长时间处于 Runnable 状态，而出现上帧超时掉帧问题；
• 某些时候出于功耗与发热的考量，将 CPU 的运行主频压的过低，导致算力不足。应用的上帧线程上的任务需要 Running 很长一段时间，而出现上帧超时掉帧。

二、典型案例分析

问题描述：腾讯视频应用中观看视频时，播放弹幕卡顿。

问题分析：结合 Systrace 工具分析问题原因如下：

!cpu block.jpg

从 Systrace 上可以看到：腾讯视频播放视频时出现掉帧卡顿的原因，是因为其负责弹幕上帧的线程无法获得 CPU 运行资源，而长时间处于 Runnable 状态，导致上帧出现严重超时。

进一步分析原因发现存在两个问题：一个就是看 CPU Trace 信息发现此时只有 CPU 0-3 四个小核心和一个 CPU 4 一个中核心在运行，而算力更强的 CPU 5-7 都处于关闭状态，导致系统总体算力受限；另一个问题就是前台应用腾讯视频进程内的所有线程运行任务都只分配到 CPU 4 上运行，其它几个小核心处于空闲状态也没有使用，导致腾讯视频应用的运行严重受限。

最终经过分析找到问题的根本原因就是：

1. 关闭算力更强的 CPU 5-7 的原因，是系统组为了降低用户全屏看视频场景下的功耗而故意为之；
2. 腾讯视频只能运行在 CPU 4 上的原因，是因为该项目使用的是高通最新的 SM8450 平台，该平台采用 ARM V9 架构设计，32 位的应用只能使用 CPU4-6 三个中核运行，而应用商店提供的腾讯视频刚好就是 32 位的版本。

至此问题水落石出，后面解决问题思路就是：一方面推动应用商店上架腾讯视频 64 位版本；二是系统组那边需要针对 32 位的应用前台全屏看视频的场景下的 CPU 配置做出调整，不再全部关闭 CPU 5-7 三个算力较强的核心。

问题描述：桌面界面左右滑动出现卡顿掉帧。

问题分析：结合 Systrace 工具分析问题原因如下：

!cpu block2.jpg

从 Systrace 上可以看到：前台应用桌面出现掉帧的原因是其 UI 线程抢不到 CPU 运算资源而长时间处于 Runnable 状态。而此时，CPU 上分布有大量后台应用的任务持续运行。出现这个问题的原因是国内部分应用存在很多进程保活机制，会在后台持续运行，并想方设法提升其进程的优先级。所以在系统关闭了相关针对性的管控后就会出现问题。

三、优化思路

针对 CPU 调度问题引起的性能卡顿问题，常见的优化思路有：

• 基于 cgroup 的进程资源隔离。Android 系统上继承了 linux 的 cgroup 机制，以控制进程的资源占用，让重要的进程获得更多的系统资源。涉及的系统资源如下图所示：

!cgroup.png

其中 cpuset（可以实现限制进程只能运行在指定的 CPU 核心上）、cpuctl（可以实现控制前后台进程的 CPU 用量）和 freezer（可以实现控制进程处于冻结休眠状态，完全放弃 CPU 执行权）就是对进程 CPU 资源的控制。后面的 top-app 标识当前进程所属的资源分组。cgroup 机制中会将不同的运行进程分成不同的资源组，比如前台应用属于 top-app 组，后台应用属于 background 组。不同的组可以支持配置不同的资源使用权限（比如通过 cpuset 的配置，background 组中的进程被限制只能运行在 cpu 0-3 三个小核心上，而处于 top-app 组中的进程可以使用所有的 cpu 核心资源）。以 cpuset 为例，如下图所示：

!cgroup_2.png

!cgroup_3.png

通过这种限制后台不重要的进程的 CPU 资源占用，从而让前台重要的应用进程获得更多的 CPU 资源（至于进程的前后台优先级定义，主要是由框架 AMS 服务来管理维护，通过写进程的 oom_score_adj 值来标识）。国内各大手机厂商的系统性能优化的策略中，有很大一部分工作都是依赖于 cgroup 机制来实现的，通过对系统资源精细的定义划分，和应用进程优先级与功能场景的精准识别，来实现对资源的合理分配，达到性能与功耗的最佳平衡。

• 基于场景识别的 CPU 调度策略配置。主要工作包括：

• 对 CPU 基础配置影响各核的性能输出：包括 CPU Frequency 运行主频调节、排程器大核小核工作分配策略 upmigrate/downmigrate/sched_boost 的调节（根据 CPU 各核心的任务负载，对线程任务进行大小核分布的迁移调整），以上都是通过 Soc 厂商提供的 Perf 服务接口设置参数，去写相关的设备节点实现，以高通平台为例相关节点如下图所示：

!cpu节点配置.png

• 还有温控策略的配置调整（出于功耗与发热的考量，移动设备上温控机制 thermal-engine 服务，会根据遍布设备内部的各个温度传感器读取的温度值，按照一定的温度阈值对 CPU 运行主频进行限制，以防止设备过热）；

• 对场景的定义识别与策略配置：比如定义应用冷启动场景，在框架进行识别，并动态将 CPU 主频进行拉升一段时间，以提升应用打开速度；定义视频播放的场景，在框架进行识别，然后对 CPU 主频进行限频，在保证播放流畅的前提下，尽量降低功耗和发热；这块也属于国内各大手机厂商的系统性能优化的核心工作。如何实现精确的场景定义与识别，精准控制 CPU 的性能输出，用最小的功耗，保证应用界面的流畅运行，就是对厂商功力的考验。

• 对三方应用后台相互唤醒和进程保活机制的限制，防止其在后台持续运行抢占CPU算力资源。这块也是国内各大手机厂商系统优化的重点工作之一。

2.2 GPU调度引起卡顿

一、理论分析

GPU 算力资源是继 CPU 算力外，系统内另一个重要的公共资源，从前文 Android 应用上帧显示的流程分析可知，应用对每一帧画面的渲染处理都离不开 GPU 算力的支撑。和 CPU 类似，设备的 GPU 也有自己的运行主频（运行主频越高，算力越强，同时发热也就越大），且支持在一定的范围内调节，以实现功耗和性能的最佳平衡。以高通 SM8450 平台所搭载的型号为 Adreno 730 的 GPU 为例，其参数信息如下图所示：

!GPU.png

从上图可以看到，GPU 支持在一定的范围内动态调节运行主频，Soc 厂商和国内的手机厂商会根据任务负载和使用场景，动态调节 GPU 的工作频率以实现功耗与性能的最佳平衡。但是如果调节不合理，就可能引起性能问题，常见的一些原因如下：

• 部分大型游戏应用（如原神）需要大量的 GPU 算力进行游戏画面的实时渲染处理，如果系统的 GPU 运行主频算力没有及时的跟上来，无法满足应用对 GPU 算力的需求就会导致游戏应用上帧时出现阻塞超时而掉帧；
• 部分应用在后台利用 GPU 做一些图像处理的并行计算，抢占了系统的 GPU 算力资源；就可能导致前台应用绘制上帧时，由于 GPU 算力不足，使其渲染线程陷入长时间阻塞等待 GPU 渲染完成的 Fence 信号的状态，最终出现上帧超时卡顿的问题。

二、典型案例分析

问题描述：三方应用 UC 浏览器界面滑动卡顿。

问题分析：结合 Systrace 工具分析问题原因如下：

!GPU block.PNG

从上图的 Systrace 可以看出，UC 浏览器出现上帧超时的主要原因是，其 RenderThread 渲染线程长时间阻塞在 queueBuffer 上帧的流程上，而 queueBuffer 阻塞在 SurfaceFlinger 进程那边的 Binder 响应，而 SurfaceFlinger 进程中又需要等待 GPU 那边完成画面渲染处理的 fence 信号的（从应用进程侧的 waiting for GPU completion 的 systrace tag 也能看出）。如下简化代码所示：

/*frameworks/native/libs/gui/BufferQueueProducer.cpp*/

status_tBufferQueueProducer::queueBuffer(int slot,
const QueueBufferInput &input, QueueBufferOutput *output){
    ATRACE_CALL();
    ...
// Wait without lock held
if (connectedApi == NATIVE_WINDOW_API_EGL) {
// Waiting here allows for two full buffers to be queued but not a
// third. In the event that frames take varying time, this makes a
// small trade-off in favor of latency rather than throughput.
        lastQueuedFence->waitForever("Throttling EGL Production"); // 等待GPU fence信号
    }
return NO_ERROR;
}

也就是说，问题出在系统的 GPU 算力资源比较紧张。后来分析应用掉帧的同一时间段系统的其它运行进程的 systrace 表现，发现系统的图库应用正在执行一些 Bitmap 图像处理的动作。再结合日志分析后与负责图库的同事沟通，最终找到问题的根本原因所在：图库应用中有一个事物分类相册的功能，当时正在后台使用 GPU 进行照片图像的特征识别与处理的逻辑，抢占了系统 GPU 算力资源，从而导致前台 UC 浏览器应用的渲染线程阻塞在等待 GPU 的 fence 信号的流程而出现掉帧。

三、优化思路

针对 GPU 调度问题引起的性能卡顿问题，常见的优化思路有：

• 基于场景的 GPU 调度策略配置。这块主要是结合前台应用场景的需求，动态调节 GPU 的运行主频等参数，以最小的功耗满足应用的性能需求。这块考验各大手机厂商的调教水平，也是厂商进行游戏优化调教的重点工作之一。
• 后台应用进程抢占 GPU 算力资源的管控。主要是限制后台应用的运行，防止其出现抢占 GPU 算力资源的行为，以保证前台应用的流畅运行。

2.3 低内存引起卡顿

一、理论分析

内存也绝对算的上是一个重要的系统公共资源，系统内任何进程的正常运行都需要消耗一定的内存资源。一般来讲设备的 RAM 硬件物理内存的大小是固定且有限的（4G、8G 或 12G 等），而系统内运行的所有进程都需要共享这些有限内存资源。如何用有限的内存资源去满足系统各个应用进程无限的需求，这就涉及到一个系统内存管理的逻辑。这是一个复杂的问题，几乎贯穿了整个 Android 系统的各个层级。从 Linux 内核到 Art 虚拟机，再到 Framework 框架，甚至到 APP 应用，都会有各自的内存管理的策略。关于 Android 系统的内存管理的详细逻辑，由于篇幅所限本文就不详细展开。我们以 systemui 应用进程为例，来看看一个普通应用进程的内存占用分布：

!app memory.png

合理的内存的分配与管理无论对系统和应用来讲都至关重要。因为内存问题既能引发稳定性问题，也能引发卡顿性能问题。 下面我们分别来分析一下：

内存引起的稳定性问题：

• 因为系统总的内存资源是有限的，为了防止单个应用进程无限制的占用内存资源，Android 系统设计了很多机制来遏制这种情况的产生。比如在虚拟机层面，谷歌设计对每个应用进程占用的 Dalvik Heap 的内存大小做出了限制，超过一定的阈值（记录在 dalvik.vm.heapgrowthlimit 的 property 中，一般为 256M），就会触发 OutOfMemory 的异常，导致应用进程崩溃。此外 Android 系统还引入了 lmkd 低内存守护机制，当系统总的可用内存低于一定的阈值，就会按照进程优先级，将占用内存比较大的应用进程杀掉。
• 32 位的应用虚拟内存的寻址空间最大为 4G，当应用进程的虚拟内存占用超过 4G 时，就无法继续为其分配内存，产生 OOM 类型的报错，出现应用崩溃或黑屏等问题。
• 另外 Android 系统基于 Linux 内核，也继承了 Linux 系统对应用进程的相关限制。如果应用进程中开启的线程过多（每创建一个空线程也会有一定的内存开销），超过 /proc/sys/kernel/threads-max 中定义的上限，也会报出 OOM 异常导致应用进程崩溃；再比如应用进程中打开的文件句柄过多，超过 /proc/pid/limits 节点中的定义上限，也会报出 OOM 异常导致应用进程崩溃。如下图所示：

!oom.png

内存引起的性能性问题：

• 当应用出现内存抖动或内存泄露的问题时，就会导致虚拟机的 GC 频繁工作，甚至触发 stop-the-world 事件，造成应用的 UI 线程出现挂起阻塞，最终导致上帧出现超时而掉帧。
• 当后台活跃运行的应用进程过多时，会造成系统总体的剩余内存偏低。此时主要有两个问题可能会造成应用的卡顿：
• a、当内存 zone 处于低水位时，内核会频繁唤醒 kswapd 的线程起来执行内存回收的动作；另外内核 PSI 内存压力信号也会频繁唤醒 lmkd 进程，进行扫描和杀进程。这些动作都会占用 CPU 运行资源，导致前台应用 UI 线程由于抢不到运行 CPU 资源而出现长时间处于 Runnable 的问题；
• b、当系统内存不足时，kswapd 的线程被唤醒进行内存回收，会将 page cache 内存页中已经缓存的磁盘文件信息进行大量释放，导致应用进程中的一些 IO 读文件操作（比如 view 读文件，读配置文件、读 odex 文件等），由于 page cache 无法命中，触发缺页中断，陷入内核态阻塞等待，一直等到 readahead 机制从磁盘中将文件内容全部读取出来才能释放返回。当大量进程在进行 IO 操作时，又进一步加重底层 IO 的阻塞时长。最终导致前台应用的 UI 线程长时间处于 Uninterruptible Sleep - Block I/O 的状态而出现上帧超时卡顿问题。

二、典型案例分析

问题描述：在三方应用唯品会的首页界面上下滑动严重掉帧卡顿。

问题分析：结合 Systrace 工具分析问题原因如下：

!lowmemory block.jpg

从 Systrace 上可以看到，唯品会应用出现掉帧卡顿的主要原因如下：

• 系统内存紧张，频繁唤醒 kswapd0 线程进行内存回收操作，其持续抢占 CPU 5 大核心运行，导致应用的 UI 线程和 RenderThread 渲染线程频繁出现抢不到 CPU 资源得不到执行，而处于 Runnable 的状态，从而导致应用上帧超时而掉帧；
• 系统内存紧张时，page cache 磁盘文件缓存被内存回收，导致应用的 UI 线程和 RenderThread 渲染线程中的一些 IO 读文件操作无法命中 page cache 缓存而频繁陷入内核 Uninterruptible Sleep - Block I/O 的状态，导致应用上帧超时而掉帧。

三、优化思路

针对内存问题引起的性能卡顿问题，常见的优化思路有：

在应用进程侧，作为应用开发者：

• 使用 Android Studio 自带的 Profile 分析工具进行内存分析与优化，具体用法可以参考这篇文章：https://www.jianshu.com/p/72b213fa6a26。
• 需要解决应用自身的内存泄漏问题，避免频繁的内存分配回收出现的内存抖动现象；
• 并尽量优化应用的内存占用，包括优化图片加载占用、采用内存更高效的数据结构（如 ArrayMap）、采用对象池和图片复用等内存复用机制、功能比较复杂的应用采用多进程方案、尽量优化应用 APK 包体积大小、监听 onTrimMemory 事件并及时释放内存中的不必要缓存等；
• 尽量不要做一些应用进程保活的机制，以免增加系统总体的内存负担；
• 将应用升级适配到64位版本，以免陷入虚拟内存耗尽而进程崩溃的局面。

在系统总体层面，这部分内容主要属于谷歌和手机厂商的工作，常见的一些针对性优化手段有：

• 调整 lowmemorykiller 的杀进程的门限值，让其提前介入清理掉一些低优先级的进程而释放内存，以免系统陷入低内存状态；
• 适当提高 extra_free_kbytes 值，让 kswapd 线程能提前介入进行内存回收，以免系统陷入低内存状态；
• 框架中设计后台应用查杀功能，定期清理后台低优先级应用进程，并限制三方应用的后台保活机制，从而释放内存，以免系统陷入低内存状态；
• 通过 cpuset 配置限制 kswapd 不让其使用部分 CPU 大核，从而让出 CPU 资源给前台应用的 UI 和渲染线程使用；
• 配置和启动 ZRAM 和 app compaction 后台内存压缩机制，从而减少应用进程后台的内存占用，腾出更多的系统可用内存；
• 优化系统的磁盘 IO 性能，采用 UFS3.1 等性能更强的存储器，以减轻系统出现内存低的情况时，出现 IO 阻塞的时长。

2.4 磁盘I/O引起卡顿

一、理论分析

磁盘是现代计算机系统实现数据持久化存储的核心硬件模块。也是继 CPU 和内存外系统内另一个重要的公共资源。Android 系统内应用程序的运行一般都会伴随有大量的磁盘 I/O 读写的操作，比如读写数据库、加载 XML 布局文件、读取配置文件等。但是相对于 CPU 和内存相比，磁盘的读写访问速度是比较慢的，很容易成为 CPU 运行的瓶颈，导致系统被拖累。当应用进程的线程中发生直接 I/O 磁盘读写时，就会导致线程进入 Uninterrupt Sleep-Block I/O 阻塞状态，如下图所示：

!IO block.png

在开始分析磁盘 I/O 读写的瓶颈引起性能问题原因之前，我们先借用一张简化图来总体看看 Linux 系统的 I/O 栈：

!linux IO.jpg

从上图可以看出，整个 Linux 下的 I/O 栈大致有三个层次：

• 文件系统层，以 write 为例，内核拷贝了 write 参数指定的用户态数据到文件系统 Cache 中，并适时向下层同步。
• 块层，管理块设备的 I/O 队列，对 I/O 请求进行合并、排序。
• 设备层，通过 DMA 与内存直接交互，完成数据和具体存储设备之间的交互。

可能存在的性能瓶颈问题如下：

• 为了优化文件读写的性能，减少磁盘的 I/O 操作，Linux 内核系统提供了页缓存（Page Cache）技术，以页为单位将磁盘上的文件内容缓存在内存中，从而提供了接近于内存读写速度的文件顺序读写速度，也就是 Buffered I/O。但是当系统剩余内存不足时，系统会回收 Page Cache 页缓存内存，导致文件读写操作直接落到磁盘上，从而极大降低 I/O 性能。这也就前一小节中分析的低内存导致的性能卡顿问题。
• 上层所有的 I/O 请求都会放入队列中进行合并排队处理，这样就可能引发不同应用进程之间的资源抢占问题。比如后台进程存在大量读写磁盘的操作请求，占用系统的 I/O 资源，这就会导致前台应用的 I/O 请求出现在队列中阻塞排队等待的现象，最终导致掉帧卡顿问题。
• 文件系统的性能瓶颈。比如针对 NAND 闪存特性设计的 f2fs 文件系统，相比于 ext4 文件系统，能够提升小文件的随机读写性能，并能减少碎片化的问题。再比如 Android 11 上引入的 Fuse 文件系统，增加 I/O 读写的开销，导致 sdcard 路径下的部分路径文件的 I/O 读写性能下降。
• 闪存的读写性能瓶颈。一个就是闪存硬件的读写性能差异，比如 UFS 3.0 相对于 UFS 2.1 来讲顺序读取速度快 90%，顺序写入速度更是提升 160%；另外一个问题就是闪存重复写入，需要先进行擦除操作，这样随着时间的推移，磁盘碎片变多，剩余空间少，一个内存页的写入会引起整个磁盘块的迁移，造成耗时操作，也就是早期 Android 手机给人形成"越用越卡"的印象的原因之一。

二、优化思路

针对 I/O 磁盘性能的瓶颈，总体优化思路从两个角度来看：

1. 从手机厂商角度：

• 采用更大的内存硬件配置，并从总体上优化系统的内存占用。以防止出现系统低内存状态下，Page Cache 页缓存被回收后，应用直接写磁盘而导致的 I/O 阻塞卡顿问题；
• **启用 Linux 的 cgroup 机制对 I/O 资源的进程隔离机制 blkio**，将进程按照优先级进行分组（分为前台进程、后台进程、甚至可以根据需求进行更详细的自定义划分），以分配不同的 I/O 带宽资源，从而解决后台应用进程抢占前台应用 I/O 资源造成的卡顿的问题；
• 采用 f2fs 文件系统，替换 ext4 文件系统，以提升文件系统的性能；可以针对部分系统文件管理类的应用不走默认的 fuse 路径，而是走 f2fs，以提升其读写性能表现；
• 采用读写性能更强的闪存器件，比如最新的 UFS 3.1；
• 启用 fstrim 磁盘碎片整理功能，在息屏、充电等条件下触发磁盘碎片整理的动作，从而减少磁盘碎片，提升磁盘读写性能；系统手机管家模块可以引导用户定期进行垃圾文件的清理，以保证磁盘有充足的剩余空间；
• 基于 mmap 内存映射机制，将系统运行常访问的文件 Lock 锁定到内存缓存中，以提升文件读写的性能，减少真正发生 I/O 磁盘读写的概率，减轻系统的 I/O 负载。Android 系统框架中的 PinnerService 服务主要职责就是这个，如下图所示：

!pinner.png

2. 从应用开发者角度：

• 选择合适的文件读写操作。对读写速度有较高的要求，并允许低概率的数据丢失问题，就采用系统默认的基于 Page Cache 的缓存 I/O；对文件读写的速度要求不高，但是需要严格的保证数据不会丢失就使用 Direct I/O；如果需要对同一块区域进行频繁读写的情况，对读写性能要求极高，可以采用 mmap 内存映射机制实现读写文件，比如腾讯开源的用于改善原生 SharePreferences 机制性能的存储工具 MMKV 就是这个原理实现的。
• I/O 方式的选择。一个是对于阻塞 I/O 操作尽量放入子线程执行，以免阻塞 UI 线程；二是适当采用异步 I/O 减少读取文件的耗时，提升 CPU 整体利用率，比如 Okio 就支持异步 I/O 操作。
• 优化数据结构，建立内存缓存，尽量减少不必要的 I/O；

学习fw课程和性能相关知识有啥疑问，请记得联系马哥本人或者在马哥vip群中进行讨论

更多vip干货独享知识，及面试定制指导上岸fw工程师服务，课程优惠购买成为vip学员进入vip群，积极讨论各种行业难点痛点疑难问题，答疑服务等。

请联系马哥微信：