漫谈HBuilderX App-Jenkins热更新构建

漫谈Uniapp App热更新包-Jenkins CI/CD打包工具链的搭建

零、写在前面

HBuilderX是DCloud旗下的IDE产品，目前只提供了Windows和Mac版本使用。本项目组在开发阶段经常需要向测试环境提交热更新包，使用Jenkins进行CD是非常有必要的一步。尽管HBuilderX提供了CLI，但Jenkins服务通常都是搭建在Linux环境下的。当前的Uniapp wgt打包服务是使用了Windows Server + HBuilderX CLI的解决方案来进行打包，再用Jenkins远程调用接口。这套方案的弊病有如下几点：

  • Jenkins侧仅负责少量参数的传递，如项目名、Git repo地址、分支名等，大部分流程不受控制，流水线的构建阶段显示不透明。
  • 核心由一个shell script和一个python脚本实现，代码逻辑存在一定重复，维护难度也比较高。
  • 从Git更新代码的流程耗费较长时间，因为每次执行流水线都要删除掉本地的repo并重新拉取。这对于带宽只有个位数的公网测试服务器来说是致命的，每次构建花费在此步的时间就有2分钟以上。
  • 后端平台侧获取的Token没有缓存，即使打包提速了也会受到验证码获取1分钟节流的限制。
  • Windows服务器上运行的HBuilderX经常出现登录态失效或启动打包任务失败的情况，测试在Jenkins侧只能得到简单的任务失败提示。而且这个提示是出现在Git拉取代码之后的，意味着每次失败前都要干等2分钟。

为了避免服务器资源的浪费，节省不必要的维护开支，我决定在等待测试的gap期研究一下这套流程的优（chong）化（gou）。

一、初次优化-Windows下脱离HBuilderX主程序

打包指令提取

首先从Windows端下手，先打开HBuilderX并登录账号，正常打一个wgt包。在打包前使用DebugView来查看HBuilderX执行任务时的输出，这是一款用于捕获Windows桌面系统程序中由TRACE和OutputDebugString输出的信息的工具。抓取到的有效日志如下：

[16764] 2023-05-16 09:50:20.583 [INFO:] node "D:/HBuilderX/plugins/node/node.exe"
[16764] 2023-05-16 09:50:20.583 [INFO:] args ("--max-old-space-size=2048", "--no-warnings", "D:/HBuilderX/plugins/uniapp-cli-vite/node_modules/@dcloudio/vite-plugin-uni/bin/uni.js")

盘一下uni.js

require('../dist/cli/index.js')

可以看到备注很完善的函数cli，这证明Uniapp打包使用的工具就是由node构建的，原则上来说可以不受系统平台的限制，移植到Linux上使用是没有问题的。至于HBuilderX软件本体就是Qt写的一个壳子，只要剖析整个打包流程就可以脱离HBuilderX本体了。

cli.command('build').option('--outDir <dir>', `[string] output directory (default: dist)`).option('--assetsInlineLimit <number>', `[number] static asset base64 inline threshold in bytes (default: 4096)`).option('--sourcemap', `[boolean] output source maps for build (default: false)`).option('--manifest', `[boolean] emit build manifest json`).option('--ssrManifest', `[boolean] emit ssr manifest json`).option('--emptyOutDir', `[boolean] force empty outDir when it's outside of root`, {default: true,
}).option('-w, --watch', `[boolean] rebuilds when modules have changed on disk`).action(action_1.runBuild);

根据参数表整理一下调用命令：

node --max-old-space-size=2048 --no-warnings "D:/HBuilderX/plugins/uniapp-cli-vite/node_modules/@dcloudio/vite-plugin-uni/bin/uni.js" build --platform app --outDir "D:/test/crp-app-dist"

直接执行上述命令是不行的，因为uniapp的node_modules下根本就没有编译该工程所需的各种依赖，并且缺少很多环境变量。具体逻辑在uniapp-cli-vite/node_modules/@dcloudio/vite-plugin-uni的/dist/cli/build.js和/dist/index.js中都有所表现。

