揭开Android Vulkan渲染封印：帧率暴增的底层指令

ps：本文内容较干，建议收藏后反复边跟进源码边思考设计思想。

壹

渲染管线的基础架构

为什么叫渲染管线？这里是因为整个渲染的过程涉及多道工序，像管道里的流水线一样，一道一道的处理数据的过程，所以使用渲染管线还是比较形象的。接下来我们来看下渲染的整个架构。

Android的渲染过程需要按照是否开启硬件加速分别看待，默认是开启硬件加速的，那么在应用层使用Canvas的一些绘图API会预先转换成OpenGL指令或者Vulkan指令，然后由OpenGL/Vulkan直接操作GPU执行像素化的过程。而如果不开启硬件加速，Canvas的绘图指令就会调用skia库直接利用CPU绘制Bitmap图。

1、开启硬件加速


DisplayList到底是什么？

class DisplayListData {
  // 基础绘制指令
  Vector<DisplayListOp*> displayListOps;
  // 子视图的应用
  Vector<DrawRenderNodeOp*> children;
  // 命令分组<用于 Z 轴排序>
  Vector<Chunk> chunks;
}

这里说的DisplayList中的指令、GPU可执行的指令序列和GPU原生指令有什么不同呢？


Android应用程序窗口的根视图是虚拟的，抽象为一个Root Render Node。此外，一个视图如果设置有Background，那么这个Background也会抽象为一个Background Render Node。Root Render Node、Background Render Node和其它真实的子视图，除了TextureView和软件渲染的子视图之外，都具有Display List，并且是通过一个称为Display List Renderer的对象进行构建的。

TextureView不具有Display List，它们是通过一个称为Layer Renderer的对象以Open GL纹理的形式来绘制的，不过这个纹理也不是直接就进行渲染的，而是先记录在父视图的Display List中以后再进行渲染的。同样，软件渲染的子视图也不具有Display List，它们先绘制在一个Bitmap上，然后这个Bitmap再记录在父视图的Display List中以后再进行渲染的。

DisplayList中的指令是一种抽象化的GPU绘制指令（GPU是无法直接使用的,每个View对应一个），包含这些类型的指令（了解即可）：

基础绘制操作

位图绘制：DrawBitmapOp(无法硬件渲染只能软件渲染的视图的Bitmap)

纹理绘制：DrawLayerOp(如TextureView的OpenGL 纹理)

图形绘制：DrawPathOp、DrawRectOp等（由Canvas.drawXXX()生成）

视图层级操作

子视图引用：DrawRenderNodeOp,封装子视图的RenderNode，递归执行其Display List

背景绘制：Background Render Node的绘制指令（独立DisplayList）

状态控制指令

ReorderBarrier：标记后续子视图需要按照Z轴排序（用于重叠视图）

InorderBarrier：标记后续子视图按默认顺序排序（无重叠）

Save/Restore：保存/恢复画布状态等等

概括起来说，DisplayList存储的指令=OpenGL/Vulkan命令的预处理抽象，这些指令在渲染线程中被转换为GPU可执行的OpenGL/Vulkan指令。

CPU可执行的指令序列是指在Render Thread中将Displaylist中的抽象指令转换成OpenGL/Vulkan的指令。

GPU原生指令是根据不同硬件生成的最基础的硬件操作指令，比如操作寄存器等。

2、关闭硬件加速

如果将整个执行流程按照从应用到底层GPU操作分层，可以这样分层：

贰

渲染阶段过程（硬件加速）

1、UI线程DisplayList生成

当需要进行画面绘制的时候(VSync信号来临)ViewRootImpl.TraversalRunnable.run()收到回调，调用ViewRootImpl.doTraversal()方法，这个方法中调用ViewRootImpl中的performTraversal()方法到performDraw()再到draw()方法，判断是否开启硬件加速，如果不开启就调用drawSoftware()；

如果开启就调用ThreadRenderer.draw()方法，再继续调用ThreadRenderer的updateRootDisplayList()，然后调到View的updateDisplayListDirty()，然后调到RenderNode.beginRecording()方法，这里面调到RecordingCanvas.obtain()方法，obtain()方法里面通过new RecordingCanvas(),然后通过JNI调用nCreateDisplayListCanvas()具体是调用Native哪个类？方法创建Native层的RecordingCanvas。

