大航路

He110 NJU!

亚楠兄 — Sun, 20 May 2012 02:02:01 +0800

记于南大110周年校庆。已然毕业将近一年，没能赶上，很是遗憾。不过私以为南大人，对学校还是有很强的归属感的，更何况体验过“两岸三地”的生活的我们，南大，生日快乐！遥想初到浦口，已然是5年前。两年的光阴，关于浦口的记忆，却极其零星——八角楼教室阳光从奇怪的角度照进来睁不开眼；每周化学实验间隙去启明园小小奢侈一把；131上抢到座位的欢乐；还有龙王山上的破楼和被烧坏了的佛像。而其他的一切似乎都淡掉了，一时甚至想不起来。辗转到仙林，当时整个校区就是一工地，作为第一批人肉净化器，目睹着仙林一天一天的变化。还记得第一天到仙林的时候，就一个人在校区里逛啊逛，看着各个规划，期待着未来的样子；却没想到现在已经远在帝都了，时光飞快啊！在仙林，是我码农生涯的真正开始了把！各中细节，就不多究了。我最喜欢的还是鼓楼，这里有一个大学所需要的一切；或者说，在我眼里，这就是大学。身处闹市，却不失风度，几十甚至上百岁的老房子，满是银杏的小花园，有大楼，更有大师。还记得当时每天下午叫上同学准时去操场跑上几圈，或是去玄武湖散步，鸡鸣寺赏樱，亦或是爬爬紫金山，依旧历历在目，又或许只是因为记忆比较新把！关于校庆，跟我还是有点关系的！做了个很搓的校庆网站，受到了校庆办老师们的厚爱很是惭愧。但是很荣幸的在北大楼呆过一段时间，这对于每个南大人来说，都是非常高的荣誉了把！Also providing the perplexed me encouragement to take one shot and got everything that I ever wanted. Though still up in the air, I should be thankful and grateful. 以上。

Refused to execute a JavaScript script. Source code of script found within request

亚楠兄 — Wed, 16 May 2012 20:04:08 +0800

情况如下：

网页A通过表单POST了一段HTML代码到网页B，网页B中直接将收到的HTML打印出来；

但是当POST的数据中，有JS或者IFRAME的时候，JS会IFRAME会被CHROME浏览器判断为可能的XSS漏洞而停止解析

报错为：
Refused to execute a JavaScript script. Source code of script found within request

完全没想法，果断google之，在stackoveflow上找到描述：
http://stackoverflow.com/questions/1547884/refused-to-execute-a-javascript-script-source-code-of-script-found-within-reque(点我)

It’s a security measure to prevent XSS (cross-site scripting) attacks.

This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message Refused to execute a JavaScript script. Source code of script found within request.

Also see this blogpost about Security in Depth: New Security Features.

大意就是，如果通过一个POST请求发送一段数据，而检测到该请求返回的数据中出现了发送的数据，则chrome浏览器判断此为潜在的XSS漏洞，从而拒绝执行页面上的JS脚本(实测还有IFRAME也停止加载了)

解决方案：
没办法啦，只能在JS发送的时候，先加个密什么的，然后在输出的时候，原样解密就行。
我在前端JS用的是 encodeHTML 方法把字符串转化为 HTML实体( & 之类)
在后端PHP用htmlspecialchars_decode()处理一下内容就好

博客搬家

亚楠兄 — Tue, 08 May 2012 10:42:40 +0800

原先备案神马的太麻烦了

干脆迁到国外了在bluehost上买了个空间

略慢

但还是能忍受了~~~总比国内动不动不能访问强

So………. It’s a new day, It’s a fresh start

用flex&bison代替正则表达式进行URL匹配(1)

亚楠兄 — Sun, 19 Feb 2012 00:10:01 +0800

其实这个标题稍显不妥，暂且不管。

需求：读取一个URL，一旦其符合某些规则，则将其转化为指定的格式。

场景：手机访问一个网站下的PC版的页面，对于某些页面，可以直接跳转到手机版本；而如果手机版没有对应的页面，则不需要跳转。通常手机版与PC版的页面的URL规划并不相同，那么就需要有一个跳转服务了——在服务器程序(如Apache)中建立一个模块，优先于路由执行，一旦判断用户是手机并且访问的URL符合规则，则直接HTTP 302跳转到对应的手机版的URL。

