老实说，延迟下载游戏资源及调用只是一种辅助手段，与游戏开发本身关系并不大，实质也无非只是文件下载及文件读取的混用。但考虑到上周有网友问及此类问题，笔者觉得与其回邮件单独解释，倒不如写篇博文看起来更具体清晰，还能令大家帮助笔者斧正刊误，故成此文，仅供参考。
一般来讲，我们之所以会需要通过下载方式加载游戏资源，无非是出于如下几种目的：
1、精简游戏体积：
假设我做了个100MB的游戏，却非想把它宣传成仅有1MB的精巧程序，这时我该怎么办呢？
去欺骗用户，用大量复杂的技术名词忽悠他们说1MB和100MB等值吗？——用户不是傻子，至少不都是傻子，无论你的话术多么巧妙，也很难让绝大部分人都相信1MB和100MB是一样的。但大话已然出口，始终要想办法解决。
其实呢，在现有技术体系下，要搞定他们好简单的，只需将游戏初始界面混合下载器打包成1MB的文件发布，再“骗”他们下载执行，而后——就让他们慢慢等待系统加载剩下那99MB吧！毕竟没人说过这个游戏不需要额外的网络资源同步嘛……
2、网游资源的延迟加载需要：
目前的网络游戏——特别是网页游戏，为了尽可能的减少不必要的资源损耗，提高运行效率，大多数时候并不会一口气将所有资源都加载到游戏中，而是“大而化之，分而治之”，将游戏资源构建成一个个小小的资源包，仅仅在需要时，才或同步、或异步的加载到游戏中。这也正是我们在很多网游中所见到的，当角色过屏、读取新地图或遭遇新怪物时，画面会出现稍候字样或者部分马赛克乃至停顿的原因。
故此，通过网络适时地去加载需要的资源，几乎已成为网游开发中必不可少的技巧之一。
3、融入特殊的加密解密机制：
我们都知道，但凡是人所做出的程序，就没有人所不能破解掉的。但是——却很可能发生一个人做出来的程序，另一个人数年之内无法破解的现象。而当数年之后，另一个人破解出来时，这段程序却早已过气，白送都没人要了。
因此，当你极端的不想自己游戏被反向工程——尤其是想保护Java这种极好反编译的代码时，通过网络下载的另一种意义便显现出来了。你可以将下载的jar或class乃至其它种种保存到一个不同于执行目录的“隐秘”场所，并且无论密钥也好，特殊结构也罢，总之变着方的将资源加密混淆，就算混淆到连你自己都不知道这是什么东西也无所谓——能解释成字节码就好，最大限度的增加反向难度。而当你执行完毕，再一删了事——下次还可以再下嘛。这样做的话，虽然不能彻底杜绝代码被他人盗用，但，至少也可让反向我代码那哥们累掉层皮（^^）。
4、本地程序及资源合法性验证：
在大多数网络游戏中，为了保证用户不做出一些诸如使用外挂的“犯规”行为，是会对系统环境乃至封包数据进行合法性验证的，而一旦发现“非法”的东西存在，则会令“违法”玩家吊线或者干脆封号以示惩罚。
但这些验证，主要都只针对程序“外部”，即当“犯规”对象“不是我的游戏时”才能发挥功效，但万一“犯规”者“来自游戏本身时”或者“验证程序认为来自游戏本身时”，则变得无能为力，这也是为什么大多数网游都“内挂”泛滥的缘故。
幸运的是，Java程序由于其“天资所限”，是很难在虚拟机外部被攻破利用的，如果用Java制作网游，原则上大可不必担心“内挂”问题——但，这也有个大前提，那就是在“内挂”运行于虚拟机之外时才行的通。
而如果“内挂”运行在虚拟机之内呢？ 如果我的“内挂”是一小段插入原始游戏中的代码呢？ 要知道，动态加载class，动态修改字节码，早就不算什么事情了。
这时，就需要校验Java程序的合法性。
本来要验证这种事情是比较耗费时间的，但如果我们善于利用每次下载资源（比较大的，比如过图或者游戏更新），如果不单单“下载”，更同步“上行”，利用空档同服务器校对本地Java程序的合法性及完整性，便能很大程度上避免这种无意义的校验时间浪费。这时有缺少的文件便添加，有多余的——也就是出现不该存在的Jar或class乃至原始字节码修改，便借机强行“咔”掉它，免得它“为祸人间”。
5、系统升级：
通常来说，大多数的程序是不可能一个版本用到底的，游戏也不例外，无论是功能的增加或者Bug修正都离不开系统的更新。为了避免每次升级都令用户面临重装的苦恼，通过网络下载更新资源并自动更新系统也就变得非常必要。