原文出处——>[Android资源管理框架(Asset Manager)简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/8738877)
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的文件,那么就可以使用以下代码来访问它:
~~~
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,那么就可以使用以下代码来访问它:
~~~
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所示:
![](https://box.kancloud.cn/eda1a4c9ef36e0bcd57efa10dffe1d12_572x536.jpg)
图1 应用程序资源的组织方式
注意,图1的表格是来自于官方文档的,它的详细描述可以参考:http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources。
这里有一点需要说明的是,表格中的18个维度是按照优先级从最大到小排列的,这个优先级次序可以帮助系统根据机器的本地配置来在应用程序资源目录中找到最合适的资源来使用。
具体来说,Android资源管理框架按照图2所示的算法流程来在应用程序资源目录中选择最合适的资源:
![](https://box.kancloud.cn/e8c306fd76b4cd8e0de05866acd6c452_361x461.png)
图2 应用程序资源的匹配算法
注意,图2的算法流程图是来自于官方文档的,它的详细描述可以参考:http://developer.android.com/guide/topics/resources/providing-resources.html#BestMatch。
我们同样是通过上述官方文档中的例子来说明上述应用程序资源匹配算法的执行过程。
假设一个应用程序的drawable资源按照以下方式来组织:
~~~
drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/
~~~
并且该应用程序所运行在的设置的配置情况如下所示:
~~~
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。
~~~
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的目录:
~~~
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
~~~
* Step 5. 继续执行Step 2、Step 3和Step 4,直到找到一个最匹配的资源目录为止,即剩下最后一个目录为止。在我们这个例子中,下一个要检查的维度是screen orienation。由于设备的screen orienation为port,因此,所有不包含有port资源维度的目录将被消除:
~~~
drawable-en-port/
~~~
最后剩下来的目录就只有drawable-en-port,因此,它就是最匹配的资源目录了,这时候所有drawable类型的资源都可以从这个目录中获取。
注意,我们在编译和打包应用程序资源的过程中,会生成一个resources.arsc文件,这个文件记录了所有的应用程序资源目录的信息,包括每一个资源名称、类型、值、ID以及所配置的维度信息。我们可以将这个resources.arsc文件想象成是一个资源索引表,这个资源索引表在给定资源ID和设备配置信息的情况下,能够在应用程序的资源目录中快速地找到最匹配的资源。
最后,我们可以通过图3来总结应用程序资源的编译、打包以及查找过程:
![](https://box.kancloud.cn/c6d2e0e249d02d195589b831438b0aaa_580x562.jpg)
图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。
- 前言
- Android组件设计思想
- Android源代码开发和调试环境搭建
- Android源代码下载和编译
- Android源代码情景分析法
- Android源代码调试分析法
- 手把手教你为手机编译ROM
- 在Ubuntu上下载、编译和安装Android最新源代码
- 在Ubuntu上下载、编译和安装Android最新内核源代码(Linux Kernel)
- 如何单独编译Android源代码中的模块
- 在Ubuntu上为Android系统编写Linux内核驱动程序
- 在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序
- 在Ubuntu上为Android增加硬件抽象层(HAL)模块访问Linux内核驱动程序
- 在Ubuntu为Android硬件抽象层(HAL)模块编写JNI方法提供Java访问硬件服务接口
- 在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务
- 在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务
- Android源代码仓库及其管理工具Repo分析
- Android编译系统简要介绍和学习计划
- Android编译系统环境初始化过程分析
- Android源代码编译命令m/mm/mmm/make分析
- Android系统镜像文件的打包过程分析
- 从CM刷机过程和原理分析Android系统结构
- Android系统架构概述
- Android系统整体架构
- android专用驱动
- Android硬件抽象层HAL
- Android应用程序组件
- Android应用程序框架
- Android用户界面架构
- Android虚拟机之Dalvik虚拟机
- Android硬件抽象层
- Android硬件抽象层(HAL)概要介绍和学习计划
- Android专用驱动
- Android Logger驱动系统
- Android日志系统驱动程序Logger源代码分析
- Android应用程序框架层和系统运行库层日志系统源代码分析
- Android日志系统Logcat源代码简要分析
- Android Binder驱动系统
- Android进程间通信(IPC)机制Binder简要介绍和学习计划
- 浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路
- 浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得Service Manager接口之路
- Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析
- Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析
- Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
- Android Ashmem驱动系统
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)简要介绍和学习计划
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)驱动程序源代码分析
- Android系统匿名共享内存Ashmem(Anonymous Shared Memory)在进程间共享的原理分析
- Android系统匿名共享内存(Anonymous Shared Memory)C++调用接口分析
- Android应用程序进程管理
- Android应用程序进程启动过程的源代码分析
- Android系统进程Zygote启动过程的源代码分析
- Android系统默认Home应用程序(Launcher)的启动过程源代码分析
- Android应用程序消息机制
- Android应用程序消息处理机制(Looper、Handler)分析
- Android应用程序线程消息循环模型分析
- Android应用程序输入事件分发和处理机制
- Android应用程序键盘(Keyboard)消息处理机制分析
- Android应用程序UI架构
- Android系统的开机画面显示过程分析
- Android帧缓冲区(Frame Buffer)硬件抽象层(HAL)模块Gralloc的实现原理分析
- SurfaceFlinger
- Android系统Surface机制的SurfaceFlinger服务
- SurfaceFlinger服务简要介绍和学习计划
- 启动过程分析
- 对帧缓冲区(Frame Buffer)的管理分析
- 线程模型分析
- 渲染应用程序UI的过程分析
- Android应用程序与SurfaceFlinger服务的关系
- 概述和学习计划
- 连接过程分析
- 共享UI元数据(SharedClient)的创建过程分析
- 创建Surface的过程分析
- 渲染Surface的过程分析
- Android应用程序窗口(Activity)
- 实现框架简要介绍和学习计划
- 运行上下文环境(Context)的创建过程分析
- 窗口对象(Window)的创建过程分析
- 视图对象(View)的创建过程分析
- 与WindowManagerService服务的连接过程分析
- 绘图表面(Surface)的创建过程分析
- 测量(Measure)、布局(Layout)和绘制(Draw)过程分析
- WindowManagerService
- WindowManagerService的简要介绍和学习计划
- 计算Activity窗口大小的过程分析
- 对窗口的组织方式分析
- 对输入法窗口(Input Method Window)的管理分析
- 对壁纸窗口(Wallpaper Window)的管理分析
- 计算窗口Z轴位置的过程分析
- 显示Activity组件的启动窗口(Starting Window)的过程分析
- 切换Activity窗口(App Transition)的过程分析
- 显示窗口动画的原理分析
- Android控件TextView的实现原理分析
- Android视图SurfaceView的实现原理分析
- Android应用程序UI硬件加速渲染
- 简要介绍和学习计划
- 环境初始化过程分析
- 预加载资源地图集服务(Asset Atlas Service)分析
- Display List构建过程分析
- Display List渲染过程分析
- 动画执行过程分析
- Android应用程序资源管理框架
- Android资源管理框架(Asset Manager)
- Asset Manager 简要介绍和学习计划
- 编译和打包过程分析
- Asset Manager的创建过程分析
- 查找过程分析
- Dalvik虚拟机和ART虚拟机
- Dalvik虚拟机
- Dalvik虚拟机简要介绍和学习计划
- Dalvik虚拟机的启动过程分析
- Dalvik虚拟机的运行过程分析
- Dalvik虚拟机JNI方法的注册过程分析
- Dalvik虚拟机进程和线程的创建过程分析
- Dalvik虚拟机垃圾收集机制简要介绍和学习计划
- Dalvik虚拟机Java堆创建过程分析
- Dalvik虚拟机为新创建对象分配内存的过程分析
- Dalvik虚拟机垃圾收集(GC)过程分析
- ART虚拟机
- Android ART运行时无缝替换Dalvik虚拟机的过程分析
- Android运行时ART简要介绍和学习计划
- Android运行时ART加载OAT文件的过程分析
- Android运行时ART加载类和方法的过程分析
- Android运行时ART执行类方法的过程分析
- ART运行时垃圾收集机制简要介绍和学习计划
- ART运行时Java堆创建过程分析
- ART运行时为新创建对象分配内存的过程分析
- ART运行时垃圾收集(GC)过程分析
- ART运行时Compacting GC简要介绍和学习计划
- ART运行时Compacting GC堆创建过程分析
- ART运行时Compacting GC为新创建对象分配内存的过程分析
- ART运行时Semi-Space(SS)和Generational Semi-Space(GSS)GC执行过程分析
- ART运行时Mark-Compact( MC)GC执行过程分析
- ART运行时Foreground GC和Background GC切换过程分析
- Android安全机制
- SEAndroid安全机制简要介绍和学习计划
- SEAndroid安全机制框架分析
- SEAndroid安全机制中的文件安全上下文关联分析
- SEAndroid安全机制中的进程安全上下文关联分析
- SEAndroid安全机制对Android属性访问的保护分析
- SEAndroid安全机制对Binder IPC的保护分析
- 从NDK在非Root手机上的调试原理探讨Android的安全机制
- APK防反编译
- Android视频硬解稳定性问题探讨和处理
- Android系统的智能指针(轻量级指针、强指针和弱指针)的实现原理分析
- Android应用程序安装过程源代码分析
- Android应用程序启动过程源代码分析
- 四大组件源代码分析
- Activity
- Android应用程序的Activity启动过程简要介绍和学习计划
- Android应用程序内部启动Activity过程(startActivity)的源代码分析
- 解开Android应用程序组件Activity的"singleTask"之谜
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Service
- Android应用程序绑定服务(bindService)的过程源代码分析
- ContentProvider
- Android应用程序组件Content Provider简要介绍和学习计划
- Android应用程序组件Content Provider应用实例
- Android应用程序组件Content Provider的启动过程源代码分析
- Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
- Android应用程序组件Content Provider的共享数据更新通知机制分析
- BroadcastReceiver
- Android系统中的广播(Broadcast)机制简要介绍和学习计划
- Android应用程序注册广播接收器(registerReceiver)的过程分析
- Android应用程序发送广播(sendBroadcast)的过程分析