很多人在Agile.NET里一开【Code Encryption】，第一反应就是包体突然变大了，于是下意识怀疑是不是加密本身把程序集“撑胖”了。真往官方说明里看，主要增量并不只来自方法级加密，而是来自随加密一起加入的本地运行时组件；默认情况下，Agile.NET会把x86和x64两套运行时都直接嵌进加密后的程序集里，如果再勾上防调试，运行时DLL体积还会继续上升。也正因为这样，这类问题不能只盯着“加密开没开”，而要回到运行时组件、嵌入方式和保护层级一起看。

　　一、Agile.NET代码加密后体积变大

　　加密后体积变大并不奇怪，关键是先分清哪些增长是正常保护成本，哪些增长是可以回收的。只要把来源拆开看，后面要不要调嵌入方式、要不要改单文件部署、要不要减少高强度保护范围，就不会乱。

　　1、代码加密不是单纯改名字

　　Agile.NET的【Code Encryption】不是只做符号混淆，而是把方法体加密后放进安全存储，再在程序运行时按方法逐个解密执行。这个过程本身就比单纯改名更重，所以产物不可能和只做重命名时一样轻。

　　2、真正显著拉大体积的是本地运行时组件

　　官方文档写得很直接，代码加密会附带一个本地组件，由它去绑定.NET运行时并接管方法执行。也就是说，加密后的包体不只是“原程序集加一点壳”，而是多了一层运行时支撑。

　　3、默认同时嵌入x86和x64会把体积继续抬高

　　Agile.NET为了同时支持x86和x64，默认会把两套运行时组件都直接嵌进加密后的程序集。这样做的好处是部署时省事，不用你手动再带额外文件；代价就是单个程序集本身更大。

　　4、反调试会让运行时DLL再膨胀一层

　　如果你在【Code Encryption】里继续勾上防调试，Agile.NET会再加一层反调试保护。官方明确说明，这个选项会增加Agile.NET运行时DLL的大小，所以有些项目一开这个选项，体积变化会特别明显。

　　二、Agile.NET运行时组件如何优化

　　做优化时，目标不是把所有保护都关掉，而是把真正需要高强度保护的部分留下，把没必要的运行时负担减掉。这样既能保住关键逻辑，又不至于把部署包越做越重。

　　1、先判断是否一定要继续使用运行时嵌入

　　官方给了两种思路。默认是把运行时组件直接嵌入程序集里，部署简单；如果你更在意包体和可控性，可以在选项里勾选【Disable runtime embedding】，改成单独部署运行时组件。这样做未必会让交付总字节数瞬间消失，但能避免每个受保护程序集都重复背一份嵌入负担，尤其适合多模块项目。

　　2、开了反调试后优先考虑分离部署

　　这一步很实用。因为官方已经明确提醒，反调试会让运行时DLL变大，所以一旦项目确实要保留反调试，更适合把运行时嵌入关闭，改成外部随包部署，而不是继续把增大的DLL塞回主程序集。

　　3、用【Assemblies Merging】减少部署总量

　　如果你的程序本来就带着一串配套DLL，一边给主程序加密，一边还保持零散部署，最后看起来就会又大又碎。Agile.NET的【Assemblies Merging】可以把一组程序集并成单文件，官方说明它能减少部署总大小，并改善加载时间。这个功能发生在其他保护操作之前，所以真要合并，最好先把主程序集和次程序集关系理清，再统一做保护。

　　4、不要把高强度保护撒满所有方法

　　Agile.NET的文档把【Code Virtualization】和【Code Encryption】都定义成高强度保护，但官方也提醒，虚拟化更适合放在许可校验、核心算法、入口控制这类高知识产权方法上，计算密集型循环不适合大面积套用。实际做体积和性能优化时，也应该沿着同样思路处理，把重保护留给关键方法，而不是全盘铺开。

　　三、Agile.NET保护层级怎么取舍

　　很多项目后期越做越重，不是因为某一个选项本身有问题，而是把加密、虚拟化、反调试、跨程序集处理一起全开了。Agile.NET本来就强调分层保护，所以真正稳妥的做法，是按风险高低分配保护，而不是用一套最重配置压所有模块。

　　1、公共接口层先以兼容为主

　　如果程序集要被外部项目引用，先不要急着把公开成员一并做重度处理。官方在【Symbol Renaming】里提到，默认不会混淆公开成员，目的就是避免外部引用断掉；只有确认不是给外部组件调用时，才更适合继续做跨程序集隐藏。

　　2、核心授权和关键算法层再上强保护

　　真正值得优先加密或虚拟化的，是授权校验、算法核心、访问控制、数据库连接等敏感逻辑。官方在虚拟化部分给出的推荐对象，本质上就是这些最怕被逆向、最怕被补丁绕过的位置。

　　3、部署层优先做减法

　　如果项目里已经决定做程序集合并，就不要再让多个受保护模块各自背重复部署负担。合并先做，保护后做，往往比所有DLL各自加密再分别打包更利索，因为合并发生在其他保护操作之前，次程序集的单独保护设置也会被主程序集接管。

　　4、排错层记得保留映射文件

　　包体和运行时优化做完以后，维护也别断。只要用了【Symbol Renaming】，Agile.NET就会生成XML映射文件，后续客户现场拿回来的混淆栈信息要靠它还原。优化体积可以做，但这类排错资产不要丢，否则出了问题反而会把维护成本抬上去。

　　总结

　　Agile.NET代码加密后体积变大，症结通常不在“加密”两个字本身，而在运行时组件怎么带、两套架构是不是一起嵌了、反调试是不是也一起开了。要把Agile.NET运行时组件如何优化这件事做得更稳，顺序上最好是先看【Code Encryption】里是否继续嵌入运行时，再结合【Assemblies Merging】收拢部署文件，最后把高强度保护集中到授权和核心算法上。这样调下来，既能保住真正重要的代码，也能把多出来的体积控制在更合理的范围里。