显而易见的是，我们的工程目录下（非cli模式）根本就没有vue、pinia之类的包，那么上面的命令是如何确定工作目录（工程目录）和其它依赖所在地的呢？先说其它依赖的问题，分析plugins目录可以看到HBuilderX自带了一套node和npm，那么去看一下npm的脚本（在Windows版本叫做npm.cmd）：

#!/bin/sh
(set -o igncr) 2>/dev/null && set -o igncr; # cygwin encoding fix
basepath=$(cd `dirname $0`; pwd)
plugin_dir=$(dirname $basepath)which "node" >/dev/null 2>&1
if ! [ $? -eq 0 ]; thennode_Path=$plugin_dir/nodenew_path=$PATH:$node_Pathexport PATH=$new_path 
fi
$basepath/node_modules/npm/bin/npm-cli.js $@

环境变量修补

HBuilderX在打包阶段会使用自己的node和npm，我们要做的就是修补环境变量使得这些工具都能找到正确的工作目录。以下是一个使用node.js成功在Windows下脱离HbuilderX主程序调用打包的例子：

/*** @author myd*/
import {exec} from "child_process";
import * as util from "util";
import path from "path";
import os from "os";const execAsync = util.promisify(exec);
export const build = (repoName: string) => {const systemTempFolderPath = os.tmpdir();return new Promise(async (resolve, reject) => {try {const HBUILDER_DIR = "D:\\HBuilderX";const UNI_INPUT_DIR = path.join(systemTempFolderPath, repoName);const VITE_ROOT_DIR = UNI_INPUT_DIR;const UNI_HBUILDERX_PLUGINS = path.join(HBUILDER_DIR, 'plugins');const UNI_CLI_CONTEXT = path.join(UNI_HBUILDERX_PLUGINS, 'uniapp-cli-vite');const UNI_NPM_DIR = path.join(UNI_HBUILDERX_PLUGINS, 'npm');const UNI_NODE_DIR = path.join(UNI_HBUILDERX_PLUGINS, 'node');const NODE_ENV: any = 'production';const NODE = path.join(UNI_NODE_DIR, 'node');const UNI_CLI = path.join(UNI_CLI_CONTEXT, 'node_modules', '@dcloudio', 'vite-plugin-uni', 'bin', 'uni.js');const PATH_ADDONS = process.env.PATH + `;${UNI_INPUT_DIR}/node_modules/.bin;`;const childEnv = {...process.env,PATH: PATH_ADDONS,HBUILDER_DIR,UNI_INPUT_DIR,VITE_ROOT_DIR,UNI_CLI_CONTEXT,UNI_HBUILDERX_PLUGINS,UNI_NPM_DIR,UNI_NODE_DIR,NODE_ENV,NODE};process.chdir(UNI_CLI_CONTEXT);const buildCommand = `"${NODE}" --max-old-space-size=2048 --no-warnings "${UNI_CLI}" build --platform app --outDir ${path.join(systemTempFolderPath, repoName + '-dist')}`const {stdout, stderr} = await execAsync(buildCommand, {env: {...childEnv}});console.error('stderr:', stderr);resolve(1)} catch (error) {console.error('Error during build:', error);reject(0)}})
}

产物是一个文件夹，把这个文件夹以zip格式压缩后，将后缀重命名为wgt即可。

做到这一步后，我就用Next.js写了一个简单的GUI，并配合一系列辅助逻辑完成了beta版的新构建平台，部署到先前的Windows服务器上提供给同事进行测试。这样做的目的主要是为了验证以上工作的正确性和稳定性，还可以从反馈意见中思考一下我对于该流程的重构设想是否正确，还有哪些点没有考虑到。

二、第二次优化-移植到Linux上并集成回Jenkins

思考

首先明确一点，这件事本身就是一个内部需求的解决方案延伸，闭门造车是不可取的。当做出一个阶段性的工作后，立刻部署demo并持续收集同事的反馈意见，及时调整，这样才能避免后续的更多问题，因为最终用户不止是我本人，还有所有参与项目的其他同事。软件的易用性和稳定性同样重要，必须在正式部署前反复地进行预先测试才能推行使用。

