12 2012 档案

摘要：包 java.util.concurrent.*[ 一 ]、常用线程池最常用构造方法为：ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactorythreadFactory, RejectedExecutionHandler handler)JDK自带的配置好的线程池： // 固定工作线程数量的线程池 ExecutorService executorServ.. 阅读全文

摘要：在编程中有时候需要对图片做特殊的处理，比如将图片做出黑白的，或者老照片的效果，有时候还要对图片进行变换，以拉伸，扭曲等等。这些效果在android中有很好的支持，通过颜色矩阵（ColorMatrix）和坐标变换矩阵（Matrix）可以完美的做出上面的所说的效果。下面将分别介绍这两个矩阵的用法和相关的函数。颜色矩阵android中可以通过颜色矩阵（ColorMatrix类）方面的操作颜色，颜色矩阵是一个5x4 的矩阵（如图1.1）可以用来方面的修改图片中RGBA各分量的值，颜色矩阵以一维数组的方式存储如下：[ a, b, c, d, e, f, g, h, i, j, k, l, m, n, o 阅读全文

摘要：1FIFO1.1.原理按照“先进先出（FirstIn，FirstOut）”的原理淘汰数据。1.2.实现FIFO队列，具体实现如下：1.新访问的数据插入FIFO队列尾部，数据在FIFO队列中顺序移动；2.淘汰FIFO队列头部的数据；1.3.分析l命中率命中率很低，因为命中率太低，实际应用中基本上不会采用。l复杂度简单l代价实现代价很小。2.SecondChance2.1.原理FIFO算法的改进版，其思想是“如果被淘汰的数据之前被访问过，则给其第二次机会（SecondChance）”。2.2.实现每个数据会增加一个访问标志位，用于标识此数据放入缓存队列后是否被再次访问过。如上图，A是FIFO队列中 阅读全文

摘要：1.LFU类1.1.LFU1.1.1.原理LFU（LeastFrequentlyUsed）算法根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。1.1.2.实现LFU的每个数据块都有一个引用计数，所有数据块按照引用计数排序，具有相同引用计数的数据块则按照时间排序。具体实现如下：1.新加入数据插入到队列尾部（因为引用计数为1）；2.队列中的数据被访问后，引用计数增加，队列重新排序；3.当需要淘汰数据时，将已经排序的列表最后的数据块删除。1.1.3.分析l命中率一般情况下，LFU效率要优于LRU，且能够避免周期性或者偶发性的操作导致缓存命中率下降 阅读全文

摘要：1.LRU1.1.原理LRU（Leastrecentlyused，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。1.2.实现最常见的实现是使用一个链表保存缓存数据，详细算法实现如下：1.新数据插入到链表头部；2.每当缓存命中（即缓存数据被访问），则将数据移到链表头部；3.当链表满的时候，将链表尾部的数据丢弃。1.3.分析【命中率】当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。【复杂度】实现简单。【代价】命中时需要遍历链表，找到命中的数据块索引，然后需要 阅读全文

摘要：在Android中实用LRU+软引用（弱引用）的方法来缓存图片，可以减少内存溢出的情况。实现思路：在把图片保存到LRU集合中的时候，同时保存在一个弱引用的集合之中，如果此元素被LRU算法删除，可能垃圾回收器还并没有回收，可以通过弱引用的集合获取到此引用。publicLinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder)；initialCapacity 初始容量loadFactor 加载因子，一般是 0.75faccessOrder false 基于插入顺序 true 基于访问顺序（get一个元素后，这个 阅读全文

摘要：bundle字段这些字段名都是XML中的名称，在xcode的属性编辑器中，名字并不相同bundle目录中的属性列表详细描述了有关该bundle的信息。Finder和一些系统API在一些情况下会使用这些信息。bundle支持下列字段类型：Core Foundation字段–描述了bundle的综合属性Cocoa特定的字段–描述了和Cocoa有关的bundle的属性Finder特定的字段–描述了和Finder与文件系统有关的信息启动服务字段–描述了和启动服务有关的信息标准Bundle字段Mac OS X 为描述bundle的信息提供了一组核心字段。集成开发环境会赋予这些字段缺省值。表A-1列出了这 阅读全文

