程序安装包体积较大的时候，一些开发团队会在保护阶段考虑启用资源压缩的功能。使用Obsidium进行资源压缩之前，需要先分清楚两类内容：一类是嵌入程序内部的资源，另一类是外部数据文件。图片、图标、对话框还有语言资源通常属于程序资源；配置文件、模板、数据库和素材包则一般归为外部文件。这两类内容的处理方式不能混在一起。Obsidium还提供了文件完整性检查和数据文件加密的能力，外部文件如果有保护需求，应该单独进行配置，不能简单把它们当作程序资源来处理压缩。

　　一、Obsidium资源压缩的启用方法

　　建议从测试工程开始进行Obsidium资源压缩的配置。不同版本的界面名称可能存在一些差异，但安装包中包含了完整的文档和示例，可以结合当前版本的具体界面来确认选项的位置。

　　1、先备份原始程序

　　操作者应该先保留未保护的exe、dll、配置文件和安装包，再复制一份作为测试输入。保护之后的文件要输出到单独的目录，不要直接覆盖原始文件，否则读取异常出现之后很难再做回退对比。

　　2、加载需要保护的文件

　　打开Obsidium工程，将主程序以及需要同步处理的内部dll都添加到工程中。根据官方页面的说明，Obsidium可以用来保护Windows平台下的exe、dll、scr等本地编译程序，同时也支持部分.NET Framework 4.x的程序。

　　3、开启资源压缩的选项

　　在工程的保护设置里面找到资源压缩、资源优化或者与压缩相关的选项，勾选之后就可以生成保护文件。第一次测试的时候不要同时开启多项保护功能，应当先只启用资源压缩，确认运行正常之后再逐步增加其他的保护设置。

　　4、运行核心功能来进行验证

　　生成保护文件之后，依次打开主界面、设置窗口、语言切换界面、图标显示、图片加载还有打印导出页面。资源问题往往不是在启动的时候立刻报错，而是在进入某个特定窗口之后才暴露出来。

　　二、排查Obsidium资源压缩后的读取异常

　　当资源压缩之后出现了图片空白、窗口打不开、图标丢失或者程序启动报错等现象时，应该先通过对照实验来缩小范围，不要直接去修改业务代码。

　　1、关闭压缩来做对照

　　保持其他保护参数不变，只关闭资源压缩这个选项，然后重新生成文件。如果异常消失，说明问题很可能和资源压缩或者资源的加载方式有关系；如果异常仍然存在，就需要继续检查其他的保护选项。

　　2、检查资源的读取方式

　　标准资源接口通常具有更好的兼容性。如果程序通过固定偏移、资源段地址、内存指针或者自定义解析器来读取资源，那么压缩之后布局发生变化就可能导致读取失败。需要让开发人员检查资源定位的逻辑，避免依赖原始文件的具体位置。

　　3、区分内部资源和外部文件

　　外部图片、模板、语言包和配置文件如果被程序按照路径来读取，就不应该被误当作嵌入资源来处理。路径错误、文件遗漏或者工作目录发生变化也可能造成类似的现象。可以先检查发布目录是否完整，再判断问题是不是由压缩导致的。

　　4、检查程序架构和签名的顺序

　　Obsidium分别提供了x86和x64两个版本，保护工程需要和目标程序架构对应起来。如果程序需要数字签名，通常应该在保护完成之后重新进行签名，然后再检查启动和资源读取是否正常。

　　三、Obsidium资源压缩上线前的检查

　　在资源压缩上线之前，建议留下可复现的记录，这样在后续版本更新时就不需要重新摸索了。

　　1、准备三组测试包

　　分别保留未保护版本、保护但未压缩版本、保护并压缩版本这三组文件，然后用同一套测试用例进行验证，这样可以更快地看出异常是从哪一步开始出现的。

　　2、检查常用资源的入口

　　重点覆盖启动页、菜单图标、弹窗、语言切换、导入导出以及异常提示这些资源入口。当资源的数量比较多的时候，可以把检查结果记录成表格的形式。

　　3、保存工程和版本信息

　　将Obsidium的工程文件、输入文件的校验值、输出文件的校验值、软件版本以及保护参数都进行归档保存。下一次升级出现问题时，就可以直接对比这些变化。

　　总结

　　程序资源压缩不能仅仅关注文件的体积有没有减小，还要确保运行时的读取是稳定的。对于Obsidium资源压缩的启用以及压缩后读取异常的排查，可以按照“单独启用、生成测试包、逐页验证、关闭压缩对照、检查读取逻辑”这个顺序来处理。把内部资源和外部文件分开管理，通常可以减少很多误判。