Docker鏡像制作教程:針對(duì)不同語(yǔ)言的精簡(jiǎn)策略

簡(jiǎn)介：?本文主要講解針對(duì)不同的語(yǔ)言來(lái)選擇適當(dāng)?shù)木?jiǎn)策略，其中主要討論?Go，同時(shí)也涉及到了?Java，Node，Python，Ruby和?Rust。同時(shí)也會(huì)詳細(xì)介紹 Alpine 鏡像的避坑指南。

一、Go 語(yǔ)言鏡像精簡(jiǎn)

Go?語(yǔ)言程序編譯時(shí)會(huì)將所有必須的依賴編譯到二進(jìn)制文件中，但也不能完全肯定它使用的是靜態(tài)鏈接，因?yàn)?Go?的某些包是依賴系統(tǒng)標(biāo)準(zhǔn)庫(kù)的，例如使用到 DNS 解析的包。只要代碼中導(dǎo)入了這些包，編譯的二進(jìn)制文件就需要調(diào)用到某些系統(tǒng)庫(kù)，為了這個(gè)需求，Go 實(shí)現(xiàn)了一種機(jī)制叫?cgo，以允許 Go 調(diào)用 C 代碼，這樣編譯好的二進(jìn)制文件就可以調(diào)用系統(tǒng)庫(kù)。

也就是說(shuō)，如果 Go 程序使用了?net?包，就會(huì)生成一個(gè)動(dòng)態(tài)的二進(jìn)制文件，如果想讓鏡像能夠正常工作，必須將需要的庫(kù)文件復(fù)制到鏡像中，或者直接使用?busybox:glibc?鏡像。

當(dāng)然，你也可以禁止?cgo，這樣 Go 就不會(huì)使用系統(tǒng)庫(kù)，使用內(nèi)置的實(shí)現(xiàn)來(lái)替代系統(tǒng)庫(kù)（例如使用內(nèi)置的 DNS 解析器），這種情況下生成的二進(jìn)制文件就是靜態(tài)的。可以通過(guò)設(shè)置環(huán)境變量?CGO_ENABLED=0?來(lái)禁用 cgo，例如：

FROM golang

COPY whatsmyip.go .ENV CGO_ENABLED=0RUN go build whatsmyip.go

FROM scratch

COPY --from=0 /go/whatsmyip .CMD ["./whatsmyip"]

由于編譯生成的是靜態(tài)二進(jìn)制文件，因此可以直接跑在?scratch?鏡像中 ?

當(dāng)然，也可以不用完全禁用?cgo，可以通過(guò)?-tags?參數(shù)指定需要使用的內(nèi)建庫(kù)，例如?-tags netgo?就表示使用內(nèi)建的 net 包，不依賴系統(tǒng)庫(kù)：

$ go build -tags netgo whatsmyip.go

這樣指定之后，如果導(dǎo)入的其他包都沒(méi)有用到系統(tǒng)庫(kù)，那么編譯得到的就是靜態(tài)二進(jìn)制文件。也就是說(shuō)，只要還有一個(gè)包用到了系統(tǒng)庫(kù)，都會(huì)開(kāi)啟?cgo，最后得到的就是動(dòng)態(tài)二進(jìn)制文件。要想一勞永逸，還是設(shè)置環(huán)境變量?CGO_ENABLED=0?吧。

二、Alpine 鏡像探秘

上篇文章已經(jīng)對(duì)?Alpine?鏡像作了簡(jiǎn)要的介紹，并保證會(huì)在后面的文章中花很大的篇幅來(lái)討論?Alpine?鏡像，現(xiàn)在時(shí)候到了！

Alpine?是眾多 Linux 發(fā)行版中的一員，和?CentOS、Ubuntu、Archlinux?之類一樣，只是一個(gè)發(fā)行版的名字，號(hào)稱小巧安全，有自己的包管理工具?apk。

與 CentOS 和 Ubuntu 不同，Alpine 并沒(méi)有像?Red Hat?或?Canonical?之類的大公司為其提供維護(hù)支持，軟件包的數(shù)量也比這些發(fā)行版少很多（如果只看開(kāi)箱即用的默認(rèn)軟件倉(cāng)庫(kù)，Alpine 只有?10000?個(gè)軟件包，而 Ubuntu、Debian 和 Fedora 的軟件包數(shù)量均大于?50000。）

