一位抄人的告白？

@westlinkin 可以。

同一时刻android只能有一个view能接受输入，但你要的是将输入「同时」分发到两个view：一个GestureOverlayView，另一个ListView。换一种理解是GestureOverlayView收到输入事件处理完后不丢弃，继续将事件传递给Listview。按照这个思路，设置GestureOverlayView的OnTouchListener, 让它再调用Listview的onTouch方法并返回false就行了。

Layout大概是:

<FrameLayout xmlns:android=... layout_w="fill_p" layout_h="fill_p">
<ListView layout_w="fill_p" layout_h="fill_p"/>
<android.gesture.GestureOverlayView layout_w="f_p" layout_h="f_p"/>
</FrameLayout>

Activity.onCreate代码大概是:

GestureOverlayView gov;
gov.setOnTouchListener(new OnTouchListener() {
onTouch(MotionEvent me) {
list.onTouchEvent(me);
return false;
}}

还得root

"Android2.3.3以上不Root就可以通过SurfaceFlinger API截图" 这条消息不太正确。SurfaceFlinger服务的确是提供了api captureScreen, 但它是给系统本身用的，对第三方应用不可见。另外，SurfaceFlinger服务没有暴露给应用层。

@meecle 相对于换编译器，升级硬件是相当安全的方法了。我有一朋友曾经遇到让他愁掉无数头发的因编译器升级一个小版本而导致编出来的程序运行不正常的问题。换编译器是要冒很大风险的。
ps 我想起了一个和优化有关的漫画: http://blog.xiqiao.info/2010/10/20/829

@Jet malloc和编译器没什么关系，这部分管理是由操作系统和库来完成的。函数写得短小是为了获取在运行时更高的命中率吧，而不是提高编译速度。

gcc用gch来优化预编译速度。

@seerhut 目前打算ramdisk。cpu/core的数量可以通过distcc解决吧，但这样瓶颈又到net io上去了。

@Jet what堆栈?

@meecle 我对llvm和gcc的优化仅仅停留在一个是面向语义另一个是面向机器（汇编）这个层面上。这两种优化是不冲突且可以叠加的，因此仅从优化方式来看我看不出llmv较gcc有什么速度上的优势。若有错误请指正。

@meecle 编译器没法换，只能用gcc，llvm不支持。
可以这样理解：编译器干的是把磁盘上一种形式的数据转换成另一种形式的工作，不仅运算量大，io吞吐量也大。这里就分别涉及到cpu的频率，cpu缓存，内存频率，内存大小，硬盘转速，硬盘缓存等等因素。我现在想要弄清楚的是哪一个环节是编译速度的瓶颈。

我记得12年前电脑爱好者有一篇关于金钻硬盘的评测，其中有一项是用vc5测试7200转较5400转对编译性能的影响，得到的结论是能明显提高编译速度。但类似的评测我现在没找着。

@Sparanoid emm……我指的是整个TextEdit(比如菜单)及整个系统偏好设置

@vivian 有可能是套钱？
就算龋齿很严重，医生也应该告诉你病情，由你来选择治疗方案。
牙髓的作用是供给营养，牙髓杀死以后牙质会由于没有营养逐渐坏死，所以杀神经后一般还要装个牙冠。一个牙冠最贵是1000+，另外根管治疗+打桩的价格也不便宜。

@Livid 10分钟增加的功能，我估计得花100分钟才能加到AndroidV2EX上去 :D
今晚开工

http://www.aqee.net/2011/04/26/first-six-months/
希望能给你启发

编程，写文档，处理文本，写日记，做笔记，记录日程，运行脚本，浏览info等。

@Anonymous 目前pop3和imap还能正常访问，用客户端吧。

去大医院吧。私人医院水平良莠不齐。
排队是免不了的，提前预约能节约些时间。

@chenshaoju 很详细，谢谢。

@chenshaoju http://twitpic.com/45ukit 是gmail吗？我在40-50这个时间段还是无法访问,

mbp+外接大显 的性价比更高些

@9hills thanks, 学习了