8

why , the resources are converted into HEXAdecimal , does it create some fast access to your resources for app .

ShreeshaDas
  • 2,032
  • 2
  • 15
  • 34
user2125918
  • 97
  • 4
  • They're not converted into anything. You just happen to be viewing them as hexadecimal. It might equally be octal or indeed binary, which is what they really are. – Simon Mar 02 '13 at 07:23

3 Answers3

8

R.java is nothing more than a class file with a static constant for each resource in your project. The constant is an index number into what is effectively a file system. So myicon.png is given a file number of 12345. The resource manager uses this index to load the resource at run time. Open it up. Take a look.

Let's look at an example R.java:

public final class R {
    public static final class id {
        public static final int myTextView=0x7f090008;
    } 
}

I can reference myTextview using:

findViewById(R.id.myTextView) - constant
findViewById(0x7f090008) - hex
findViewById(2131296264) - decimal
findViewById(017702200010) - octal
findViewById(0b1111111000010010000000000001000) - binary

They are all equivalent.

Equally, I could code my R.java file like this:

public final class R {
    public static final class id {
        public static final int myTextView=0b1111111000010010000000000001000;
    } 
}

It still works.

Nothing is "converted", you are just using a constant to reference the index number. The compiler takes care of it. You just happen to be viewing it as hexadecimal but ultimately, as is everything in your app, it's just ones and zeros.

The only reason for doing this is so that you can use the constants. Imagine maintaining your code if you had to use the actual index values, especially given that they may, and will change every time you rebuild R.java.

The index numbers are not memory addresses, or offsets, or a special kind of cheese. They are simply constants, generated by the compiler, to enable you to access resources using human friendly names.

Simon
  • 14,029
  • 6
  • 43
  • 60
2

The R.java file is generated by the Android Resource Manager Android asset manager packer(aapt.exe) and contains references to all resources of your app. Each reference is a unique id (public static final int). These constants are written to the R.java file in hexadecimal format.

Manoj Kumar
  • 1,482
  • 3
  • 19
  • 40
Danny
  • 1,050
  • 3
  • 11
  • 26
-2

It's kind of architectural from android perspective. when you develop the Android application and just build the code(not installed on the device/emulator) at that time the resource manager allocate the unique address to all the resources. Once the application is installed on the device the actual memory allocation will happen and this file will help Android to map the actual memory required for it.

Hope this answer your question

Dinesh Prajapati
  • 8,719
  • 5
  • 27
  • 47
  • but , do you think about this .... a single bit addressic_action_search=0x7f020000; ic_launcher=0x7f020001; A single bit address is enough for creating difference . – user2125918 Mar 02 '13 at 06:14
  • 2
    I can't wait to hear your explanation of how the compiler on my PC uses the DVM on my phone to build these "memory addresses". It also seems to work when I don't plug my phone in! Amazing! – Simon Mar 02 '13 at 07:41
  • @user2125918 : It's only the address it stores the other piece of the memory is given from the heap. you just imaging if every thing is allocated on compile time then application size will be of huge size – Dinesh Prajapati Mar 02 '13 at 10:53
  • @Simon : R.java is just a memory map created while compilation so when actually you deploy that on the device it will replicate that in the device memory according to the device heap allocated. hope that helps – Dinesh Prajapati Mar 02 '13 at 10:57
  • 1
    @Drax Your understanding or R.java is way off the mark. It's nothing of the sort. See my answer for a brief introduction. – Simon Mar 02 '13 at 14:03