轻读一下 Android 应用开发中的 assets 目录

乡下高铁站张 發表於 2019-8-7 14:35:00

轻读一下 Android 应用开发中的 assets 目录

2019-08-07
关键字：APK预置文件、预置配置文件、res,raw与assets的区别
<hr>
 
在Android的应用开发中，难免会遇到外部文件的预置需求。例如图像、音视频、配置文件、字体等等。对于图像，我们很容易会想到将它们存放在 res/drawable 目录或者是 res/mipmap 目录下。但对于其它类型的文件，就得另寻它法了。
 
比较常见的可以保存任意类型文件的地方主要有两个：
1、res/raw 目录；
2、assets 目录。
 
drawable/mipmap、raw、assets 三者都可以用来存储一些外部资源文件，那它们之间各自有什么优缺点呢？
 
首先，在 drawable 或 mipmap 下只能保存图像文件或图像描述文件，但在这两个目录下保存的图像文件在编译时会建立一张“索引表”。这个索引信息会被统一保存在一个名称为 R.java 的文件中。在程序的任何地方都可以直接通过 R.drawable.xxx 的形式来使用图片资源。
 
res/raw 目录算是一个比较特殊的资源文件目录。它被设计用于保存一些二进制文件，即在这个目录下的所有文件都会被记录到“索引表”中，但是编译系统不会去动里面的文件。raw 目录下的文件放进去时是什么样的，编译成 APK 以后还是什么样。这个目录比较适合保存一些音视频等二进制文件。
 
res 目录下的资源文件夹，不管是 raw 还是 drawable 或 mipmap，都不能自由地设计子目录层级关系。不管你有多少文件，都只能放在同一级目录中。
 
assets 目录是一个非常自由的目录。它就像是Android应用中的“三不管”地带，不会为里面的文件建立索引、不会限制目录层级关系、不会处理里面的文件。如果你想更好地管理自己的外部资源文件，建议使用 assets 目录。
 
本篇文章，我们重点来讲解一下 Android 的 assets 目录。
 
<h2>1、assets 简介</h2>
 
assets 在 APK 工程中就是一个普通的目录而已。不管是 Eclipse 创建的工程还是 Android Studio 创建的工程，在它的工程根目录下都可以发现（或者自己创建）一个 assets 目录，如下图所示
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190806205500901-1118638066.png">
assets 目录是专门用于保存各种外部文件的。常见的有：图像、音视频、配置文件、字体、自带数据库等。之所以说它适合用来管理这些文件，是因为应用程序在编译时不会去处理这个目录下的文件，但是却会将它们打包进 APK 中。而其它你随便创建的目录在编译时就会被直接忽略掉。同时，你可以在 assets 目录内任意创建目录层级关系，这对于有大量外部文件需要集成的应用来说，就能很方便地分类管理了。
 
在 APK 开发中，有一种管理配置信息的做法比较常见：直接将配置信息文件放入 assets 目录中管理，程序首次运行时将这里面的配置信息拷贝到外部的可操作的目录下，后续程序的运行均靠这份保存在外部的配置信息为准，assets 中的信息仅作为原始配置信息的备份。
 
但是，assets 目录在使用上也还是有一点小缺憾的。
 
assets 目录内的文件在程序打包发布以后就是只读的。就是你只能读取那里面的文件，而无法修改或增加文件。这条特性其实也可以理解，因为应用程序一旦打包发布了，它就应该是只读的。而 assets 目录又是直接保存在 APK 内部的，所以它自然也不能修改或增加内容了。实在要想增加内容，通过 Database 或者 SharedPreferences 往 /data/data 目录下保存就好了嘛。再或者这两者不能满足你的要求，你也可以直接将它们保存在 sdcard 下面嘛。反正现在市面上的 APK  在 sdcard 里创建自己的数据文件夹的可不少。
 
<h2>2、assets 开发</h2>
 
关于读取 assets 目录下的文件，Android 提供了一个 android.content.res.AssetManager 类来实现。这个类的签名体如下图所示
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190806212715693-208638066.png">
这里我们需要关注的方法有以下几个：
1、构造方法
2、open() 方法
3、openFd() 方法
4、openNonAssetFd() 方法
5、openXmlResourceParser() 方法
 