例：http://bigline.cn/blog/xxxx.html 需要转化为 http://wap.bigline.cn/blog/xxxx.html；
而 http://bigline.cn/blog/page/xxxx 则不需要进行转化

如何实现：最简单，最直接的方法，就是用正则表达式(什么是正则表达式?)了把。我们写几条规则，然后挨个进行判断，一旦符合其中一条规则，则立即生成并返回新的URL即可。

比如当前URL为博客页：”http://xxx.bigline.cn/liupc21/blog/item/5b39ae4bf9bc31ef83025c2c.html”
对应的规则为： “^http://xxx\\.bigline\\.cn/([^/]*)/blog/item/([^/]*).html”
匹配成功后，我们可以获得其中匹配到子串，分别为 liupc21 与 5b39ae4bf9bc31ef83025c2c ，分别表示用户名以及文章的ID
于是我们生成新的URL： ”http://wap.xxx.bigline.cn/liupc21/blog/item/5b39ae4bf9bc31ef83025c2c.html”

就是这么简单。

当然，在用户量大的时候，就什么事情都变得不简单了。

一下子蜂拥而至的请求，对任何程序的性能都是考验啊。假如我们设置了10条规则，用户每一次访问 Bigline.cn 上的任何一个网页的时候，都会进行匹配。这样，最好的情况是刚匹配到第一条规则就成功了，只需要匹配一次；最坏的情况当然是不在规则列表中了，得匹配十次。在最坏情况频频发生的时候，事情就不太好办了。

一个简单的解决策略就是，调整规则匹配的顺序，将容易成功的规则放在前面。例如bigline.cn是一个博客，那么它的博客页的访问显然是最多的，将匹配博客页的规则放在前面，(理想情况下，)将会减少平均的匹配次数。

但是这个方案总觉得不是很稳妥，特别是在需求的规则到了几十条的时候，又该怎么办。于是突然想到《编译原理》中使用到的flex&bison。

思路就是一个： 用一个DFA取代多个DFA。当然，如果你已经瞬间明白了，就可以不用往下看啦。不过有兴趣的话，可以查看两种方式执行效率对比的DEMO(点我下载)，有源代码哦~亲！

在11条规则，处理400条URL的时候，两者都判断出290条需要转换，且生成新的URL，用正则表达式消耗9毫秒，而用flex&bison居然只用了1ms。而实际上，前者的9毫秒并不包括编译正则表达式所需要的时间，由于正则表达式在程序每次执行的时候都要编译一遍先，得额外花上一些时间，当然，低于1ms。

Count ALL 400 URLs
Using Regexp time cost 9ms need jump 290
Using Flex&Bison Compiler time cost 1ms need jump 290

那么我就开始慢慢道来了。。。。

flex是词法分析生成器LEX的一个实现，扫描一段文字，并将其转化为一段TOKEN序列。例如在某种规则下，读入”this is a word”，则会得到四个TOKEN，分别是{“this”,”is”,”a”,”word”}。当然，flex的功能远比这个强大，自己定义规则之后，想怎样识别都没有问题啊。(更多介绍点我)。

bison则是一个采用LALR(1)文法的语法分析器，配合flex简直天下无双啊。通过一系列产生式，将flex生成的TOKEN列表规约到我们需要的结果，并能在规约过程中进行各种处理，当然，编译器就是这样实现的啦。(更多介绍点我)

而实际上，flex与bison的工作原理都是：将我们编好的规则依据某些算法，生成一个确定型的有穷自动机(DFA)。即有程序负责读取每一个字符(或TOKEN)，并跳转到对应的状态。
例如，状态A读入某字母X后能跳转到状态B，而状态B读入X则跳转到状态A，最终到达某个终止状态Z的时候，就终止读取了。当然，在某个状态读入某个X的时候，发现可以跳转到好几个状态去，那这就是NFA了。(点我看更多)

那么这个跟正则表达式有什么关系呢？真相就是，每一条正则表达式背后，都是一个默默工作着的DFA啊！在各种语言中，编译器/解释器会将每一条正则表达式编译成一个DFA，它碰到字符串输入的时候，就开始在各个状态之间跳来跳去了，当跳到某个状态表示匹配成功了，就把数据输出来。

回到最初的话题，如果我们有20条规则，那么会生成20个DFA，那么有无可能减少甚至合并成1个？BINGO！我跟你想到一块去了！

