-
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
这是因为MSVC默认会把符号和调试信息都打到静态库里,需要自己调用命令行移除。或者你可以使用我们提供的node编译工具来构建,那边也会自动帮你优化包体,具体操作看一下README文档:https://github.com/Tencent/tgfx/blob/main/README.md#build-library 另外静态库的大小是没有参考意义的,可以不用关心,不会影响最终链接后的程序大小。你关注最终连接后的动态库或者可执行程序大小就行。 |
Beta Was this translation helpful? Give feedback.
-
@domchen 因为我们这边有一个静态库项目,为用户提供基础的绘图和游戏编写功能。这个项目原先是使用 GDI/GDI+ 作为底层进行渲染,但是因为渲染速度太慢并且功能不足的问题,想更换一下底层。库本身大小在 1MB 左右,希望选择一个绘图性能高效、功能不弱的库,因为需要合并到我们本身的库文件中一起提供给用户,体积过大则不太合适。 之前有考虑过 Skia, Blend2D 之类的,但是 Blend2D 只支持 CPU 渲染,性能还是稍弱,并且现在开发停滞,后续功能很难跟上。 上面在 CLion 中使用 VS2022 工具链编译出的 TGFX 2.0 Release 版本,体积在 60MB 左右,这次根据您给出的 Node 构建方式,构建出的 release 库文件体积变成 250MB,我怀疑过可能是弄错成了 debug,但是以 ![]() 有现有的使用 tgfx 动态库作为渲染底层的应用可供参考吗?参考如何裁剪 TGFX 以得到合适体积的库文件。 |
Beta Was this translation helpful? Give feedback.
-
下周一我去Windows测试一下看看,也有可能MSVC编译出来的静态库格式就是这么大的。静态库本身其实就是中间产物,Windows平台可能给它打入了过多的调试信息,但只要最终链接到动态库或者可执行程序里就会变成和其他平台一样的大小,那个才是用来运行的。但是tgfx并不合适作为动态库使用。动态库是需要定义暴露哪些接口的,tgfx的API太庞大了而且和Skia一样并不保证向后兼容。你如果需要提供动态库给用户,建议不要把tgfx编译为动态库,而是把你自己的库编译为动态库,然后链接tgfx的静态库进去,只要有任何一个包装tgfx的外层程序或者动态库,最终的产物就是会很小的。这样你也容易保证自己给用户暴露的动态库API都是稳定的。 |
Beta Was this translation helpful? Give feedback.
-
我测试了一下,Windows上node编译工具配置有一些问题,在release模式下也把调试信息生成了,刚刚已经提交了修复,main分支最新代码用node工具编译也是60多M。然后查了下似乎没有其他编译优化选项。静态库在MSVC上的产物应该就是文件格式比较大的,60多M就是正常的静态库大小了。但是如之前所说,静态库大小并不影响最终应用程序的包体,只是中间过程产物。你的用户正常也不会看静态库大小的,都是看编译之后最终的程序增量。60M按现在的网速也不算是问题,直接按这个分发就行。你举例的skia的dll库比较小,因为dll就是动态库。tgfx的如果也编译为动态库或者嵌入可执行程序,增量应该只有不到1M。但是如果你提前编译为动态库,那么就没法实现嵌入宿主程序了,用户那边要额外附带一个动态库并且打包分发给他们的用户,没法编译为单可执行程序方式分发,用起来也不是很方便。而且为了这个点把静态库改为动态库并没有实际意义,只是中间开发状态觉得文件大一点而已,最终用户拿到的可执行程序并没有大小区别。 |
Beta Was this translation helpful? Give feedback.
这是因为MSVC默认会把符号和调试信息都打到静态库里,需要自己调用命令行移除。或者你可以使用我们提供的node编译工具来构建,那边也会自动帮你优化包体,具体操作看一下README文档:https://github.com/Tencent/tgfx/blob/main/README.md#build-library 另外静态库的大小是没有参考意义的,可以不用关心,不会影响最终链接后的程序大小。你关注最终连接后的动态库或者可执行程序大小就行。