摘要：Afinal 是一个android的 orm 和 ioc 框架。而且封装了android中的httpClient，使其更加简单易用。使用finalBitmap，无需考虑bitmap在android中加载的时候oom的问题和快速滑动的时候图片加载位置错位等问题。Afinal的宗旨是简洁，快速。约定大于配置的方式。尽量一行代码完成所有事情。目前Afinal主要有四大模块：1、FinalDB模块：android中的orm框架，一行代码就可以进行增删改查。支持一对多，多对一等查询。2、FinalActivity模块：android中的ioc框架，完全注解方式就可以进行UI绑定和事件绑定。无需findV 阅读全文

摘要：Run LoopsRun loops是线程相关的的基础框架的一部分。一个run loop就是一个事件处理的循环，用来不停的调度工作以及处理输入事件。使用run loop的目的是让你的线程在有工作的时候忙于工作，而没工作的时候处于休眠状态。Run loop的管理并不完全自动的。你仍然需要设计你的线程代码在合适的时候启动run loop并正确响应输入事件。Cocoa和Core Fundation都提供了run loop objects来帮助配置和管理你线程的run loop。你的应用程序不需要显式的创建这些对象(run loop objects)；每个线程，包括程序的主线程都有与之对应的run l 阅读全文

摘要：虽然iOS 5.0版本之后加入了ARC机制，但由于相互引用关系比较复杂时，内存泄露还是可能存在。所以了解原理很重要。这里讲述在没有ARC的情况下，如何使用Instruments来查找程序中的内存泄露，以及NSZombieEnabled设置的使用。本文假设你已经比较熟悉Obj-C的内存管理机制。实验的开发环境：XCode 4.5.21、运行Demo。先下载一个实现准备好的内存泄露的Demo吧：leak app下载下来，打开运行，程序是一个寿司的列表，列出各种寿司卷。试着选择里面的几行，应该是选第二行的时候就崩溃了。崩溃截图：在崩溃的地方断住了，知道crash的地方了，但是不知道具体crash的原 阅读全文

摘要：MacVim下载安装DownloadMacVim 7.3 (snapshot 64) for Mac OS X Lion. (Released Jan 2, 2012.)下载后得到MacVim-snapshot-64.tbz这个包里面有三个文件（MacVim、mvim、reader.txt）把MacVim.app放到你的应用程序也就是/Applications目录下PS:必须放到应用程序目录下,否则终端调用:mvim会找不到MacVim的可执行文件把mvim拷贝到/usr/bin/这个目录下$sudo cp -f mvim /usr/bin/终端就可以通过$ mvim 文件名来启动MacVim 阅读全文

摘要：基本思路是：对每一条曲线的首末点虚连一条直线，求所有点与直线的距离，并找出最大距离值dmax，用dmax与限差D相比：若dmax＜D，这条曲线上的中间点全部舍去；若dmax≥D，保留dmax对应的坐标点，并以该点为界，把曲线分为两部分，对这两部分重复使用该方法。/// <summary>/// Uses the Douglas Peucker algorithm to reduce the number of points./// </summary>/// <param name="Points">The points.</par 阅读全文

摘要：BitmapFactory.decodeResource和BitmapFactory.decodeStream，相信对于有过android app开发经验的人来说都是很熟悉了。关于Bitmap的OOM问题，网上也有很多文章进行了分析，不少文章都说为避免OOM，最好使用BitmapFactory.decodeStream，但是具体说明原因的我至今没有找到，所以趁着10.1期间有空，就调查了一番，希望结果对大家能有帮助。 先来张时序图，看了这张图，估计很多问题都不用说明了：下面做些说明：1，函数externalBytesAvailable(...)的内存计算方法详细请参见文章《Android .. 阅读全文

摘要：在编写Android程序的时候，我们总是难免会碰到OOM的错误，那么这个错误究竟是怎么来的呢？我们先来看一下这段异常信息：08-14 05:15:04.764: ERROR/dalvikvm-heap(264): 3528000-byte external allocation too large for this process.08-14 05:15:04.764: ERROR/(264): VM won’t let us allocate 3528000 bytes08-14 05:15:04.764: DEBUG/skia(264): — decoder->decode retu 阅读全文