JRE ultimate streamlining exploration manual [1]-streamlining a swing real-time strategic game

 

In this example, the greenjvm direct compression after the streamlined green version of the game: http://download.csdn.net/source/612943

This example describes the actual steps for streamlining a Java application and selects the small Java instant strategy game apodefence as a use case.

The author information can be found:

If you are interested, you can download it as a reference.

Apodefence is a 2D real-time strategic game made in Java. The game themes are reinforcement of the home fortress and protection of the home castle. Although the functions provided by the author are far from complete compared with commercial games, however, the basic elements of real-time strategic games, such as small maps, selecting objects, building, repair, damage, timing, building upgrades, and multi-weapon collaboration, the interaction between the enemy and me and the map editing are all displayed in this game. This program is a good reference example for developing Java real-time games.

The apodefence file consists of two parts: apodefence. jar and the script map in the levels folder. The total size of the two files is 734kb.

It should be said that if it is always so large, it will be placed on the same-person game site, downloads will never be lost to similar games developed in other languages.

Game interface 1:

Game interface 2:

Unfortunately, this game was developed in Java. It would be hard to run without the support of dozens of megabytes of virtual machines.

If you see such a small game, remember that it is just a small game. It seems to be fun, but you need to download installation programs of dozens or even dozens of megabytes. Are you interested in trying it? I believe most people have no answer, so I started to try to streamline it.

Step 1: organize your Rt. JAR File

We all know that the full version of JRE is very large, and its folders are filled with countless DLL, jar, and properties configuration files. But the file is the largest and most occupied space, the first RT. jar files are not.

Taking Rt. jar in jre1.6 as an example, it occupies nearly MB of hard disk space with only one jar, which is undoubtedly a monopoly and severely compresses the same type of living space in other jar ~~~

I posted an article on my blog two days ago about this (streamlining the size of JRE). I provided an article named greenjvmmake. jar 6 kb applet, which can accurately record the classes called by each startup Java program and RT. jar class ing, and generate a rt that only carries the call class after the program is executed. jar.

So, we have to streamline Rt. jar.

First, create a simple bat batch processing file with the following content: Java-jar greenjvmmake. jar-t da-I./apodefence. jar-o ./

In order to call the apodefence. Jar graphical program and output the simplified Rt. Jar locally.

As we can see, with our operations, all called classes have been recorded. In fact, most of the components will be reused, as long as several typical interfaces are run, you can package all the classes used by the entire program without having to go through customs.

Now let's take a look at the results. A "monster" with an original size of nearly MB, how much is left in this swing game environment? 20 mb? 10 MB? No, it is much smaller than that. The answer is only less than 3.2mb.

Can such a small library run this swing game? We can try it on the local machine first.

As a result, the answer seems to be positive, and we have simplified it. But is that true? Not necessarily. Let's release the program to a machine that has never configured a Java environment.

PS: This example uses self-made greenjvm as a virtual machine boot program, see: http://blog.csdn.net/cping1982/archive/2008/08/21/2806598.aspx

We can clearly see that although the author's ugly face has been loaded after the startup ~ | ...... However, greenjvm prompts us an exception at the same time, indicating that the sun. Font. standardglyphvector class cannot be found. But we have a good local debugging. Why?

In fact, the reason is very simple: Our JRE is configured for the system environment, not the B system.

We all know that when we develop a Java program or a JRE, different operations are performed on different systems to maximize the cross-platform Java features, thus improving the Java execution efficiency in the local environment.

However, when we use greenjvmmake. jar for rt. after the jar is simplified, only the classes required in the local environment are obtained, but not all the classes are common in the environment. This is also the cause of exceptions. So what should we do?

In fact, it is a good solution. First, because we use our own JRE, there will never be version conflicts. No matter how the call method is, the final result is definitely produced by a specific version, that is, it is impossible to worry about version optimization and lack of class libraries. Second, in fact, there are not many configuration changes for different environments. The most common one is language and font. The typical exception is the font package exception we just saw. Most of these exceptions are caused by the unsupported local environment of the existing Java font library. For programs used in different environments, when streamlining, We can deliberately retain all font and all corresponding classes customized for different languages, such as zh_cn and EN (English programs do not need to retain all language support ), in this way, although the program volume is slightly larger than before, it can fundamentally solve the problem.

Now, I am replacing the simplified RT. jar re-copy all the font support classes (this part is in greenjvmmake. jar has added the function of retaining the specified library completely. because there are too few changes and it is not released yet, CTRL + C and CTRL + V are not troublesome ).

Simplified Rt. Jar size after replacement

Step 2: delete unnecessary EXE, DLL and all other configuration files.