回到View的updateDisplayListDirty()方法里，执行完RenderNode.beginRecording()方法后得到RecordingCanvas的实例canvas，然后继续执行View里面的draw()方法，根据实际情况drawBackground(),再调onDraw()，以及draw子视图，里面都是调用RecordingCanvas的api,最终这些API都是JNI调用，在Native层调用的时候会将各种操作记录为各种抽象命令，并不直接进行画图。

2、渲染线程的并行化处理

上一步已经构建好DisplayList数据，ThreadedRenderer调用父类（HardwareRenderer）函数syncAndrDrawFrame()，函数里使用JNI调用nSyncAndDrawFrame(...)，也就调用到android_graphics_HardwareRenderer.cpp中的android_view_ThreadedRenderer_syncAndDrawFrame()函数。

这个函数里调用RenderProxy.cpp的syncAndDrawFrame()函数，syncAndDrawFrame()函数里调用DrawFrameTask.cpp的drawFrame()函数，此函数调用函数当前类的postAndWait()函数，然后函数里调用RenderThread的queue()函数，将当前Task入到渲染线程的队列；当任务执行时，回调到DrawFrameTask.cpp中的run()函数，这个函数就是渲染的核心函数：

void DrawFrameTask::run() {
  ...
  if (CC_LIKELY(canDrawThisFrame)) {
        // 渲染上下文CanvasContext.draw()
        context->draw();
    } else {
        // wait on fences so tasks don't overlap next frame
        context->waitOnFences();
    }
  ...

}

真正的绘制是通过调用ContextCanvas的draw()函数，里面再通过mRenderPipeline->draw()函数将DisplayList命令转换成GPU命令，mRenderPipeLine这个就是实际实现渲染的管线，他有可能是通过OpenGL来实现或者通过Vulkan来实现，代码中有三种渲染管线类型(不同Android版本有一些区别)：

SkiaOpenGLPipeline：基于OpenGL的Skia渲染管线

使用OpenGL API进行GPU渲染

兼容性好，支持大多数GPU

性能稳定

SkiaVulkanPipeline：基于Vulkan的Skia渲染管线

使用Vulkan API进行GPU渲染

更低的CPU开销

更好的多线程支持

更现代的GPU API

SkiaCpuPipeline：基于CPU的Skia渲染管线

用于非Android平台

纯CPU渲染，不依赖GPU

用于调试或者特殊环境

那么Android源码中是怎么选择使用哪种渲染管线呢，我们看CanvasContext的create()函数：

CanvasContext* CanvasContext::create(RenderThread& thread, bool translucent,
                                     RenderNode* rootRenderNode, IContextFactory* contextFactory,
                                     pid_t uiThreadId, pid_t renderThreadId) {
    // 根据系统属性配置获取使用的渲染管线类型
    auto renderType = Properties::getRenderPipelineType();

    switch (renderType) {
        case RenderPipelineType::SkiaGL:
            return new CanvasContext(thread, translucent, rootRenderNode, contextFactory,
                                     std::make_unique<skiapipeline::SkiaOpenGLPipeline>(thread),
                                     uiThreadId, renderThreadId);
        case RenderPipelineType::SkiaVulkan:
            return new CanvasContext(thread, translucent, rootRenderNode, contextFactory,
                                     std::make_unique<skiapipeline::SkiaVulkanPipeline>(thread),
                                     uiThreadId, renderThreadId);
#ifndef __ANDROID__
        case RenderPipelineType::SkiaCpu:
            return new CanvasContext(thread, translucent, rootRenderNode, contextFactory,
                                     std::make_unique<skiapipeline::SkiaCpuPipeline>(thread),
                                     uiThreadId, renderThreadId);
#endif
        default:
            LOG_ALWAYS_FATAL("canvas context type %d not supported", (int32_t)renderType);
            break;
    }
    return nullptr;
}

目前官方已经全方面切换到Vulkan库，那我们就以Vulkan库继续分析。那么上文中的mRenderPipeline->draw()函数实际就是SkiaVulkanPipeline->draw()函数调用，draw()函数中调用到父类SkiaGpuPipeline的父类SkiaPipeline的renderFrame()函数mark1:下方寻找SkCanvas实例时机时返回到这里，然后继续调到SkiaPipeline->renderFrameImpl()函数。这个函数里调用RenderNodeDrawable的基类SkDrawable->draw()函数，draw()函数又调到子类RenderNodeDrawable->onDraw()函数；

渲染线程阶段时序图1

