新的代码已经上传，请在 https://x-framework.googlecode.com/svn/trunk 更新
这一次的更新有些仓促，主要是有一些网友希望能早些看到chrome的tab页效果的具体实现，目前来讲还有一些没实现的地方，会导致一些bug，下载代码调试的时候，请忽视异常，勇敢的按下f5，不能正常退出请终止调试或者杀掉进程，任何崩溃不能退出的地方都有可能，仅故学习参考。
一些截图：
我认为chrome的架构在三个方面做的非常好：通知系统（线程模型/观察者模式）、preference系统和extension扩展系统，非常具有互联网客户端特征，大部分功能都可以重用。适合搭建互联网客户端平台，然而在中国能驾驭如此全面架构的互联网企业应该也不多，小步跑多迭代需要依赖可靠的平台。其多进程的架构模型，好处自然不用多说，然而需要的架构水平之高恐怕很难在实际开发中真正全部跑起来。
下面是所在团队使用chrome遇到问题时候，我做的一些研究分析，在分析前我对chrome内部的线程对象关系也很模糊，希望对他人有用。
chrome在线程和对象之间运作的一些基础技巧，总体来讲使用了三种设施，而不是一刀切，一个不规范的报告如下：
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
同一线程同一对象的方法异步调用 ScopedRunnableMethodFactory能保证对象自身异步方法调用的安全性
同一线程不同对象之间的通知 调用者派生NotificationObserver，通过NotificationRegistrar把自己注册到通知系统，通知源触发NotificationService 订阅模式，线程内同步调用，不存在对象生命周期的问题
MessageLoopProxy是线程安全的引用计数对象，内部封装了线程消息循环，MessageLoop销毁的时候会置空其MessageLoopProxy中的消息循环，支持线程安全的异步调用，适合在不同线程之间回调，回调过程是异步的，所以牵扯到的参数必须考虑对象生命周期以及对象方法调用的线程问题。我的想法就是回调的对象最好是生命周期跟application的一致的大对象，充当manager（这也正是一个管理者该做的事情），这样就能维持回调对象的合法性。
chrome推荐多使用非线程安全对象，也就是对象方法的执行都在对象创建的线程
Application<----------------------------------------------------------
|--------|... |
V V |
UI线程 文件读写线程 数据库读写线程 网络线程 ... |
UIMgr FileIOMgr DatabaseIOMgr NetIOMgr |
Obj... Obj... ... ... |
Obj... Obj... ... ... ---
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
在chrome中运用最多的是第二种技法，因为本身就没有那么多对象需要跨线程；其次是第三种，因为互联网客户端确实存在不少的多线程数据管理；最后是第一种技法，这种情况较为少见。
至于全面详尽的剖析，我没有精力或者暂时没有勇气去整理。后面代码的更新可能也会减缓，自己会考虑在如何使用这套框架做一些东西。
