2016 January 18

关于一次实际算法优化尝试

论数据结构选取的重要性

一个案例:

从服务器返回的企业信息状态数据列表中,分为两种,一种有Id标识,一种无Id标识;

要点1: 本地需要分别对于 两种企业 存储在两个列表中做有序展示,按照企业名称的拼音首字母;

要点2:每次从服务器获取的最新信息返回的数据是混乱的,两种数据混合返回

要点3: 返回的数据中有可能与目前已有的数据重合,判定规则是 Id相同则相同,Id相同的数据以服务器的更新替代本地的;

那么如何做这个数据整理呢?如果你第一时间想的是 硬排序 Double迭代,那么你的算法需要训练了,同时你对于Android的性能是不够重视的;

这种情况一般第一时间想到的是Hash算法,针对第一次本地没有数据的时候,对于第一次返回的服务器数据做遍历,建立两个列表,分别存储有Id与没有Id的数据,同时建立一个有Id的Hash索引,便于数据的更新替换,而不用重新再遍历确认本地数据中是否已有该Id,最后进行数据整理排序,排序当然是可以利用重写 Comparable接口,利用内置排序直接排序;

这样写貌似没什么问题,但是是不是还有其他容器可以利用呢?我们再仔细想想Java中的容器特性,就发现TreeSet集合就是用来干这个的,只需要我们指定什么样的情形是同样的,也就是重写 equal函数,指定合适的相同对象判断逻辑,那么内置不是直接就排序好了吗?

进一步想去如何解决后来的信息对象更新问题,想着是不是可以在equls判断的时候做数据更新呢?发现没什么用,其实想想 其实Set内部也是是维护了一个Map,每次将 作为Keyput进去,利用HashMap的 Key判定机制去判定对象是否相同,那么更新数据的思路就来了,只需要先针对 该Set Remove该对象,若Remove成功,代表先前有这个对象,再Add进去,这样就完成了数据更新,最后利用这个思路写出来代码简洁了一倍,性能差异不明显,根据其实现机制,可以推测其实后面一种方式更加耗费内存;

whether or no,这些都是一些好的有益的尝试;

补充:

最后在理清了服务器数据对象后还是选择了重写 企业Bean对象实现自然排序接口,重写 hashCode() 以及 equals函数;

上一篇
下一篇
Loading Disqus comments...
Table of Contents