Android 源码 图形系统之 Surface 初始化

最新推荐文章于 2024-05-21 21:39:28 发布
最新推荐文章于 2024-05-21 21:39:28 发布
阅读量863 收藏
点赞数
分类专栏： Android源码
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tyyj90/article/details/108087543
版权

在 《Android 源码 图形系统之 relayoutWindow》 一节中，outSurface 初始化（调用其 copyFrom(…) 方法，入参是 SurfaceControl 对象）没有继续分析了。现在详细来分析一下后续流程。

copyFrom(…) 方法将另一个 Surface 复制到此 Surface。现在，此 Surface 拥有对与原始 Surface 相同数据的引用，并且不是所有者。这是供窗口管理器从客户端返回窗口 Surface 时使用的，将其从窗口管理器管理的表示形式转换为客户端用来向其绘制的表示形式。

surfaceControlPtr 指针指向 Native SurfaceControl 对象，接着调用 nativeCreateFromSurfaceControl(…) jni 方法获取 Native Surface 指针，最后将指针强转为 jlong 赋值给成员变量 mNativeObject。

frameworks/base/core/java/android/view/Surface.java

public class Surface implements Parcelable {
    ......
    public void copyFrom(SurfaceControl other) {
        if (other == null) {
            throw new IllegalArgumentException("other must not be null");
        }

        long surfaceControlPtr = other.mNativeObject;
        if (surfaceControlPtr == 0) {
            throw new NullPointerException(
                    "SurfaceControl native object is null. Are you using a released SurfaceControl?");
        }
        long newNativeObject = nativeCreateFromSurfaceControl(surfaceControlPtr);

        synchronized (mLock) {
            if (mNativeObject != 0) {
                nativeRelease(mNativeObject);
            }
            setNativeObjectLocked(newNativeObject);
        }
    }    
    ......
}

构造 Surface 之后，WindowManagerService 会使用此方法，这对于将 Surface 引用返回给调用方是必需的。在这一点上，我们应该只有一个 SurfaceControl。

frameworks/base/core/jni/android_view_Surface.cpp

static jlong nativeCreateFromSurfaceControl(JNIEnv* env, jclass clazz,
        jlong surfaceControlNativeObj) {
    sp<SurfaceControl> ctrl(reinterpret_cast<SurfaceControl *>(surfaceControlNativeObj));
    sp<Surface> surface(ctrl->getSurface());
    if (surface != NULL) {
        surface->incStrong(&sRefBaseOwner);
    }
    return reinterpret_cast<jlong>(surface.get());
}

getSurface() 中终于创建了 Surface 对象。

frameworks/native/libs/gui/SurfaceControl.cpp

sp<Surface> SurfaceControl::getSurface() const
{
    Mutex::Autolock _l(mLock);
    if (mSurfaceData == 0) {
        // SurfaceFlinger 始终消耗此 Surface，因此 controlledByApp 值无关紧要，使用 false。
        mSurfaceData = new Surface(mGraphicBufferProducer, false);
    }
    return mSurfaceData;
}

ANativeWindow 的实现，可将图形缓冲区输入 BufferQueue。

这些程序通常用于希望通过某种方式（例如 OpenGL，软件渲染器或硬件解码器）渲染帧并将其创建的帧转发到 SurfaceFlinger 进行合成。例如，视频解码器可以渲染帧并调用 eglSwapBuffers()，后者调用由 Surface 定义的 ANativeWindow 回调。然后，Surface 通过 Binder IPC 将缓冲区转发到 BufferQueue 的生产者接口，从而将新帧提供给诸如 GLConsumer 之类的消费者。

根据给定的 IGraphicBufferProducer 创建一个 Surface（具体实现是 BufferQueue）。

在断开连接时，Surface 主要是无状态的，可以将其视为美化的 IGraphicBufferProducer 持有者。因此，从同一 IGraphicBufferProducer 创建其他 Surface 是安全的。但是，一旦连接了 Surface，它将防止其他引用同一个 IGraphicBufferProducer 的 Surface 连接起来，从而防止将它们用作缓冲区的实际生成器。

controlledByApp 标志指示此 Surface（生产者）由应用程序控制。此标志在连接时使用。

