给客户端写得LRU缓存

前言

由于我们的客户端的元素和资源比较多,cocos框架的各种库质量参差不齐,导致了有些地方加载速度实在很慢。并且没有一个统一的内存管理机制导致了整个内存占用不太好控制。

同时手机的硬件环境实在是千差万别,在IOS上,由于CPU和IO比较好,很多东西重算代价倒不大。 但是在Android上,CPU本来就偏弱,然后很多国产性价比机器,零件都缩水在IO设备上,还附加了各种用于节能和降低发热的降频策略,锁CPU策略。导致了很多数据重建的延迟比较高。 然而我们很容易发现,大多数Android的机器的内存都非常高,动辄2-3GB。 所以就希望说我们的应用能够最大化的利用内存作为缓存,在IOS上内存不够时重算,在Android上就拼命地用内存坐缓存,加载loading速度。

于是乎有了个写个LRU算法作为资源管理的想法。并且既然要做,就做得尽量简单、可复用,最好还能到时候服务器上也用。

LRU实现设计

由于最主要还是由客户端的问题引起的,所以最先还是考虑客户端的需求。目标如下:

  1. 首先这个管理器必须能够管理多种不同类型的资源(这是必须得,不然没存在的意义)
  2. 其次需要在不同类型的设备上用,所以一个很重要的功能就是自适应,能够弹性得自动调整在不同设备上的阈值
  3. 低性能消耗的LRU算法

为解决第一个问题,我们把LRU对象池分为两部分,LRU管理器对象池。其中LRU管理器负责管理所管辖的多种不同类型对象的对象池,然后负责判定LRU算法的缓存和失效淘汰规则。而对象池中则实际负责保存对象缓存。

对第二个问题,考虑到在IOS上有专门的事件通知内存报警,但是在Android没有,所以为了简便起见,统一设置告警走类似IOS的报警作为LRU的主动GC操作。这样的话Android需要自己判定低内村并触发内存回收。 关键在于回收的同时需要动态调整阈值,以适应当前的内存总量。目前的策略是单触发主动回收时,各项阈值减半,并大量回收资源。而push数量过多时触发一次资源回收,但是随之会将阈值的上限+1。总体上有点像TCP的拥塞算法。

最重要的就是LRU算法设计,为了减少LRU管理器的消耗,默认情况下对LRU资源池的操作都可以认为是O(1)的。

  1. 每种对象池内部维护一个队列,记录着所有缓存的空闲对象。
  2. LRU管理器内部维护一个队列,记录着各类对象的进入缓存池的顺序。
  3. 每种对象池对饮一个*push*操作,一个*pull*操作。
  4. 每一次*push*意味着一个对象进入对象池,把该对象推入队列首,同时分配一个push id,并记录到LRU管理器的push序列队列中。 > LRU管理器的push序列队列只记录push id和对象池内部的缓存队列
  5. 每一次*pull*意味着从对象池里取出一个对象,直接从队列首取出。这个操作和上面的一起组成了后进先出(LIFO)队列,即用来判定LRU的最近使用对象。
  6. push id使用uint64_t基本可以认为单进程内不可能会重复(实际使用中会保留如此之多的push id,所以必定唯一)
  7. LRU管理器统计总对象数量和push序列队列长度,当总对象数量超出上限或push序列队列长度过长时触发被动GC
  8. LRU管理器提供接口触发主动GC
  9. 每次执行GC则是从push序列队列里取最前面的节点,如果该节点的push id和里面记录的缓存队列的队列尾的push id一致,则认为该节点有效,执行该对象的gc。否则就是已失效,直接跳过。 > 因为存在一个对象被push,然后被pull出来,再被push进去的情况。这时候前一次的push序列记录已然已经失效,为了减少CPU消耗,pull的时候并不清理失效的push序列记录。 > 但是无论何时被push进对象池,push id一定是唯一的,所以只要判定push id是否有效就可以了。 > > 另外,由于是LRU算法,所以缓存队列里的队尾的必定是最早被push进队列的,而push序列也一定是按次序排序的,所以利用它们的这个特性可以实现O(1)复杂度的对象管理。因为每次push一定只伴随着一次pull或者一次gc。
  10. 被动GC的阈值调整是指push过多,pull过少导致的缓存数量过多时调整最大上限。对应着push序列的最大上限总对象数量上限。每次超出都+1,然后回收一个对象。
  11. 主动GC的阈值是指系统资源不足,需要主动由外部触发的缓存回收,这时候会把push序列的最大上限总对象数量上限总对象数量下限(即回收的时候保留的数量)调整为和当前序列数量/对象数量的平均值。然后回收的时候仅保留总对象数量下限 > 这一条和上一条配合使用,上一条会使缓存数量缓慢增加,这一条会使缓存数量大幅减少。这样,在高内存机器上就会很少触发主动GC,低内存机器上多触发主动GC。 > 目前使用这两种算法来实现各个机型上的动态缓存数量。
  12. 在实际使用过程中加入了超时机制,即即便内存很大,超过一定时间的push序列也会触发超时回收。
  13. 在实际使用过程中加入了自动调整各类上下限阈值的边界,因为在客户端场景里,有时候触发主动GC之后,有些资源会过一会再回收资源或在下一个关键点再回收。这会导致短时间内频繁触发主动GC。这会使动态调整的限制很快被调整到0值。以防这种情况再出现,加入了一个边界限制。