在测试了一天后，同事认为打包速度大大提高，但简陋的web控制台不能同时执行多个打包任务，打包期间不能刷新或离开页面也是硬伤。当时我还没有想好如何把这套代码搬到Linux上跑，因为这涉及HBuilderX的平台差异问题。将这套代码的构建核心抽出来集成回Jenkins是最佳选择，但我当时是有一些偷懒的想法的，因为这套轮子也同样提供了工程选择、Git同步的处理逻辑等，已经解决了上面的大部分痛点。但轮子毕竟是轮子，最终我还是决定放弃推行自己的平台给大家使用的想法，而是以这个平台作为测试工具，在此之上研究将HBuilderX的打包器迁移到Linux上的方法。

uniapp-cli-vite承担了大部分打包功能，按理说它作为一个node包本来是不挑系统的。但我陷入了思维上的误区，一定要迁移node和npm再给plugins搬家。实际上只要node环境隔离得当，只迁移npm即可。而对于npm来说，Linux和Windows的npm结构差异较大，但几乎可以直接使用macOS的包。所以迁移工作我选择在macOS平台下研究。

编写脚本&部署

明确一下思路，只要在macOS下写一个接受工程目录的路径、打包产物的路径和HBuilderX plugins的路径，输出打包产物的脚本并测试成功，那么就算成功了80%了。把上面的node函数用GPT转成sh脚本，自己再微调一下：

#!/bin/bash# HBuilder目录修改此处
HBUILDER_DIR=/root/HBuilderX
NODE_ENV=production
repoDir=$1
# 导出目录修改此处
distExportDir=$2
# Nodejs修改此处
NODE=/root/HBuilderX/plugins/node/nodeUNI_INPUT_DIR="$repoDir"
VITE_ROOT_DIR="$UNI_INPUT_DIR"
UNI_HBUILDERX_PLUGINS="$HBUILDER_DIR/plugins"
UNI_CLI_CONTEXT="$UNI_HBUILDERX_PLUGINS/uniapp-cli-vite"
UNI_NPM_DIR="$UNI_HBUILDERX_PLUGINS/npm"
UNI_NODE_DIR="$UNI_HBUILDERX_PLUGINS/node"
UNI_CLI="$UNI_CLI_CONTEXT/node_modules/@dcloudio/vite-plugin-uni/bin/uni.js"export HBUILDER_DIR
export UNI_INPUT_DIR
export VITE_ROOT_DIR
export UNI_CLI_CONTEXT
export UNI_HBUILDERX_PLUGINS
export UNI_NPM_DIR
export UNI_NODE_DIR
export NODE_ENV
export NODE
export PATH="$PATH:$UNI_INPUT_DIR/node_modules/.bin"cd "$UNI_CLI_CONTEXT"
buildCommand="$NODE --max-old-space-size=2048 --no-warnings $UNI_CLI build --platform app --outDir $distExportDir/${repoDir}-dist"
eval $buildCommand
exitCode=$?
if [ $exitCode -eq 0 ]; thenecho "Build successful"exit 1
elseecho "Error during build"exit 0
fi

效果很好，先把HBuilderX的主目录打包为tar并传到Linux服务器上展开：

tar -cf ~/HbuilderX-3.9.5-darwin.tar /Applications/HBuilderX.app/Contents/HBuilderX
scp -P 22 -r ~/HbuilderX-3.9.5-darwin.tar root@192.168.1.252:/root/
tar -xf ./HbuilderX-3.9.5-darwin.tar

在macOS机器上看一下HBuilderX使用的Node版本：

myd@myddeMac-Pro ~ % /Applications/HBuilderX.app/Contents/HBuilderX/plugins/node/node -v
v16.17.0

为Linux服务器下载对应系统和架构的Node二进制包并覆盖HBuilderX所使用的node，这里以Linux-amd64-16.17.0为例：