This step is simple and easy. It is troublesome to say that rt is simple. jar is not called, except JVM. DLL (which calls everything), we can simply delete it. The trouble is that no tool has provided such a function so far (consider writing one ), now we can only determine whether these files will be rt based on experience. jar is called. I want to write this part and try again. I want to sell it first. However, you can note that these file names usually correspond to each other.

Step 3: compress the simplified JRE

 

There are two ways to choose from.

 

1. Use install4j and other tools to create a streamlined JRE.

 

I suggest using install4j. This is the most comprehensive installation package creation tool for Java software so far. I personally use version 4.1.4.

 

Take install4j as an example.[Create a JRE bundle]To create a custom JRE package.

 

 

 

Select the simplified JRE path, version, and extension name (for install4j recognition ).

 

In this case, install4j has two different compression methods for jre: Direct Compression for versions earlier than jre1.5 and pack200 compression jar for versions earlier than jre1.5, compress the data into a JRE package.

 

When we use versions earlier than jre1.5 to compress the JRE package, there is usually no problem, because install4j only compresses a GZ file.

 

 

As shown in, JRE compression is successful for versions earlier than jre1.5. The final generated file is located in the jres folder under the install4j directory. The size of the JRE file generated in this example is about 5 MB.

 

When we use jre1.5 or a later version to compress the JRE, the problem arises because install4j will call pack200 to compress the jar.

 

For a complete JRE package, having pack200 related functions is certainly not a problem, but it is not necessary to use a streamlined JRE.

 

 

 

Look, install4j, which is still running normally, is on strike now. The keystore file, which must be supported by the class library in rt. jar.

 

No way. Create a complete small program that calls the pack class library, then generate Rt. jar with only dependent libraries, merge and package it into the custom Rt. jar, and run the program again. OK.

 

 

After jre1.5 and later versions packaged by install4j, JRE can be compressed quite badly. We originally compressed nearly 10 MB of files and then only a little more than 2 MB.

 

However, install4j is a paid software after all. In addition, green software is popular in the current environment, that is, a program without installing plug-ins and without modifying the registry or other system files ...... After all, we sometimes want to release Java programs as a green software.

 

2. Use 7-zip and other tools to create a simplified JRE.

 

 

Now, we create a JRE compressed package in 7z format.

 

First, we will learn the install4j method, and pack all the jar files in pack200. Since pack200 is a compression program customized for jar, it can minimize the file volume in JRE.

 

.

 

In fact, we use a compression tool to compress the JRE folder. In this example, we use 7-zip to compress the folder.

7-Zip is an open source code based on lzma method of free software, single file compression ratio, higher than RAR format: http://www.7-zip.org/

Then I will get a JRE. Now, this JRE package with a total size of about 5 MB is capable of running the swing game environment (compared with the JRE package compressed by install4j, this JRE compressed file is still large, and some mechanisms can be used to reduce the pressure, which will be introduced later ).

Regardless of the mechanism we adopt, the final release of this JRE will be kept within 5 MB.

Step 4: Package and release.

1. directly compress and Package

 

In fact, there is nothing to say. If you use a green Java program created by greenjvm, you only need to discard the JRE after using the program and then streamlining it. Double-click the EXE file and run it. I believe most people who have used computers still understand it ......

 

In addition, it should be noted that secondary compression of the same compression method will make it difficult to reduce the file again. For example, in this example, we pack JRE in 7z format, if the file is compressed again for the entire application, the RAR format is more suitable.

2. Use install4j for packaging and Publishing

Compared with most Java programs, the above green release version is quite small and can already meet the needs of most JAVA games (except for no sound, because the original game was not called), but compared with the program developed in the local environment, it is still too large for the user to accept it. In this case, we want to make it smaller, simple compression can no longer be used, rather than using the Installation tool to compress multiple compression.

Install4j is still used, and its view installation method is extremely simple. The authentic "Next" step can be done. The time relationship is not described in detail here, and you can directly jump to the set media file mode.

Because this example is developed based on the Windows system, only the Windows platform is supported.

 

After a series of next steps, select the JRE we created and static binding.

 

 

 

Finally, we chose to build an installer for Windows.

Look, this is the final result.

A swing instant strategy game of only MB. If we don't say this is a Java-developed program, how many other people can want to package a virtual machine with an executable program of only MB? In fact, it can be reduced to within 1 MB. (For the next reply)

Now, let's install it on a computer without a JRE.

Shell attacks, Lions run ~~~ Completely OK.

Next, we will look for factors that limit the size of JRE and further free it.

 

In this example, the greenjvm direct compression after the streamlined green version of the game: http://download.csdn.net/source/612943

 

(Due to some details of install4j packaging, the installation program is not released for the time being. To release the compressed JRE normally, you need to add some files, see release some items in temp during normal installation of install4j ~)