接着继续调到RenderNodeDrawable->forceDraw()函数再到drawContent()函数，函数调用SkiaDisplaylist->draw()函数，draw()函数委托给DisplayListData->draw()函数，DisplayListData的定义在RecordingCanvas.h文件中，实现在RecordingCanvas.cpp文件中，也就是DisplayListData->draw()在RecordingCanvas.cpp的DisplayListData::draw()函数。

 void DisplayListData::draw(SkCanvas* canvas) const {
     SkAutoCanvasRestore acr(canvas, false);
     this->map(draw_fns, canvas, canvas->getTotalMatrix());
 }

inline void DisplayListData::map(const Fn fns[], Args... args) const {
     auto end = fBytes.get() + fUsed;
     for (const uint8_t* ptr = fBytes.get(); ptr < end;) {
         auto op = (const Op*)ptr;
         auto type = op->type;
         auto skip = op->skip;
         if (auto fn = fns[type]) {  // We replace no-op functions with nullptrs
             fn(op, args...);        // to avoid the overhead of a pointless call.
         }
         ptr += skip;
     }
 }

作为一个Java开发者，这代码看过去可能会一脸懵。别急让我们来稍微拆解下代码，首先看：【this->map(draw_fns, canvas, canvas->getTotalMatrix());】这一行，调用map函数时传入的draw_fns是啥？

#define X(T) \ 
    [](const void* op, SkCanvas* c, const SkMatrix& original) { \ 
        ((const T*)op)->draw(c, original); \ 
    }, 
static const draw_fn draw_fns[] = { 
    #include "DisplayListOps.in" 
}; 
#undef X 

这是C++中的一个X宏（X Macro）技术，为了避免造成更多的困惑不再细讲，便于Java开发者理解可粗略的认为draw_fns就是一个数组，里面存储了绘制相关的操作类型函数指针，具体存储了哪些操作，定义在DisplayListOps.in文件中：

X(Save)
X(Restore)
X(SaveLayer)
X(SaveBehind)
X(Concat)
X(SetMatrix)
X(Scale)
X(Translate)
X(ClipPath)
X(ClipRect)
X(ClipRRect)
X(ClipRegion)
X(ClipShader)
X(ResetClip)
X(DrawPaint)
X(DrawBehind)
X(DrawPath)
X(DrawRect)
X(DrawRegion)
X(DrawOval)
X(DrawArc)
X(DrawRRect)
X(DrawDRRect)
X(DrawAnnotation)
X(DrawDrawable)
X(DrawPicture)
X(DrawImage)
X(DrawImageRect)
X(DrawImageLattice)
X(DrawTextBlob)
X(DrawPatch)
X(DrawPoints)
X(DrawVertices)
X(DrawAtlas)
X(DrawShadowRec)
X(DrawVectorDrawable)
X(DrawRippleDrawable)
X(DrawWebView)
X(DrawSkMesh)
X(DrawMesh)

回到map()函数中，结合上面的分析可以理解为fBytes.get()是DisplayList绘图指令的内存地址块的首地址，然后不断遍历这块内存取出指令，根据指令的type，结合fns[]函数指针数组，匹配到指令对应的函数指针然后调用对应的函数，我们这里以DrawPath()为例，回到RecordingCanvas.cpp文件中，根据宏定义会调用【((const T*)op)->draw(c, original)】，对应到：

struct DrawPath final : Op {
    static const auto kType = Type::DrawPath;
    DrawPath(const SkPath& path, const SkPaint& paint) : path(path), paint(paint) {}
    SkPath path;
    SkPaint paint;
    void draw(SkCanvas* c, const SkMatrix&) const { c->drawPath(path, paint); }
};

然后调到SkCanvas->drawPath(),函数里继续调用onDrawPath()函数：

 void SkCanvas::onDrawPath(const SkPath& path, const SkPaint& paint) {
     if (!path.isFinite()) {
         return;
     }

     const SkRect& pathBounds = path.getBounds();
     if (!path.isInverseFillType() && this->internalQuickReject(pathBounds, paint)) {
         return;
     }
     if (path.isInverseFillType() && pathBounds.width() <= 0 && pathBounds.height() <= 0) {
         this->internalDrawPaint(paint);
         return;
     }

     auto layer = this->aboutToDraw(paint, path.isInverseFillType() ? nullptr : &pathBounds);
     if (layer) {
         this->topDevice()->drawPath(path, layer->paint(), false);
     }
 }