wget https://nodejs.org/download/release/v16.17.0/node-v16.17.0-linux-x64.tar.gz
tar -xzvf ./node-v16.17.0-linux-x64.tar.gz
cp ./node-v16.17.0-linux-x64/bin/node ./HBuilderX/plugins/node
chmod +x ~/HBuilderX/plugins/node/node

更多版本可以在https://nodejs.org/download/release/查看。

公司服务器的Ubuntu 18.04缺少node 18的依赖glibc-2.28，因此需要进一步对系统环境进行修补。编译glibc-2.28：

sudo apt-get install g++ make gcc bison
apt install -y gawk
cd ~
wget -c https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.gz
tar -zxf glibc-2.28.tar.gz
cd glibc-2.28
mkdir glibc-build
cd glibc-build
../configure --prefix=/opt/glibc-2.28
make -j 6
make install
cd ~
rm -rf ./glibc-2.28 ./glibc-2.28.tar.gz
apt install -y patchelf
# 直装的node使用如下命令
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/ /usr/local/bin/node
# nvm使用如下命令
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/ /root/.nvm/versions/node/v18.18.2/bin/node
# 记得修补HBuilderX的node
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib/:/lib/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/ ~/HBuilderX/plugins/node/node

接下来修改uniapp-cli-vite的package.json

vi /root/HBuilderX/plugins/uniapp-cli-vite/package.json

删除devDependencies节点下的@esbuild/darwin-arm64、@esbuild/darwin-x64和fsevents，并安装对应目标平台的esbuild：

npm i -D -f @esbuild/linux-x64@0.17.19
npm i -f

领导非常支持这件事，抽出时间将上面的脚本集成回了Jenkins。我也将之前对于几个痛点的思考和解决方案提供了出来，至此整个wgt打包流程得到了巨大的优化，无论是速度还是稳定性。

三、第三次优化-封装Docker进行环境隔离

思考

在第二次优化的过程中，因为出了修补glibc这档子事，我意识到环境隔离非常重要。Ubuntu 18.04作为LTS版本，至今仍在广泛使用。这种不算特别老的系统尚且出现环境导致的兼容性问题，假如我要在一个使用musl库的发行版上部署，比如Alpine Linux或者Gentoo Linux的时候又该怎么办呢？

显然，解决这个问题的最好办法就是封装Docker镜像。

精简HBuilderX包

封装Docker镜像自然是产物体积越小越好。HBuilderX macOS版在安装若干打包所需依赖后，主目录膨胀到2个多G，这里的大多数文件都是用不上的。在macOS下复制一份HBuilderX主程序目录，开搞：

  • 只有plugins文件夹需要保留，HBuilderX主程序及其相关的文件完全用不上。删之。
  • plugins文件夹下的大部分包也用不上，比如为HBuilderX提供代码补全、语法检查之类的IDE所需包，或者项目中根本没有使用到的UTS相关包，统统删之。
  • 每删几个包，就执行一遍之前的sh构建脚本，将HBuilderX目录指向当前魔改的目录下，进行可用性测试。
  • 删到最后，只留下about、complie-dart-sass、node、npm、uniapp-cli-vite与node_modules这几个目录。
  • 鲁迅说过，node_modules的体积比珠穆朗玛峰还要大，结构比马里亚纳海沟还要深。提取出node_modules目录下的package.json和package-lock.json，复制到plugins目录下，再将node_modules删之。
  • 根据上文的步骤，修改一下uniapp-cli-vite的package.json。

精简以后压缩一下，原来2个多G的plugins只剩7.2M。将压缩包命名为core-3.9.5.zip备用。

Docker封装前的思考和一些选择

既然要做Docker镜像，那么Docker镜像的系统就最好选个轻量点的。Alpine Linux只有50多M，采用APK包管理器，是一个非常理想的选择。然而必须注意的是，Alpine Linux的libc实现使用的是musl而非常用的glibc。但我们既然是为了封装HBuilderX的专属镜像，那nodejs版本理应和原环境一样，也就是v16.17.0以保障兼容性，但是APK包管理器只能下载latest版本的nodejs，nodejs又依赖于glibc。从源码编译不太现实，所以这里使用多阶段构建的方法，先通过nodejs官方提供的node-alpine来获取可用的nodejs二进制文件，再进行后续的操作。

