1 Very general, suitable for all Java programs: less string, multi-use StringBuffer2 Try to use the fixed size array instead of using VECTOR3 If you do not use the new class, you can implement the new Class because each class is Have a certain memory overhead 4 use limited object-oriented, because pure OOs often mean more imaginary methods, more levels of relationships, more Class5 consider using public domain (ie, data members) instead of getter and setter6 pairs Determine that the method that does not have to be inherited is used to use the Final Model 7 to use BufferedInputStream or BufferedReader to encircle the input stream 8 to use the obfuscator to handle your classes, in addition to prevent others from compiling your programs, you can reduce the size of the class file. Because the obfuscator often replaces the original variable or method name with a shorter string. --Rocks ********************** * People swooping. * * To play is human. * *******************************
Reprinted from www.cnjm.net
If possible, consider some libraries provided by Siemens, such as GAME, MMC, etc., can significantly increase the speed, but the cost is not good compatibility.
--ASMAIR
My principle is such two of them: 1. It is pre-processed in the PC machine to form a static data structure on the PC machine, and then use the simple algorithm to use the simple algorithm. 2. It is necessary to pay attention to: Repeated frequent operation is a bottleneck of performance. It is very worthwhile to work above. For example: a loop once a time takes only 10ms, if you don't pay attention, let it cost 20ms (at this time you may not feel a problem, only a small 10MS). Suppose this loop is very frequent, accounting for 30% of the total time of software running, then, this will reduce the overall speed in uncomfortable. So the solution is first to check the performance bottleneck of the software, and then the next medicine.
- Leelong
Optimize it with Borland Optimizeit Suit Enterprise, do you have any of her registration code? Borland gives me the trial license expires, can't use, and I have found a few crack things, all the names are not realistic, fire page ! If you have a registration code, please raise your hands! !
--Zmg229
I also have two questions: 1, using objects to encapsulate data will not significantly affect speed, such as using objects containing a variety of different types of properties while entering output, rather than raw integers. 2. Display call system.gc () is not possible to quickly speed up the program running speed.
- fuchs
1. It is not very obvious, but it must have an impact, it is necessary to resolve significant places that affect performance, and the optimization of the details should be the last thing. 2. It should be reduced, but you can optimize memory. Use
--Rocks
To Rocks: 1. For your article: Will you increase memory overhead with inner class? 2. For your article 5: Because we doing the mobile phone program, security is the first, so I suggest you remove the fifth! - AnonimousBoy:
To anonimousboy: 1 Inner Class, you will generate a separate class file, such as MyHostClass $ MyinnerClass.class, even if it is anonymous. 2 Imagine that PUBLIC Field will affect security, huh, the primary purpose of getter and setter is to enhance the encapsulation of objects, not considering security. 3 If the real safety and performance can be contradict, then according to the specific problem, it is specifically analyzed. If it is a securities software, there is no doubt security is the most important. If it is an instant action game, that performance should Is the question of the top consideration. Just for Your Infomation:) - Rocks I just learned J2ME. Not long, the following points are based on some of my talk to Java language characteristics, the heroes are more advised A: For the problem of the processor speed: try to use Array, less useful objects, even if you want to specify the initial space according to its true expected size, the program on the mobile phone is not large, usually we can consider some details, pre-envisioned B: For memory Less problems: 1. Sometimes to sacrifice some object-oriented features, use less class to implement the program 2. Implement the function as possible, so that you should spend a lot of space on the stack 3. Leave the god, With the appropriate data type, don't be as big as it is on the desktop, since the poor is diligent, good habits are the most important, and you should use the object as little as possible, more basic types 4. When you let go, let go, lose NULL gives an object, don't rely on GC (do you think of a GC doesn't have money?), Don't let GC are too busy 5. ...... I will think about it again ...
- yuanaoe
Agree 1, do not agree 2, actually the function stack does not waste time. Function is the most important, and the method may bring more code waste. Agree 3, each empty class has 200 bytes of space. Disagree 4, you give null just eliminate its connection, the object does not release, or wait for GC, but if it is called GC, no matter whether it is null, as long as it is no longer used, it will release it.
--Horsthief
Give NULL, is it the same as the efficiency collected by NULL? And the GC compared to the GC in the CLDC is compared to the GC in J2SE, whether it is efficiency or safety.
--Yuanaoe
Don't use the obfuscator, it may cause the program to run correctly. The speed is the most critical, while the size is not a big problem, because the size of the memory is very fast.
--Bobyyuan
I am talking about my own experience. If you must use multiple threads, try to reduce the number of thread switches, which can significantly improve program speed. The method is as follows: Class mythread extends thread {... public void Run () {while {setPriority (thread.max_priority - 1); ... ... setpriority (thread.min_priority);}}}
--Fuchs
- Jacksun
Optimized J2ME program size by Eric Giguerefebruary 27, 2002
To distinguish the J2ME program from the J2SE program, its basis is the restricted environment where J2ME runs. Most J2ME systems' main limited conditions are the size of the memory required to store and run the program. For example, many MIDP devices limit the size of not more than 50K, which is far less than those of the Server-end J2SE running environment. In practical applications, the program will easily exceed these restrictions. Through this article you will learn some techniques to reduce the size of the program, and practice these technologies in the examples below. This example MIDlet only displays a text box and vocal when its content changes. package com.j2medeveloper.techtips; import javax.microedition.lcdui *;. public class BeforeSizeOptimization extends BasicMIDlet {public static final Command exitCommand = new Command ( "Exit", Command.EXIT, 1); public BeforeSizeOptimization () {} protected void initMIDlet () {getDisplay () setCurrent (new Mainform ());.} public class Mainform extends form {public Mainform () {super ( "Mainform"); addCommand (exitCommand); append (textf); setCommandListener (new CommandListener ( ) {Public void CommandAction (Command C, Displayable D) {EXITMIDLET ();}}}}); setItemStatelistener (new itemStatelistener () {public void itemStateChanged ( Item item) {if (item == textf) {alerttype.info.playside (getDisplay ());}}});
Private textfield textf = new textfield ("Type Anything", NULL, 20, 0);}} Although this MIDlet is only an example, the size optimization technique used can be applied to the Profile of J2ME. Note that the above requires the following MIDlet class helper classes:.. Package com.j2medeveloper.techtips; import javax.microedition.lcdui *; import javax.microedition.midlet *; public abstract class BasicMIDlet extends MIDlet {private Display display; public BasicMIDlet () {} protected void destroyApp (boolean unconditional) throws MIDletStateChangeException {exitMIDlet ();} public void exitMIDlet () {notifyDestroyed ();} public Display getDisplay () {return display;} protected abstract void initMIDlet (); protected void pauseApp () {} Protected void startapp () throws midletStateChangeException {if (display == null) {display = display.getdisplay (this); InitmIdlet ();}} When packaged with J2ME WTK, this example MIDLET takes up 4K space. The primary step of reducing the size is to remove excess classes through the functional implementation of the procedure. Does all the functions of the program do to be implemented? Can users do not need these "accessory features"? To design as little program as possible, the MIDlet example here is quite small.
The second step is to in-depth inspection of the internal classes defined by the program, especially anonymous classes. Remember, each class file has a certain amount of system overhead related to system. Even if the most common class also has system overhead. Public class foo {// Nothing Here} Compile the class, the generated class file is approximately 200Byte size. For example, implementing an event listener is common to use the anonymous class. Two such listeners are defined in the example MIDET. The simplest optimization of the next step is to let the main MIDlet class implement CommandListener and ItemStateListener interface and move the listener code here. Remember, multiple objects can use the same listener. If necessary, you can use the parameters passing to the CommandAction and the ItemStateChanged method. The internal class can also make the code too large because the compiler must generate a special variable and method so that the internal class can access private content that contains their classes. Please refer to the specification of the internal class to get more information.
Step 3, try to use existing classes. For example, CLDC-based Profile does not construct a set class, so we can implement it with a built-in HashTable and VECTOR class. This method can also be used when constructing the MIDP program. An example midlet defines a form class to generate a primary table, which can be easily generated as follows: mainform = new form ("mainform"); mainform.addcommand (OkCommand); mainform.setcommandlistener (listener); there is not correct or wrong here The answer is just to be built. The fourth step is to damage the inheritance relationship of the program. You may put the relevant code in one or more abstract classes, which is the recommended practice for improving the programcode code reuse in OOD. Although the damage inheritance relationship is contrary to the knowledge you have learned, the simplified inheritance relationship is more meaningful. Special, when your abstract class - may come from other items - only inherited once, the result of destroying inheritance relationship is self-evident. For example, an example MIDLET inherits a BasicMIDlet class, but both merge into a class.
The fifth step is to shorten the name length, such as the name, class name, method name, and data element name. It looks a little stupid, but a class file does contain too many symbol information. Shorten the names of the names that reduce the size of the generated class file. This savings will not be particularly obvious, but the sum of the total additions in multiple classes is still considerable. The name of the package is particularly appropriate to reduce the size. The MIDP program is completely self-inclusive, it is totally free of use, because the package name on the handheld device is not possible to conflict with other class names. In the example MIDET, you can remove the com.j2medeveloper.tchtips. Note that generally, the shortening name does not need to be manually do, and use a "obfuscator" to do. The main function of the "obfuscator" is "hidden" program code so that it cannot be read by reverse. Its side effect is to reduce the size of the program. Because the hidden process is mainly done primarily by changing the names of the method and the data member. There is an open source confusator called Retroguard, you can get free from http://www.retrological.com. There are also some commercial packages available. (When the CLDC-based Profile is confused, remember to confuse before the pre-calibration, otherwise the obfuscator will make the pre-calibration data in the class file.)
Finally, in-depth initialization. (Example MIDlet does not do an array initialization, but the initialization of the program is important to compile, one array initialization declaration is as follows: int Arr [] = {0, 1, 2, 3}; and actually generate code The process is as follows: Arr [0] = 0; Arr [1] = 1; Arr [2] = 2; Arr [3] = 3; this process can be binary code by using JavaP tools attached in Java 2 SDK Referior to classified (using the -c option). Maybe you will be surprised to see the content, especially when you want to see a row of row binary constants. There are two ways to let you see the anti-compiled program code, (1) encoding the data as a string, runtime decoding, or (2) sack the data as binary and packaged, with the class loader The getResourceAsStream method is accessed at runtime.
The above is just some guiding methods, and for each J2ME program, there is no specific step here. But most methods can be applied. MIDlet optimized as follows: import javax.microedition.lcdui *; import javax.microedition.midlet *; public class ASO extends MIDlet implements CommandListener, ItemStateListener {private Display display; private form mainform; private TextField mainformTF = new TextField.. ("Type anything", null, 20, 0); public static final command exitcommand = new command ("exit", command.exit, 1); public ASO () {} public void command (Command C, Displayable D) { if (c == exitCommand) {exitMIDlet ();}} protected void destroyApp (boolean unconditional) throws MIDletStateChangeException {exitMIDlet ();} public void exitMIDlet () {notifyDestroyed ();} public Display getDisplay () {return display;} protected void initmidlet () {mainform = new form ("mainform"); mainform .addCommand (exitCommand); mainform.setCommandListener (this); mainform.setItemStateListener (this); mainform.append (mainformTF);. getDisplay () setCurrent (mainform);} public void itemStateChanged (Item item) {if (item == mainformTF) {AlertType.INFO.playSound (getDisplay ());}} protected void pauseApp () {} protected void startApp () throws MIDletStateChangeException {if (display == null) {display = Display.getDisplay (this); initMIDlet ( }}}
