Android Resource

转自：[url]http://tech.ddvip.com/2010-05/1273125396152852_4.html[/url]

关于资源配置，以及选择的详情，参见SDK中的：guide/topics/resources/resources-i18n.html部分。

　　R类

　　在使用资源后，界面逻辑与底层逻辑的耦合被降低了，但这不意味着，两者没有关联了。比如，需要为某个按钮增加一个点击事件，就需要定位到所需的那个按钮；再比如，你需要使用某个字符串资源，通知用户某件事情，就需要能定位到资源中放置的该字串。

　　最显而易见的一种方式，就是通过字符串比较，用名字信息在资源的xml描述文件中定位到所需的内容，加载并使用。这种方式，解决了查找的问题，但反复的字符串比较，势必带来严重的效率隐患。因此，在Android中，类似于Symbian的方法，引入了一个R类。

　　它的基本思想是，通过增加一个额外的编译器，为所有的资源项，都赋予一个32位的整形数来表示，同一个资源像的不同配置，都使用同一个id。这个整形数，就相当于这个资源项的门牌号码，能够帮助定位到对应的资源项。所有的这些整形数，都以常量的方式，整合到一个Java类中，这个类就是R类。这样，在程序中，就可以通过使用这个R类，来查找所需的资源，这就将字符串比较，简化成了一个整形数的比较，大大的节约了开销。

　　不得不说，这整套逻辑和Symbian中的资源文件预编译一致。但两者很不同的点在于Symbian中的整形数，代表的是一个二进制流的偏移量，资源中的内容在编译时决定了。而Android中的整形数，是一个有逻辑意义的数值，它表达了这个资源所处的资源包，类别，和脚标，它的具体内容在运行时才确定，这使得它的灵活性大大增强，付出的则是一定的效率代价。实现

　　按照惯例，还是要说实现的，以一个查找流程为示例。当在Activity中需要使用字符串的，会调用它的getString方法，传入R.stirng.xxx的一个整形数，换取一个符合当前机器环境配置的字符串。

　　getString，追根溯源，来到AssetManager类中。Asset类，其实是一个空壳，它仅仅是提供了一些便利的接口，而将请求，通过JNI的接口，传入到了底层C++实现的类库中。

　　在底层的实现，主要是在C++实现的，AssetManager，ResourceTypes等等之中。其中：

　　JNI文件在：framework/base/core/jni

　　头文件在：framework/base/include/utils

　　CPP文件在：framework/base/libs/utils

　　具体实现，和前述的算法逻辑是一致的。每一个资源的id，32位，高8位表示资源包，低16位用于描述脚标，中间8位，用来说明类别。所有资源中的文件，都被预处理了，放入到了一系列的队列和表中，通过id，可以查到具体的位置。然后根据缓存的环境设置对象，跑一次淘汰算法，获得匹配的资源对象的对应文件和偏移量。然后将值读取出来，通过JNI接口，拷贝回去。

　　以上这些描述，并不能帮助了解真实的实现细节，主要是为了促使大家对读取资源的效率有一个比较直观的认知。整个资源读取的流程比较长，但是实现在C++中，可以预想，效率比Java高一些，开发人员，应该能够根据自己的需求，决定是否将内容写入资源文件中（还是写在代码中...），是不是需要自己稍微缓存一下，诸如此类。