至于封装好的镜像如何使用，我的解决方案是启动一个小型的HTTP API服务。为了减少不必要的依赖，这个服务也使用node来写。服务器应该向镜像挂载一个项目文件夹，通过API调用进行打包。Git代码同步之类的操作全部交给Jenkins侧执行，Docker容器只负责最核心的打包部分——如无必要，勿增实体。

编写Dockerfile

以下是开发阶段的Dockerfile：

ARG NODE_VERSION=16.17.1
ARG ALPINE_VERSION=3.18
FROM node:${NODE_VERSION}-alpine AS node
ARG ALPINE_VERSION
FROM alpine:${ALPINE_VERSION}
ENV API_SERVER_URL=https://gitclone.com/github.com/hbuilderx-vanilla/api-server.git# Set China APK Manager Mirrors
RUN echo "https://mirrors.aliyun.com/alpine/v3.18/main/" > /etc/apk/repositories \&& echo "https://mirrors.aliyun.com/alpine/v3.18/community/" >> /etc/apk/repositories
RUN apk update && apk add --no-cache bash unzip wget git# Install node-16.17.1
COPY --from=node /usr/lib /usr/lib
COPY --from=node /usr/local/lib /usr/local/lib
COPY --from=node /usr/local/include /usr/local/include
COPY --from=node /usr/local/bin /usr/local/bin# Set China NPM Mirrors
RUN npm install -g yarn --force \ && npm config set registry https://registry.npmmirror.com# Inject HBuilderX 3.9.5 core
COPY core-3.9.5.zip /opt/
RUN unzip /opt/core-3.9.5.zip -d /opt/ \&& rm /opt/core-3.9.5.zip && mkdir /projects# Install HBuilderX core dependencies
COPY core-install.sh /root/
RUN chmod +x /root/core-install.sh
# Need manual run it if minimal version
# RUN /root/core-install.sh# Install and start api server
WORKDIR /root
RUN git clone ${API_SERVER_URL} && \cd api-server && \npm i
EXPOSE 3000
CMD [ "node","/root/api-server/index.js" ]

我把HTTP API服务单独做了一个Git仓库出来，这样方便后续扩充功能和进行bugfix。在开发环境下，一些反向代理和镜像源的设置是必不可少的。为了减少Docker镜像体积，我选择在镜像运行后再让用户手动安装HBuilderX的巨型npm依赖。

容器的部署和初始化

容器启动示例：

docker run -d --restart=always -v /<user_name>/<projects_folder>:/projects -p 13300:3000 --name hbuilder-vanilla flymyd114/hbuilderx-vanilla:latest
  • /<user_name>/<projects_folder>是本机的待打包工程父目录，你的所有工程均应处于该目录下，如/Users/myd/projects下有hello-uniapp文件夹。
  • 13300为建议的API端口映射点。

容器首次启动后，执行如下命令以初始化依赖：

docker exec -it <docker_id> /bin/sh
chmod +x /root/core-install.sh && /root/core-install.sh
exit

访问http://127.0.0.1:13300以检查API服务是否正确启动。

打包示例：

curl --location 'http://localhost:13300/build?project=crp-app'

产物将会在/projects/crp-app/wgt-dist中生成。

发布到Github上并编写workflows

可以看到，上面的容器已经被发布到了DockerHub。同样的，我也将仓库开源并编写了workflows以自动构建新版本的Docker镜像。以下是docker-build.yml：

name: Build and Push Docker imageon:push:branches:- maintags:- 'v*'paths:- 'Dockerfile'workflow_dispatch:jobs:build-and-push:runs-on: ubuntu-lateststeps:- name: Check out the repouses: actions/checkout@v2- name: Set up Docker Buildxuses: docker/setup-buildx-action@v1- name: Log in to Docker Hubuses: docker/login-action@v1with:username: ${{ secrets.DOCKER_HUB_USERNAME }}password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}- name: Extract metadata (tags, labels) for Dockerid: metauses: docker/metadata-action@v3with:images: flymyd114/hbuilderx-vanillatags: |type=semver,pattern={{version}}- name: Build and push Docker imageuses: docker/build-push-action@v2with:context: .file: ./Dockerfilepush: truetags: ${{ steps.meta.outputs.tags }}labels: ${{ steps.meta.outputs.labels }}