容器崛起之前，Alpine?還是個(gè)無(wú)名之輩，可能是因?yàn)榇蠹也⒉皇呛荜P(guān)心操作系統(tǒng)本身的大小，畢竟大家只關(guān)心業(yè)務(wù)數(shù)據(jù)和文檔，程序、庫(kù)文件和系統(tǒng)本身的大小通常可以忽略不計(jì)。

容器技術(shù)席卷整個(gè)軟件產(chǎn)業(yè)之后，大家都注意到了一個(gè)問(wèn)題，那就是容器的鏡像太大了，浪費(fèi)磁盤空間，拉取鏡像的時(shí)間也很長(zhǎng)。于是，人們開(kāi)始尋求適用于容器的更小的鏡像。對(duì)于那些耳熟能詳?shù)陌l(fā)行版（例如 Ubuntu、Debian、Fedora）來(lái)說(shuō)，只能通過(guò)刪除某些工具（例如?ifconfig?和?netstat）將鏡像體積控制在?100M?以下。而對(duì)于 Alpine 而言，什么都不用刪除，鏡像大小也就只有?5M?而已。

Alpine 鏡像的另一個(gè)優(yōu)勢(shì)是包管理工具的執(zhí)行速度非常快，安裝軟件體驗(yàn)非常順滑。誠(chéng)然，在傳統(tǒng)的虛擬機(jī)上不需要太關(guān)心軟件包的安裝速度，同一個(gè)包只需要裝一次即可，無(wú)需不停重復(fù)安裝。容器就不一樣了，你可能會(huì)定期構(gòu)建新鏡像，也可能會(huì)在運(yùn)行的容器中臨時(shí)安裝某些調(diào)試工具，如果軟件包的安裝速度很慢，會(huì)很快消磨掉我們的耐心。

為了更直觀，我們來(lái)做個(gè)簡(jiǎn)單的對(duì)比測(cè)試，看看不同的發(fā)行版安裝?tcpdump?需要多長(zhǎng)時(shí)間，測(cè)試命令如下：

? → time docker run install tcpdump

測(cè)試結(jié)果如下：

Base image Size Time to install tcpdump

---------------------------------------------------------

alpine:3.11 5.6 MB 1-2s

archlinux:20200106 409 MB 7-9s

centos:8 237 MB 5-6s

debian:10 114 MB 5-7s

fedora:31 194 MB 35-60s

ubuntu:18.04 64 MB 6-8s

如果你想了解更多關(guān)于 Alpine 的內(nèi)幕，可以看看?Natanel Copa 的演講。

好吧，既然 Alpine 這么棒，為什么不用它作為所有鏡像的基礎(chǔ)鏡像呢？別急，先一步一步來(lái)，為了趟平所有的坑，需要分兩種情況來(lái)考慮：

使用 Alpine 作為第二構(gòu)建階段（run?階段）的基礎(chǔ)鏡像

使用 ALpine 作為所有構(gòu)建階段（run?階段和?build?階段）的基礎(chǔ)鏡像

run 階段使用 Alpine

帶著激動(dòng)的心情，將 Alpine 鏡像加入了 Dockerfile：

FROM gcc AS mybuildstage

COPY hello.c .RUN gcc -o hello hello.c

FROM alpine

COPY --from=mybuildstage hello .CMD ["./hello"]

第一個(gè)坑來(lái)了，啟動(dòng)容器出現(xiàn)了錯(cuò)誤：

standard_init_linux.go:211: exec user process caused "no such file or directory"

這個(gè)報(bào)錯(cuò)在上篇文章已經(jīng)見(jiàn)識(shí)過(guò)了，上篇文章的場(chǎng)景是使用?scratch?鏡像作為?C?語(yǔ)言程序的基礎(chǔ)鏡像，錯(cuò)誤的原因是?scratch?鏡像中缺少動(dòng)態(tài)庫(kù)文件?？墒菫槭裁词褂?Alpine 鏡像也有報(bào)錯(cuò)，難道它也缺少動(dòng)態(tài)庫(kù)文件？