frameworks/native/libs/gui/Surface.cpp


Surface::Surface(
        const sp<IGraphicBufferProducer>& bufferProducer,
        bool controlledByApp)
    : mGraphicBufferProducer(bufferProducer),
      mGenerationNumber(0)
{
    // 初始化 ANativeWindow 函数指针。
    ANativeWindow::setSwapInterval  = hook_setSwapInterval;
    ANativeWindow::dequeueBuffer    = hook_dequeueBuffer;
    ANativeWindow::cancelBuffer     = hook_cancelBuffer;
    ANativeWindow::queueBuffer      = hook_queueBuffer;
    ANativeWindow::query            = hook_query;
    ANativeWindow::perform          = hook_perform;

    ANativeWindow::dequeueBuffer_DEPRECATED = hook_dequeueBuffer_DEPRECATED;
    ANativeWindow::cancelBuffer_DEPRECATED  = hook_cancelBuffer_DEPRECATED;
    ANativeWindow::lockBuffer_DEPRECATED    = hook_lockBuffer_DEPRECATED;
    ANativeWindow::queueBuffer_DEPRECATED   = hook_queueBuffer_DEPRECATED;

    const_cast<int&>(ANativeWindow::minSwapInterval) = 0;
    const_cast<int&>(ANativeWindow::maxSwapInterval) = 1;

    mReqWidth = 0;
    mReqHeight = 0;
    mReqFormat = 0;
    mReqUsage = 0;
    mTimestamp = NATIVE_WINDOW_TIMESTAMP_AUTO;
    mDataSpace = HAL_DATASPACE_UNKNOWN;
    mCrop.clear();
    mScalingMode = NATIVE_WINDOW_SCALING_MODE_FREEZE;
    mTransform = 0;
    mStickyTransform = 0;
    mDefaultWidth = 0;
    mDefaultHeight = 0;
    mUserWidth = 0;
    mUserHeight = 0;
    mTransformHint = 0;
    mConsumerRunningBehind = false;
    mConnectedToCpu = false;
    mProducerControlledByApp = controlledByApp;
    mSwapIntervalZero = false;
}

现在开始分析 Surface 分配缓冲区都做了什么？这是调用 Surface 类 allocateBuffers() 实现的。

mGraphicBufferProducer 是在 Surface 构造器中初始化的。它实际指向一个 BpGraphicBufferProducer 对象。Surface::allocateBuffers() 方法中实际调用了 BpGraphicBufferProducer 类 allocateBuffers(…) 方法。

frameworks/native/libs/gui/Surface.cpp

void Surface::allocateBuffers() {
    uint32_t reqWidth = mReqWidth ? mReqWidth : mUserWidth;
    uint32_t reqHeight = mReqHeight ? mReqHeight : mUserHeight;
    mGraphicBufferProducer->allocateBuffers(mSwapIntervalZero, reqWidth,
            reqHeight, mReqFormat, mReqUsage);
}

调用了 BpGraphicBufferProducer 类 allocateBuffers(…) 方法，最终会调用到 Bn 端对应实现（BufferQueueProducer）。

  1. 查找空闲 Slot
  2. 获取可用 Slot 数量（newBufferCount）
  3. 创建 GraphicBuffer
  4. 关联 GraphicBuffer 到对应槽位

frameworks/native/libs/gui/BufferQueueProducer.cpp

