因为项目的关系，需要在 Android 上实现一个支持 HTTP 代理的 Webview。一个较早的方案 可以很好的工作在 Android 2.3 及以下版本。而 3.0 之后，Android 在系统代理这一块做了较大的改动，前面所提到的方案已难以适用。
通过分析最新的 AOSP 源代码，这儿提供一个改进后的方案供各位参考。经测试可以正常兼容 ICS。
以下代码涉及到 Private API，请谨慎使用
你所知道的一切都是错误的！
这是一篇译作，原文发表于 The memories of a Product Manager，记录的是 SPLASH’2011 上由 David Ungar 做得一段结语。这是一番非常具有前瞻性的言论，至于究竟未来路在何方，请各位稍安勿躁，静观其变。
在这新世纪第一个十年的末尾，芯片制造商们正向我们展示着以众核（Many Core）为基础的未来：台式计算机的 CPU 将拥有成千的同构核心。
不同于云计算或者一般的分布式系统，新系统中核心之间通信的开销将会很小；同时与当下常见的多核系统不同，多达上千路的内存系统，更长的核内与核间连线，意味着核间同步（coherency）的开销将不再小到足以忽略。而如此这般的新架构意味着全新的编程方式。上个世纪80年代，编程模型开始由静态发展为动态，而今天我们也面临着类似的变革。
假如无法打破 Amdahl 定律 的限制，增加的那几百颗核心依然无法带来任何好处。因为哪怕程序中出现一小段的串行部分，都将意味着性能的极大损失。同样的，锁的机制（甚至包括一些 lock-free 的算法）也无法提供足够大的并行度。与之前由静态向动态的转变相似，我们现在需要的是一种全新的完全不存在同步机制的编程方式。
IBM 的 Renaissance 项目正在研究一种反同步锁的（anti-lock），数据竞争并修复的（race-and-repair），端到端不确定的（end-to-end nondeterministic）编程方式。作为种种努力中一部分，他们在一台配备了 64 核心 Tilera 芯片的 Smalltalk 系统上，基于动态语言做了一些有趣的实验。当我们决定放弃同步机制，同时我们也放弃了编程中的确定性。这可以看做是一种妥协，是性能与确定性之间的妥协，犹如静态类型检查与性能之间的妥协。
一个需要首先克服的障碍是：适用于众核系统的编程方式意味着，我们惯常认为的程序执行总能得到确定结果的假设将被破坏。实际上这种假设正强烈的影响着我们的编程方式与思维。可能一些搜索引擎的工程师们已经体会到了这一点，但对于其他绝大多数程序员来说，你所知道的一切都是错误的（Everything You Know Is Wrong）！
编译 Android 源代码的种种
在编译 Android 的最新源码时遇到了些小问题，在这里记录下来，供各位参考。
由 4.0.1 更新到 4.0.3
按照 Android Developer 官方文档上的步骤，同步下来的源代码还是 4.0.1 的。而如果要同步最新的代码，则需要进入 master 分支。
1 2 | |
如果已经同步到 4.0.1 了，直接 check out 出 master 分支即可。
1 2 | |
切换目标体系结构为 ARMv5TE
Android 4.0 之后的默认 target 都是 ARMv7-a，如果你恰巧在做一些依赖于 Source Tree 的工作，记住一定要把 target 切换到 ARMv5TE，否则在某些情况下（国内众多的 ARM 11 手机和平板）会遇到 illegal instruction 的问题。
1
| |
在 Fedora 15 及以上编译
Android 团队建议使用 Ubuntu 环境来编译整个项目，而如果你执意或者不得不在 Fedora 中工作，则会遇到各种奇怪的问题。由于 Android 的源码一直处于变动中，很难给出一个完整的解决方案，但一般来说都是与依赖相关的毛病，遇到新问题时人肉 Patch 一番即可。需要注意的几点有：
请将你的 make 降级到 3.8.1，否则编译时会告诉你不兼容。另外不建议用
yum downgrade命令降级，直接从 gnu 的网站上下载相应版本再自行编译即可。在 Fedora 上无法像 Ubuntu 那样直接安装
sun-java6-jdk（只用官方源的情况下），所以需要去 Oracle 下载相应的 rpm 文件，然后手动设置环境变量什么的。记住一定要把原来装的 openjdk 什么的给卸载掉。
吐槽篇
最近 Android 的代码库里出现了各种奇怪的东西，特别是 external 目录下，甚至 LLVM 和 clang 都加进来了 （与 RenderScript 有关）。于是当你编译 Android 整个代码库时，也需要把这些杂七杂八的东西都编译一遍，这也是为什么源码库现在有 10 GB 之巨的原因。
编译 Android 是一个漫长且痛苦的过程，如果你恰巧有足够 NB 的机器，请一定要用 make -jN（N 为你愿意用来跑编译任务的 CPU 核心数）。另外还请做好散热工作，以免你的电脑惨遭不幸。也请不要用你那可怜的笔记本电脑编译，除非你打算找个玩意暖暖手。