关键的一行：this->topDevice()->drawPath(path, layer->paint(), false); mark0那么topDevice()获取到的设备是什么呢？代码跟到这里，我们心中是否有个疑问，从开始渲染的时候选择Vulkan渲染管线进行渲染，怎么跳来跳去都是在Skia库中呢？Vulkan不是要直接转换GPU命令的吗？在哪里去转的？

所以我们回到选择Vulkan渲染管线的代码的前面，先回到标注为mark1的位置SkiaPipeline的renderFrame()函数：

void SkiaPipeline::renderFrame() {
    bool previousSkpEnabled = Properties::skpCaptureEnabled;
    if (mPictureCapturedCallback) {
        Properties::skpCaptureEnabled = true;
    }

    // Initialize the canvas for the current frame, that might be a recording canvas if SKP
    // capture is enabled.
    SkCanvas* canvas = tryCapture(surface.get(), nodes[0].get(), layers);

    // draw all layers up front
    renderLayersImpl(layers, opaque);

    renderFrameImpl(clip, nodes, opaque, contentDrawBounds, canvas, preTransform);

    endCapture(surface.get());

    if (CC_UNLIKELY(Properties::debugOverdraw)) {
        renderOverdraw(clip, nodes, contentDrawBounds, surface, preTransform);
    }

    Properties::skpCaptureEnabled = previousSkpEnabled;
}

我们找到canvas是怎么得到的tryCapture(surface.get(), nodes[0].get(), layers);mark2这个函数也就是通过surface中获取的，那么surface是怎么实例化的？

再往上回到SkiaVulkanPipeline->draw()函数中，

IRenderPipeline::DrawResult SkiaVulkanPipeline::draw(
        const Frame& frame, const SkRect& screenDirty, const SkRect& dirty,
        const LightGeometry& lightGeometry, LayerUpdateQueue* layerUpdateQueue,
        const Rect& contentDrawBounds, bool opaque, const LightInfo& lightInfo,
        const std::vector<sp<RenderNode>>& renderNodes, FrameInfoVisualizer* profiler,
        const HardwareBufferRenderParams& bufferParams, std::mutex& profilerLock) {
    sk_sp<SkSurface> backBuffer;
    SkMatrix preTransform;
    if (mHardwareBuffer) {
        backBuffer = getBufferSkSurface(bufferParams);
        preTransform = bufferParams.getTransform();
    } else {
        backBuffer = mVkSurface->getCurrentSkSurface();
        preTransform = mVkSurface->getCurrentPreTransform();
    } 

    ...

    renderFrame(*layerUpdateQueue, dirty, renderNodes, opaque, contentDrawBounds, backBuffer,
                preTransform);

    ...

    return {true, drawResult.submissionTime, std::move(drawResult.presentFence)};
}

省略了其他的干扰代码，backBuffer = getBufferSkSurface(bufferParams); 这一行是获取SkSurface的，我们一直将代码跟进去，这里省略了，有兴趣的同学自行去跟下源码，跳转实在是太多了。最终跳到SkSurface_Ganesh.cpp类中：

sk_sp<SkSurface> WrapBackendTexture() {
    ...
    auto device = rContext->priv().createDevice(grColorType,
                                                std::move(proxy),
                                                std::move(colorSpace),
                                                origin,
                                                SkSurfacePropsCopyOrDefault(props),
                                                skgpu::ganesh::Device::InitContents::kUninit);
    ...

    return sk_make_sp<SkSurface_Ganesh>(std::move(device));
}

可以看到device实例的创建代码了，继续跟进调进了GrRecordingContextPriv.cpp这个类：

sk_sp<skgpu::ganesh::Device> GrRecordingContextPriv::createDevice() {
    return skgpu::ganesh::Device::Make(this->context(),
                                       budgeted,
                                       ii,
                                       fit,
                                       sampleCount,
                                       mipmapped,
                                       isProtected,
                                       origin,
                                       props,
                                       init);
}

可以看到是创建skgpu::ganesh::Device实例，让我们再回到SkCanvas.cpp中的onDrawPath()函数中的this->topDevice()->drawPath(path, layer->paint(), false);这里的device和topDevice是不是同一个东西呢？

topDevice()函数中是通过fMCRec->fDevice返回，fMCRec的实例是在SkCanvas->init()函数中实例化的：

void SkCanvas::init(sk_sp<SkDevice> device) {
    ...

    fMCRec = new (fMCStack.push_back()) MCRec(device.get());

    ...
}

