libgdx thinking之慎用static

首先一些公共变量声明为static类型确实很方便，但请不要滥用，即使你觉得这不会带来内存上很大的代价，也会破坏代码的结构，想想一个变量谁都能引用他，在他的职责分配上会很困扰。

而且对于Texture，assetmanager等资源更加建议不要用static。也许你在desktop上测试发现这并没有问题，但在android上就会发生各种错误（纹理丢失，错误的纹理）。

desktop关闭后，jvm就关闭进程了，而android没有很明显的进程概念，退出游戏后，仍会保留进程，这是因为android系统设计者考虑了重复启动一个activity的代价，所以不会立即关闭进程而是采取内存不足时才关闭。（Gdx.app.exit（）也只是退出游戏，没有关闭进程，除非你使用system.exit或killProcess，但这抛弃了android系统设计者的优化技巧）。

再来看看这几个生命周期吧：application lifetime像上面说的，进程不会立即退出。activity lifetime，libgdx游戏其实只启动一个activity，游戏的生命周期和activity周期才对得上。opengl lifetime，activity失去焦点它就被回收了。纹理底层的byte是指向opengl contex的，所以activity失去焦点，texture也会丢失内容，但有时你发现再返回activity时显示正常，这是因为纹理管理机制自动帮你加载丢失的内容了。可是你退出activity（游戏）后就没这么幸运，java object依赖于应用进程，没被回收的就不会消失如静态变量，但纹理内容可是全都消失了，你再启动游戏，驻存的static声明的texture对象又被取来使用，但其指向的opengl context无法恢复，所以你会看到一些诡异的现象。

那么避免使用static声明资源吧，有意识的把资源的生命周期和activity的生命周期绑定。释放资源后使java object无效（赋null）也是避免诡异的好习惯。