当main分支上的commit被打上形如v3.9.5的Tag时即可触发workflows。当然，也可以手动触发这个构建。

注意，在Github上发布的Dockerfile应该去除镜像源和反代的部分，否则构建速度反而会变慢：

ARG NODE_VERSION=16.17.1
ARG ALPINE_VERSION=3.18
FROM node:${NODE_VERSION}-alpine AS node
FROM alpine:${ALPINE_VERSION}
ENV API_SERVER_URL=https://github.com/hbuilderx-vanilla/api-server.gitRUN apk update && \apk add --no-cache bash unzip wget git && \rm -rf /var/cache/apk/*COPY --from=node /usr/lib /usr/lib
COPY --from=node /usr/local/lib /usr/local/lib
COPY --from=node /usr/local/include /usr/local/include
COPY --from=node /usr/local/bin /usr/local/bin
RUN npm install -g yarn --forceCOPY core-3.9.8.zip /opt/
RUN unzip /opt/core-3.9.8.zip -d /opt/ && \rm /opt/core-3.9.8.zip && \mkdir /projectsCOPY core-install.sh /root/
RUN chmod +x /root/core-install.sh# Need manual run it if minimal version
# RUN /root/core-install.shWORKDIR /root
RUN git clone ${API_SERVER_URL} && \cd api-server && \npm i
EXPOSE 3000
CMD [ "node","/root/api-server/index.js" ]

后续的版本升级

公司的项目目前统一使用HBuilderX 3.9.5的基座。但随着未来的升级，我们也需要及时更新打包核心以兼容高版本基座。天下没有不散的筵席，这篇文章既是我对这项工作的一个总结归纳，也是为后来人提供一个维护的文档和应对版本改变的思路。对于plugins文件夹下的依赖来说，我们只需要在一台电脑上将HBuilderX升级到想要的版本，然后提取里面的package.json进行依赖版本的替换就好。通常来说，要更新的package.json涉及about、uniapp-cli-vite和根目录。更新后重新将plugins放到core文件夹下打包，同步修改Dockerfile内的zip名即可。

以3.9.5升级至3.9.8举例，修改core/plugins内的如下文件：

about/package.json
uniapp-cli-vite/package.json
package.json

然后压缩core文件夹，重命名为core-3.9.8.zip。修改Dockerfile：

COPY core-3.9.8.zip /opt/
RUN unzip /opt/core-3.9.8.zip -d /opt/ && \rm /opt/core-3.9.8.zip && \mkdir /projects

Github项目地址

Docker项目：https://github.com/hbuilderx-vanilla/docker

API项目：https://github.com/hbuilderx-vanilla/api-server

联系我

邮箱：flymyd@foxmail.com

或在上方项目处提issue，@flymyd

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

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

相关文章

python pyaudio给数据加噪声

python pyaudio给数据加噪声

python pyaudio给数据加噪声 # -*- coding: utf-8 -*- import argparse import array import math import numpy import numpy as np import random import wavedef get_args():parser argparse.ArgumentParser()parser.add_argument("--clean_file", typestr, req…
阅读更多...
cordova详解

cordova详解

从八个方面让你快速了解cordova&#xff08;一&#xff09; - 掘金 从八个方面让你快速了解cordova&#xff08;二&#xff09; - 掘金 Cordova和React-Native两种框架的区别和优劣分析_cordova和react native-CSDN博客 Cordova开发App的优缺点是什么&#xff1f; - 咕噜企业…
阅读更多...
开源CDN软件GoEdge —— 筑梦之路

开源CDN软件GoEdge —— 筑梦之路