而init()函数是在SkCanvas的构造函数中调用的，这里又回到上面mark2的位置，SkCanvas的获得过程SkiaPipeLine->tryCapture()函数中，通过surface->getCanvas()获得canvas,一直调到SkSurface_Base.h中定义的onNewCanvas()函数，这个是基类，实现类也就回到了上面的surface的创建过程的分析过程知道为SkSurface_Ganesh.cpp文件，

我们看里面的onNewCanvas()函数的实现，里面的device就是在SkSurface_Ganesh的构造函数中传入的，也就是我们WrapBackendTexture()函数中创建的device，到这里终于闭环了，所以topDevice()就是skgpu::ganesh::Device实例，

那么继续skgpu::ganesh::Device->drawPath()，然后调到SurfaceDrawContext->drawPath();因为调用过程比较多，这里省略部分调用链，一直到获得一个适合的Renderer进行渲染，这里我们以画虚线为例，使用DashLinePathRenderer.cpp->onDrawPath()函数：

bool DashLinePathRenderer::onDrawPath(const DrawPathArgs& args) {

    ...
    GrOp::Owner op = DashOp::MakeDashLineOp(args.fContext, std::move(args.fPaint),
                                            *args.fViewMatrix, pts, aaMode, args.fShape->style(),
                                            args.fUserStencilSettings);
    if (!op) {
        return false;
    }
    args.fSurfaceDrawContext->addDrawOp(args.fClip, std::move(op));
    return true;
}

这里将绘制指令封装在DashOp中。至此本阶段过程分析完成。

渲染线程阶段时序图2

3、提交的GPU操作命令

接上面生成的命令封装实例后，调用：

args.fSurfaceDrawContext->addDrawOp(args.fClip, std::move(op));

看方法名猜测是将封装的操作加到什么地方去，我们继续跟踪代码，即SurfaceDrawContex->addDrawOp函数中，

void SurfaceDrawContext::addDrawOp(const GrClip* clip,
                                   GrOp::Owner op,
                                   const std::function<WillAddOpFn>& willAddFn) {
    ...
    opsTask->addDrawOp(this->drawingManager(), std::move(op), drawNeedsMSAA, analysis,std::move(appliedClip), dstProxyView,GrTextureResolveManager(this->drawingManager()), *this->caps());
    ...

}

是通过调用OpsTask->addDrawOp()函数进行添加的，addDrawOp函数中调用recordOp()函数将操作指令记录到操作链OpChains中（包含一些合并优化操作，减少GPU命令的数量），等待flush指令执行任务OpsTask的onExcute函数，flush发生的时机可能有以下几个：

自动触发：AutoCheckFlush析构函数，资源压力检测，帧缓冲区交换前

手动触发：SkSurface::flush()，GrContext::flush()，显示API调用

当GrDrawingManager->flush()函数被调用，函数里调用GrRenderTask->execute()函数，实际调用的是其实现类OpsTask->onExecute()函数：

bool OpsTask::onExecute(GrOpFlushState* flushState) {

    const GrCaps& caps = *flushState->gpu()->caps();
    GrRenderTarget* renderTarget = proxy->peekRenderTarget();
    SkASSERT(renderTarget);

    // 创建渲染通道
    GrOpsRenderPass* renderPass = create_render_pass(flushState->gpu(),
                                                     proxy->peekRenderTarget(),
                                                     fUsesMSAASurface,
                                                     stencil,
                                                     fTargetOrigin,
                                                     fClippedContentBounds,
                                                     fColorLoadOp,
                                                     fLoadClearColor,
                                                     stencilLoadOp,
                                                     stencilStoreOp,
                                                     fSampledProxies,
                                                     fRenderPassXferBarriers);

    flushState->setOpsRenderPass(renderPass);
    renderPass->begin();

    GrSurfaceProxyView dstView(sk_ref_sp(this->target(0)), fTargetOrigin, fTargetSwizzle);

    // Draw all the generated geometry.
    for (const auto& chain : fOpChains) {
        if (!chain.shouldExecute()) {
            continue;
        }

        GrOpFlushState::OpArgs opArgs(chain.head(),
                                      dstView,
                                      fUsesMSAASurface,
                                      chain.appliedClip(),
                                      chain.dstProxyView(),
                                      fRenderPassXferBarriers,
                                      fColorLoadOp);

        flushState->setOpArgs(&opArgs);
        // 遍历指令将其转换成GPU指令
        chain.head()->execute(flushState, chain.bounds());
        flushState->setOpArgs(nullptr);
    }

    renderPass->end();

    // 提交给GPU执行指令
    flushState->gpu()->submit(renderPass);
    flushState->setOpsRenderPass(nullptr);

    return true;
}