也不完全是，Alpine 使用的也是動(dòng)態(tài)庫(kù)，畢竟它的設(shè)計(jì)目標(biāo)之一就是占用更少的空間。但 Alpine 使用的標(biāo)準(zhǔn)庫(kù)與大多數(shù)發(fā)行版不同，它使用的是?musl libc，這個(gè)庫(kù)相比于?glibc?更小、更簡(jiǎn)單、更安全，但是與大家常用的標(biāo)準(zhǔn)庫(kù)?glibc?并不兼容。

你可能又要問(wèn)了：『既然?musl libc?更小、更簡(jiǎn)單，還特么更安全，為啥其他發(fā)行版還在用?glibc？』

mmm。。。因?yàn)?glibc?有很多額外的擴(kuò)展，并且很多程序都用到了這些擴(kuò)展，而?musl libc?是不包含這些擴(kuò)展的。詳情可以參考?musl 的文檔。

也就是說(shuō)，如果想讓程序跑在 Alpine 鏡像中，必須在編譯時(shí)使用?musl libc?作為動(dòng)態(tài)庫(kù)。

所有階段使用 Alpine

為了生成一個(gè)與?musl libc?鏈接的二進(jìn)制文件，有兩條路：

某些官方鏡像提供了 Alpine 版本，可以直接拿來(lái)用。

還有些官方鏡像沒(méi)有提供 Alpine 版本，我們需要自己構(gòu)建。

golang 鏡像就屬于第一種情況，golang:alpine?提供了基于 Alpine 構(gòu)建的?Go?工具鏈。

構(gòu)建 Go 程序可以使用下面的?Dockerfile：

FROM golang:alpine

COPY hello.go .RUN go build hello.go

FROM alpine

COPY --from=0 /go/hello .CMD ["./hello"]

生成的鏡像大小為 7.5M，對(duì)于一個(gè)只打印『hello world』的程序來(lái)說(shuō)確實(shí)有點(diǎn)大了，但我們可以換個(gè)角度：

即使程序很復(fù)雜，生成的鏡像也不會(huì)很大。

包含了很多有用的調(diào)試工具。

即使運(yùn)行時(shí)缺少某些特殊的調(diào)試工具，也可以迅速安裝。

Go 語(yǔ)言搞定了，C 語(yǔ)言呢？并沒(méi)有?gcc:alpine?這樣的鏡像啊。只能以 Alpine 鏡像作為基礎(chǔ)鏡像，自己安裝 C 編譯器了，Dockerfile 如下：

FROM alpine

RUN apk add build-baseCOPY hello.c .RUN gcc -o hello hello.c

FROM alpine

COPY --from=0 hello .CMD ["./hello"]

必須安裝?build-base，如果安裝?gcc，就只有編譯器，沒(méi)有標(biāo)準(zhǔn)庫(kù)。build-base 相當(dāng)于 Ubuntu 的?build-essentials，引入了編譯器、標(biāo)準(zhǔn)庫(kù)和 make 之類的工具。

最后來(lái)對(duì)比一下不同構(gòu)建方法得到的『hello world』鏡像大?。?/p>

使用基礎(chǔ)鏡像?golang?構(gòu)建：805MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?ubuntu：66.2MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang:alpine，run 階段使用基礎(chǔ)鏡像?alpine：7.6MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?scratch：2MB

最終鏡像體積減少了?99.75%，相當(dāng)驚人了。再來(lái)看一個(gè)更實(shí)際的例子，上一節(jié)提到的使用?net?的程序，最終的鏡像大小對(duì)比：

使用基礎(chǔ)鏡像?golang?構(gòu)建：810MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?ubuntu：71.2MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang:alpine，run 階段使用基礎(chǔ)鏡像?alpine：12.6MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang，run 階段使用基礎(chǔ)鏡像?busybox:glibc：12.2MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?golang?并使用參數(shù) CGO_ENABLED=0，run 階段使用基礎(chǔ)鏡像?ubuntu：7MB

鏡像體積仍然減少了?99%。

三、Java 語(yǔ)言鏡像精簡(jiǎn)