官方网站&#xff1a;GoEdge CDN - 制作自己的CDN - GoEdge CDN | 自建CDN GoEdge是一款管理分布式CDN边缘节点的开源工具软件&#xff0c;目的是让用户轻松地、低成本地创建CDN/WAF等应用。 特性 免费 - 开源、免费、自由、开放 简单 - 架构简单清晰&#xff0c;安装简单&a…
阅读更多...
Android，JNI开发和NDK之间的联系

Android，JNI开发和NDK之间的联系

Android&#xff0c;JNI开发和NDK。 1.jni和ndk jni是在jdk中就有出现的 在我们jdk路径中 D:\java\jdk11\include 这就是jdk中的jni Android开发环境中的ndk也有jni&#xff0c; D:\Android\sdk\ndk\20.0.5594570\toolchains\llvm\prebuilt\windows-x86_64\sysroot\usr\in…
阅读更多...
DICE模型原理

DICE模型原理

随着温室气体排放量的增大和温室效应的增强&#xff0c;全球气候变化问题受到日益的关注。我国政府庄严承诺在2030和2060年分别达到“碳达峰”和“碳中和”&#xff0c;因此气候变化和碳排放已经成为科研人员重点关心的问题之一。气候变化问题不仅仅是科学的问题&#xff0c;同…
阅读更多...
Django二转Day06

Django二转Day06

1.多表查询 基于对象 基于双下划线 正向和反向 聚合查询 分组查询&#xff08;配合聚合使用&#xff09; F查询和Q查询 2.其他字段和字段参数 其他字段 字段参数&#xff1b;ORM参数 ForeignKey 属性 ManyToManyField 用于表示多对多的关联关系。在数据库中通过第三…
阅读更多...
解决msvcp140.dll丢失问题的5种方法，验证有效

解决msvcp140.dll丢失问题的5种方法，验证有效

在计算机编程和软件开发中&#xff0c;我们经常会遇到一些陌生的DLL文件&#xff0c;比如msvcp140.dll。这些DLL文件是动态链接库&#xff08;Dynamic Link Libraries&#xff09;的缩写&#xff0c;它们包含了可以被多个程序共享的代码和数据。那么&#xff0c;msvcp140.dll是…
阅读更多...
优思学院｜六西格玛中的过程管理思维

优思学院｜六西格玛中的过程管理思维

过程是什么&#xff1f; 过程&#xff08;Process&#xff09;是一系列相互关联的活动&#xff0c;将输入转化为输出&#xff0c;我们习惯于用 X 来表示输入&#xff0c;用 Y 来表示输出&#xff0c;就如下图一样。在产品&#xff08;服务&#xff09;质量形成过程中&#xff…
阅读更多...
【ArcGIS Pro微课1000例】0048：深度学习--人群计数

【ArcGIS Pro微课1000例】0048：深度学习--人群计数

文章目录 一、小学回忆录二、深度学习计算人头数三、案例实现一、小学回忆录 加载配套实验数据包中的图片及训练模型。你还记得当年的小学毕业班有多少同学吗？今天我们就用ArcGIS提供的人工智能工具，重温一下童年记忆。 二、深度学习计算人头数 本案例使用到的是深度学习中…
阅读更多...
pyinstaller打包pyside

pyinstaller打包pyside

准备软件 准备一个python代码展示pyside的gui 安装PyInstaller 首先检查本机有没有安装PyInstaller &#xff0c;如果没有安装的话&#xff0c;需要运行 pip3 install PyInstaller 打包windowed界面 pyinstaller -w pymain.py 问题 Could not find the Qt platform plugi…
阅读更多...
UNDERSTANDING AND IMPROVING INFORMATION TRANSFER IN MULTI-TASK LEARNING

UNDERSTANDING AND IMPROVING INFORMATION TRANSFER IN MULTI-TASK LEARNING

Z i _i i​ X i R i X_iR_i Xi​Ri​&#xff0c; X X X是Task embedding layers&#xff0c; R R R是Alignment matrices 辅助信息 作者未提供代码
阅读更多...
编程实战：类C语法的编译型脚本解释器（七）语句

