android fence机制,Android中的GraphicBuffer同步機制-Fence

最新推荐文章于 2024-12-16 16:08:43 发布
最新推荐文章于 2024-12-16 16:08:43 发布
阅读量447 收藏
点赞数
文章标签： android fence机制

http://blog.youkuaiyun.com/jinzhuojun/article/details/39698317

Fence是一種同步機制，在Android里主要用於圖形系統中GraphicBuffer的同步。那它和已有同步機制相比有什么特點呢？它主要被用來處理跨硬件的情況，尤其是CPU，GPU和HWC之間的同步，另外它還可以用於多個時間點之間的同步。GPU編程和純CPU編程一個很大的不同是它是異步的，也就是說當我們調用GL command返回時這條命令並不一定完成了，只是把這個命令放在本地的command buffer里。具體什么時候這條GL command被真正執行完畢CPU是不知道的，除非CPU使用glFinish()等待這些命令執行完，另外一種方法就是基於同步對象的Fence機制。下面舉個生產者把GraphicBuffer交給消費者的例子。如生產者是App中的renderer，消費者是SurfaceFlinger。GraphicBuffer的隊列放在緩沖隊列BufferQueue中。BufferQueue對App端的接口為IGraphicBufferProducer，實現類為Surface，對SurfaceFlinger端的接口為IGraphicBufferConsumer，實現類為SurfaceFlingerConsumer。BufferQueue中對每個GraphiBuffer都有BufferState標記着它的狀態：

8ed04475bda64dee7002cdf60c31efbf.jpe

這個狀態一定程度上說明了該GraphicBuffer的歸屬，但只指示了CPU里的狀態，而GraphicBuffer的真正使用者是GPU。也就是說，當生產者把一個GraphicBuffer放入BufferQueue時，只是在CPU層面完成了歸屬的轉移。但GPU說不定還在用，如果還在用的話消費者是不能拿去合成的。這時候GraphicBuffer和生產消費者的關系就比較曖昧了，消費者對GraphicBuffer具有擁有權，但無使用權，它需要等一個信號，告訴它GPU用完了，消費者才真正擁有使用權。一個簡化的模型如下：

f4feab4fe8361c4e57439b7252f8ca27.jpe

這個通知GraphicBuffer被上一個使用者用完的信號就是由Fence完成的。Fence的存在非常單純，從誕生開始就是為了在合適的時間發出一個信號。另一個角度來說，為什么不在生產者把GraphicBuffer交給消費者時就調用glFinish()等GPU完成呢？這樣擁有權和使用權就一並傳遞了，無需Fence。就功能上這樣做是可以的，但性能會有影響，因為glFinish()是阻塞的，這時CPU為了等GPU自己也不能工作了。如果用Fence的話就可以等這個GraphicBuffer真正要被消費者用到時再阻塞，而那之前CPU和GPU是可以並行工作的。這樣相當於實現了臨界資源的lazy passing。

