最近在处理打开客户端界面加载卡顿的问题，两年前做cocos2dx项目的时候也注意到了这个问题，不过因为当时的界面比较简单，也没有太多精力去处理，不了了之。
现象是这样的，几百行甚至几千行的客户端代码里面，大部分时间都只卡在widgetFromJsonFile这个函数中，即对UI界面的UI元素树进行加载。不难猜想，里面进行了递归遍历并生成了一个个对应的cocos widget。我们组也对此做了不少的底层优化，纹理的缓存优化，json文件的加载优化，处理文本的卡顿bug等等。
抛开底层的优化，单纯地看待创建UI界面这个问题。整个流程只有两个入口：1. load，2. destroy，非常类似于服务端开发永远都优化不完的malloc和free函数。很容易想到UI界面缓存，显然这不是我想出来的，梦幻手游的UI界面就做了这种处理，细心的同学可以发现，打开商城界面操作一番，关闭界面再次打开，有些部分竟还是上次打开保留下来的，这是梦幻对界面加载贡献非常大的一个优化，缓存下来的界面可以做到瞬开。
有了加载结果缓存，那什么时候清理缓存呢，我目前发现的是断线重连会清理。其实清理方法很多，通过检测内存不足的时候清理，或者通过LRU的方式清理，或者兼而有之。最近发现剑侠情缘移动版是通过LRU的方式清理的。
下面来说下实现，主要的变化是，创建出来的root widget，增加了一个休眠状态，即三种状态：创建、销毁、休眠。休眠状态就是被cache住的状态，可以被唤醒重新利用来达到优化的效果。每次创建出来的widget通过FakeUI作为代理，接管原来的removeFromParent和setVisible这两个函数，缓存的时候并不真正销毁，只是隐藏起来，并记录下上次休眠的时间。
界面的生存周期流程图如下： 
再创建一个管理UIService，每次创建界面时候先读缓存，有则直接激活，没有则走正常创建流程，创建完以后，判断是否需要加入界面缓存管理。添加几个接口就可以投入使用了，如下：
class UIService(object):
add_to_cache(self, fake_ui)
get_cache(self, name)
clear(self, force=False) # 清理所有深度睡眠的ui cache
step_clear(self) # LRU的方式，一次清理一个深度睡眠的ui cache为了减少设备的内存占用，界面缓存提供了一个根据LRU的淘汰方式来逐步清理休眠中的界面，实现如下：
def step_clear(self):
""" LRU的方式，一次清理一个深度睡眠的csb cache """
oldest_cache = None
sorted_cache = self.sort_cache()
for i,cache in enumerate(sorted_cache):
deep_sleep_tiem = cache.get_deep_sleep_time()
if cache.is_deep_sleep() == True and deep_sleep_tiem > 0 and not self.check_ancestor(cache): # 只检索深度睡眠中的cache
oldest_cache = cache
break
if oldest_cache:
name = oldest_cache.get_name()
oldest_cache.fake_do_destroy()
del self._csb_cache[name]写完发现才100来行代码，对原有的逻辑代码侵害非常小，但是需要注意对root_widget动态addChild的控件需要清理以便下一次利用，最后再说一下，这种是通过内存来换取时间的方法，由于UI缓存长期占用纹理，内存占用过高降不下去，导致我们ios上线初期频繁闪退。后来我们最终只在android设备上开启了界面缓存。