加了 -ldflags="-s -w" 这样的参数
func Hello() {
fmt.Println("hello world")
}

一个 hello world 出来都要 2MB 多，更别说要写些业务代码了

你引入了 fmt 包

一是用了 fmt ，static link 进去了一大堆东西，二是 go 有 runtime 。2MB 都嫌大那只能试试 Rust 或者 C

运行时的最低开销，后续业务代码不会增加得那么恐怖，简单 APP 打包出来估计二十 MB 吧

目前打包出来是 6MB 多

正常 我用 go 编译的 so 用 zip 压缩了还有 14m

这里 2MB 主要体积都在 runtime 上了，其实你再往上添很多代码也不会加太多体积的。可以用 github.com/Zxilly/go-size-analyzer 分析下体积

而且安卓现在的包个顶个的大，这个感觉都不算啥占用了……

对于空间如此敏感的话，只有用 C/C++了，可以引用系统动态库。体积骤减。

有个可执行文件压缩工具 upx ，可以试试

2MB 还大啊？现在没见过哪个 app 低于 50MB 的

兼容 x86 ，32 位，armv7 就成 8m 了。 体积还是用纯 cpp 或者 c 好点来控制吧

＃1
＃2
有什么办法解决这个 fmt 的问题吗? 求问大佬

我再补充一点：不像其他编译语言，go 设计的时候就没有关注二进制体积，也没有考虑性能优化，甚至都没有给用户任何能微调这些偏好的编译选项。它唯一保证的就是静态链接或者说 standalone executable 。比如就算某次更新后编译体积暴涨，go team 也不会觉得这是 bug 。

如果体积和性能是你的主要焦点，还是换其他语言比较好。

非要打包在一起、8m 也不多，没人关心几十 m 的大小；不要纠结于这种问题

如果应用需要接入两个不同 go 项目程序编译的 so 文件，是不是会存在两个额外的 go runtime ？

我欣然接受 100M 以内的包，因为我是千兆网 LOL

用 lua runtime ，很小

习惯了 Go 编译出来十几 MB 的文件，那天 deno compile 了一下直接 150MB 起跳。

go 编译的二进制文件就是大, 我们现在编译的二进制, 不加 -s -w 是 100M, 加了 70M 左右

再用 upx 压缩下

用 strip 去除一下符号信息和调试信息

用安卓的原生 Java 开发啊，一个 apk 就几 KB ，加上 jni 的 arm64 only ，体积也不会太大的。

不用焦虑安装包大小，该要的代码得加上。毕竟是个草台班子。