void BufferQueueProducer::allocateBuffers(bool async, uint32_t width,
        uint32_t height, PixelFormat format, uint32_t usage) {
    ATRACE_CALL();
    while (true) {
        Vector<int> freeSlots;
        size_t newBufferCount = 0;
        uint32_t allocWidth = 0;
        uint32_t allocHeight = 0;
        PixelFormat allocFormat = PIXEL_FORMAT_UNKNOWN;
        uint32_t allocUsage = 0;
        { // Autolock scope
            Mutex::Autolock lock(mCore->mMutex);
            mCore->waitWhileAllocatingLocked();

            if (!mCore->mAllowAllocation) {
                BQ_LOGE("allocateBuffers: allocation is not allowed for this "
                        "BufferQueue");
                return;
            }

            int currentBufferCount = 0;
            for (int slot = 0; slot < BufferQueueDefs::NUM_BUFFER_SLOTS; ++slot) {
                if (mSlots[slot].mGraphicBuffer != NULL) {
                    ++currentBufferCount;
                } else {
                    if (mSlots[slot].mBufferState != BufferSlot::FREE) {
                        BQ_LOGE("allocateBuffers: slot %d without buffer is not FREE",
                                slot);
                        continue;
                    }

                    freeSlots.push_back(slot);
                }
            }

            int maxBufferCount = mCore->getMaxBufferCountLocked(async);
            BQ_LOGV("allocateBuffers: allocating from %d buffers up to %d buffers",
                    currentBufferCount, maxBufferCount);
            if (maxBufferCount <= currentBufferCount)
                return;
            newBufferCount =
                    static_cast<size_t>(maxBufferCount - currentBufferCount);
            if (freeSlots.size() < newBufferCount) {
                BQ_LOGE("allocateBuffers: ran out of free slots");
                return;
            }
            allocWidth = width > 0 ? width : mCore->mDefaultWidth;
            allocHeight = height > 0 ? height : mCore->mDefaultHeight;
            allocFormat = format != 0 ? format : mCore->mDefaultBufferFormat;
            allocUsage = usage | mCore->mConsumerUsageBits;

            mCore->mIsAllocating = true;
        } // Autolock scope

        Vector<sp<GraphicBuffer>> buffers;
        for (size_t i = 0; i <  newBufferCount; ++i) {
            status_t result = NO_ERROR;
            sp<GraphicBuffer> graphicBuffer(mCore->mAllocator->createGraphicBuffer(
                    allocWidth, allocHeight, allocFormat, allocUsage, &result));
            if (result != NO_ERROR) {
                BQ_LOGE("allocateBuffers: failed to allocate buffer (%u x %u, format"
                        " %u, usage %u)", width, height, format, usage);
                Mutex::Autolock lock(mCore->mMutex);
                mCore->mIsAllocating = false;
                mCore->mIsAllocatingCondition.broadcast();
                return;
            }
            buffers.push_back(graphicBuffer);
        }

        { // Autolock scope
            Mutex::Autolock lock(mCore->mMutex);
            uint32_t checkWidth = width > 0 ? width : mCore->mDefaultWidth;
            uint32_t checkHeight = height > 0 ? height : mCore->mDefaultHeight;
            PixelFormat checkFormat = format != 0 ?
                    format : mCore->mDefaultBufferFormat;
            uint32_t checkUsage = usage | mCore->mConsumerUsageBits;
            if (checkWidth != allocWidth || checkHeight != allocHeight ||
                checkFormat != allocFormat || checkUsage != allocUsage) {
                // 当我们释放锁时，有些东西改变了。重试。
                BQ_LOGV("allocateBuffers: size/format/usage changed while allocating. Retrying.");
                mCore->mIsAllocating = false;
                mCore->mIsAllocatingCondition.broadcast();
                continue;
            }

            for (size_t i = 0; i < newBufferCount; ++i) {
                int slot = freeSlots[i];
                if (mSlots[slot].mBufferState != BufferSlot::FREE) {
                    // 消费者使用 attachBuffer 分配空闲槽。丢弃我们分配的缓冲区。
                    BQ_LOGV("allocateBuffers: slot %d was acquired while allocating. "
                            "Dropping allocated buffer.", slot);
                    continue;
                }
                mCore->freeBufferLocked(slot); // 先把槽清理干净
                mSlots[slot].mGraphicBuffer = buffers[i];
                mSlots[slot].mFence = Fence::NO_FENCE;

                // freeBufferLocked 将此槽放入空闲槽列表。
                // 由于我们随后 attach 了缓冲区，因此将槽移至空闲缓冲区列表。
                mCore->mFreeSlots.erase(slot);
                mCore->mFreeBuffers.push_front(slot);

                BQ_LOGV("allocateBuffers: allocated a new buffer in slot %d", slot);
            }

            mCore->mIsAllocating = false;
            mCore->mIsAllocatingCondition.broadcast();
            mCore->validateConsistencyLocked();
        } // Autolock scope
    }
}
  1. new 一个 GraphicBuffer 对象
  2. 调用 GraphicBuffer 类 initCheck()，检查其返回值

