17、资源加载与管理：Resources、AssetManager、资源ID映射、多语言与屏幕适配
资源管理，说白了就是Android系统怎么找到你放在res目录下的那些东西。你想想看，一个APK里可能有几百张图、几十个布局、一堆字符串，系统怎么知道该用哪个？这里面的门道，我今天跟你好好聊聊。
17.1 Resources与AssetManager：谁管谁？
很多人搞不清Resources和AssetManager的关系。我刚开始做Android时也迷糊过，以为它们是一回事。其实不是。
AssetManager是底层干活的那个。它负责从APK里把文件读出来，不管是res目录下的，还是assets目录下的。它就是个文件读取器，不关心你存的是什么类型。
Resources是上层封装。它调用AssetManager拿到原始数据，然后根据资源类型做解析。比如拿到一个XML，它知道要解析成布局对象；拿到一个图片，它知道要解码成Bitmap。
简单说：AssetManager管“找文件”，Resources管“用文件”。
核心调用链：
Context.getResources() → Resources → AssetManager → APK文件
我个人习惯在写工具类时直接持有Resources引用，而不是Context。因为Resources是全局的，不会泄漏。但如果你要操作assets目录下的文件，那就得用AssetManager了。
17.2 资源ID映射：R文件是怎么来的？
你有没有好奇过，R.id.tv_name这种写法，背后到底发生了什么？
编译时，aapt（Android Asset Packaging Tool）会扫描所有res目录下的文件，给每个资源分配一个int类型的ID。这个ID是32位的，结构如下：
| 位域 | 位数 | 说明 |
|---|---|---|
| Package ID | 8位 | 0x7f表示应用资源，0x01表示系统资源 |
| Type ID | 8位 | 资源类型，如layout=0x02，drawable=0x03 |
| Entry ID | 16位 | 具体资源的序号 |
举个例子，R.layout.activity_main的值可能是0x7f020000。嗯，这里要注意：这个ID在编译时就固定了，运行时不会变。所以资源查找非常快，就是一次整数匹配。
我曾经遇到过一个坑：在library模块里，Package ID是0x7f，但主工程也是0x7f。如果两个模块有同名资源，就会冲突。后来Google引入了资源命名空间（resource prefix）来解决这个问题。所以你在写library时，记得给资源加前缀，比如mylib_btn_ok。
17.3 资源加载流程：从ID到对象
当你调用getResources().getDrawable(R.drawable.ic_launcher)时，系统做了什么？
- ID解析：Resources拿到0x7f030001，拆解出Package ID=0x7f，Type ID=0x03，Entry ID=0x0001。
- 查找资源表：AssetManager里维护着一张资源表（ResourceTable），记录了每个ID对应的文件路径和配置信息。
- 配置匹配：根据当前设备的屏幕密度、语言、方向等，找到最匹配的资源文件。比如drawable-hdpi和drawable-xhdpi，系统会根据屏幕密度选一个。
- 读取文件：AssetManager从APK里读取对应的文件数据。
- 解析对象：Resources把原始数据解析成Drawable、String、XmlResourceParser等对象。
这个过程看起来简单，但性能开销不小。尤其是解析XML布局，每次inflate都要走一遍。所以我建议：能缓存的资源尽量缓存，比如用ViewStub延迟加载，或者用SparseArray存一下解析好的Drawable。
17.4 多语言适配：不只是strings.xml
多语言适配，很多人以为就是加几个strings.xml文件。其实远不止这些。
系统根据Locale来选择资源。Locale包含语言和地区，比如zh_CN、en_US。资源目录的命名规则是：
- values-zh-rCN：简体中文
- values-zh-rTW：繁体中文
- values-en-rUS：美式英语
但要注意：不是所有资源都需要多语言。比如布局文件，如果只是文字不同，用strings引用就行。如果布局结构完全不同（比如阿拉伯语从右到左），那才需要单独放layout-ar目录。
我曾经犯过一个错：把图片也放到values目录下，结果切换语言后图片找不到了。记住，drawable目录不支持语言限定符。图片资源应该用密度限定符，比如drawable-mdpi、drawable-hdpi。
17.5 屏幕适配：dp、sp与限定符
屏幕适配是Android的老大难问题。我做了这么多年，总结下来就三个核心点：
第一，用dp和sp，别用px。
dp是密度无关像素。1dp在mdpi屏幕上等于1px，在hdpi上等于1.5px，在xhdpi上等于2px。系统会自动换算。sp是缩放无关像素，专门用于字体，会跟随用户设置的字号缩放。
第二，提供多密度资源。
你至少得准备mdpi、hdpi、xhdpi、xxhdpi四套图。现在主流是xxhdpi，但别忽略低端机。我建议用矢量图（VectorDrawable）代替位图，一个文件搞定所有密度，省心省力。
第三，使用限定符做精细适配。
除了密度，还有屏幕尺寸、方向、宽高比等限定符。比如：
- layout-sw600dp：屏幕宽度大于600dp的设备（通常是平板）
- layout-land：横屏
- values-night：深色模式
这些限定符可以组合使用，比如drawable-sw600dp-land-xhdpi。但别搞太多组合，否则APK会变得很大，维护也麻烦。
17.6 资源加载的性能陷阱
资源加载看着简单，但性能问题不少。我列几个常见的：
- 重复解析：每次getDrawable都重新解析一次。用Resources.getDrawable(int, Theme)时，如果主题变了，缓存会失效。
- 大图加载：直接加载原图到内存，一张1920x1080的图可能占8MB。用BitmapFactory.Options的inSampleSize做采样加载。
- XML解析慢：复杂的布局文件，inflate一次可能要几十毫秒。用ConstraintLayout减少层级，或者用X2C插件把XML转成Java代码。
我个人习惯在Application.onCreate里预加载一些常用资源，比如默认头像、启动图。用LruCache或者SparseArray存起来，避免运行时频繁IO。
17.7 知识体系总览
下面这张图把资源加载与管理的核心脉络画出来了。你可以看到从资源ID到最终对象的完整链路，以及多语言和屏幕适配的决策点。
这张图里，你重点关注两个地方：一是AssetManager到Resources的转换，这是从“文件”到“对象”的关键一步；二是配置匹配模块，它决定了多语言和屏幕适配的结果。
好了，资源加载与管理就聊到这儿。记住一句话：理解资源ID的映射机制，你就掌握了Android资源系统的钥匙。剩下的，就是多写多踩坑，慢慢积累经验。