chain.head()->execute(flushState, chain.bounds());这一行将按画虚线为例会调到DashOpImpl->onExecute()函数：

    void onExecute(GrOpFlushState* flushState, const SkRect& chainBounds) override {
        if (!fProgramInfo || !fMesh) {
            return;
        }

        flushState->bindPipelineAndScissorClip(*fProgramInfo, chainBounds);
        flushState->bindTextures(fProgramInfo->geomProc(), nullptr, fProgramInfo->pipeline());
        flushState->drawMesh(*fMesh);
    }

onExecute函数中调用flushState->drawMesh()函数，然后一直调用到GrVkOpsRenderPass.cpp->onDraw()函数，继续调用到GrVkCommandBuffer.cpp->draw()函数生成Vulkan 的GPU命令，然后回到OpsTask->onExecute()这个函数继续往下看，通过flushState->gpu()->submit(renderPass);提交到GPU中执行渲染命令。剩下的就交给GPU去执行命令绘制像素了。

叁

总结与展望

Android通过分层抽象，在兼容性与性能间取得完美平衡。每层只需关注相邻接口，使Vulkan等新技术可无缝接入现有架构。Vulkan通过瓦解GPU驱动瓶颈，将CPU渲染开销从15ms压缩至3ms，释放出12ms/帧的GPU算力空间：

  1. 1.

    指令编译革命

  • •

    DisplayList → SPIR-V中间指令（预编译避免运行时解析）

  • •

    对比OpenGL：减少80%驱动层校验指令

  • 2.

    并行化引擎

    • •

      OpsTask.onExecute()实现OpChain多核分发

    • •

      渲染通道(RenderPass)无锁提交使DrawCall并发量提升8倍

  • 3.

    零拷贝控制

    • •

      GrVkCommandBuffer直接操作设备内存

    • •

      消除OpenGL的显存二次拷贝（省去3ms/帧）

    现代图形架构的核心矛盾是绘制复杂度与帧时间确定性的对抗。Android的解法是：将非确定操作提前（指令编译），将确定操作并发（管线并行），最终驯服GPU这头性能猛兽。

    此刻我们正站在渲染技术的奇点：当Vulkan封印揭开，帧率已不是终点，而是重构视觉体验的起点。未来会有哪些期待？

    • DisplayList预测生成（LSTM模型预判下帧指令）？

    • 将Path计算卸载到DSP处理（节省GPU 30%负载）？

    • 实时光追管线（Vulkan Ray-Tracing扩展）？

    点赞+关注，下一期更精彩！

    本文分析源码基于最新的AOSP：https://cs.android.com/android/platform/superproject?hl=zh-cn

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/news/919185.shtml
繁体地址，请注明出处：http://hk.pswp.cn/news/919185.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

HTTP 请求转发与重定向详解及其应用（含 Java 示例）

HTTP 请求转发与重定向详解及其应用（含 Java 示例）

在 Web 开发中&#xff0c;我们经常需要在不同页面之间跳转&#xff0c;比如登录成功后跳到首页、提交表单后跳到结果页面。这时&#xff0c;常见的两种跳转方式就是 请求转发&#xff08;Request Forward&#xff09; 和 重定向&#xff08;Redirect&#xff09;。虽然它们都能…
阅读更多...
如何将 MCP Server （FastMCP） 配置为公网访问（监听 0.0.0.0）

如何将 MCP Server （FastMCP） 配置为公网访问（监听 0.0.0.0）

如何将 MCP Server &#xff08;FastMCP&#xff09; 配置为公网访问&#xff08;监听 0.0.0.0&#xff09;引言常见错误尝试根本原因&#xff1a;从源码解析正确的解决方案总结引言 在使用 Model Context Protocol(MCP) 框架开发自定义工具服务器时&#xff0c;我们经常使用 …
阅读更多...
The Network Link Layer: 无线传感器中Delay Tolerant Networks – DTNs 延迟容忍网络

The Network Link Layer: 无线传感器中Delay Tolerant Networks – DTNs 延迟容忍网络

