XML 文件应优先放入 /res/xml 而非 assets，因其支持编译校验、R.xml 引用及系统级解析；assets 仅适用于需保留格式、注释或超大文件（>1MB）等特殊场景。
XML 文件别往 assets 里塞，除非你明确要跳过编译
Android 的 /res/xml 是专为 XML 配置文件设计的正统路径——它会被编译进 APK 的资源表（resources.arsc），支持通过 R.xml.filename 直接获取解析器，且能享受系统级校验（比如标签闭合、命名空间合法性）。而 assets 下的 XML 文件只是普通二进制 blob，读出来就是原始字节流，得自己用 XmlPullParser 或 DOM 手动解析，连编码错误都得自己兜底。
-
/res/xml适合：权限声明、预置配置、UI 模板（如searchable.xml）、需要被getResources().getXml()安全加载的结构化数据 -
assets适合：第三方 SDK 要求的原始 XML（如某些地图瓦片元数据）、需保留注释/格式/处理指令的 XML、或作为纯文本模板动态生成内容 - 误放
assets的典型症状：XmlPullParserException: Unexpected token（因 BOM 或 UTF-8 编码不一致）、FileNotFoundException（路径拼错，assets不支持通配符和资源 ID 查找）
openRawResource() 不能读 XML，但 getXml() 只认 /res/xml
getResources().openRawResource(R.raw.xxx) 返回的是裸 InputStream，它不管内容是不是 XML；而 getResources().getXml(R.xml.xxx) 内部调用的是经过编译优化的解析器，能跳过 DTD 加载、自动处理命名空间前缀。如果你把 XML 放进 /res/raw，虽然能读到字节，但无法用 getXml()，也得不到编译时的语法检查。
-
/res/raw中的 XML 文件会生成R.raw.xxx，但只能当普通流读取，getXml()方法压根不接受R.raw类型参数 -
/res/xml中的文件必须以.xml结尾，且根元素需符合 Android XML 规范（如不能是开头） - 如果 XML 里用了自定义命名空间（如
app:），放在/res/xml下才能被正确识别；放raw或assets就得手动注册命名空间处理器
超过 1MB 的 XML 别硬塞进 /res/xml，小心 aapt2 编译失败
aapt2 对单个 /res/xml 文件有隐式大小限制（实测常在 1–2MB 触发 ERROR: failed to read resource），这不是运行时问题，而是构建阶段直接报错。此时别折腾分包或压缩，直接换路径更稳妥。
- 大 XML（如离线词典、完整 Schema）应移入
assets/configs/large.xml，用getAssets().open("configs/large.xml")读取 - 若仍需结构化解析，建议改用
XmlPullParser+InputStreamReader组合，显式指定UTF-8编码，避免 BOM 导致首字符解析异常 -
/res/raw同样有大小隐患：4MB 以上可能触发 dex 分包或 AssetManager 读取截断（尤其旧版 Android），但/res/xml的限制更早、更严格
assets 子目录路径写错是 runtime 常见崩溃点
getAssets().open("data/config.xml") 看似合理，但一旦 assets/data/config.xml 实际不存在，抛出的是 IOException 而非编译期错误——这种问题上线后才暴露，排查成本高。
- 务必在打开前用
list("data")校验子目录存在性：getAssets().list("data")返回字符串数组，空数组即目录不存在或拼写错误 -
assets路径区分大小写（Linux 底层），"Config.xml"和"config.xml"在 Windows 开发机上可能侥幸通过，但在真机上必挂 - 不要依赖 IDE 的“自动补全”路径：AS 的 assets 提示常缓存旧结构，删了文件夹后仍显示已删除路径
assets 却在代码里写死 R.xml.xxx 引用，编译能过，运行时报 Resources$NotFoundException。这类错误往往藏在初始化逻辑深处，等用户点到某个二级页面才炸。 