构造方法
这里我们注意到 AssetManager 的构造方法的权限是 default，这意味着我们无法在我们的程序中通过 new 的方式来实例化它（在Android4.4 中它是 public 修饰的）。通常，我们可以通过两种方式来得到 AssetManager 的实例：1、通过 Context 实例的 getAssets() 方法；2、通过 Resources 实例的 getAssets() 方法。
 
open(string) & open(string,int)
这两个方法的作用是一样的。都是将 assets 目录下的某个文件封装成 InputStream 的形式以供使用。说白了就是让我们读文件用的。
 
两个方法中的 string 参数都指的是“文件名”，其实应该说是文件的相对路径更合适，它需要的是某个文件在 assets 目录下的相对路径。例如：dir1/file1.png , dir2/dir3/dir4/file2.avi。
 
第二个方法中还有一个 int 型参数，它是“访问模式”，就是将 assets 目录下的文件以什么模式来打开的意思。它一共有以下 4 种模式可供选择：
1、ACCESS_UNKNOW
无模式。其代表的值是 0。
2、ACCESS_RANDOM
这个不应该翻译成随机访问模式，无序访问模式会更适合一点。这种模式下文件的访问只会打开其中一段内容，然后再根据你的需要向流的前方或后方移动读取指针。其代表的值是 1。
3、ACCESS_STREAMING
顺序读取模式。文件将会被从头部打开，然后按顺序向后面移动读取数据。其代表的值是 2。
4、ACCESS_BUFFER 
缓存读取模式。读取时会将整个文件直接读取到内存中，这种模式适合小文件的读取。其代表的值是 3。
 
在 open(string) 中，它使用的文件读取模式是 ACCESS_STREAMING 模式。
 
openFd(string)
将 assets 目录中的文件以 FileDescriptor 的形式打开，返回一个 AssetFileDescriptor 实例。
 
openNonAssetFd(string) & openNonAssetFd(int,string)
这个其实和上面的 openFd() 是一样的。只不过它是跳出了 assets 目录的范围限定，它是站在工程根目录的视角来打开文件的 FileDescriptor 的。换句话说，它允许打开 APK 中任意位置的文件的 AssetFileDescriptor 实例。
 
openXmlResourceParser(int,string)
打开 assets 目录下的 xml 形式的文件，直接返回 XmlResourceParser 实例。其实就是官方替我们做了从 InputStream 到 XML 解析器之间的转换，有助于增加一些开发效率而已。
 
 
那接下来，我们通过实例来演示一下 assets 目录下的文件的读取方法。首先第一个是直接读取最普通的文件的方法
<div class="cnblogs_code">
<pre>try {
InputStream is = this.getAssets().open("moutain.png");
Log.d("type1", "File available:" + is.available());

InputStream is2 = this.getResources().getAssets().open("river.png");
Log.d("type1", "File available2:" + is2.available());
} catch (IOException e) {
e.printStackTrace();
}</pre>
</div>
执行的结果如下所示：
<div class="cnblogs_code">
<pre> D/type1: File available:3
D/type1: File available2:11416</pre>
</div>
当然，最后一定不要忘记将用完的 InputStream 资源关掉！！！
 
第二个是读取自定义目录层级的文件的方法
<div class="cnblogs_code">
<pre>try {
InputStream is = this.getAssets().open("sences/nature/forest.png");
Log.d("type2", "File available:" + is.available());

} catch (IOException e) {
e.printStackTrace();
}</pre>
</div>
执行的结果如下所示：
<div class="cnblogs_code">
<pre> D/type2: File available:32114</pre>
</div>
同样，不要忘记调用 InputStream 的 close() 方法哦。
 
第三个是以文件描述符形式读取的方法
<div class="cnblogs_code">
<pre>try {
AssetFileDescriptor afd = this.getAssets().openFd("river.png");
Log.d("type3", "File available:" + afd.getLength());

InputStream is = afd.createInputStream();
Bitmap bm = BitmapFactory.decodeStream(is);

is.close();
afd.close();

iv01.setImageBitmap(bm);
} catch (IOException e) {
e.printStackTrace();
}</pre>
</div>
这里将一张图片以 AssetFileDescriptor 的形式读取出来，并转换成 Bitmap 显示在 ImageView 上，这段代码的执行结果如下图所示
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807105212688-941879510.png">
 
 
<h2>3、assets 深度剖析</h2>
 