当然，直接把这些DFA进行合并不太可能——相当于重写个正则表达式的解析器，且目前网上比较出名的几个正则解析器都是经过各种精心优化的，绝对不是盖的。不过特殊情况特殊分析，在flex&bison中设置一些规则，是不是也能起到识别的作用呢？而且无论规则有多少条，编译后的DFA只有两个：一个在flex中用来扫描URL并转化成TOKEN列表，另外一个则在Bison中用于分析flex扫描得到的TOKEN序列。

理论上，这样会比直接正则表达式直接上阵快很多，具体怎么样，还是得实事求是，数据说话。

于是我分别实现了相同的11条规则下，分别用正则和编译器处理同样数据的时间消耗对比DEMO，代码在这里(点我下载)

具体怎么实现，且听下回分解。

注：可能需要根据实际情况修改Makefile，使用GCC进行编译.同时需要Flex&Bison&Regex的库，在windows下，可以去GnuWin32的主页上下载

[转]法兰西是培根？

亚楠兄 — Tue, 07 Feb 2012 19:54:11 +0800

小时候，爸爸对我说：

“知识就是力量。——弗朗西斯·培根”

然而，年幼的我对于陌生的人名缺乏认识，便想当然地将这句话听成了：

“知识就是力量。法兰西是培根。”

之后的十多年里，这句名言的后半部分一直在困扰着我：它是什么意思？为什么能和前半句列在一起？知识与力量、法国与培根之间，难道冥冥之中有着什么难以言喻的联系吗？

我无法理解。

可是，每当我向大人们提起“知识就是力量，法兰西是培根”这句话，他们却只是赞同地点点头。

或者是当有人说了句“知识就是力量”时，我会紧跟着接上一句“法兰西是培根”……可从没有人用怪异的眼光看着我、认为我说了奇怪的事，而只是若有所思地表示同意。

我还专门去问过一个老师，“知识就是力量，法兰西是培根。”这句话是什么意思，然而得到的答复却是整整10分钟关于“知识就是力量”的解释，压根没有触及一点儿“法兰西是培根”的内容。当我怯生生地用疑问的语气提醒老师，“法兰西是培根？”他只是说了句“没错。”只有12岁的我没有勇气和自信再追问下去。

我绝望了。

从那一刻起，我知道自己永远不可能理解这句谜一般的话语背后的奇特意义，我放弃了追寻，仅仅将它当作是可以挂在嘴边、却不去思考其意味的一个谜。

直到多年之后在书籍中偶尔见到这句话，我才意识到发生了什么。

那一瞬间，童年崩坏……

英文原版传送门 http://www.reddit.com/tb/dxskm

[译]Google+提升网页性能的5个小秘密

亚楠兄 — Wed, 04 Jan 2012 20:24:30 +0800

原文地址： https://plus.google.com/115060278409766341143/posts/ViaVbBMpSVG

1.使用Closure

我们使用Closure库、模版以及编译器来渲染Google+里每一个页面的每一个节点——甚至包括掌控页面的Javascript脚本。以下几点有助于加速网页的显示：

-Closure模版可以在服务器端用Java渲染，也可以在浏览器里用JS生成。这样的话，我们需要的内容总是能立即获取到；同时，我们也可以在”后台”( 指浏览器中的异步加载 )中载入javaScript（就像“装饰”一个网页，在主干之上，不断给各节点增加事件的响应）

-同时，Closure套件为JS提供了许多新特性：强类型、更强的错误检测、“死代码”预估、跨模块的通信以及很多的优化手段。

