gloom-阴暗，阴沉，阴郁，微光
【一男讲词】：gl/oom gl-光，oom-表音成分，无义，整词：阴暗就是微光，和“光”有关。
【同类举例】：
gl-光 →glory-光荣（光荣有“光”）→gl-表义，ory-表音/名词后缀
st-站、停 →story-故事（“故”事是“停”在历史中之事，已“故”之事）→st-表义，ory-无义、表音/名词后缀
fact-词根：做、制造→factory-工厂（工厂是制造东西的地方）→ory-名词后缀
【造词奥秘】：gl-oom(左义右声)←→阴（“月”表含义，“阴”不是黑，“阴”是有光，微
光而已，“月”表微光，“日”表强光，才有汉字的“阴／阳”之分）。
loom-织布机；隐现
【一男讲词】：l/oom l-线条，oom-表音成分，无义，整词：织布机用“纱、线”作为原料。
【同类举例】：
l -线条 →long-长（“线条”代表“长”的含义）→l-表义，ong-表音
thr-three-三、多 →throng-群、群集、群众（三人成“众”、“三”表示“多”）→thr-无义、表义，ong-表音
t-to-去、延伸→tongue-舌头（“舌头”的概念特征是“伸、延伸”）→t-表义，ong-无义、表音，ue-名词后缀
【造词奥秘】：l-oom(左义右声)←→织（都是左义右声）。
【补充解惑】：为什么” loom”还有“隐约出现”的含义——这是由“织布机”的含义衍生而来，指的是“织布机”织布的工作原理，由一根线到两根线再到多根线到最后完全地织成一张清晰的布，这个过程正是由淡到浓，由模糊到清楚的过程——隐约出现、朦胧地出现。
【同密扩展】：land-陆地（“陆地”是连续的，所谓“陆续”） lace-鞋带 lamp-灯（l-light-光线） lick-舔（l-舌、口条） lap-大腿（l-leg-“腿”是长条的） lash-鞭子
broom-扫帚
【一男讲词】：br/oom br-树枝、分支，oom-表音成分，无义，整词：人类最早使用的一个扫帚应该是由树枝制成。
【同类举例】：
br-树枝、分支→brook-小溪、支流（“支流”即“分支、树枝”）→br-表义，ook-表音
b -板子 →book-书（一本“书”的样子恰似一块板子→b-表义，ook-表音
【造词奥秘】：br-oom(左义右声)←→扫帚（两个字中的“ヨ”部，就恰似“分支、树枝”的概念，所谓中西贯通，文化相类。
【同密扩展】： brush-刷子（“刷子”的样子就像“树枝”和“扫帚”大同小异）
breed-繁殖（由“主干”到“分支”的过程恰是“繁殖”） brood一窝
brother-兄弟（每个“兄弟”是一个“分支”） bracket-壁架（一种在墙上突出的类似树枝结构的） bridge桥梁（人类在无法渡河的第一和历史瞬间将岸边的较粗大树枝折断，始成桥梁的雏形。） brace词根：手臂，括号（人的手臂、四肢类似“树枝”） embrace拥抱（em=in-进入） bright发光（br-分支、发散，ight-light-光） brook小溪(小溪是“支流”、“分支”)。
【补充解惑】：那么怎么解释brass-黄铜/bronze-青铜/brand-商标，烙印——这三个单词开首的”br”表示“烧”的含义，由简单词”burn-烧”简化而来，显然，“黄铜、青铜”都是“烧”出来的，“brand-烙印”更是有“火”才有“烙”。
bloom-花朵；开花
【一男讲词】：bl/oom bl-颜色，oom-表音成分，无义，整词：花朵是五颜六色的，是最初给人类有很多颜色感觉的自然界事物。
【同类举例】：
bl- 颜色→blush-脸红、红色、红光 →bl-表义，ush-表音
br -树枝→brush-刷子（“刷子”像“树枝”）→br-表义，ush-表音
r-run-跑→rush-冲、奔（“跑”的一种） →r-表义，ush-表音
【造词奥秘】：中文中表示颜色的词 ：黄[h]红[h]黑[h]褐[h]灰[h]粉[f，约等h]
（补充：[f]/[h]是一对近亲辅音字母，在很多语言中出现过彼此混用，如：“飞
机”在福建方言中是[hui][ji] ；“湖南”在湘方言中是[fu][lan] ；“凤凰”更是
被很多人说成[feng][fang]等），都由相同的生母开头。和中文类似，英语单词的“颜色”家族词汇也都是用相同的“密码”开头：blush-红色，black-黑色，blue-蓝色，blond-金色，brown-褐色。（’r’和’l’ 是一对近亲字母，在本人千篇文章有过讲述）。
【同密扩展】： blood血-bleach漂白blank空白的、失色的
【补充解惑】：” bl”的第二个密码含义——“吹”，例如：
blow吹
blast一阵风，爆炸的冲击波；爆炸（“风、波”都是吹出来的）
bleak寒冷的，凄凉的（有风吹才“凉”）
bless福分，福气（福“气”是一种气息、气流，福气、运气，都是如此）
breeze微风（”br”由”bl-吹”变化而来，”r”/”l”是近亲辅音字母，发生变异，情理之中。
zoom- 急速上升（原指直升飞机的猛然上升）突然扩大,急速上升
【一男讲词】：这是一个简单的象声词。整词的声音模仿直升飞机猛然上升时发出的“哫——”的声音。在中文中，最能代表这种含义的是“骤”字，我们说“骤然上升”，他们说“‘zoom’然上升”，异曲同工，都是在用声音记录生活。有些学者将这个单词联想成所谓“200米”，也算精彩，但是未能触及文字灵魂，亦不能授人以渔，年深岁久，便贻笑大方了。
1. 正确释放drawable的方式：Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash)
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm)
mBtn.setBackgroundDrawable(bd)
来代替mBtn.setBackgroundResource(R.drawable.splash)。
销毁的时候使用：
BitmapDrawable bd ＝ (BitmapDrawable)mBtn.getBackground()
mBtn.setBackgroundResource(0)//别忘了把背景设为null，避免onDraw刷新背景时候出现used a recycled bitmap错误
bd.setCallback(null)
bd.getBitmap().recycle()
2. 使用字节流，突破Android heap size的限制
从中不难发现，bitmap的存放位置根据Android版本的不同真的有所不同。好了，下面就是找出怎么把图片存放到native heap里就行了，BitmapFactory里就那么几个decode方法，很容易找到BitmapFactory .decodeStream就可以解决。下面贴一下代码：
BitmapFactory.Options options = new BitmapFactory.Options()
options.inPreferredConfig = Config.ARGB_8888
options.inPurgeable = true// 允许可清除
options.inInputShareable = true// 以上options的两个属性必须联合使用才会有效果
String sname = String.format( “xxx.png”, sTowerStyle, j, sDirction, i)
InputStream is = am.open(sname)
arrBmp[ iBmpIndex] = BitmapFactory .decodeStream(is, null, options)
ok搞定收工。
尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，
因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。
因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，
decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，
无需再使用java层的createBitmap，从而节省了java层的空间。
如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常
另外，decodeStream直接拿的图片来读取字节码了， 不会根据机器的各种分辨率来自动适应，
使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源，
否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。
redis可以被作为类似memcached的应用级缓存使用，在内存超过限制时，按照配置的策略，淘汰掉相应的kv，使得内存可以继续留有足够的空间保存新的数据。redis的conf文件中有对该机制的一份很好的解释：194 # Don't use more memory than the specified amount of bytes.195 # When the memory limit is reached Redis will try to remove keys196 # accordingly to the eviction policy selected (see maxmemmory-policy).197 #198 # If Redis can't remove keys according to the policy, or if the policy is199 # set to 'noeviction', Redis will start to reply with errors to commands200 # that would use more memory, like SET, LPUSH, and so on, and will continue201 # to reply to read-only commands like GET.202 #203 # This option is usually useful when using Redis as an LRU cache, or to set204 # an hard memory limit for an instance (using the 'noeviction' policy).205 #206 # WARNING: If you have slaves attached to an instance with maxmemory on,207 # the size of the output buffers needed to feed the slaves are subtracted208 # from the used memory count, so that network problems / resyncs will209 # not trigger a loop where keys are evicted, and in turn the output210 # buffer of slaves is full with DELs of keys evicted triggering the deletion211 # of more keys, and so forth until the database is completely emptied.212 #213 # In short... if you have slaves attached it is suggested that you set a lower214 # limit for maxmemory so that there is some free RAM on the system for slave215 # output buffers (but this is not needed if the policy is 'noeviction').216 #217 # maxmemory <bytes>注意，在redis按照master-slave使用时，其maxmeory应设置的比实际物理内存稍小一些，给slave output buffer留有足够的空间。redis支持如下五种缓存淘汰策略：219 # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory220 # is reached? You can select among five behavior:221 # 222 # volatile-lru ->remove the key with an expire set using an LRU algorithm223 # allkeys-lru ->remove any key accordingly to the LRU algorithm224 # volatile-random ->remove a random key with an expire set225 # allkeys->random ->remove a random key, any key226 # volatile-ttl ->remove the key with the nearest expire time (minor TTL)227 # noeviction ->don't expire at all, just return an error on write operations注释已经解释的很清楚了，不再赘述。其缓存管理功能，由redis.c文件中的freeMemoryIfNeeded函数实现。如果maxmemory被设置，则在每次进行命令执行之前，该函数均被调用，用以判断是否有足够内存可用，释放内存或返回错误。如果没有找到足够多的内存，程序主逻辑将会阻止设置了REDIS_COM_DENYOOM flag的命令执行，对其返回command not allowed when used memory >'maxmemory'的错误消息。具体代码如下：int freeMemoryIfNeeded(void) {size_t mem_used, mem_tofree, mem_freedint slaves = listLength(server.slaves)/* Remove the size of slaves output buffers and AOF buffer from the * count of used memory. */ 计算占用内存大小时，并不计算slave output buffer和aof buffer，因此maxmemory应该比实际内存小，为这两个buffer留足空间。mem_used = zmalloc_used_memory()if (slaves) {listIter lilistNode *lnlistRewind(server.slaves,&li)while((ln = listNext(&li))) {redisClient *slave = listNodeValue(ln)unsigned long obuf_bytes = getClientOutputBufferMemoryUsage(slave)if (obuf_bytes >mem_used)mem_used = 0elsemem_used -= obuf_bytes}}if (server.appendonly) {mem_used -= sdslen(server.aofbuf)mem_used -= sdslen(server.bgrewritebuf)}/* Check if we are over the memory limit. */if (mem_used <= server.maxmemory) return REDIS_OKif (server.maxmemory_policy == REDIS_MAXMEMORY_NO_EVICTION)return REDIS_ERR/* We need to free memory, but policy forbids. *//* Compute how much memory we need to free. */mem_tofree = mem_used - server.maxmemorymem_freed = 0while (mem_freed <mem_tofree) {int j, k, keys_freed = 0for (j = 0j <server.dbnumj++) {long bestval = 0/* just to prevent warning */sds bestkey = NULLstruct dictEntry *deredisDb *db = server.db+jdict *dictif (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_RANDOM){dict = server.db[j].dict} else {dict = server.db[j].expires}if (dictSize(dict) == 0) continue/* volatile-random and allkeys-random policy */if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_RANDOM server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_RANDOM){de = dictGetRandomKey(dict)bestkey = dictGetEntryKey(de)}//如果是random delete,则从dict中随机选一个key/* volatile-lru and allkeys-lru policy */else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU){for (k = 0k <server.maxmemory_samplesk++) {sds thiskeylong thisvalrobj *ode = dictGetRandomKey(dict)thiskey = dictGetEntryKey(de)/* When policy is volatile-lru we need an additonal lookup * to locate the real key, as dict is set to db->expires. */if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)de = dictFind(db->dict, thiskey)//因为dict->expires维护的数据结构里并没有记录该key的最后访问时间o = dictGetEntryVal(de)thisval = estimateObjectIdleTime(o)/* Higher idle time is better candidate for deletion */if (bestkey == NULL thisval >bestval) {bestkey = thiskeybestval = thisval}}//为了减少运算量,redis的lru算法和expire淘汰算法一样，都是非最优解，lru算法是在相应的dict中，选择maxmemory_samples(默认设置是3)份key，挑选其中lru的，进行淘汰}/* volatile-ttl */else if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_TTL) {for (k = 0k <server.maxmemory_samplesk++) {sds thiskeylong thisvalde = dictGetRandomKey(dict)thiskey = dictGetEntryKey(de)thisval = (long) dictGetEntryVal(de)/* Expire sooner (minor expire unix timestamp) is better * candidate for deletion */if (bestkey == NULL thisval <bestval) {bestkey = thiskeybestval = thisval}}//注意ttl实现和上边一样，都是挑选出maxmemory_samples份进行挑选}/* Finally remove the selected key. */if (bestkey) {long long deltarobj *keyobj = createStringObject(bestkey,sdslen(bestkey))propagateExpire(db,keyobj)//将del命令扩散给slaves/* We compute the amount of memory freed by dbDelete() alone. * It is possible that actually the memory needed to propagate * the DEL in AOF and replication link is greater than the one * we are freeing removing the key, but we can't account for * that otherwise we would never exit the loop. * * AOF and Output buffer memory will be freed eventually so * we only care about memory used by the key space. */delta = (long long) zmalloc_used_memory()dbDelete(db,keyobj)delta -= (long long) zmalloc_used_memory()mem_freed += deltaserver.stat_evictedkeys++decrRefCount(keyobj)keys_freed++/* When the memory to free starts to be big enough, we may * start spending so much time here that is impossible to * deliver data to the slaves fast enough, so we force the * transmission here inside the loop. */if (slaves) flushSlavesOutputBuffers()}}//在所有的db中遍历一遍，然后判断删除的key释放的空间是否足够if (!keys_freed) return REDIS_ERR/* nothing to free... */}return REDIS_OK}注意，此函数是在执行特定命令之前进行调用的，并且在当前占用内存低于限制后即返回OK。因此可能在后续执行命令后，redis占用的内存就超过了maxmemory的限制。因此,maxmemory是redis执行命令所需保证的最大内存占用，而非redis实际的最大内存占用。（在不考虑slave buffer和aof buffer的前提下）