客户端上的应用

实际缓存池的实际使用过程中还是碰到了一些问题的。首先是cocos的很多组件本身有缓存机制,比如dragonbones和spine,还有sprite对贴图文件的缓存,对于这种对象实测缓存的影响不是特别大。

影响特别大得就是cocostudio创建的对象,我们里面实施了两层缓存。第一层是把csb文件缓存进来,这样可以减少IO操作,但是后来发现根据csb文件创建cocostudio节点反而花费了更多的时间(2/3的时间耗在这里)。 所以后来不得不对cocostudio创建的节点做缓存。然而如果是一开始就使用这个缓存的话就比较容易发现问题,我们中途开始切入这个缓存的话就发现。我们的很多UI模块代码并没有特别去重置CCNode,而是依赖析构作为资源回收和重置。 这导致了很多地方如果回收作为缓存的话,这次改动的地方,就变成下次读入以后的默认值。包括上一次添加到ListView里的节点都还在。

为了解决这个问题,我们不得不改动了cocos的源代码,对CCNode里一些公用的属性,比如children、position、anchor等属性做了快照。然后下次pull完以后恢复到快照。本来也想直接使用cocos的clone函数,无奈cocos的clone接口实现不全最后没有使用。 而cocostudio创建的一些子类的ui对象比如ListView、ImageView等等里那些不属于CCNode的属性,就要求使用前手动reset,因为如果每个子类都去加缓存的话对cocos的改动有点大,怕以后不好merge。

最后就是实际释放缓存的过程中,有些数据是在切换场景的时候释放的,这时候很多对资源的引用都会清空,不会再次使用。 比如sprite的贴图,清理的时候如果场景里还有引用到的地方,是不会清除的。 再比如dragonbones的骨骼和贴图,dragonbones自己有一层缓存和引用记录,但是它做得不好,在缓存清理的时候不通知被引用的Node,然后会导致被引用的Node在渲染时崩溃。所以清除dragonbones自身的缓存的同时还必须清理所有已有的对象。 而且特别是dragonbones和spine,即便目前没有使用在一场战斗中十有八九马上也会用到。战斗中卡一下的体验是非常不好的。所以对这些资源都会延后释放。

延后释放也会碰到一个问题,就是可能短时间内内存并没有被清理出来,然后会频繁调用主动GC。于是就有了上面第12条提到的限制。但是特别是IOS既然到了内存告警,最好先释放一部分出来。以备后用。 所以我们的缓存回收里加了一些分级,有些对象常规内存回收不做,紧急内存(IOS内存告警)回收会尽量释放一些应该不会再被引用到的资源。

