go 编译 andriod .so 文件体积太大怎么解决呢

[aladdinding]

加了 -ldflags="-s -w" 这样的参数

func Hello() {
	fmt.Println("hello world")
}

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

[warlock]

你引入了 fmt 包

[bagel]

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

[yplam]

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

[aladdinding]

目前打包出来是 6MB 多

[sardina]

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

[iyear]

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

[iyear]

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

[gam2046]

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

[lveye]

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

[lysShub]

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

[jeesk]

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

[zoharSoul]

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

[w568w]

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

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

[lysShub]

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

[lisongeee]

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

[GeekGao]

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

[hanxiV2EX]

用 lua runtime ，很小

[GuangXiN]

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

[bruce0]

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

[TrigVon]

再用 upx 压缩下

[xssshell]

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

[sir283]

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

[murmurkerman]

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

[aladdinding]

@iyear 看了下 runtime 大概 1mb ，然后用了 net 包 ，占 1mb ，crypto 占了 1mb

[flyqie]

有点好奇，为什么要用 go 做 android 。。

是某些组件不方便移植吗？

感觉貌似 go 在 android 这块用的似乎不是很多？

[debuggeeker]

直接用默认的 as 工具开发不好吗，就是 c++那套（ ndk ）

[mogging]

@bagel 确实 go 有 runtime 这反而是他的精华，大部分场景可以不依赖 libc ，这点磁盘空间不算事

[aladdinding]

@flyqie 有些网络方面的包 go 写方便一些