FAQ

 

What are the system requirements?

When operating in standalone mode mBooster requires:

  • Windows XP or Windows 2000
  • Pentium 4 2GHz CPU or equivalent
  • 512MB free memory (Recommended 1GB installed memory)
  • 30MB free hard disk (Recommended 60MB)


When operating as a remote server, mBooster Remote Access Server and mBooster require:

  • Windows XP or Windows 2000
  • Pentium 4 2GHz CPU or equivalent
  • 768MB free memory (Recommended 1.5GB installed memory)
  • 30MB free hard disk (Recommended 4000MB)

 

How is mBooster different from an obfuscator?

The core functions of an obfuscator are

  • Removing methods and fields that are not required
  • Renaming methods, fields and classes to shorter names.

At the core of mBooster is an optimizing compiler. It is designed to support complex optimizations that you would expect in an optimizing compiler for a non-java platform, such as GCC. mBooster therefore is capable of performing a much greater range of optimizations that goes way beyond renaming. The optimizing compiler is complemented by a custom-built preverifier, designed to minimize the size of stackmap.

The mBooster optimization suite also includes mBoosterZip, mBoosterPng and mBoosterM3G. mBoosterZip is a ZIP/JAR deflater delivering the highest compression ratio and the smallest JAR file. mBoosterPng delivers maximum PNG recompression and is complementary to all standard PNG optimizers. mBoosterM3G delivers maximum M3G file recompression.

 

How much size reduction does mBooster deliver?

Tests on more than 100 commercial off-the-shelf Nokia series 40 and Nokia series 60 games have reported a median classfile size reduction of around 15% and median jar size reduction of around 12% for Nokia Series 60 games. As expected there are significant variations between the amount of size reduction achieved on individual games. On all tested games we are able to significantly reduce the size, in some cases more than 25% of the jar size.

The exact amount of size reduction is reflective of the characteristics of each mobile game. Games programmed in certain programming styles are more optimizable. Heavily manually optimized games are less optimizable.

Please also see the FAQ entry: How can we maximize size reduction?

 

Do we need to change our programming style to make best use of mBooster?

Generally no. However certain programming idioms and constructs are very costly without mBooster; experienced J2ME programmers would avoid these constructs and employ workaround solutions instead. An example is to manually consolidate the classes into a smaller number of classes. mBooster includes a number of advanced optimizations making these manual work-arounds obsolete. Please see Optimizations. for details.

Please also see the FAQ entry: How can we maximize size reduction

 

Does mBooster support reflection?

mBooster supports the use of reflection in J2ME midlets. mBooster cannot precisely detect reflection and so relies on configuration from the user to indicate what classes are reflected via the REFLECTEDCLASSES property. mBooster now will warn the user when reflection is detected and will report an error if reflection is not configured completely.

 

Could mBooster optimize DoJa or CLDC 1.0/1.1 or MIDP 1.0/2.0 applications?

mBooster is agnostic with respect to the system libraries. mBooster works equally well with DoJa applications, CLDC 1.0/1.1 applications and MIDP 1.0/2.0 applications.

 

Our application requires a vendor specific/handset specific API, could we use mBooster?

mBooster is agnostic with respect to the system libraries. mBooster works with any vendor specific/handset specific libraries.

The LIB.CLASSPATH property must be defined to include these system libraries.

 

We use third-party libraries that are incorporated into the SKU, could we use mBooster?

mBooster works with any third party libraries. mBooster does not require the source code of the third party libraries. Through whole program optimizations, mBooster will deliver size and performance advantages by analyzing and optimizing the interactions between the third party libraries and your proprietary classes.

The APP.CLASSPATH property must be defined to include these third party libraries.

 

How can we maximize size reduction?

mBooster is highly configurable. The default settings will provide reasonable size reduction, however you could consider the following modifications for even higher size reduction:

  1. Configure your obfuscator to combine all Java packages into a single package. mBooster class merging optimization does not merge classes in different packages. By instructing the obfuscator to combine the packages you create many more class merging opportunities.
  2. If the class merging optimization is enabled (OPT.CLASS.MERGING=ON) and operating in Simple mode, setting CLASS.MERGING.SIMPLE.LEVEL to a higher number will result in more opportunities for class merging. Alternatively in heap constrained situation consider using Advanced mode.
  3. If the class merging optimization is enabled (OPT.CLASS.MERGING=ON), setting the property CLASS.MERGING.NOCHECK.CLINIT.ORDER=ON can greatly increase the class merging opportunities and significantly reduce the output JAR size. However please first carefully read the documentation on CLASS.MERGING.NOCHECK.CLINIT.ORDER to see if the conditions apply.
  4. If the resource packing optimization is enabled (OPT.RESOURCE.PACKING=ON), and the application is not accessing the resource files with complex paths, then consider setting the property RESOURCE.PACKING.PARSE.COMPLEX.PATHS=OFF. This can reduce the JAR size by up to 600 bytes. Pease refer the documentation on RESOURCE.PACKING.PARSE.COMPLEX.PATHS to see if the conditions apply.
  5. Turn on PNG recompression optimization by setting the property OPT.PNG.RECOMPRESSION=ON. Alternatively recompress the PNG files prior to running mBooster using the standalone mBoosterPng utility.
  6. Turn on M3G recompression optimization by setting the property OPT.M3G.RECOMPRESSION=ON. Alternatively recompress the M3G files prior to running mBooster using the standalone mBoosterM3G utility.
  7. If your application is already resource packed, please
    1. Optimize the PNG files and M3G prior to resource packing using mBoosterPng and mBoosterM3G utilities, prior to packing the resource files.
    2. Consider switching to mBooster automated resource packing optimization. Quite often mBooster automated resource packing optimization will produce smaller packed files than human optimized packed files.

 