Delay Tolerant Networks – DTNs 延迟容忍网络架构归属Delay Tolerant Networks – DTNs 延迟容忍网络应用实例例子 1&#xff1a;瑞典北部的萨米人 (Saami reindeer herders)例子 2&#xff1a;太平洋中的动物传感网络DTNs路由方式——存储&转发DTNs移动模型Random walk …
阅读更多...
计算机视觉（opencv）实战二——图像边界扩展cv2.copyMakeBorder()

计算机视觉（opencv）实战二——图像边界扩展cv2.copyMakeBorder()

OpenCV copyMakeBorder() 图像边界扩展详解与实战在图像处理和计算机视觉中&#xff0c;有时需要在原始图像的四周增加边界&#xff08;Padding&#xff09;。这种操作在很多场景中都有应用&#xff0c;比如&#xff1a;卷积神经网络&#xff08;CNN&#xff09;中的图像预处理…
阅读更多...
ansible管理变量和事实

ansible管理变量和事实

ansible管理变量和事实与实施任务控制 在 Ansible 中&#xff0c;变量和事实&#xff08;Facts&#xff09;就像给剧本&#xff08;Playbook&#xff09;配备的 “信息工具箱”&#xff0c;让你的自动化配置管理更灵活、更智能。 变量&#xff1a;提前准备的 “预设信息” 变…
阅读更多...
STM32--寄存器与标准库函数--基本定时器

STM32--寄存器与标准库函数--基本定时器

目录 前言 基本定时器概念 定时时间 定时器时钟确定 倍频锁相环被正确配置为168MHz 定时器的库函数操作 代码 定时器的寄存器操作 代码 寄存器 后言 前言 使用平台:STM32F407ZET6 使用数据手册&#xff1a;STM32F407数据手册.pdf 使用参考手册&…
阅读更多...
PCA 实现多向量压缩：首个主成分的深层意义

PCA 实现多向量压缩：首个主成分的深层意义

PCA 实现多向量压缩 第一个主成分（components_[0]）正是数据协方差矩阵中最大特征值对应的特征向量。 ，layer_attention_vector[layer] 被赋值为 pca.components_[0]，这确实是一个特征向量，具体来说是 PCA 分解得到的第一个主成分（主特征向量）。 关于它的维度： 假设 c…
阅读更多...
网络常识-DNS如何解析

网络常识-DNS如何解析

DNS&#xff08;Domain Name System&#xff0c;域名系统&#xff09;是互联网的“地址簿”&#xff0c;负责将人类易记的域名&#xff08;如www.example.com&#xff09;转换为计算机可识别的IP地址&#xff08;如192.168.1.1&#xff09;。其工作流程可以简单理解为“从域名到…
阅读更多...
Java中 23 种设计模式介绍，附带示例

Java中 23 种设计模式介绍，附带示例

文章目录设计模式六大原则设计模式分类1、创建型模式&#xff08;Creational Patterns&#xff09;2、结构型模式&#xff08;Structural Patterns&#xff09;3、行为型模式&#xff08;Behavioral Patterns&#xff09;一、创建型模式&#xff08;Creational Patterns&#x…
阅读更多...
嵌入式开发入门——电子元器件~电磁继电器、蜂鸣器

嵌入式开发入门——电子元器件~电磁继电器、蜂鸣器

文章目录电磁继电器定义关键参数实物蜂鸣器实物内部结构分类关键参数电磁继电器 定义 概述&#xff1a;电磁继电器是利用电磁感应原理职称的一种电磁开关&#xff0c;他能通过&#xff1a;低电压、低电流的电路&#xff0c;来控制高电压、高电流的电路。 关键参数 线圈电压…
阅读更多...
ROS2基础

ROS2基础

1.helloworld案例1.创建功能包&#xff08;C&#xff09;终端下&#xff0c;进入ws00_helloworld/src目录&#xff0c;使用如下指令创建一个C 功能包:ros2 pkg create pkg01_helloworld_cpp --build-type ament_cmake --dependencies rclcpp --node-name helloworld执行完毕&a…
阅读更多...
Python爬虫实战：研究pygalmesh，构建Thingiverse平台三维网格数据处理系统

Python爬虫实战：研究pygalmesh，构建Thingiverse平台三维网格数据处理系统