Java?屬于編譯型語(yǔ)言，但運(yùn)行時(shí)還是要跑在?JVM?中。那么對(duì)于 Java 語(yǔ)言來(lái)說(shuō)，該如何使用多階段構(gòu)建呢？

靜態(tài)還是動(dòng)態(tài)？

從概念上來(lái)看，Java 使用的是動(dòng)態(tài)鏈接，因?yàn)?Java 代碼需要調(diào)用?JVM?提供的?Java API，這些 API 的代碼都在可執(zhí)行文件之外，通常是?JAR?文件或?WAR?文件。

然而這些 Java 庫(kù)并不是完全獨(dú)立于系統(tǒng)庫(kù)的，某些 Java 函數(shù)最終還是會(huì)調(diào)用系統(tǒng)庫(kù)，例如打開(kāi)文件時(shí)需要調(diào)用?open(),?fopen()?或它們的變體，因此?JVM?本身可能會(huì)與系統(tǒng)庫(kù)動(dòng)態(tài)鏈接。

這就意味著理論上可以使用任意的?JVM?來(lái)運(yùn)行 Java 程序，系統(tǒng)標(biāo)準(zhǔn)庫(kù)是?musl libc?還是?glibc?都無(wú)所謂。因此，也就可以使用任意帶有?JVM?的基礎(chǔ)鏡像來(lái)構(gòu)建 Java 程序，也可以使用任意帶有?JVM?的鏡像作為運(yùn)行 Java 程序的基礎(chǔ)鏡像。

類文件格式

Java 類文件（Java 編譯器生成的字節(jié)碼）的格式會(huì)隨著版本而變化，且大部分變化都是?Java API?的變化。還有一部分更改與 Java 語(yǔ)言本身有關(guān)，例如?Java 5?中添加了泛型，這種變化就可能會(huì)導(dǎo)致類文件格式的變化，從而破壞與舊版本的兼容性。

所以默認(rèn)情況下，使用給定版本的 Java 編譯器編譯的類不能與更早版本的 JVM 兼容，但可以指定編譯器的?-target?（Java 8 及其以下版本）參數(shù)或者?--release?（Java 9 及其以上版本）參數(shù)來(lái)使用較舊的類文件格式。--release?參數(shù)還可以指定類文件的路徑，以確保程序運(yùn)行在指定的 JVM 版本中（例如 Java 11），不會(huì)意外調(diào)用 Java 12 的 API。

JDK vs JRE

如果你對(duì)大多數(shù)平臺(tái)上的 Java 打包方式很熟悉，那你應(yīng)該知道?JDK?和?JRE。

JRE?即 Java 運(yùn)行時(shí)環(huán)境（Java Runtime Environment），包含了運(yùn)行 Java 程序所需要的環(huán)境，即?JVM。

JDK?即 Java 開(kāi)發(fā)工具包（Java Development Kit），既包含了 JRE，也包含了開(kāi)發(fā) Java 程序所需的工具，即 Java 編譯器。

大多數(shù) Java 鏡像都提供了 JDK 和 JRE 兩種標(biāo)簽，因此可以在多階段構(gòu)建的?build?階段使用?JDK?作為基礎(chǔ)鏡像，run?階段使用?JRE?作為基礎(chǔ)鏡像。

Java vs OpenJDK

推薦使用?openjdk，因?yàn)殚_(kāi)源啊，更新勤快啊~~

也可以使用?amazoncorretto，這是?Amazon?fork OpenJDK 后打了補(bǔ)丁的版本，號(hào)稱企業(yè)級(jí)。

開(kāi)始構(gòu)建

說(shuō)了那么多，到底該用哪個(gè)鏡像呢？這里給出幾個(gè)參考：

openjdk:8-jre-alpine（85MB）

openjdk:11-jre（267MB）或者?openjdk:11-jre-slim（204MB）

openjdk:14-alpine（338MB）

如果你想要更直觀的數(shù)據(jù)，可以看我的例子，還是搬出屢試不爽的『hello world』，只不過(guò)這次是 Java 版本：