frameworks/native/libs/gui/GraphicBufferAlloc.cpp

sp<GraphicBuffer> GraphicBufferAlloc::createGraphicBuffer(uint32_t width,
        uint32_t height, PixelFormat format, uint32_t usage, status_t* error) {
    sp<GraphicBuffer> graphicBuffer(
            new GraphicBuffer(width, height, format, usage));
    status_t err = graphicBuffer->initCheck();
    *error = err;
    if (err != 0 || graphicBuffer->handle == 0) {
        if (err == NO_MEMORY) {
            GraphicBuffer::dumpAllocationsToSystemLog();
        }
        ALOGE("GraphicBufferAlloc::createGraphicBuffer(w=%d, h=%d) "
             "failed (%s), handle=%p",
                width, height, strerror(-err), graphicBuffer->handle);
        return 0;
    }
    return graphicBuffer;
}

GraphicBuffer 构造函数中初始化了成员变量 mBufferMapper，获取 GraphicBufferMapper 单例进行了初始化。接着调用了 initSize(…) 开始实际分配工作。

frameworks/native/libs/ui/GraphicBuffer.cpp

GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight,
        PixelFormat inFormat, uint32_t inUsage)
    : BASE(), mOwner(ownData), mBufferMapper(GraphicBufferMapper::get()),
      mInitCheck(NO_ERROR), mId(getUniqueId())
{
    width  =
    height =
    stride =
    format =
    usage  = 0;
    handle = NULL;
    mInitCheck = initSize(inWidth, inHeight, inFormat, inUsage);
}

GraphicBufferMapper 类构造器中加载了 HAL 模块 gralloc。

frameworks/native/libs/ui/GraphicBufferMapper.cpp

ANDROID_SINGLETON_STATIC_INSTANCE( GraphicBufferMapper )

GraphicBufferMapper::GraphicBufferMapper()
    : mAllocMod(0)
{
    hw_module_t const* module;
    int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);
    ALOGE_IF(err, "FATAL: can't find the %s module", GRALLOC_HARDWARE_MODULE_ID);
    if (err == 0) {
        mAllocMod = reinterpret_cast<gralloc_module_t const *>(module);
    }
}
  1. 获取 GraphicBufferAllocator 对象
  2. 调用 GraphicBufferAllocator 类 alloc(…) 方法进行内存分配

frameworks/native/libs/ui/GraphicBuffer.cpp

status_t GraphicBuffer::initSize(uint32_t inWidth, uint32_t inHeight,
        PixelFormat inFormat, uint32_t inUsage)
{
    GraphicBufferAllocator& allocator = GraphicBufferAllocator::get();
    uint32_t outStride = 0;
    status_t err = allocator.alloc(inWidth, inHeight, inFormat, inUsage,
            &handle, &outStride);
    if (err == NO_ERROR) {
        width = static_cast<int>(inWidth);
        height = static_cast<int>(inHeight);
        format = inFormat;
        usage = static_cast<int>(inUsage);
        stride = static_cast<int>(outStride);
    }
    return err;
}

initCheck() 方法仅仅返回成员变量 mInitCheck 的值。

frameworks/native/libs/ui/GraphicBuffer.cpp

