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?
Good question!
Compression (GZip, ZLib) may be useful when installing large bin/txt/xml files
And that's what they say in RIM:
Setting appropriate access
Avoid creating interfaces
Use static inner classes
Avoid unnecessary field initialization
Import individual classes
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
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.
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.
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.
Related
we have implemented one universal application. It's a huge application and 6-8 SDKs are integrated, So the entire app is taking around 40MB size.
After all, we want to reduce the size of the application. So we started the investigation, where exactly it is taking more size. What I know is, I can check for useless view controllers, and I can remove 1x images. And these things we can do in Xcode. But what if we want to know the sizes it is taking in .ipa file itself. Is it possible ?
But is there any better way to know the .ipa size module/ SDK wise. Please let me know. Any optimisation tool are available ?
The following post has good advice on optimizations
https://medium.com/#mandrigin/ios-app-performance-instruments-beyond-48fe7b7cdf2#.btdp7bv5t
Also, you can try to access images in the IPA file using such tools like iBrowse and even better if you have a device with a firmware less than 9.3.3 to perform a jailbreak and investigate.
You can go even deeper by:
reducing image size using tools like imageAlpha & imageOptim which are both free
take a look at webP image format developed by google
https://developers.google.com/speed/webp/#webp_support_stylefont-weight_bold
I'm very interested in using GStreamer's iOS framework http://docs.gstreamer.com/display/GstSDK/Installing+for+iOS+development for video streaming, but when I add the framework to a blank project and add a few lines of code to take advantage of its powerful features, the final IPA is 27MB. This is just way to big to be adding to my project, what is the best way to go about stripping this down the the bare necessities as I'm sure I'm only using a small percent of the code that is included in the SDK.
Here's a pic showing the package contents of the IPA:
Thanks!
In the gst_ios_main.h you can disable all the plugins that you don't need (make sure to enable linker optimizations so that unused code is removed). If that's not enough, you can build your own stripped down version of the iOS binaries with http://cgit.freedesktop.org/gstreamer/cerbero/ (you need to remove things from the .package and .recipe files to only build what you need). Just disabling things from gst_ios_main.h should be enough in 99% of the cases though.
Note that by default you'll build applications for multiple architectures, as such the resulting application will be rather large. Depending on your use case you can drop some architectures.
On another note, gstreamer.com is providing an completely outdated version of GStreamer and is in no way related to the GStreamer project. The official website is http://gstreamer.freedesktop.org .
SDKs have their source code encapsulated away from you, the user. You get access only to header files. Thus you just can't extract some class from it because you don't have access to the implementation file.
Of course if this library is opensource you can attempt to isolate one class, but sometimes everything is so deeply connected, that it is close to impossible.
I'm looking to minimize the size of my android ndk built library.
I have started with the pre-built OpenCv libraries for Android and as of now the size of my lib is about 3MB. How can I minimize it's size?
I only need read/write files capability, png encode/decode, jpeg decoder and the typical image manipulation functions from OpenCv such as resize and cvtColor.
Any pointers greatly appreciated!
You've probably moved on with your project by now, Jona, but others not using the cmake-gui may like a command-line example. i.e. if you didn't want the CCALIB module, you could build like this:
cmake -DBUILD_OPENCV_CCALIB=OFF [other cmake flags] ../
Manipulating build flags may not cover all the module exclusions you would like, however, it's probably a good place to start. To see the list of flag options, open CMakeLists.txt file (top of the opencv source directory).
Turning on/off flags also won't break your builds as much as manually commenting-out code.
The OpenCV library has several modules, you might consider leaving out modules like 'highgui' and 'gpu', and maybe more depending on what you need and don't need. Anyhow, I am not quite sure what you need. Maybe you should use a different smaller library instead, as reading, writing, decoding, converting, etc are not really Computer Vision operations, like a Hough transform or a distance map
One you might consider is cimg btw, you can easily strip that one down as it simply just defines more and more functions as part of the cimg class.
Good luck!
I have an nascent iPad application, which stores "documents" internally on the device in the file system as a series of distinct files in a folder.
I'd like to try incorporating an import/export function through iTunes, using the features for OS 3.2 for this. I want to put all the document pieces that I keep internally into one container file for export.
So, smart folks of Stack Overflow: What's the simplest solution that will put a file hierarchy (or could be flat list in a pinch) into one file? There will not in theory need to be manipulation of the "archive"/container outside the app-- so random access isn't super important here, although it would be a bonus of course.
A tar file type thing springs to mind immediately. Roll my own? Any other thoughts or gotchas? (And if anyone can point me to code that reads/writes from a tar file, I'm all ears.)
Thanks!
Update: Made community wiki, since there's no single right answer here.
Try libarchive which is a friendly licensed, BSD derived (easier for iPhone OS) library for handling archive files.
I'm developing a BlackBerry application in which I need to unpack a zip file compressed with PKZIP. The package could have one file in it, or it could have 10; it will vary in each case. I know that the BlackBerry API has native support for GZip and Zlib, although I'm pretty sure that these methods aren't going to be helpful in my case. It doesn't look as if I can extract the individual files using these calls.
I've tried JZlib (http://www.jcraft.com/jzlib/), which compiled fine, but again it doesn't look as if the methods contained therein are going to allow me to pull the individual files.
It appears as if this is possible, as there's an application called Ziplorer (http://www.s4bb.com/software/ziplorer/) that claims to do perform this exact procedure. How they're doing it, however, escapes me.
So here I am after hours of Googling. I'm welcoming any insight into my problem with open arms.
"zip" algorithms are typically offshoots of the Lempel-Ziv-Welch algorithm. They are a fairly efficient stream compression algorithms, but because of how they function, you can't start to decompress at random points in the file, you have to start from the start.
Any product that claims to be able to decompress one file from a zip still has to decompress everything before it in the zip file in order to know how to decrypt the given file, or even, for that matter, where the file is in the archive.
If you can tolerate GPL code in your application, then this library http://jazzme.sourceforge.net/ that might work. However the project (and its parent project http://sourceforge.net/projects/jazzlib/) don't look like they're being developed.