class hello {

public static void main(String [] args) {

System.out.println("Hello, world!");

}

不同構(gòu)建方法得到的鏡像大?。?/p>

使用基礎(chǔ)鏡像?java?構(gòu)建：643MB

使用基礎(chǔ)鏡像?openjdk?構(gòu)建：490MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk，run 階段使用基礎(chǔ)鏡像?openjdk:jre：479MB

使用基礎(chǔ)鏡像?amazoncorretto?構(gòu)建：390MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk:11，run 階段使用基礎(chǔ)鏡像?openjdk:11-jre：267MB

多階段構(gòu)建，build 階段使用基礎(chǔ)鏡像?openjdk:8，run 階段使用基礎(chǔ)鏡像?openjdk:8-jre-alpine：85MB

所有的 Dockerfile 都可以在這個(gè)倉(cāng)庫(kù)找到。

四、解釋型語(yǔ)言鏡像精簡(jiǎn)

對(duì)于諸如?Node、Python、Rust?之類的解釋型語(yǔ)言來(lái)說(shuō)，情況就比較復(fù)雜一點(diǎn)了。先來(lái)看看 Alpine 鏡像。

Alpine 鏡像

對(duì)于解釋型語(yǔ)言來(lái)說(shuō)，如果程序僅用到了標(biāo)準(zhǔn)庫(kù)或者依賴項(xiàng)和程序本身使用的是同一種語(yǔ)言，且無(wú)需調(diào)用 C 庫(kù)和外部依賴，那么使用?Alpine?作為基礎(chǔ)鏡像一般是沒(méi)有啥問(wèn)題的。一旦你的程序需要調(diào)用外部依賴，情況就復(fù)雜了，想繼續(xù)使用 Alpine 鏡像，就得安裝這些依賴。根據(jù)難度可以劃分為三個(gè)等級(jí)：

簡(jiǎn)單：依賴庫(kù)有針對(duì) Alpine 的安裝說(shuō)明，一般會(huì)說(shuō)明需要安裝哪些軟件包以及如何建立依賴關(guān)系。但這種情況非常罕見(jiàn)，原因前面也提到了，Alpine 的軟件包數(shù)量比大多數(shù)流行的發(fā)行版要少得多。

中等：依賴庫(kù)沒(méi)有針對(duì) Alpine 的安裝說(shuō)明，但有針對(duì)別的發(fā)行版的安裝說(shuō)明。我們可以通過(guò)對(duì)比找到與別的發(fā)行版的軟件包相匹配的 Alpine 軟件包（假如有的話）。

困難：依賴庫(kù)沒(méi)有針對(duì) Alpine 的安裝說(shuō)明，但有針對(duì)別的發(fā)行版的安裝說(shuō)明，但是 Alpine 也沒(méi)有與之對(duì)應(yīng)的軟件包。這種情況就必須從源碼開(kāi)始構(gòu)建！

最后一種情況最不推薦使用 Alpine 作為基礎(chǔ)鏡像，不但不能減小體積，可能還會(huì)適得其反，因?yàn)槟阈枰惭b編譯器、依賴庫(kù)、頭文件等等。。。更重要的是，構(gòu)建時(shí)間會(huì)很長(zhǎng)，效率低下。如果非要考慮多階段構(gòu)建，就更復(fù)雜了，你得搞清楚如何將所有的依賴編譯成二進(jìn)制文件，想想就頭大。因此一般不推薦在解釋型語(yǔ)言中使用多階段構(gòu)建。

有一種特殊情況會(huì)同時(shí)遇到 Alpine 的絕大多數(shù)問(wèn)題：將 Python 用于數(shù)據(jù)科學(xué)。numpy?和?pandas?之類的包都被預(yù)編譯成了?wheel，wheel?是 Python 新的打包格式，被編譯成了二進(jìn)制，用于替代 Python 傳統(tǒng)的?egg?文件，可以通過(guò)?pip?直接安裝。但這些 wheel 都綁定了特定的 C 庫(kù)，這就意味著在大多數(shù)使用?glibc?的鏡像中都可以正常安裝，但 Alpine 鏡像就不行，原因你懂得，前面已經(jīng)說(shuō)過(guò)了。如果非要在 Alpine 中安裝，你需要安裝很多依賴，重頭構(gòu)建，耗時(shí)又費(fèi)力，有一篇文章專門解釋了這個(gè)問(wèn)題：使用 Alpine 構(gòu)建 Pyhton 鏡像會(huì)將構(gòu)建速度拖慢 50 倍！。