这一小节我们来探究一下 AssetManager 的“前世今生”。
 
首先来看看 AssetManager 实例是怎么来的。通过前面的介绍，我们已经知道了可以直接通过 Activity 实例来调用 getAssets() 方法以取得 AssetManager 实例，或者是通过 Activity 实例里的 getResources() 得到 Resources 的实例以后再调用 getAssets() 来得到 AssetManager 实例。那我们应该都知道，所谓的 Activity 里提供的 getAssets() 方法或者是 getResources() 方法，都是被定义在 android.app.Context 类中的方法，如下图所示
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807110659188-1023965163.png">
但是它们在 Context 类中都是抽象方法。那这两个方法的具体实现在哪呢？在 android.app.ContextImpl 类上。如下图所示
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807110934506-1567156863.png">
通过上图，我们很意外地发现，原来通过 Context 的 getAssets() 和通过 Resources 的 getAssets() 走的路线竟然是完全一样的！！！
 
好吧，来不及在这感慨了，我们得接着看看 mResources 又是怎么来的。
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807120104446-1758485033.png">
这个 mResource 是通过 packageInfo 得到的。而 packageInfo 又是在 ContextImpl 构造的时候传进来的。
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807120223315-705825084.png">
我们这里且不管是谁 new 了 ContextImpl 的对象，我们只需要知道这个 packageInfo 是 LoadedApk 类的实例就好了。我们下面直接去看看 LoadedApk 类里的 getResources() 方法。
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807120552123-2115708361.png">
好嘛，又跳到 ActivityThread 类里去了，跟过去
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807120629681-1641605234.png">
牛皮，又跳到 ResourcesManager 里去了，没办法，只能再跟。不过在跟踪之前这里必须说一下，这个方法中的第一个参数 resDir 指的是这个 APK 在文件系统下的路径，例如，你是通过 install 方式安装的，它就会在 /data/app 下，你是系统应用它就会在 /system/app 或 /system/priv-app 下。总之这个参数的作用就是把当前正在运行的 APK 的地址传进去，因为后面要去解析它里面的资源的。
 
ResourcesManager 里的 getTopLevelResources 方法比较长，这里只贴需要我们关注的代码。我们在这个方法里终于发现有人实例化了 AssetManager 类。
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807120821210-1151068173.png">
同时下面一点的地方还发现了这样一段代码
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807134507392-454342741.png">
将刚创建出来的 AssetManager 实例传给 Resources 类实例化去了。传它的作用想也不用想就知道是将这个 assets 对象保存起来，以便后面调用 Resources 类的 getAssets() 方法时好返回了。而事实上，Resources 类中的 getAssets() 方法所干的事也确实就是简单地返回这个 assets 对象的引用而已。下图是 Resources 类中的代码实现
<img src="https://img2018.cnblogs.com/blog/1146198/201908/1146198-20190807134734697-281514700.png">
 
前面我们简单地了解了 AssetManager 的由来过程。简单总结一下就是：
1、每个 APK 在启动时都会实例化属于自己的 Context 对象；
2、APK 里的资源文件统一具化为 Resources 实例，并由 ResourceManager 管理；
3、assets 目录统一由一个 AssetManager 实例管理；
4、AssetManager 实例在 APK 启动时创建；
 
 
上面是 AssetManager 在应用层的流程。当然其实 AssetManager 还有一个在 Java 以下的流程，这个流程挺复杂的，我这边也不是很有时间，而且感觉了解的太过深入的价值不是很高，就不再继续分析了。不过不排除以后我有兴趣时会继续跟踪下去。
 
<hr>
 

</div>
<div id="MySignature" role="contentinfo">
+++ 
来源：https://www.cnblogs.com/chorm590/p/11308107.html

頁: [1]

琼殿技术论坛's Archiver

轻读一下 Android 应用开发中的 assets 目录