字符串常量在编译后的DLL中占用多少空间
本文关键字:多少 空间 DLL 常量 编译 字符串 | 更新日期: 2023-09-27 18:12:20
我正试图找出影响Silverlight应用程序程序集编译大小的因素。显然,我想减少我的应用程序的大小,最明显的方法是摆脱我的一些常量字符串(例如错误字符串-在应用程序中没有图像或其他资源密集型实体)。随后,我将根据需要从服务器拉出字符串。在我进行这项工作之前,我想计算出大约可以节省多少空间。
一个编译后的常量在编译后的DLL中占用多少内存?我假设它是作为UNICODE UTF-16字符数组存储的,所以每个字符将是2字节?这是正确的吗?对于用于创建最终.xap文件的zip压缩,是否有一条经验法则(或更严格的规则)来计算可以对字符串进行多少压缩?
很明显,我问这个问题的方式引起了一些困惑。我说的"内存占用"不是"应用程序消耗的内存量",而是"dll"的大小以及由此创建的xap文件的大小。让我们这么说:. net中的System.Char
(c#中的char
)是2个字节。它不能表示所有的Unicode字符。单个Char
只能表示BMP (Basic Multilingual Plane)的字符。其他的被分成代理对,需要2x Char
。99%的情况下,您不会使用BMP以外的字符。http://en.wikipedia.org/wiki/UTF-16
现在…. net中的 String
s由System.Char
组成(末尾有一个NUL
终止符),所以它"通常"是每个BMP字符2字节(加上另外2个字符作为终止符)。
在程序集中,字符串被保存为UTF-16。我刚刚用十六进制编辑器检查过。它们不是"完全"NUL
终止的(它们在0处有一个字节),但它们的长度(以字节为单位)+ 1(对于0处的单个字节)前缀为16位值。
减少内存占用[…]最明显的方法是删除一些常量字符串(例如错误字符串),以便根据需要从服务器中取出它们。
内存占用与可执行文件大小无关。我可以有一个几个K的可执行文件,可以填满你所有的内存。
你认为创建一个套接字,通过HTTP等协议请求字符串,用只需要的字符串填充数组不会像简单地将字符串数组编译成可执行文件那样占用至少那么多的内存吗?
如果有的话,您应该查看条件编译(#if ENGLISH // language specific variables here #endif
),从而只包含您需要的字符串,或者使用许多国际化选项之一,如区域性。
如果我没记错的话,UTF-8是向后兼容ASCII的,这意味着对于大多数常见字符,它将是每个字符1字节。