Bytecode is the output of compiled Java source code. It is a binary file format designed for efficient execution by the Java Virtual Machine (JVM). To see the bytecodes generated in a human-readable format, add the JDK bin directory to your system path. Then type:
javap -v my.class
This can be especially interesting when investigating how the results from a small source code change, either before or after Proguard obfuscation. We have several examples of this approach in this performance documentation, and encourage you to use this to test and understand the ultimate results of your performance improvements. For example, you might be surprised to find your own very long variable, class, and method names directly in the class file if you have not used Proguard.
If you look at the bytecode, you will notice that not all of the code you are executing is shown there. Some is in bytecode libraries that are part of the Nokia Series 40 platform, such as the many Java Specification Requests (JSRs) and Nokia’s own libraries. These have already been optimised and carefully developed for you, so your only performance concern should be to understand what they do and call them appropriately, on the right thread, with the right arguments and at the right time.
Another important part of the code on your Nokia Series 40 phone
that is not visible in your own .class files is the
native device drivers and similar libraries that are responsible for
things like networking, graphics and storage. This native code can
allocate memory, other resources such as image and network buffers,
and occasionally threads which aid the smooth operation of the relatively
simple API you call. You can, as in the case of network buffers, control
how the native code will operate and use resources, and this may have
a significant impact on memory usage and performance.