status_t GraphicBuffer::initCheck() const {
    return static_cast<status_t>(mInitCheck);
}
TYYJ-洪伟
关注
专栏目录
Android SurfaceFlinger——OpenGL ES初始化（十三）
小旭的专栏
06-25 1033
上一篇文章我们对 OpenGL ES 相关知识有了一定的了解，并知道在使用 OpenGL ES 是需要先通过 eglGetDisplay() 方法获取 EGLDisplay 默认主屏幕句柄。这里就分析一下 eglGetDisplay() 中的 egl_init_drivers() 初始化 OpenGL ES 的对应流程。
深入Android系统（十二）Android图形显示系统-1-显示原理与Surface
m0_66265052的博客
01-29 2977
Window Positioning中的WindowManager主要是用来控制Window对象 Window对象是用来存放View对象的容器，每个Window对象都会关联Surface对象 WindowManager监视Window对象的生命周期、输入和焦点事件、屏幕方向、转换、动画、位置、变换、z顺序等 然后将所有Window元数据发送给SurfaceFlinger，SurfaceFlinger利用这些元数据把自己管理的所有Surface组合成layer 然后交给Hardware C..
Android Surface解析
mao7101的博客
11-14 1630
本文为作者原创，转载请注明出处。公众号为 毛铜飞 欢迎关注 (源码截图是Android 5.1.1_r6) 一 App和Surface的关系是怎样的 不论是用Skia绘制二维图像，还是用OpenGL绘制三维图像，最终Application都要和Surface交互。Surface 是什么： Handle onto a raw buffer that is being man...
Android绘图基础--Surface创建及初始化
leif 的博客
07-21 2098
Android绘图基础–Surface创建及初始化一个Window将和一个Surface绑定，绘制前ViewRootImpl会从Surface中lock除一个Canvas。同一个ViewRootImpl不同类型的View使用同一个Surface。
Android图像缓存与Surface初始化
最新发布
LeeDuoZuiShuai的博客
05-21 1367
在Android系统中，绘制渲染与渲染管理是分开的，分别由Surface和SurfaceControl负责。Surface是SurfaceFlinger管理的一块缓存，Surface的创建依赖SurfaceControl。SurfaceControl用于管理Surface的绘制层级与获取。Surface和SurfaceControl声明在ViewRootImpl的全局成员变量中，在创建ViewRootImpl时会一起创建Surface和SurfaceControl。
Android应用程序是如何请求SurfaceFlinger服务渲染一个Surface的？
CallmeZhe的博客
06-03 413
在前面一篇文章中，我们分析了Android应用程序请求SurfaceFlinger服务创建Surface的过程。有了Surface之后，Android应用程序就可以在上面绘制自己的UI了，接着再请求SurfaceFlinger服务将这个已经绘制好了UI的Surface渲染到设备显示屏上去。在本文中，我们就将详细分析Android应用程序请求SurfaceFlinger服务渲染Surface的过程。Android应用程序在请求SurfaceFlinger服务渲染一个Surface之前，首先要将该Sur...
surface java程序_「Android」 Surface分析
weixin_35964164的博客
02-27 406
本篇针对Surface模块进行分析，从Java层的Activity创建开始，到ViewRoot、WindowsManagerService，再到JNI层和Native层。首先推荐一个Android源码查看的网站：http://androidxref.com/Surface的创建涉及三个部分：App 进程App需要将自己的内容显示在屏幕上，所以App负责发起Surface创建请求，创建好Surfac...
Android Surface 分析+源码
m0_71524094的博客
03-06 736
显示层（Layer）和屏幕组成图8-10 屏幕组成示意图从图8-10中可以看出：· 屏幕位于一个三维坐标系中，其中Z轴从屏幕内指向屏幕外。· 编号为①②③的矩形块叫显示层（Layer）。每一层有自己的属性，例如颜色、透明度、所处屏幕的位置、宽、高等。除了属性之外，每一层还有自己对应的显示内容，也就是需要显示的图像。在Android中，Surface系统工作时，会由SurfaceFlinger对这些按照Z轴排好序的显示层进行图像混合，混合后的图像就是在屏幕上看到的美妙画面了。
Android Surface
05-01
2. Surface Manager 负责初始化 Surface Flinger，包括加载图形驱动程序和设置 Surface 的参数。 3. Surface Flinger 初始化完成后，会启动 Surface Manager，负责管理 Surface 的创建、销毁和更新。 五、一个简单...
Android 图形架构 之三—— 创建Layer、Surface、SurfaceControl
热门推荐
薛瑄的博客
10-12 1万+
前言 上一篇我们分析了，app与SurfaceFlinger建立连接的过程，现在我们就可以继续往下分析，看下创建Surface的过程。 我们可以将Surface理解为一个绘图表面，Android应用程序负责往这个绘图表面上填内容，而SurfaceFlinger服务负责将这个绘图表面的内容取出来，并且渲染在显示屏上。 概述 在Android中，Window与Surface一一对应。 如果说Window关心的是层次和布局，是从设计者角度定义的类，Surface则从实现角度出发，是工程师关系和考虑的类。Windo
android图形系统组件
小老鼠的博客
04-02 738
深入剖析android新特性 笔记 9.2 图形系统组件 图形系统的实现涉及比较多的模块，代码在： frameworks/base/core/jni/ frameworks/native/libs/ui/ frameworks/native/libs/gui/ frameworks/native/service/.surfaceflinger/. hardware/libhardwa...
Android深入浅出之Surface
weixin_33798152的博客
07-26 336
Android深入浅出之Surfacehttp://blog.csdn.net/Innost/article/details/6172893一 目的本节的目的就是为了讲清楚Android中的Surface系统，大家耳熟能详的SurfaceFlinger到底是个什么东西，它的工作流程又是怎样的。当然，鉴于SurfaceFlinger的复杂性，我们依然将采用情景分析的办法，找到合适的切入点...
android graphic(8)—surface申请GraphicBuffer过程
lyf's blog
02-22 1万+
surface的dequeueBuffer函数 向BufferQueue申请内存 Surface去requestBuffer 本节分析surface向Buffer Queue申请GraphicBuffer的过程（这里的surface是native的surface，不是java中的），在此过程中还会涉及Flattenable对对象序列化，binder传递文件描述符等概念。surface的deque
AndroidO 图形框架下应用绘图过程——Surface创建
深入剖析Android系统
06-13 8944
Android图形框架在前几年已经分析过了，不过，随着Android版本的升级，虽然框架主体未变，但有些细节变动还是比较大的，应网友要求，今天再次以AndroidO为基础，重新介绍图形框架实现，Android图形框架包括以下三大部分：1. 应用绘图；2. SurfaceFlinger混合图层；3. Hwc Hal实现本文首先介绍AndroidO下应用的绘图过程，应用绘图也分为以下几个步骤：sp&l...
Surface的理解
u012845099的博客
01-23 1003
1Surface創建 既然requestLayout内部是通过给主线程Handler发送任务消息并在Vsync同步信号返回后执行Runable。那我们就继续看看Runable内部执行的 // ========== android.view.ViewRootImpl =========== void doTraversal() { if (mTraversalScheduled) { mTraversalScheduled = false; //移除同步屏障，.
surface copy 的几个方法
hziee_的专栏
10-13 1601
1.IDirect3DDevice9::StretchRect texture to RT texture RT texture to RT texture 2.IDirect3DDevice9::GetRenderTargetData POOL_DEFAULT to D3DPOOL_SYSTEMMEM (RT texture to texture) 3.IDirect3DDev
Pygame高阶知识（4）-Surface的copy对象
pynickle的博客
02-01 1345
欢迎来到pygame大讲堂，这次我们来讲copy对象 anotherSurface=Surface.copy() Surface的copy对象返回一个新的Surface对象，这两个对象内容完全相同，但它们是两个Surface对象，以至于你可以用blit或绘制函数来绘制到某个Surface对象，而另一个Surface对象不会改变，比如说，你可以用一个Surface对象来保存用户的动作，另一个保存原...
Android SurfaceFlinger 学习之路(七)----创建图形缓冲区GraphicBuffer
STN_LCD的专栏
06-28 6755
http://windrunnerlihuan.com/2017/06/22/Android-SurfaceFlinger-%E5%AD%A6%E4%B9%A0%E4%B9%8B%E8%B7%AF-%E4%B8%83-%E5%88%9B%E5%BB%BA%E5%9B%BE%E5%BD%A2%E7%BC%93%E5%86%B2%E5%8C%BAGraphicBuffer/
Android13 SurfaceControl创建流程分析
liuning1985622的博客
05-05 1539
SurfaceControl是Android系统中的一个类，用于管理和控制Surface的创建、显示和销毁，SurfaceControl的创建过程如下：下面分析WindowManagerService创建SurfaceControl的步骤：首先应用进程会new一个java层SurfaceControl，什么都没做，然后传递到WMS进程，因为SurfaceControl在AIDL中是out类型，所以在WMS进程赋值。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

TYYJ-洪伟

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值