(欲了解更多的Closure套件细节，访问 http://code.google.com/closure/ )

2.总是在最适当的时候，书写最恰当的JS代码

我们将JS代码分割程序多小的模块，并能被异步加载，从而更方便的管理Google+中的JS脚本。而用户只需要按需下载最少的JS脚本。我们依照两个规则来进行设计：

-客户端必须包含一个核心的代码，它通过历史标记(也就是记录浏览器地址栏中的地址)来判断加载需要的模块。

-如果需要的JS模块没有加载完全，我们会阻塞页面所有的操作，直到加载完毕。

3.无刷新实现页面间的跳转

一旦JS脚本载入完毕，我们将脱离服务器，在本地渲染所有的内容，因此可以达到很快的速度。我们设置了一个全局的事件监听器——它监听页面上所有的锚点的单击事件。我们尽可能将单击事件转换为页面内的跳转。然而，对于不能在客户端渲染，或是用户单击鼠标中键或者按住CTRL键的情况下，将打开一个新的页面。

在这种情况下，浏览器中的地址可以代表当前页面的状态，所以我们可以复制/分享这个地址以分享当前页面。

4.刷新输出数据块

为了让数据下载完就立刻呈现出来，我们使用刷新输出数据块的技术(flushing chunks)，这样用户就不需要等待整个页面载入完成。

我们的实现方法是：
-最开始只载入最精简的数据，剩下的交由异步请求去获取。
-仅当需要的数据没有下载完全的时候才阻塞页面的渲染。

这个系统也可以让我们更快的加载CSS,JS,图像等等资源，并让这个网站显得更快且响应更加及时。

5.使用IFRAME

突破浏览器并行加载JS脚本的限制(参见 http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/)，[一般浏览器在一个页面中最多会并行加载3个JS脚本或是其他资源文件]——我们在页面的BODY的最前面加上一个IFRAME。其间的具体实现比较复杂，但是幸好我们还有Closure套件，实现此类功能非常方便。总而言之，相较网页速度的提升，这些努力都是值得的。

同时，你可能发现了我们通过XHR而非<style>标签来加载CSS样式表——这个设定并非为了优化，只是为了突破IE浏览器中一个样式表内选择器个数的限制。

最后的话

略。。。。

[译]关于Android图形系统的一些事实真相

亚楠兄 — Thu, 08 Dec 2011 21:06:52 +0800

原文地址：https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

(作者更新：后面的很多评论认为我写这个只是为Android不如IOS流畅乱找借口或是不体贴用户等等，我在这里需要澄清一下：之所以写这篇文章，仅仅是为了纠正网上传播的关于Android的各种错误认知。我并非是为了解释什么，只不过是想给那些关注Android却又被网上各种错误认知困扰的童鞋提供参考)

现在网上满天飞的各类关于Android图像渲染的水文实在让我不爽，下面给大家一些关于Android硬件渲染的事实真相：

1. Android 一直在使用硬件加速。实际上从1.0版本之后，所有的窗口元素的合成与显示都是通过硬件完成的。

2.这意味着许多你所看见的动画都是被加速过的：按钮的显示、通知栏下拉的阴影、不同Activity之间的切换动画、弹出窗口以及提示框的显示和隐藏等等等等。

3.Android以前使用软件方式(与硬件加速相对应)来控制各个窗口元素的渲染，例如下图的UI，其中包括四个窗口组件：状态条、壁纸、桌面上的的启动器、以及菜单。如果其中一个元素更改了自身的内容，例如一个菜单条目被高亮，那么在3.0之前的版本中，系统会使用软件方式来绘制新的内容。不过此时，并非所有的元素都需要被重新绘制，而各个窗口元素的拼接也是通过硬件方式完成的。类似的，任何窗口的移动：例如菜单的上下运动是完全通过硬件方式渲染的。

4. 现在我们来关注窗口元素的内部渲染过程：实际上为了达到每秒60帧的FPS,你并不一定非得要硬件加速。帧速取决于要显示的像素的数量和CPU的速度。比如说，二儿子(Nexus S)完全可以以60FPS的速度在它800*480分辨率的屏幕上完成任何普通的原生UI动画，类似列表的滚动等，完全没有问题。而最初的Droid系列却很难达到这样的速度。

5.在Android3.0中可以实现窗口元素”完全”的硬件加速绘制，而Android 4.0也基本上与3.0相同。从3.0开始，如果你在应用中设置了一个标志允许硬件加速，那么此时所有的窗口的绘制都会交给GPU来完成。而在Android 4.0中最主要的改变就是：在面向Android 4.0或更高版本的应用中，硬件加速是被默认开启的，因而再也不需要在配置文件中设置 android:handwareAccelerated=”true”. (注意，我们之所以不允许面向之前版本的应用默认打开硬件加速，是因为光靠硬件加速，无法很好的完成某些旧版本的绘制操作；同时在应用需要其中一部分UI更新的时候，会影响其的一些表现。对于目前现有的很多应用，强制开启硬件加速，会明显的感觉到卡顿)

6.硬件加速并不如大家所认为的那样完美。例如在基于PVR驱动的设备上(比如二儿子跟三儿子)，光是在进程中开启OpenGL就得占用8M的RAM——对比一般进程的2M的开销实在是巨大。大家都知道，RAM是有限的，如果一大部分被拿去绘制，那么其他正在运行的进程就会因为缺少内存而出问题，比如严重拖缓应用间切换的速度。

7.由于OpenGL的额外开销，一般情况下，我们最好不要过多的使用其进行绘制。我们现在就在做一些工作，让Android 4.0能在不开启硬件加速的情况下流畅的在二儿子上使用：这样我们就不需要在系统进程中浪费8MB的内存用，也不需要在手机进程中浪费额外的8M内存，或者是在系统UI进程中的8MB内存等等等等。相信我，你一般会忽略——用OpenGL来绘制一些类似状态栏的更新或是某些动画是完全没有好处的。

8.硬件加速并非流畅UI的“解药”。事实上，我们为了让UI更流畅，尝试了很多不同的方法，比如说：在1.6中引入了对前台/后台进程的调度策略，在2.3中对输入系统的重写，而后”严厉模式”的使用，并发的垃圾回收机制，载入器等等。如果你想达到60fps的帧速，你只有20毫秒的时间来处理每帧的内容。这时间实在太短，光是在UI进程中读取存储卡的操作产生的延时就会大于这个时限，尤其是在写操作的时候。

9.举些最近发现的影响UI流畅度的例子：我们注意到在二儿子上，使用4.0时列表的滚动就不如使用2.3时流畅。而导致这个现象的原因则是计时器的轻微漂移：有些时候应用正在接收触摸事件并在屏幕上绘制，而在上一个动作还没完成的的时候，就接受到下一个事件并开始绘制，导致它丢失了当前这帧。尽管发生这种现象的时候，帧速能达到稳定的60FPS.(当然，这个问题已经修正)

10.当人们比较Android跟IOS上浏览器的滚动流畅度的时候，他们所看见的差别实际上并不是开没开启硬件加速所致。最初的时候，Android使用了一种完全不同的渲染策略，并做了一些折中：网页被转换成一个”显示列表“，并持续的在屏幕上进行绘制——而非使用块(Tiles)的形式。它有一个优点：就是在滚动或是缩放的时候不会发生有的块还没被渲染出来的现象(译者注：早期的IOS上这种现象非常明显，快速滚动到底部时要等一会网页才会一块一块的绘制出来)。而这个方法的不给力之处就在于页面复杂的时候，帧速就明显低了。而在Android3.0中，浏览器开始使用块的方式进行渲染，于是它可以在滚动或是放大的时候保持一个稳定的帧速，自然也会出现新的块没有被立即渲染出来的情况。与此同时，每个块都是以软件方式绘制的，我相信在iOS中也是这样的。(在3.0之前的版本中，即便没有开启硬件加速，基于块的策略也可以使用。而且如我之前提到的，二儿子可以很容易的达到60FPS)

11.硬件加速并不能如大家所想奇迹般的让绘制的问题统统消失。GPU的性能就是一个很重要的限制。最近一个很有趣的例子：基于英伟达的Tegra2的平板可以很容易的以60FPS的速度访问2.5次1280*800分辨率的屏幕中的任何一个像素点。现在考虑到在Android 3.0中切换到所有应用列表的情形：你需要绘制背景(1x 所有的像素)、接着是启动器和桌面小工具(假设内容不多，花费0.5x)，接着是所有应用的黑色背景(1x)，再接着是所有应用的ICON(0.5x)。显然，到这一步我们就已经超过了原先的预算了，而此时我们还没完成各个独立窗口元素的拼接并做最后的显示。想要取得帧速60FPS的动画效果，Android 3.0以及后续版本使用了一系列的小技巧。其中主要的一个就是：它将所有的窗口元素平铺在一个层中，而不是挨个拷贝到GPU的缓存中。然而即便这样，我们已然超出预算，幸好我们还有另一个策略：因Android中的背景是一个独立的窗口元素，我们可以将它设置的比屏幕更大来放置整幅位图。假设用户开始滑动，背景会跟着运动，此时却并不需要任何特殊的绘制，仅仅是移动窗口即可，而由于这个窗口是在一个平铺层上，我们甚至不需要用GPU来将这个窗口元素组织到屏幕中输出。

12.随着屏幕分辨率的不断升高，能否达到60FPS跟GPU的速度尤其是内存总线带宽息息相关。事实上，如果你想要提升硬件的效力，特别注意得提升内存总线的带宽。很多时候CPU(特别是带有完美的NEON指令集的CPU)会比内存总线块的多。

作者更新：下面居然有这么多讨论，但是我木有能力解释清楚相关的所有问题了。不过我会尽力在这里提供一些我认为比较有趣的观点。

有些人认为盖世兔(Galaxy S2)已经有了一个非常流畅的UI，并指出他们已然超越三儿子(Galaxy Nexus)并做了相当多的提升。事实上，大家忽略了很多设备上的差异，比如盖世兔的屏幕是480*800而三儿子是720*1280，如果二儿子在它480*800的屏幕上都能达到60FPS，那么拥有更NB的CPU的盖世兔必须得同样流畅嘛。

而两者之间最大的差别就是三儿子需要同时绘制2.4倍于盖世兔的像素。这相当于在单核上提升到2.4倍的速度。(需要指出在UI渲染的时候，多核是没有意义的，因为最终的渲染必须要在一个主UI线程中完成，无法并行)

这就是为什么硬件加速非常重要：随着像素的提升，GPU通常能更好的处理图像相关的运算。事实上，这是我们在Android中引入硬件加速的最大动力。在720*1280的屏幕上，现有的ARM CPU达到60FPS很吃力，但是通过GPU渲染就不同了。同样，在与盖世兔的比较中，同时打开没有硬件加速的应用，在三儿子中无法达到盖世兔同样的60FPS，是因为它得渲染2.4倍于盖世兔的像素。

在最后，还得提及GPU的另外一个优势：GPU的引入让许多绘制效果变得更加容易。比如你要以软件形式绘制一个位图，你除了设置一个偏移量，不能做任何事。仅仅是放大/缩小这个位图就得花上相当多的时间进行渲染。而在GPU中，此类转换则相当容易。这就是为神马新的默认主题Holo使用硬件加速绘制背景。而在没有开启硬件加速的应用中，此类背景会自动去掉~

[摄影]单反、手机、与卡片机推荐

亚楠兄 — Sun, 04 Dec 2011 17:09:44 +0800

看到一份统计，图片EXIF设备参数排行，不禁感觉佳能真心霸气啊(至少在国内范围的)。而统计一下不同设备的使用率，也可以大概知道什么档次的摄影需求可以购入什么型号的机子了~

分析

1. 5D Mark II作为高端单反，真心是一代神机啊，大家的选择还是不错的~

2. 接下来是入门单反了，佳能的三位数大军很给力，600D,550D,500D,450D都有很多的使用者。作为入门单反，也是极具性价比的。在目前看来，600D跟550D都是很不错的选择。

3.尼康的D90和D80作为中端单反，使用者还是非常多的。而且两个型号其实拍照差不多，D90在D80的基础上只是进行了功能上的升级，唯一一点就是D80停产，基本买不到正品了把。

4.卡片机：进入排行榜的卡片机就佳能的IXUS系50，95 IS，200 IS 和 A1100 IS了，再加上 SONY家的DSC-W310，感觉这个跟市面上的推荐都差不多，都是千元及以下的口碑货~可惜都停产了啊

5.手机： iPhone 4 虽然很装B，但是拍照真心不错，而且最主要是方便，能够拍完就分享到各种SNS微博上，毕竟是街机嘛~ 而诺基亚的 5230与5233也证明了底端机市场诺记的强大~虽然大家都在唱衰塞班，但是至少在低端机器上的表现还是很不错的，各种应用也能轻松的分享身边精彩，而且诺基亚的镜头比同档次手机还是好很多的说~

基本上这就是通过统计数据得到的推荐了~大家可以作为参考~~

附排行如下：

Canon EOS 5D Mark II_Canon
Canon EOS 600D_Canon
Canon EOS 450D_Canon
iPhone 4_Apple
NIKON D90_NIKON CORPORATION
Canon EOS 500D_Canon
Canon EOS 550D_Canon
Canon EOS 50D_Canon
Canon EOS 5D_Canon
NIKON D80_NIKON CORPORATION
Canon DIGITAL IXUS 50_Canon
5230_Nokia
NIKON D700_NIKON CORPORATION
Canon DIGITAL IXUS 200 IS_Canon
Canon EOS 60D_Canon
5233_Nokia
NIKON D3000_NIKON CORPORATION
Canon DIGITAL IXUS 95 IS_Canon
DSC-W310_SONY
Canon PowerShot A1100 IS_Canon

Android拾遗

亚楠兄 — Wed, 30 Nov 2011 20:12:49 +0800

学习&实践Android开发之中，发现了好多恶心问题啊 Mark一下~

Tread 的 Run 与 Start
在写ListView的时候，想通过新建一个线程来更新Adapter的数据，让此线程sleep 3000ms，再通过Handler返回UI线程进行更新，结果发现主UI线程也被睡了。。。研究了一晚上，终于发现我建立线程的时候，调用的是 Thread.run(); 此时主线程会等到新的线程执行完才会继续执行，囧。
应该调用Thread.start() 才对，这样会新开一个线程。

透明颜色
类似 AARRGGBB 的写法，我一直使用的是

@color/transparent = #00ffffff

设置了一个背景图，然后在ListView之中设定其

Divider = @color/transparent, CacheHintColor = @color/transparent,

结果发现在拖动的时候还是会有黑影出现，于是把颜色改成

@color/transparent = #00000000

这时候，拖动的时候倒没阴影了，但是Divider显示却出问题了，变成了后面ImageView的内容，最后只好折中，设置

Divider = #00ffffff, CacheHintColor = #00000000,

结果。。。奇迹般的没有问题了。。。。真心诡异啊

LayoutAnimation
在第一次给ListView设置Adapter时，可以设定LayoutAnimation给每个View进入加入一个动画。但是在之后，增加列表数据，并调用notifyDatasetChanged更新显示的时候，新加入的条目是不会以动画的形式加入的，实在无奈，只能自己写一个动画管理器了。
实现的思路是：ListView作为ViewGroup，取得其中的每一个View，而后设定Animation…..当然，这样有一个好处，就是可以控制每一个动画播放的时差，可以让动画越来越快~~

ListView中条目动画形式飞出
在设置了Animation之后，每一个条目会依据动画飞出，但是在动画结束之后，会原样重现在原先的列表中，没有办法，只能对每一个动画加载一个监听器，动画结束之后，调用 setVisibility(View.INVISIBLE)，此时不能用View.GONE哦~GONE会释放这个列表所占用的位置，使得后面的列表项向前移一格

ListView的缓冲
Android默认的ListView居然没有缓动，也就是移到顶部或尾部的时候不会跟iOS一样象征性的继续滚动然后弹性恢复，而是直接就停住了。用户体验非常不爽，不过网上关于这个的教程也蛮多的~我就不啰嗦了~自行百度把

。。。。继续整理挖掘Android的恶心问题。。。。。

2011GDD(谷歌开发者日)大会

亚楠兄 — Thu, 27 Oct 2011 21:17:18 +0800

好久木有更新了果断写篇游记凑个数啊哈哈

拿到了邀请函，今天去鸟巢边上的国际会议中心参加谷歌开放者日技术大会，开始还以为跟百度世界大会一样是在郭嘉会议中心呢，百度大会没去实在是失策啊失策。

早早的就到了会场，然后吃吃零食看看合作公司的小展台，就等待入场了，不过时间太早，很多公司的展台都还没布置好的说~

进了主会场就开始了各种主题演讲~一开始的Chrome广告以及配合Chrome展示的舞蹈感觉超赞啊~动作跟视频还是蛮同步的！一阵中文寒暄讲解创新之后，各位谷歌的Boss就上场了，不过接下来的都是英文的 = = 还好说的蛮标准的表示经过HowIMetYourMother的磨练没有压力。

先是Google Map的创始人Michael Jones上台讲述GoogleMap给咱带来的改变以及新的技术~几个例子印象蛮深刻的：
　　一是利用Google Map API实现的GTA里的Liberty City的街景地图，这个以前就有了～看过
　　二是大家利用开放的地图编辑功能去完善自己身边的地图，并给出了一个中国周边的世界地图，展示用户创建地图的热点图，可惜　中国那就是一片空白，深意啊深意
　　三是使用MapsGL进行的加速非常流畅！
　　四是通过GoogleMap的接口确定海上每条船的位置和方向，在有人遇难的时候，寻找周围最近的船只及时去营救，这个还是非常赞的！以前也看过~
　　再就是介绍Google新出的基于Google Map的 Fusion Tables了~通过用户输入数据，快速在地图上呈现出来，并能进行类似SQL的筛选等等，反正功能貌似蛮多，但总觉得没啥用。专门用中国的网络覆盖率来作演示(其中提到了internet penetration我一直在想是网络入侵到后来才想起来是网络覆盖率。。。)后来专门去听了Mano Marks的专题演讲，还是觉得Fusion Table跟我们没啥关系。。。只适合做统计报表的把。。。。
　　期间还展示了google地图中的鸟巢从2002-2008 每一年的变化，后来又讲了世界上只有22%的人能够接入网络，而科技就是为了让更多的人去接触网络神马的~而且科技就是要将人的IQ提高20，这个要赞啊哈哈

　　之后是大家都很关注的Galaxy Nexus和ICS的展示了~展示的功能跟在香港的发布会差不多~亲眼看到Beam的功能还是蛮好玩的~这次的Face Unlock奇迹般的成功了哈哈。之后介绍的就是Android的相关信息了，以及Android的核心价值了：Opportunity Distribution and Innovation
　　再后来带来的就是Chrome Innovation Platform的主题演讲了~其实Chrome蛮好的嘛~虽然我也很喜欢Opera 哈哈

　　之后主题演讲结束~大家各自去分会场听讲座了~我果断直奔New&Important in Android ICS，讲师的穿着很给力啊~一副乡村打扮哇哈哈。接着是期待的午饭时间了！居然是盒饭！！！！太伤心了！我明明记得说是有自助餐的！不过还是蛮好吃的啦。
　　吃完去了各个展台看看~收货小礼物若干~这次360特别出风头啊~可惜对360没好感就不多说了 = =
　　下午听了Android 用户体验、HTML5打造现代化的网络应用、Managing Spatial data with fusion tables 和 Android Market Features。最后一个太蛋疼了 = = 明明是黄皮肤黑眼睛的国人还得操着一口不标准的英语来演讲，内容也木有啥特点，唉
　　不过晚宴很给力啊！居然是自助！边吃台上还有表演～各种讲话表演之后就是自由发言阶段了～大家使用到google的技术都能上去随便扯扯~2分钟内结束即可，讲完之后就可以抽奖赢礼品，我总感觉要送出Galaxy Nexus啊！结果第一个哥么上台了。。。。我擦不就是刚刚吃饭坐我旁边的那个360工程师嘛~隐约想起他吃饭的时候说是待会要上台之类，果然是有阴谋啊！
　　不过人家还是很牛的～在google米国待了３年，回来到数字公司开发急速浏览器了，唉。不过抽奖抽到了咖啡杯~
　　后来才发现根本木有Galaxy Nexus嘛，只有两种礼品：咖啡杯和 U盘。。。到后来都是不用抽奖直接问你要哪个了。。。唉看来还是不给力嘛
　　最后一个上台的哥么，不要咖啡杯跟U盘，主持人说你台上能抱走的就当作你的奖品～～～大家一致在下面起哄要把旁边的MM抱走，可惜人家一摇一摆终于把旁边的一米多高的Android机器人的模型给抱走了实在是太囧了啊
　　
　　不过最激动的还是我发现之前有演讲的两个Google总部的大佬就一直站在我身后！！！可惜木有勇气搭讪啊！应该果断搭讪求工作的！
　　
　　其他的都没啥啦～终于回来了　带了一大包东西= = 一个Android的娃娃还有一个之前自己定制的Android肖像的长袖衫~哈哈所有出来的人都是提着一个大包好囧的说

　　最后还得感慨一下　百度就是不如谷歌嘛～看人家的礼品多给力！

您可能也喜欢：
[一起看电影] 之长发公主	更新一下	所谓的喜剧演员	一梦三四年
无觅

您可能也喜欢：
[译]Google+提升网页性能的5个小秘密	基于AJAX：WebIM的简单实现	再发张涂鸦～～～	[译]关于Android图形系统的一些事实真相
无觅

您可能也喜欢：
遗传算法与寒武纪生命大爆发	无聊北上	HTTP请求过程与在线代理流程	基于AJAX：WebIM的简单实现
无觅

您可能也喜欢：
int还是unsigned int	菊花体生成器	所谓的喜剧演员	基于AJAX：WebIM的简单实现
无觅

您可能也喜欢：
狄拉克海上的涟漪	菊花体生成器	基于AJAX：WebIM的简单实现	北京欢乐谷 2010
无觅