How can we speed up mBooster?

mBooster is designed to provide maximum size reduction. Some mBooster optimizations are very computation intensive. Typically day-to-day builds may not require maximum size reduction but could benefit from a faster mBooster run-time. The following setting would help reduce mBooster run time:

  1. Switch the JAR compression method to STANDARD or 7ZIP by setting the property JAR.METHOD. The default compression method MBOOSTERZIP delivers the highest compression ratio at a high computation cost.
  2. Enable the FAST property, to switch to using faster algorithms in steps 14, 16 and 40. By setting this property 10% to 40% improvement in overall execution time can be achieved at the cost of typically <100 bytes less JAR size reduction.


mBooster contains partial result caching. The intermediate results are cached to speed up subsequent mBooster runs on the same application (or variants). Note: mBooster Evaluation Version disables this feature.

On a computer with 784MB memory (at least 512MB free memory) and an AMD XP2500, when mBooster result caching is enabled it takes on average 1.5 - 4 minutes to optimize a Nokia series 60 commercial game on the above recommended property settings on subsequent runs. If mBooster is taking significantly longer, it is likely due to inadequate available memory. Please refer to this FAQ entry for a suggested work-around.

 

mBooster reports an OutOfMemoryError, but I have a lot of memory in my system?

mBooster is constrained to not consume more than 512MB of memory due to a need to avoid excessive paging of the hard disk, and this is fine for optimizing most applications. On systems with 1GB or more RAM, large applications can be optimized more quickly by raising this limit with a special windows environment variable. Please see this section: Controlling memory use.

 

mBooster pages the hard disk constantly, or appears to stop running, what can I do?

mBooster requires 512MB of free memory. If your computer does not have adequate physical memory, mBooster can cause constant memory paging, and result in a greatly deteriorated mBooster run time.
You may be able to run mBooster on low memory systems by setting a limit to how much memory mBooster is able to use. Please see this section: Controlling memory use

 

The mBooster optimized version of our application does not run on the emulator.

The most common cause of this problem is the use of reflection capabilities within the application. If your application does use reflection, you must specify the set of reflected classes through REFLECTEDCLASSES properties.

Please also see the next FAQ entry.

 

The mBooster optimized version of our application runs on the emulator, but does not on the handset.

The most common cause is that the optimized version has run out of heap memory. We recommend that you check for out of memory errors using an emulator. If the optimized application had indeed run out of heap memory, it is likely a result of Resource Packing optimization and/or Class Merging optimization

Resource Packing is a powerful optimization, but must be used with care with heap memory constrained applications. Please refer to this section on how to avoid this issue.

Class merging must also be used with care with heap memory constrained applications. Please refer to this section on how to control heap memory usage with respect to class merging.

Please also see the previous FAQ entry.

 

Does mBooster treat classfile and resource file filenames in a case sensitive manner?

Java specifications specify that class names are case-sensitive. mBooster internally complies with the Java specifications and respects the case-sensitivity of all resource files and classfiles.

 

However the file system in Microsoft Windows is case-insensitive. If mBooster is instructed to invoke an external program such as 7-Zip or an external preverifier, it must save the intermediate results onto the file system. Due to the case insensitivity of the file system, if there are multiple files with the same name but in different cases, they would conflict and the subsequent behavior is undefined. If your application have multiple files that would conflict in a case-insensitive environment, please configure mBooster in the following way to avoid calling external applications:

 

We have identified a bug / we have a game that does not optimize well. What should we do?

Great! We would love to fix the problem. If it is possible please send the jar file to us mbooster-support@innaworks.com together with the property file and information on the operating environment. We appreciate your assistance to help us track down the problem.

 

What optimizations does mBooster perform?

Please see Optimizations.

 

Why doesn't mBooster implement our favourite optimization?

We would love to hear any feedback especially on how we can improve mBooster to work better for you. Please contact our R&D team on mbooster-support@innaworks.com. We look forward to a conversation to understand your requirements better.

 

— Previous page – Contents – Next page —