既然 Alpine 鏡像這么坑，那么是不是只要是 Python 寫的程序就不推薦使用 Alpine 鏡像來(lái)構(gòu)建呢？也不能完全這么肯定，至少 Python 用于數(shù)據(jù)科學(xué)時(shí)不推薦使用 Alpine，其他情況還是要具體情況具體分析，如果有可能，還是可以試一試 Alpine 的。

:slim 鏡像

如果實(shí)在不想折騰，可以選擇一個(gè)折衷的鏡像?xxx:slim。slim 鏡像一般都基于?Debian?和?glibc，刪除了許多非必需的軟件包，優(yōu)化了體積。如果構(gòu)建過(guò)程中需要編譯器，那么 slim 鏡像不適合，除此之外大多數(shù)情況下還是可以使用 slim 作為基礎(chǔ)鏡像的。

下面是主流的解釋型語(yǔ)言的 Alpine 鏡像和 slim 鏡像大小對(duì)比：

Image Size

---------------------------

node 939 MB

node:alpine 113 MB

node:slim 163 MB

python 932 MB

python:alpine 110 MB

python:slim 193 MB

ruby 842 MB

ruby:alpine 54 MB

ruby:slim 149 MB

再來(lái)舉個(gè)特殊情況的例子，同時(shí)安裝?matplotlib，numpy?和?pandas，不同的基礎(chǔ)鏡像構(gòu)建的鏡像大小如下：

Image and technique Size

--------------------------------------

python 1.26 GB

python:slim 407 MB

python:alpine 523 MB

python:alpine multi-stage 517 MB

可以看到這種情況下使用 Alpine 并沒(méi)有任何幫助，即使使用多階段構(gòu)建也無(wú)濟(jì)于事。

但也不能全盤否定 Alpine，比如下面這種情況：包含大量依賴的?Django?應(yīng)用。

Image and technique Size

--------------------------------------

python 1.23 GB

python:alpine 636 MB

python:alpine multi-stage 391 MB

最后來(lái)總結(jié)一下：到底使用哪個(gè)基礎(chǔ)鏡像并不能蓋棺定論，有時(shí)使用 Alpine 效果更好，有時(shí)反而使用 slim 效果更好，如果你對(duì)鏡像體積有著極致的追求，可以這兩種鏡像都嘗試一下。相信隨著時(shí)間的推移，我們就會(huì)積累足夠的經(jīng)驗(yàn)，知道哪種情況該用 Alpine，哪種情況該用 slim，不用再一個(gè)一個(gè)嘗試。

五、Rust 語(yǔ)言鏡像精簡(jiǎn)

Rust?是最初由?Mozilla?設(shè)計(jì)的現(xiàn)代編程語(yǔ)言，并且在?Web?和基礎(chǔ)架構(gòu)領(lǐng)域中越來(lái)越受歡迎。Rust 編譯的二進(jìn)制文件動(dòng)態(tài)鏈接到 C 庫(kù)，可以正常運(yùn)行于?Ubuntu、Debian?和?Fedora?之類的鏡像中，但不能運(yùn)行于?busybox:glibc?中。因?yàn)?Rust 二進(jìn)制需要調(diào)用?libdl?庫(kù)，busybox:glibc?中不包含該庫(kù)。

還有一個(gè)?rust:alpine?鏡像，Rust 編譯的二進(jìn)制也可以正常運(yùn)行其中。

如果考慮編譯成靜態(tài)鏈接，可以參考?Rust 官方文檔。在 Linux 上需要構(gòu)建一個(gè)特殊版本的 Rust 編譯器，構(gòu)建的依賴庫(kù)就是?musl libc，你沒(méi)有看錯(cuò)，就是 Alpine 中的那個(gè)?musl libc。如果你想獲得更小的鏡像，請(qǐng)按照文檔中的說(shuō)明進(jìn)行操作，最后將生成的二進(jìn)制文件扔進(jìn)?scratch?鏡像中就好了。

審核編輯：湯梓紅

閱讀全文