编程实战：类C语法的编译型脚本解释器（七）语句

系列入口&#xff1a; 编程实战&#xff1a;类C语法的编译型脚本解释器&#xff08;系列&#xff09;-CSDN博客 本文介绍语句&#xff0c;主要是控制语句&#xff0c;if、else、for之类。 一、语句概览 //语句//EXPRESSION RETURN:expressions[0]//BLOCK:senetnces//IF:if(exp…
阅读更多...
github setting在哪

github setting在哪

像创建一个ssh连接&#xff0c; 参考&#xff1a;【Github问题解决】解决Github&#xff1a;fatal:unable to access ‘https://github.com/.../.git‘:Could not resolve host:git_阳的糖的博客-CSDN博客
阅读更多...
安全测试之推荐工具（一）

安全测试之推荐工具（一）

文章目录 一、前言二、Web安全&#xff08;一&#xff09;AppScan&#xff08;推荐&#xff09;&#xff08;二&#xff09;AWVS&#xff08;推荐&#xff09;&#xff08;三&#xff09;Burp Suite&#xff08;推荐&#xff09;&#xff08;四&#xff09;OWASP ZAP 三、主机安…
阅读更多...
《python每天一小段》--（9）使用Paramiko库，批量操作linux服务器

《python每天一小段》--（9）使用Paramiko库，批量操作linux服务器

使用Paramiko库&#xff0c;批量操作多Linux服务器 使用Paramiko库建立SSH连接并执行命令获取多个Linux服务器的磁盘信息。通过这个例子&#xff0c;你可以学习到如何使用Python自动化操作远程服务器。 操作如图&#xff1a; 查看了两台服务器的磁盘容量&#xff1a; 安装模…
阅读更多...
Socket 编程

Socket 编程

1&#xff1a;针对 TCP 应该如何 Socket 编程&#xff1f; 服务端和客户端初始化 socket&#xff0c;得到文件描述符&#xff1b; 服务端调用 bind&#xff0c;将 socket 绑定在指定的 IP 地址和端口; 服务端调用 listen&#xff0c;进行监听&#xff1b; 服务端调用 accept&am…
阅读更多...
单片机系统

单片机系统

我们来看单片机 的例子&#xff0c;读者可能会担心单片机&#xff08;又称MCU&#xff0c;或微控制器&#xff09; 过于专业而无法理解。完全没必要&#xff01;在这里我们仅借它谈论一下有关时间的话题&#xff0c;顺带提一下单片机系统的概念。 单片机顾名思义是集成到一个芯…
阅读更多...
高薪资是跳出来的，好工作是面出来的～

高薪资是跳出来的，好工作是面出来的～

听人劝、吃饱饭，奉劝各位小伙伴，不要订阅该文所属专栏。 如需要项目实战或者是体系化资源，文末名片加V！ 作者：哈哥撩编程，工作十余年, 从事过全栈研发、产品经理等工作，目前在公司担任研发部门CTO。荣誉：2022年度博客之星Top4、2023年度超级个体得主、谷歌与亚马逊开发…
阅读更多...
【雷电模拟器桥接问题解决方法】

【雷电模拟器桥接问题解决方法】

1.ROOT权限开启 2.开启网络桥接模式&#xff0c;选择静态IP设置&#xff0c;点击安装桥接网卡&#xff0c;填写IP地址&#xff08;注意&#xff1a;IP地址要与host主机在同一IP段内&#xff09; 3.重启后 adb shell就能进入到模拟器控制台中了&#xff0c;如果出现以下内容&…
阅读更多...
作用域和作用域链

作用域和作用域链

前端面试大全JavaScript作用域和作用域链 &#x1f31f;经典真题 &#x1f31f;作用域&#xff08;Scope&#xff09; 什么是作用域 全局作用域和函数作用域 块级作用域 &#x1f31f;作用域链 什么是自由变量 什么是作用域链 关于自由变量的取值 &#x1f31f;作用域…
阅读更多...
最新文章

Copyright @ 2022~2023