针对较小的 .cod (.jar) 文件进行优化

发布于 2024-07-27 17:08:11 字数 427 浏览 5 评论 0原文

RIM 编译器在构建最终 .cod 文件时对生成的“.jar”执行额外的优化和压缩,但开发人员可以采取一些措施来显着减小最终 .cod 文件的大小。

其中之一就是运行 PNGCrush, OptiPNG,或类似的工具来减小所包含的 .png 文件的大小。 在具有大量图像文件的应用程序(例如具有自定义 UI 的应用程序)中,这可以显着减小最终 .cod 文件的大小。

如何优化最终 .cod 文件的大小? .java 代码本身需要做什么? 项目结构中需要做什么? 要对文件或资源做些什么?

The RIM compiler performs extra optimization and compression on the resulting ".jar" while building the final .cod file, but there are things that can be done by the developer to significantly reduce the final .cod file size.

One such thing would be to run PNGCrush, OptiPNG, or a similar tool to reduce the size of the included .png files. In an application with a large number of image files (such as an app featuring a custom UI), this can yield a significant reduction in the final .cod file size.

How can I optimize the final .cod file for size? Something to be done in the .java code itself? Something to be done in the project structure? Something to be done to the files or resources?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

且行且努力 2024-08-03 17:08:11

好问题!

  • 压缩(GZipZLib) 在安装大型 bin/txt/xml 文件时可能很有用

这就是 RIM 中所说的:

另外,有趣的事实

所有图像均为 PNG 格式。 我想要
知道为什么:使用 JDE 4.5 编译 -->
900k,编译JDE 4.2、2.6.1、4.7 -->
1800k。 有什么区别? 谢谢 !

<小时>

似乎 JDE 4.5 比旧版 JDE 使用了更多优化技术
版本。

<小时>

检查下图,它是由 PngOut 从 55 K png 图像生成的。 它的大小是 3427 字节

Good question!

  • Compression (GZip, ZLib) may be useful when installing large bin/txt/xml files

And that's what they say in RIM:

Also, interesting facts:

All images was PNG format. I want to
know why : compile with JDE 4.5 -->
900k, compile JDE 4.2, 2.6.1, 4.7 -->
1800k. What is difference ? Thanks !


Seems that JDE 4.5 uses more optimization techniques than older JDE
versions.


Check the image below, it produced by PngOut from 55 K png image. It's size is 3427 bytes

谁对谁错谁最难过 2024-08-03 17:08:11

我认为你肯定想考虑像 ProGuard 这样的收缩器(和优化器/混淆器)(http://sourceforge. net/projects/proguard/)。 这可以通过将完整的类名压缩为缩短的版本、删除未使用的代码等来缩小 Java 代码。在此过程中,它可以提高代码的效率。 这很棒。 唯一困难的部分是在 RIM 构建工具使用它来制作 .cod 之前修改您的构建以优化生成的类文件。

I think you most certainly want to consider a shrinker (and optimizer/obfusticator) like ProGuard (http://sourceforge.net/projects/proguard/). This can shrink your Java code by collapsing full class names into shortened versions, removing unused code, etc. Along the way it can improve the efficiency of the code. It's great. The only hard part is modifying your build to optimize the generated class files before the RIM build stuff gets its hands on it to make a .cod.

川水往事 2024-08-03 17:08:11

一个好的方法是对所有资源进行 GZIP,然后使用 net.rim.device.api.compress.GZIPInputStream 类加载压缩文件。 这样您就不必自己实现解压缩代码。

您还可以使用 pngout 来优化图像资源。

A good approach is to GZIP all resources and then use net.rim.device.api.compress.GZIPInputStream class to load compressed files. That way you don't have to implement decompress code by yourself.

Also you can use pngout for optimizing image resources.

つ低調成傷 2024-08-03 17:08:11

确保尽可能使用 PNG-8 而不是 PNG-24。 尝试尽量减少调色板中的颜色数量。 之后,使用 PngOut。

至于 ProGuard,当我使用 Progruard 的优化功能(“-dontoptimize”开关)时,我在旧的 BB 设备上遇到了问题 - 所以请小心使用它,尽管它是一个很棒的工具。

Make sure that you use PNG-8 instead of PNG-24 when possible. Try to minimize number of colors in palette. After this, use PngOut.

As for ProGuard, I have problems on old BB devices when using optimize feachure of Progruard ("-dontoptimize" switch) - so use it carefully, although it is a great tool.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文