1. 引言 1.1 研究背景 在数字化浪潮席卷全球的当下，三维建模技术已成为连接虚拟与现实的核心纽带，广泛渗透于工程设计、地理信息系统（GIS）、虚拟现实（VR）、增强现实（AR）、医学影像等关键领域。例如，在建筑工程中，BIM（建筑信息模型）技术依赖高精度三维网格实现施工…
阅读更多...
开发者说 | EmbodiedGen：为具身智能打造可交互3D世界生成引擎

开发者说 | EmbodiedGen：为具身智能打造可交互3D世界生成引擎

概述 具身智能的发展离不开高质量、多样化的可交互3D仿真环境。为突破传统构建方式的瓶颈&#xff0c;我们提出了EmbodiedGen&#xff0c;一个基于生成式AI技术的自动化3D世界生成引擎&#xff0c;助力低成本、高效率地创建真实且可交互的3D场景。用户仅需输入任务定义或场景图…
阅读更多...
GitHub Copilot：AI编程助手的架构演进与真实世界影响

GitHub Copilot：AI编程助手的架构演进与真实世界影响

本文由「大千AI助手」原创发布&#xff0c;专注用真话讲AI&#xff0c;回归技术本质。拒绝神话或妖魔化。搜索「大千AI助手」关注我&#xff0c;一起撕掉过度包装&#xff0c;学习真实的AI技术&#xff01; 1. 技术背景与核心架构 GitHub Copilot 是由 GitHub 与 OpenAI 联合开…
阅读更多...
PDF OCR + 大模型：让文档理解不止停留在识字

PDF OCR + 大模型：让文档理解不止停留在识字

在企业数字化的实际场景中&#xff0c;PDF OCR 已经很普遍了&#xff1a;从扫描件提取文本、表格到生成可搜索 PDF。但这类技术往往停留在"把图片变成文字"&#xff0c;对文档背后的语义、逻辑、业务价值理解不足。 而当 OCR 遇上大语言模型&#xff08;LLM&#xff…
阅读更多...
半敏捷卫星观测调度系统的设计与实现

半敏捷卫星观测调度系统的设计与实现

半敏捷卫星观测调度系统的设计与实现 摘要 本文详细阐述了一个基于Python的半敏捷卫星观测调度系统的设计与实现过程。系统针对半敏捷卫星特有的机动能力限制&#xff0c;综合考虑了地面目标观测需求、卫星资源约束、能源管理等多重因素&#xff0c;提出了一种混合启发式算法解…
阅读更多...
软件测试中，常用的抓包工具有哪些？抓包的原理是什么？

软件测试中，常用的抓包工具有哪些？抓包的原理是什么？

回答重点在软件测试中&#xff0c;常用的抓包工具主要有&#xff1a;1&#xff09;Fiddler2&#xff09;Wireshark3&#xff09;Charles4&#xff09;Postman&#xff08;它的拦截器功能也可以用于抓包&#xff09;5&#xff09;tcpdump抓包的原理大致是通过安装在本地的抓包工…
阅读更多...
Cesium学习（二）-地形可视化处理

Cesium学习（二）-地形可视化处理

Cesium地形可视化是其核心功能之一&#xff0c;允许开发者在3D地球中展示真实的地形数据。以下是关于Cesium地形可视化的详细处理方法&#xff1a; 文章目录1. 启用地形可视化基本地形加载自定义地形提供者2. 地形相关操作地形高度采样地形夸张效果3. 地形可视化设置地形照明效…
阅读更多...
《告别 if-else 迷宫：Python 策略模式 (Strategy Pattern) 的优雅之道》

《告别 if-else 迷宫：Python 策略模式 (Strategy Pattern) 的优雅之道》

《告别 if-else 迷宫：Python 策略模式 (Strategy Pattern) 的优雅之道》 大家好，我是你的朋友，一位与 Python 代码相伴多年的开发者。在我们的编程生涯中，几乎都曾与一种“代码怪兽”搏斗过，它就是那冗长、复杂、牵一发而动全身的 if-elif-else 结构。 每当一个新的需求…
阅读更多...
Redis--day7--黑马点评--优惠券秒杀

Redis--day7--黑马点评--优惠券秒杀

&#xff08;以下内容全部来自上述课程&#xff09;优惠券秒杀 1. 全局唯一ID 每个店铺都可以发布优惠券:当用户抢购时&#xff0c;就会生成订单并保存到tb voucher order这张表中&#xff0c;而订单表如果使用数据库自增ID就存在一些问题: id的规律性太明显受单表数据量的限制…
阅读更多...
最新文章

Copyright @ 2022~2023