①Bloom filter
适用范围：可以用来实现数据字典,进行数据的判重,或者集合求交集
基本原理及要点：
对于原理来说很简单,位数组◆k个独立hash函数.将hash函数对应的值的位数组置1,查找时如果发现所有hash函数对应位都是1说明存在,很明显这个过程并不保证查找的结果是100%正确的.同时也不支持删除一个已经插入的关键字,因为该关键字对应的位会牵动到其他的关键字.所以一个简单的改进就是 counting Bloom filter,用一个counter数组代替位数组,就可以支持删除了.
注意这里m与n的单位不同,m是bit为单位,而n则是以元素个数为单位(准确的说是不同元素的个数).通常单个元素的长度都是有很多bit的.所以使用bloom filter内存上通常都是节省的.
扩展：
Bloom filter将集合中的元素映射到位数组中,用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中.Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter,从而支持了元素的删除操作.Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联.SBF采用counter中的最小值来近似表示元素的出现频率.
适用范围：快速查找,删除的基本数据结构,通常需要总数据量可以放入内存
hash函数选择,针对字符串,整数,排列,具体相应的hash方法.
碰撞处理,一种是open hashing,也称为拉链法；另一种就是closed hashing,也称开地址法,opened addressing. ()
问题实例：
①.).海量日志数据,提取出某日访问百度次数最多的那个IP.
适用范围：可进行数据的快速查找,判重,删除,一般来说数据范围是int的10倍以下
扩展：bloom filter可以看做是对bit-map的扩展
适用范围：海量数据前n大,并且n比较小,堆可以放入内存
基本原理及要点：最大堆求前n小,最小堆求前n大.方法,比如求前n小,我们比较当前元素与最大堆里的最大元素,如果它小于最大元素,则应该替换那个最大元素.这样最后得到的n个元素就是最小的n个.适合大数据量,求前n小,n的大小比较小的情况,这样可以扫描一遍即可得到所有的前n元素,效率很高.
扩展：双堆,一个最大堆与一个最小堆结合,可以用来维护中位数.
①.)100w个数中找最大的前100个数.
用一个100个元素大小的最小堆即可.
适用范围：第k大,中位数,不重复或重复的数字
基本原理及要点：因为元素范围很大,不能利用直接寻址表,所以通过多次划分,逐步确定范围,然后最后在一个可以接受的范围内进行.可以通过多次缩小,双层只是一个例子.
适用范围：大数据量的增删改查
基本原理及要点：利用数据的设计实现方法,对海量数据的增删改查进行处理.
适用范围：搜索引擎,关键字查询
基本原理及要点：为何叫倒排索引?一种索引方法,被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射.
以英文为例,下面是要被索引的文本：
T0 = "it is what it is"
T1 = "what is it"
我们就能得到下面的反向文件索引：
"what": {0, 1}
检索的条件"what", "is" 和 "it" 将对应集合的交集.
正向索引开发出来用来存储每个文档的单词的列表.正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询.在正向索引中,文档占据了中心的位置,每个文档指向了一个它所包含的索引项的序列.也就是说文档指向了它包含的那些单词,而反向索引则是单词指向了包含它的文档,很容易看到这个反向的关系.
问题实例：文档检索系统,查询那些文件包含了某单词,比如常见的学术论文的关键字搜索.
适用范围：大数据的排序,去重
基本原理及要点：外排序的归并方法,置换选择 败者树原理,最优归并树
适用范围：数据量大,重复多,但是数据种类小可以放入内存
基本原理及要点：实现方式,节点孩子的表示方式
扩展：压缩实现.
①.).有10个文件,每个文件1G, 每个文件的每一行都存放的是用户的query,每个文件的query都可能重复.要你按照query的频度排序 .
①.0.分布式处理 mapreduce
适用范围：数据量大,但是数据种类小可以放入内存
基本原理及要点：将数据交给不同的机器去处理,数据划分,结果归约.
①.).The canonical example application of MapReduce is a process to count the appearances of
each different word in a set of documents:
void map(String name, String document):
// name: document name
// document: document contents
for each word w in document:
EmitIntermediate(w, 1);
void reduce(String word, Iterator partialCounts):
// key: a word
// values: a list of aggregated partial counts
int result = 0;
for each v in partialCounts:
result ◆= ParseInt(v);
Emit(result);
Here, each document is split in words, and each word is counted initially with a "1" value by
the Map function, using the word as the result key. The framework puts together all the pairs
with the same key and feeds them to the same call to Reduce, thus this function just needs to
sum all of its input values to find the total appearances of that word.
经典问题分析
上千万or亿数据（有重复）,统计其中出现次数最多的前N个数据,分两种情况：可一次读入内存,不可一次读入.
可用思路：trie树◆堆,数据库索引,划分子集分别统计,hash,分布式计算,近似统计,外排序
所谓的是否能一次读入内存,实际上应该指去除重复后的数据量.如果去重后数据可以放入内存,我们可以为数据建立字典,比如通过 map,hashmap,trie,然后直接进行统计即可.当然在更新每条数据的出现次数的时候,我们可以利用一个堆来维护出现次数最多的前N个数据,当然这样导致维护次数增加,不如完全统计后在求前N大效率高.
如果数据无法放入内存.一方面我们可以考虑上面的字典方法能否被改进以适应这种情形,可以做的改变就是将字典存放到硬盘上,而不是内存,这可以参考数据库的存储方法.
实际上可能想直接将数据均分到不同的机子上进行处理,这样是无法得到正确的解的.因为一个数据可能被均分到不同的机子上,而另一个则可能完全聚集到一个机子上,同时还可能存在具有相同数目的数据.比如我们要找出现次数最多的前100个,我们将1000万的数据分布到10台机器上,找到每台出现次数最多的前 100个,归并之后这样不能保证找到真正的第100个,因为比如出现次数最多的第100个可能有1万个,但是它被分到了10台机子,这样在每台上只有1千个,假设这些机子排名在1000个之前的那些都是单独分布在一台机子上的,比如有1001个,这样本来具有1万个的这个就会被淘汰,即使我们让每台机子选出出现次数最多的1000个再归并,仍然会出错,因为可能存在大量个数为1001个的发生聚集.所以呢不能将数据随便均分到不同机子上,而是要根据hash 后的值将它们映射到不同的机子上处理,让不同的机器处理一个数值范围.
而外排序的方法会消耗大量的IO,效率不会很高.而上面的分布式方法,也可以用于单机版本,也就是将总的数据根据值的范围,划分成多个不同的子文件,然后逐个处理.处理完毕之后再对这些单词的及其出现频率进行一个归并.实际上就可以利用一个外排序的归并过程.
另外还可以考虑近似计算,也就是我们可以通过结合自然语言属性,只将那些真正实际中出现最多的那些词作为一个字典,使得这个规模可以放入内存.
①. 如果放在项目中用,验证码图片希望可以是接口返回.ImageView以及其子类支持花式加载图片.
* 在onSizeChanged()方法中生成 和 控件宽高相关的属性值：
①. 初始化时随机生成验证码区域起点
* onDraw()时,依次绘制：
①. 验证码阴影
MySQL 原生并不支持 bitmap 类型,所以就只能存字符串,然后就根据你的 bitmap 长度以及转换方式来选择是用什么类型来存储,处理的过程在代码层面完成.
我简单说下我们做同样的事情的做法,不一定是好方法,可以一起探讨.
不过我们用 MySQL 存储也就是为了确保数据的安全性,大部分的查询操作都在 redis 里面完成,redis 原生支持 bitmap 用起来又高效又方便.
尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图,
因为这些函数在完成decode后,最终都是通过java层的createBitmap来完成的,需要消耗更多内存.
所以呢,改用先通过BitmapFactory.decodeStream方法,创建出一个bitmap,再将其设为ImageView的 source,
decodeStream最大的秘密在于其直接调用JNInativeDecodeAsset()来完成decode,
无需再使用java层的createBitmap,从而节省了java层的空间.
如果在读取时加上图片的Config参数,可以跟有效减少加载的内存,从而跟有效阻止抛out of Memory异常
另外,decodeStream直接拿的图片来读取字节码了, 不会根据机器的各种分辨率来自动适应,
使用了decodeStream之后,需要在hdpi和mdpi,ldpi中配置相应的图片资源,
否则在不同分辨率机器上都是同样大小（像素点数量）,显示出来的大小就不对了.
另外,以下方式也大有帮助：
① InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width,hight设为原来的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
bmp.recycle() //回收图片所占的内存
system.gc() //提醒系统及时回收
}
以下奉上一个方法：
Java代码
① /**
①.0. opt.inPurgeable = true;
①.1. opt.inInputShareable = true;
================================================================================
Android内存溢出的解决办法
转自：
昨天在模拟器上给gallery放入图片的时候,出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常,图像大小超过了RAM内存.
由于每张图片先前是压缩的情况,放入到Bitmap的时候,大小会变大,导致超出RAM内存,具体解决办法如下：
//解决加载图片 内存溢出的问题
//Options 只保存图片尺寸大小,不保存图片到内存
BitmapFactory.Options opts = new BitmapFactory.Options();
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
通过上面的方式解决了,但是这并不是最完美的解决方式.
通过一些了解,得知如下：
优化Dalvik虚拟机的堆内存分配
Android堆内存也可自己定义大小
对于一些Android项目,影响性能瓶颈的主要是Android自己内存管理机制问题,目前手机厂商对RAM都比较吝啬,对于软件的流畅性来说RAM对性能的影响十分敏感,除了 优化Dalvik虚拟机的堆内存分配外,我们还可以强制定义自己软件的对内存大小,我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
bitmap 设置图片尺寸,避免 内存溢出 OutOfMemoryError的优化方法
★android 中用bitmap 时很容易内存溢出,报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
● 主要是加上这段：
BitmapFactory.Options options = new BitmapFactory.Options();
● eg1：(通过Uri取图片)
private ImageView preview;
Bitmap bitmap = BitmapFactory.decodeStream(cr
.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出,但它只是改变图片大小,并不能彻底解决内存溢出.
Bitmap b = BitmapFactory.decodeFile(fileName, options);
preview.setImageBitmap(b);
filePath.setText(fileName);
★Android 还有一些性能优化的方法：
● 首先内存方面,可以参考 Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配
● 图形对象优化,这里要说的是Android上的Bitmap对象销毁,可以借助recycle()方法显示让GC回收一个Bitmap对象,通常对一个不用的Bitmap可以使用下面的方式,如
if(bitmapObject.isRecycled()==false) //如果没有回收
bitmapObject.recycle();
● 对于大多数Android手机没有过多的物理按键可能我们需要想象下了做好手势识别 GestureDetector 和重力感应来实现操控.通常我们还要考虑误操作问题的降噪处理.
对于一些大型Android项目或游戏来说在算法处理上没有问题外,影响性能瓶颈的主要是Android自己内存管理机制问题,目前手机厂商对RAM都比较吝啬,对于软件的流畅性来说RAM对性能的影响十分敏感,除了上次Android开发网提到的优化Dalvik虚拟机的堆内存分配外,我们还可以强制定义自己软件的对内存大小,我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
介绍一下图片占用进程的内存算法吧.
android中处理图片的基础类是Bitmap,顾名思义,就是位图.占用内存的算法如下：
图片的width*height*Config.