服务器上的应用

暂时还未实施,但是这样的LRU算法设计也考虑了服务器上可能可以使用的场景。比如聊天服务器按活跃度来缓存玩家或者频道的聊天数据,淘汰冷数据。

另外在服务器端虽然不用太多地考虑内存回收问题,但是可以利用这个算法管理器的过期机制来提供定期保存的功能。甚至实现定期脏数据保存的功能。

**定期保存: ** 每个对象只push一次,在gc时保存并重新push进pool **定期脏数据保存: ** 每个对象在写脏时先pull再push一次,在gc时保存 并且这些功能都可以利用lru管理器的各类上限来实现过载保护

代码实现

以上的代码位于: https://github.com/owent-utils/c-cpp/blob/master/include/MemPool/lru_object_pool.h 单元测试见: https://github.com/owent-utils/c-cpp/blob/master/test/case/LRUObjectPoolTest.cpp

Written with StackEdit.

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏烂笔头

在Python应用中使用MongoDB

目录[-] Python是开发社区中用于许多不同类型应用的强大编程语言。很多人都知道它是可以处理几乎任何任务的灵活语言。因此,在Python应用中需要一个...

4344
来自专栏测试开发架构之路

今天研究了一下手机通信录管理系统(C语言)

题目:手机通信录管理系统 一、题目要求 二、需求分析 三、设计步骤/编写代码 四、上机/运行结果 五、总结 一、题目要求 模拟手机通信录管理系统,实现对手机中...

56610
来自专栏生信宝典

Python文学化编程 - Jupyter notebook使用和插件拓展

Jupyter notebook (Ipython notebook)是集代码、结果、文档三位一体的文学化可重复程序文档。支持40多种程序语言,Python为原...

49710
来自专栏高性能服务器开发

从零学习开源项目系列(三) CSBattleMgr服务源码研究

如上图所示,这篇文章我们将介绍CSBattleMgr的情况,但是我们不会去研究这个服务器的特别细节的东西(这些细节我们将在后面的文章中介绍)。阅读一个未知的项目...

1643
来自专栏Albert陈凯

【Hadoop】三句话告诉你 mapreduce 中MAP进程的数量怎么控制?

原文地址: MapReduce Input Split(输入分/切片)详解 结论: 经过以上的分析,在设置map个数的时候,可以简单的总结为以下几点: (...

4838
来自专栏Small Code

MATLAB批量文件重命名(详细解释)

这段时间在用 matlab 做手写数字识别,处理样本的时候需要对样本文件进行重命名,可是有好多,总不能一个一个重命名吧,于是上网百度了好多,不过大多都一样,但是...

3407
来自专栏智能大石头

XCode之第一次亲密接触

首先得说明,本教程仅用于让第一次接触XCode的朋友了解XCode,不具有任何别的实际意义,真正的项目也不会采取这种开发方式,而采用更先进、快速而强大的开发方式...

2539
来自专栏SDNLAB

深度数据包检测DPI开发解析

深度数据包检测(DPI) 深度数据包检测(Deep packet inspection,缩写为 DPI)是一种特殊的网络技术,一般网络设备只会查看以太网头部、I...

5027
来自专栏Python攻城狮

Python数据科学(四)- 数据收集系列1.数据型态2.结构化vs半结构化vs非结构化数据3.Python IO与档案处理

◆ 定性分析: 分析: _ 知几写了很多篇文章 ◆ 定量分析: 分析:_ 知几写了107篇文章。

1342
来自专栏魏琼东

一步一步教你使用AgileEAS.NET基础类库进行应用开发-基础篇-ORM访问器及其配置

系列回顾          本系列前面有三篇文章介绍和演示了AgileEAS.NET平台ORM组件的开发流程及其常见的使用方式,通过前面的三篇文章,大家都可以正...

1989

扫码关注云+社区

领取腾讯云代金券