Android应用程序主要由两部分内容组成：代码和资源。资源主要就是指那些与UI相关的东西，例如UI布局、字符串和图片等。代码和资源分开可以使得应用程序在运行时根据实际需要来组织UI。这样就可使得应用程序只需要编译一次，就可以支持不同的UI布局。这种特性使得应用程序在运行时可以适应不同的屏幕大小和密度，以及不同的国家和语言等。在本文中，我们就简要介绍Android的资源管理框架，以及制定学习计划。
在软件开发中，说到代码与资源分离，最容易想到的可能就是Web开发了。在Web开发中，我们一般会通过CSS文件来描述HTML页面的展现形式，也就是通过CSS来控制HTML页面的UI。这样就可以很方便地进行Web开发和维护。例如，当我们要更改HTML页面的UI时，只要修改相应的CSS文件就可以了。注意，这些CSS文件都是在运行时加载的。这样我们就可以根据HTML页面的运行环境来加载不同的CSS文件，例如，根据不同的地区或者语言来选择不同的CSS文件，从而实现国际化。
再来看PC客户端软件的开发。开始的时候，微软的MFC应用程序框架非常流行。在开发MFC程序的时候，代码和资源同样也是分开的，例如，程序的界面一般都是通过一个RC文件来描述的。不过我们一般都是在Visual Studio里面通过可视化界面来编辑RC文件的，即一般都不会直接手动去操作RC文件，所以我们一般都不怎么意识到其实RC文件和CSS文件一样，都是用来描述程序的界面的。实际上，RC文件和CSS文件一样，都是可以看作是一个界面配置文件，而且它们的配置信息都是通过文字来描述的，只不过这些文字描述要遵循一定的规范。
随着PC客户端软件的发展，微软的MFC应用程序框架显得有些力不从心了，其中的一个原因就是它的界面比较丑陋。如果要对MFC应用程序的UI进行美化以及个性化的话，是要费比较大的劲的，这严重地影响了软件开发效率，特别是不适合要进行快速迭代开发的互联网客户端软件。微软后来又开发了另外一套应用程序开发框架WPF。WPF同样是使用一种称为XAML的文件来描述应用程序的界面的。实际上，包括现在Win 8的Metro界面，也同样是通过XAML文件来描述应用程序界面的。XAML文件是一种XML文件，它具有更好的可读性，非常方便编辑以及维护。
在PC客户端软件的发展过程中，还有一种不得不提的应用程序框架——QT。QT最初由Trolltech公司开发，后来被Nokia收购。随着Meego的没落，如日冲天的Nokia也没落了，Qt又被卖给了芬兰的另外一家IT服务公司Digia。QT也算得是一套优秀的应用程序框架，而且它是跨平台的。QT同样也是通过一种称为QML的文件来描述应用程序的界面的，不过QML文件不是XML格式的，它的格式有点类似Web页面的CSS。
类似这种采用XML文件来描述界面的PC客户端软件开发框架其实还有很多，例如，迅雷用的Bolt界面引擎，以及腾讯QQ用的GF界面引擎，它们都同样是通过XML文件来描述程序界面的，并且做成代码和界面描述文件分离。
最后看iOS应用程序的开发，它的界面和代码同样是分开，并且通过一种称为XIB的文件来描述界面。XIB文件实际上也是一个XML文件，因此，它也是非常方便编辑以及维护的。
从上面的分析就可以看出，无论是Web应用程序，还是PC客户端应用程序，以及移动客户端应用程序，它们都无一例外地将代码与界面分离，并且界面都是通过描述性的文字来描述的，这种描述性的文字越来越倾向于使用XML格式。
Android应用程序作为一种移动客户端应用程序，它同样也是毫无意外地将代码逻辑和界面资源进行分离，但是它的资源管理方式与传统的Web应用程序和PC客户端应用程序以及iOS应用程序相比会更复杂一些，这是因为Android应用程序可能会运行在各种大小和密度不等的设备之上。接下来我们就将注意力集中在Android应用程序资源的组织和管理之上。
我们首先看Android应用程序资源的分类。Android应用程序资源可以分为两大类，分别是assets和res：
1. assets。assets类资源放在工程根目录的assets子目录下，它里面保存的是一些原始的文件，可以以任何方式来进行组织。这些文件最终会被原装不动地打包在apk文件中。如果我们要在程序中访问这些文件，那么就需要指定文件名来访问。例如，假设在assets目录下有一个名称为filename的文件，那么就可以使用以下代码来访问它：
|
1
2
|
AssetManager am= getAssets();
InputStream is = assset.open(
"filename"
);
|
2. res。res类资源放在工程根目录的res子目录下，它里面保存的文件大多数都会被编译，并且都会被赋予资源ID。这样我们就可以在程序中通过ID来访问res类的资源。res类资源按照不同的用途可以进一步划分为以下9种子类型：
--animator。这类资源以XML文件保存在res/animator目录下，用来描述属性动画。属性动画通过改变对象的属性来实现动画效果，例如，通过不断地修改对象的坐标值来实现对象移动动画，又如，通过不断地修改对象的Alpha通道值来实现对象的渐变效果。
--anim。这类资源以XML文件保存在res/anim目录下，用来描述补间动画。补间动画和属性动画不同，它不是通过修改对象的属性来实现，而是在对象的原来形状或者位置的基础上实现一个变换来得到的，例如，对对象施加一个旋转变换，就可以获得一个旋转动画，又如，对对象实施一个缩放变换，就可以获得一个缩放动画。从数学上来讲，就是在对象的原来形状或者位置的基础上施加一个变换矩阵来实现动画效果。注意，在动画的执行过程中，对象的属性是始终保持不变的，我们看到的只不过是它的一个变形副本。
--color。这类资源以XML文件保存在res/color目录下，用描述对象颜色状态选择子。例如，我们可以定义一个选择子，规定一个对象在不同状态下显示不同的颜色。对象的状态可以划分为pressed、focused、selected、checkable、checked、enabled和window_focused等7种。
--drawable。这类资源以XML或者Bitmap文件保存在res/drawable目录下，用来描述可绘制对象。例如，我们可以在里面放置一些图片（.png, .9.png, .jpg, .gif），来作为程序界面视图的背景图。注意，保存在这个目录中的Bitmap文件在打包的过程中，可能会被优化的。例如，一个不需要多于256色的真彩色PNG文件可能会被转换成一个只有8位调色板的PNG面板，这样就可以无损地压缩图片，以减少图片所占用的内存资源。
--layout。这类资源以XML文件保存在res/layout目录下，用来描述应用程序界面布局。
--menu。这类资源以XML文件保存在res/menu目录下，用来描述应用程序菜单，例如，Options Menu、Context Menu和Sub Menu。
--raw。这类资源以任意格式的文件保存在res/raw目录下，它们和assets类资源一样，都是原装不动地打包在apk文件中的，不过它们会被赋予资源ID，这样我们就可以在程序中通过ID来访问它们。例如，假设在res/raw目录下有一个名称为filename的文件，并且它在编译的过程，被赋予的资源ID为R.raw.filename，那么就可以使用以下代码来访问它：
|
1
2
|
Resources res = getResources();
InputStream is = res .openRawResource(R.raw.filename);
|
--values。这类资源以XML文件保存在res/values目录下，用来描述一些简单值，例如，数组、颜色、尺寸、字符串和样式值等，一般来说，这六种不同的值分别保存在名称为arrays.xml、colors.xml、dimens.xml、strings.xml和styles.xml文件中。
--xml。这类资源以XML文件保存在res/xml目录下，一般就是用来描述应用程序的配置信息。
注意，上述9种类型的资源文件，除了raw类型资源，以及Bitmap文件的drawable类型资源之外，其它的资源文件均为文本格式的XML文件，它们在打包的过程中，会被编译成二进制格式的XML文件。这些二进制格式的XML文件分别有一个字符串资源池，用来保存文件中引用到的每一个字符串，包括XML元素标签、属性名称、属性值，以及其它的一切文本值所使用到的字符串。这样原来在文本格式的XML文件中的每一个放置字符串的地方在二进制格式的XML文件中都被替换成一个索引到字符串资源池的整数值。这样做有两个好处：
A. 文件占用更小。例如，假设在原来的文本格式的XML文件中，有四个地方使用的都是同一个字符串，那么在最终编译出来的二进制格式的XML文件中，字符串资源池只有一份字符串值，而引用它的四个地方只占用一个整数值。
B. 解析速度更快。由于在二进制格式的XML文件中，所有的XML元素标签和属性等值都是使用整数来描述的，因此，在解析的过程中，就不再需要进行字符串解析，这样就可以提高解析速度。
还有另外一个地方需要注意的是，每一个res资源在编译的打包完成之后，都会被分配一个资源ID，这些资源ID被终会被定义为Java常量值，保存在一个R.java文件中，与应用程序的其它源文件一起被编译到程序中，这样我们就可以在程序或者资源文件中通过这些ID常量来访问指定的资源。
我们接下来再看应用程序资源的组织。应用程序资源的组织方式有18个维度，如图1所示：
图1 应用程序资源的组织方式
注意，图1的表格是来自于官方文档的，它的详细描述可以参考：http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources。这里有一点需要说明的是，表格中的18个维度是按照优先级从最大到小排列的，这个优先级次序可以帮助系统根据机器的本地配置来在应用程序资源目录中找到最合适的资源来使用。
具体来说，Android资源管理框架按照图2所示的算法流程来在应用程序资源目录中选择最合适的资源：
图2 应用程序资源的匹配算法
注意，图2的算法流程图是来自于官方文档的，它的详细描述可以参考：http://developer.android.com/guide/topics/resources/providing-resources.html#BestMatch。我们同样是通过上述官方文档中的例子来说明上述应用程序资源匹配算法的执行过程。
假设一个应用程序的drawable资源按照以下方式来组织：
|
1
2
3
4
5
6
7
|
drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
|
并且该应用程序所运行在的设置的配置情况如下所示：
|
1
2
3
4
5
|
Locale = en-GB
Screen orientation = port
Screen pixel density = hdpi
Touchscreen type = notouch
Primary text input method = 12key
|
根据图2所示的算法，Android资源管理框架按照以下步骤来选择一个drawable资源：
Step 1. 消除与设备配置冲突的drawable目录，即drawable-fr-rCA目录，因为设备设置的语言是en-GB。
|
1
2
3
4
5
6
|
drawable/
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
|
Step 2. 从MMC开始，选择一个资源组织维度来过渡从Step 1筛选后剩下来的目录。
Step 3. 检查Step 2选择的维度是否有对应的资源目录。如果没有，就返回到Step 2继续处理。如果有，那么就继续往下执行Step 4。在我们这个例子中，要一直重复执行Step 2，直到检查到language这个维度时。
Step 4. 消除那些不包含有Step 2所选择的资源维度的目录。在我们这个例子中，就是要消除那些不包含有en这个language的目录：
|
1
2
3
|
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
|
Step 5. 继续执行Step 2、Step 3和Step 4，直到找到一个最匹配的资源目录为止，即剩下最后一个目录为止。在我们这个例子中，下一个要检查的维度是screen orienation。由于设备的screen orienation为port，因此，所有不包含有port资源维度的目录将被消除：
|
1
|
drawable-en-port/
|
最后剩下来的目录就只有drawable-en-port，因此，它就是最匹配的资源目录了，这时候所有drawable类型的资源都可以从这个目录中获取。
注意，我们在编译和打包应用程序资源的过程中，会生成一个resources.arsc文件，这个文件记录了所有的应用程序资源目录的信息，包括每一个资源名称、类型、值、ID以及所配置的维度信息。我们可以将这个resources.arsc文件想象成是一个资源索引表，这个资源索引表在给定资源ID和设备配置信息的情况下，能够在应用程序的资源目录中快速地找到最匹配的资源。
最后，我们可以通过图3来总结应用程序资源的编译、打包以及查找过程：
图3 应用程序资源的编译、打包以及查找过程
通过图3我们就可以看出：
A. 除了assets和res/raw资源被原装不动地打包进APK之外，其它的资源都会被编译或者处理。
B. 除了assets资源之外，其它的资源都会被赋予一个资源ID。
C. 打包工具负责编译和打包资源，编译完成之后，会生成一个resources.arsc文件和一个R.java，前者保存的是一个资源索引表，后者定义了各个资源ID常量。
D. 应用程序配置文件AndroidManifest.xml同样会被编译成二进制的XML文件，然后再打包到APK里面去。
E. 应用程序在运行时通过AssetManager来访问资源，或通过资源ID来访问，或通过文件名来访问。
在接下来的一系列文章中，我们主要关注以下三个关键情景：
1. 应用程序资源的编译和打包过程；
2. 应用程序资源的初始化过程；
3. 应用程序资源的查找过程。
通过这个三个情景，我们基本上就可以了解Android系统的资源管理框架了，敬请关注。不过在阅读这个系列的文章之前，希望读者可以先了解一下Android应用程序资源的基础知识，因为这个系列的文章不会陷入到这些基础知识中去，具体可以参考以下官方文档：
A. http://developer.android.com/guide/topics/resources/index.html。
B. http://developer.android.com/guide/practices/screens_support.html。