說完Fence的基本作用，再說下它的實現。Fence，顧名思義就是把先到的攔住，等后來的，兩者步調一致了再往前走。抽象地說，Fence包含了同一或不同時間軸上的多個時間點，只有當這些點同時到達時Fence才會被觸發。更詳細的介紹可以參考這篇文章(http://netaz.blogspot.com/2013/10/android-fences-introduction-in-any.html)。

Fence可以由硬件實現(Graphic driver)，也可以由軟件實現(Android kernel中的sw_sync)。EGL中提供了同步對象的擴展KHR_fence_sync(http://www.khronos.org/registry/vg/extensions/KHR/EGL_KHR_fence_sync.txt)。其中提供了eglCreateSyncKHR ()，eglDestroySyncKHR()產生和銷毀同步對象。這個同步對象是往GL command隊列中插入的一個特殊操作，當執行到它時，會發出信號指示隊列前面的命令已全部執行完畢。函數eglClientWaitSyncKHR()可讓調用者阻塞等待信號發生。

在此基礎之上，Android對其進行了擴展-ANDROID_native_fence_sync  (http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt)，新加了接口eglDupNativeFenceFDANDROID()。它可以把一個同步對象轉化為一個文件描述符(反過來，eglCreateSyncKHR()可以把文件描述符轉成同步對象)。這個擴展相當於讓CPU中有了GPU中同步對象的句柄，文件描述符可以在進程間傳遞(通過binder或domain socket等IPC機制)，這就為多進程間的同步提供了基礎。我們知道Unix系統一切皆文件，因此，有個這個擴展以后Fence的通用性大大增強了。

Android還進一步豐富了Fence的software stack。主要分布在三部分：C++ Fence類位於/frameworks/native/libs/ui/Fence.cpp; C的libsync庫位於/system/core/libsync/sync.c; Kernel driver部分位於/drivers/base/sync.c。總得來說，kernel driver部分是同步的主要實現，libsync是對driver接口的封裝，Fence是對libsync的進一步的C++封裝。Fence會被作為GraphicBuffer的附屬隨着GraphicBuffer在生產者和消費間傳輸。另外Fence的軟件實現位於/drivers/base/sw_sync.c。SyncFeatures用以查詢系統支持的同步機制：/frameworks/native/libs/gui/SyncFeatures.cpp。

下面分析下Fence在Android中的具體用法。它主要的作用是GraphicBuffer在App, GPU和HWC三者間傳遞時作同步。

首先溫故一下GraphicBuffer從App到Display的旅程。GraphicBuffer先由App端作為生產者進行繪制，然后放入到BufferQueue，等待消費者取出作下一步的渲染合成。SurfaceFlinger作為消費者，會把每個層對應的GraphicBuffer取來生成EGLImageKHR對象。合成時對於GraphicBuffer的處理分兩種情況。對於Overlay的層，SurfaceFlinger會直接將其buffer handle放入HWC的Layer list。對於需要GPU繪制的層(超出HWC處理層數或者有復雜變換的)，SurfaceFlinger會將前面生成的EGLImageKHR通過glEGLImageTargetTexture2DOES()作為紋理進行合成(http://snorp.net/2011/12/16/android-direct-texture.html)。合成完后SurfaceFlinger又作為生產者，把GPU合成好的framebuffer的handle置到HWC中的FramebufferTarget中(HWC中hwc_display_contents_1_t中的hwc_layer_1_t列表最后一個slot用於放GPU的渲染結果所在buffer)。HWC最后疊加Overlay層再往Display上扔，這時HWC是消費者。整個大致流程如圖：

a561359c25183a34a8c311fa63525d5d.jpe

可以看到，對於非Overlay的層來說GraphicBuffer先后經過兩個生產消費者模型。我們知道GraphicBuffer核心包含的是buffer_handle_t結構，它指向的native_handle_t包含了gralloc中申請出來的圖形緩沖區的文件描述符和其它基本屬性，這個文件描述符會被同時映射到客戶端和服務端，作為共享內存。

ab045a65dcb4697c0cd2df28b451a8f2.jpe

由於服務和客戶端進程都可以訪問同一物理內存，因此不加同步的話會引起錯誤。為了協調客戶端和服務端，在傳輸GraphicBuffer時，還帶有Fence，標志了它是否被上一個使用者使用完畢。Fence按作用大體分兩種：acquireFence和releaseFence。前者用於生產者通知消費者生產已完成，后者用於消費者通知生產者消費已完成。下面分別看一下這兩種Fence的產生和使用過程。首先是acquireFence的使用流程：

6e20abbd00b2603ef3ee8b8087288d54.jpe

當App端通過queueBuffer()向BufferQueue插入GraphicBuffer時，會順帶一個Fence，這個Fence指示這個GraphicBuffer是否已被生產者用好。之后該GraphicBuffer被消費者通過acquireBuffer()拿走，同時也會取出這個acquireFence。之后消費者(也就是SurfaceFlinger)要把它拿來渲染時，需要等待Fence被觸發。如果該層是通過GPU渲染的，那么使用它的地方是Layer::onDraw()，其中會通過bindTextureImage()綁定紋理：

486    status_t err = mSurfaceFlingerConsumer->bindTextureImage();

該函數最后會調用doGLFenceWaitLocked()等待acquireFence觸發。因為再接下來就是要拿來畫了，如果這兒不等待直接往下走，那渲染出來的就是錯誤的內容。

如果該層是HWC渲染的Overlay層，那么不需要經過GPU，那就需要把這些層對應的acquireFence傳到HWC中。這樣，HWC在合成前就能確認這個buffer是否已被生產者使用完，因此一個正常點的HWC需要等這些個acquireFence全被觸發才能去繪制。這個設置的工作是在SurfaceFlinger::doComposeSurfaces()中完成的，該函數會調用每個層的layer::setAcquireFence()函數：

428    if (layer.getCompositionType() == HWC_OVERLAY) {

429        sp fence = mSurfaceFlingerConsumer->getCurrentFence();

...

431            fenceFd = fence->dup();

...

437    layer.setAcquireFenceFd(fenceFd);

可以看到其中忽略了非Overlay的層，因為HWC不需要直接和非Overlay層同步，它只要和這些非Overlay層合成的結果FramebufferTarget同步就可以了。GPU渲染完非Overlay的層后，通過queueBuffer()將GraphicBuffer放入FramebufferSurface對應的BufferQueue，然后FramebufferSurface::onFrameAvailable()被調用。它先會通過nextBuffer()->acquireBufferLocked()從BufferQueue中拿一個GraphicBuffer，附帶拿到它的acquireFence。接着調用HWComposer::fbPost()->setFramebufferTarget()，其中會把剛才acquire的GraphicBuffer連帶acquireFence設到HWC的Layer list中的FramebufferTarget slot中：

580        acquireFenceFd = acquireFence->dup();

...

586    disp.framebufferTarget->acquireFenceFd = acquireFenceFd;

綜上，HWC進行最后處理的前提是Overlay層的acquireFence及FramebufferTarget的acquireFence都被觸發。

看完acquireFence，再看看releaseFence的使用流程：

d93da695d5e37cad0f81ee900e4c0b06.jpe

前面提到合成的過程先是GPU工作，在doComposition()函數中合成非Overlay的層，結果放在framebuffer中。然后SurfaceFlinger會調用postFramebuffer()讓HWC開始工作。postFramebuffer()中最主要是調用HWC的set()接口通知HWC進行合成顯示，然后會將HWC中產生的releaseFence(如有)同步到SurfaceFlingerConsumer中。實現位於Layer的onLayerDisplayed()函數中：

151        mSurfaceFlingerConsumer->setReleaseFence(layer->getAndResetReleaseFence());

上面主要是針對Overlay的層，那對於GPU繪制的層呢？在收到INVALIDATE消息時，SurfaceFlinger會依次調用handleMessageInvalidate()->handlePageFlip()->Layer::latchBuffer()->SurfaceFlingerConsumer::updateTexImage() ，其中會調用該層對應Consumer的GLConsumer::updateAndReleaseLocked() 函數。該函數會釋放老的GraphicBuffer，釋放前會通過syncForReleaseLocked()函數插入releaseFence，代表如果觸發時該GraphicBuffer消費者已經使用完畢。然后調用releaseBufferLocked()還給BufferQueue，當然還帶着這個releaseFence。這樣，當這個GraphicBuffer被生產者再次通過dequeueBuffer()拿出時，就可以通過這個releaseFence來判斷消費者是否仍然在使用。

另一方面，HWC合成完畢后，SurfaceFlinger會依次調用DisplayDevice::onSwapBuffersCompleted() -> FramebufferSurface::onFrameCommitted()。onFrameCommitted()核心代碼如下：

148    sp fence = mHwc.getAndResetReleaseFence(mDisplayType);

...

151        status_t err = addReleaseFence(mCurrentBufferSlot,

152                mCurrentBuffer, fence);

此處拿到HWC生成的FramebufferTarget的releaseFence，設到FramebufferSurface中相應的GraphicBuffer Slot中。這樣FramebufferSurface對應的GraphicBuffer也可以被釋放回BufferQueue了。當將來EGL從中拿到這個buffer時，照例也要先等待這個releaseFence觸發才能使用。

Y.HL
关注
Android SurfaceFlinger——Fence流转状态（五十）
小旭的专栏
08-07 1042
fence 本质上对应上内核中一个文件描述符 sync_file，sync_file 中有一个核心的 fence 结构体，用于预计释放的时间点。所有的 fence 都是以 sync_timeline 为基准进行递增的。sync_timeline 作为内核记录已经渲染屏幕多少个时间点，每一次通过 hwc_set 都会递增一个时间点，并且会尝试的唤醒关联在 sync_timeline 中 active_list 中 sync_pt 的 fence 的阻塞。
Android SurfaceFlinger——GraphicBuffer的生成（三十二）
小旭的专栏
07-25 1237
通过前面的学习我们知道，在 SurfaceFlinger 中使用的生产者/消费者模型，Surface 做为生产者一方存在如下两个比较重要的函数：dequeueBuffer：获取一个缓冲区（GraphicBuffer），也就是 GraphicBuffer 生成。queueBuffer ：把缓冲区（GraphicBuffer）放入缓冲队列中。这里我们就先来看看 dequeueBuffer() 函数，该函数通常由生产者调用，用于从 BufferQueue 中取出一个缓冲区以供渲染。
Fence_Android：Fence_Android
02-16
磨床 Dart工作流程，自动化。 Grinder由定义项目任务的库（例如test ， build ， doc ）和运行它们的命令行工具组成。 入门 要开始使用grinder ，请将其添加到您的。 定义任务 任务完全由Dart代码定义，使您可以利用整个Dart生态系统来编写和调试任务。 任务定义位于tool/grind.dart脚本中。 要创建一个简单的grinder脚本，请运行： pub run grinder:init 通常，grinder脚本如下所示： import 'package:grinder/grinder.dart' ; main (args) => grind (args); @DefaultTask ( 'Build the project.' ) build () { log ( "Building..." ); } @Task ( 'Test stuff.'
Android中的GraphicBuffer同步机制-Fence
weixin_34037173的博客
05-20 414
Fence是一种同步机制，在Android里主要用于图形系统中GraphicBuffer的同步。那它和已有同步机制相比有什么特点呢？它主要被用来处理跨硬件的情况。尤其是CPU。GPU和HWC之间的同步，另外它还能够用于多个时间点之间的同步。GPU编程和纯CPU编程一个非常大的不同是它是异步的。也就是说当我们调用GL command返回时这条命令并不一定完毕了。仅仅是把这个命令放在本地的co...
Android SurfaceFlinger中Fence机制--个人理解整理
入琞的博客
05-19 9193
1 Fence 是什么？ Fence中文是栅栏/围墙的意思，理解成分界/界限的东西。android中的一个资源锁机制。(i.e. a kind of memory barrier） 下面链接是english 介绍 Bringing Android explicit fencing to the mainline 2 Fence是干什么的？ android 从4.4开始提供提供了fence机制，协调下面各模块的运作。各模块都是操作的buffer信息，所有对于buffer加一个资源锁，就可以实现buf
Android Fence机制
路先生的杂货铺，学习总结+好文分享
03-29 689
Android P 图形显示系统（十一） BufferQueue（二）](（最全最详细，推荐）
android fence机制,Android4.4 fence机制分析
weixin_34703307的博客
05-31 1936
在任何一个系统中，无可避免的都会跟各种buffers打交道，最经典的模式就是消费-生产者模式，一个独立的buffer在它们之间的交换等操作都需要一个机制来控制每个buffer的“生命周期”，即ALLOCATION和 RELEASE ，此外还要考虑到同步性问题，什么时候可以read buffer和write buffer都需要听从调遣。在android中的fence就是这样一个为了解决同步性而出现的...
Android SurfaceFlinger——GraphicBuffer的提交（三十三）
小旭的专栏
07-25 882
在 SurfaceFlinger 中，我们 dequeueBuffer 和 queueBuffer 是 Surface 控制接口中非常重要的两个函数，分别用于从 Surface 的 BufferQueue 中取出缓冲区和向 BufferQueue 提交（队列）缓冲区。这两个函数在生产者和消费者模型中扮演着核心角色，确保了图像数据的高效和有序传输。上一篇文章我们已经介绍了 dequeueBuffer() 函数，这里我们就来看一下 queueBuffer() 函数。
Android显示系统（13）- 向SurfaceFlinger提交Buffer
Ziwubiancheng的博客
12-16 1456
Buffer被填充完渲染数据之后，通过Binder告诉SF端对应的消费者，后续通知流程：生产者->进入了消费者->Layer->SurfaceFlinger。就进入了视频显示的主流程，具体如何显示，且听下回分解。
android fence机制,Android中的GraphicBuffer同步机制-Fence
weixin_26854475的博客
05-31 728
Fence是一种同步机制，在Android里主要用于图形系统中GraphicBuffer的同步。那它和已有同步机制相比有什么特点呢？它主要被用来处理跨硬件的情况。尤其是CPU。GPU和HWC之间的同步，另外它还能够用于多个时间点之间的同步。GPU编程和纯CPU编程一个非常大的不同是它是异步的。也就是说当我们调用GL command返回时这条命令并不一定完毕了。仅仅是把这个命令放在本地的comman...
Android fb driver中的fence机制
qwaszx523的博客
10-20 1624
转自：http://blog.youkuaiyun.com/ear5cm/article/details/45093807   Android HardwareComposer中的fence机制中讨论了hwc中的fence,hwc最终把layer的acqireFenceFd送进fb driver,再由fb drvier生成新的reitreFenceFd并return回user space.本篇文章我们来
Android4.4 fence机制分析
热门推荐
天马行空，隐姓埋名
09-12 1万+
Android4.4 fence机制分析  在任何一个系统中，无可避免的都会跟各种buffers打交道，最经典的模式就是消费-生产者模式，一个独立的buffer在它们之间的交换等操作都需要一个机制来控制每个buffer的“生命周期”，即ALLOCATION 和 RELEASE ，此外还要考虑到同步性问题，什么时候可以read buffer和write buffer都需要听从调遣。   在an
android系统同步功能,Android系统中GraphicBuffer的同步-Fence同步机制
weixin_35448391的博客
05-25 665
http://www.mamicode.com/info-detail-1814612.htmlFence是一种同步机制，在Android里主要用于图形系统中GraphicBuffer的同步。那它和已有同步机制相比有什么特点呢？它主要被用来处理跨硬件的情况。尤其是CPU。GPU和HWC之间的同步，另外它还能够用于多个时间点之间的同步。GPU编程和纯CPU编程一个非常大的不同是它是异步的。也就是说当...
Android Fence timeout
superjaingchao的专栏
01-22 2476
Android fence是一个用来同步的东西
android graphic(15)—fence
lyf's blog
03-28 1万+
fence的使用 fence的作用 软件实现的opengl 硬件实现的opengl 上层canvas绘图 关于fence，不错的参考文章http://blog.youkuaiyun.com/jinzhuojun/article/details/39698317。但是和我理解的还是有些出入，本文结合代码分析下自己理解的fence的产生和传递。 fence的使用 一般f
Android SurfaceFlinger——同步围栏Fence（四十九）
小旭的专栏
08-06 1146
在 Android 的 SurfaceFlinger 组件中，围栏（Fence）是一种用于同步不同系统组件间操作完成的机制。围栏的概念来源于硬件图形加速器（如 GPU）和其他系统服务（如 SurfaceFlinger）之间的同步需求。在图形渲染和显示的过程中，多个组件可能会并发地访问共享资源（如缓冲区），为了确保数据的一致性和操作的正确顺序，就需要一种机制来协调这些操作，这就是围栏的作用。
Android HardwareComposer中的fence机制
ear5cm的专栏
04-16 7374
Android HardwareComposer中的fence机制
GPU fence 是composer fence
最新发布
06-13
<think>嗯，用户这次提出了一个相当专业的图形系统问题，关于Android中GPUfence和composerfence的关系。看来用户已经深入研究了SurfaceFlinger的合成机制，现在想进一步了解底层的同步机制。从引用内容看，用户应该是个Android系统开发人员或图形工程师。ta的问题非常聚焦，直接针对同步原语这种底层机制。这类问题通常只有做图形性能优化或解决画面撕裂问题时才会遇到。用户能准确区分GPUfence和composerfence这两个概念，说明已经具备相当的图形知识基础。用户引用的材料很有意思：引用[2]提到HWC的图层分配和厂商HAL层路径；引用[4]提到IComposer与HWC交互的关键机制；引用[5]则涉及BufferQueue的监听机制。这些恰好是理解fence运作的基础。不过奇怪的是，用户没有引用任何直接讨论fence的文档，可能相关资料比较稀缺。回答时需要特别注意：必须明确区分硬件fence和软件fence的抽象层级。GPUfence是驱动层的概念，而composerfence是HWC服务层的封装。二者的联系在于都通过syncframework实现跨进程同步，但作用对象完全不同。关键要解释清楚“h/wcfence传递原理”和“生产者-消费者依赖关系”这两个难点。用户可能真正想解决的是画面撕裂或卡顿问题，ta的深层需求或许是优化合成性能。所以在最后列举相关问题时要包含“如何调试fence超时”这种实战性问题。</think> 在 Android 图形系统中，**GPU fence** 和 **Composer fence** 是两类关键的同步原语，其核心作用在于协调图像生产者（应用）与消费者（合成器/显示器）的执行时序，防止数据竞争和显示异常。以下详解其区别与联系： --- ### **GPU Fence** 主要用于协调 **GPU 命令队列的执行顺序**： 1. **生产者同步**： - 应用通过 `EGL/ Vulkan` 提交渲染命令后，GPU 驱动生成 `EGL Fence` 或 `Vk Fence`。 - 该 fence 会关联到 `GraphicBuffer`，并在 `BufferQueue` 入队（`queueBuffer`）时传递给 SurfaceFlinger[^2]。 $$ \text{渲染完成信号} \xrightarrow{\text{GPU Fence}} \text{Buffer 可消费通知} $$ 2. **消费者同步**： - SurfaceFlinger 在合成前，会等待 GPU fence 触发（确保应用的渲染已完成）。 - 代码路径：`frameworks/native/libs/gui/BufferQueueConsumer.cpp` 中检查 fence 状态[^5]。 --- ### **Composer Fence** 由 **Hardware Composer (HWC)** 管理，负责 **硬件合成流水线的时序控制**： 1. **显示硬件同步**： - HWC 在配置显示层（Overlay）时，生成 `HWC Fence`（硬件信号）。 - 该 fence 确保显示器在帧缓冲区（Framebuffer）准备就绪前不会读取数据[^4]。 2. **跨进程同步机制**： - 底层通过 `sync framework`（如 Linux `sync_file`）将硬件信号抽象为同步对象。 - SurfaceFlinger 通过 `HWC2::Layer::setReleaseFence()` 接收 Composer fence[^4]。 --- ### **核心区别** | **维度** | GPU Fence | Composer Fence | |-------------------|--------------------------------------|------------------------------------| | **作用域** | GPU 命令队列同步 | 显示硬件流水线同步 | | **生成者** | GPU 驱动 (EGL/Vulkan) | HWC HAL 实现 (厂商驱动) | | **消费者** | SurfaceFlinger (合成前等待) | 显示控制器 (Display Controller) | | **同步目标** | 确保渲染完成 | 确保帧缓冲区可安全读取/切换 | --- ### **协同工作流程** ```mermaid sequenceDiagram participant App as 应用 participant GPU as GPU 驱动 participant SF as SurfaceFlinger participant HWC as Hardware Composer participant Display as 显示器 App->>GPU: 提交渲染命令 GPU-->>App: 生成 GPU fence App->>SF: queueBuffer(GPU fence) SF->>HWC: prepareOverlay() HWC-->>SF: 返回合成计划（含 Composer fence） SF->>GPU: 执行合成（等待 GPU fence） SF->>HWC: setLayerReleaseFence(Composer fence) HWC->>Display: 提交帧（等待 Composer fence） Display-->>HWC: 显示完成 ``` 1. **合成阶段**：SurfaceFlinger 等待 **GPU fence** 确保应用渲染完成[^2]； 2. **送显阶段**：HWC 等待 **Composer fence** 确保显示控制器安全读取帧缓冲区[^4]； 3. **Buffer 释放**：当显示器完成帧消费后，HWC 触发 `Release Fence` 通知生产者（应用）可复用 Buffer[^5]。 --- ### **关键设计意义** - **避免撕裂（Tearing）**：双重缓冲机制中，fence 确保 Back Buffer 在渲染/合成完成前不会被提前切换[^4]； - **降低延迟**：异步合成流水线中，GPU 渲染下一帧的同时，显示器正消费当前帧（由 fence 隔离风险）； - **功耗优化**：减少 GPU 轮询，依赖硬件信号唤醒系统[^4]。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值