chromium开发设置代理

在中国,由于某些客观原因,经常无法访问google服务。在做chromium开发的时候,depot_tools工具经常无法正常运行,用git或者svn也不能从服务器获取到代码。 如果有vpn,开启vpn就好了。但是公司内部偏偏又不能使用vpn。不过路并未堵死,我们可以使用http代理来访问google服务。 depot_tools代理 运行gclient... Read More | Share it now!

在chromium中使用智能指针

在chromium这种多进程,多线程,代码量巨大的工程里,很多对象的创建、使用和销毁往往不在一个地方,对象的生命周期管理起来非常困难。这种情况下智能指针就能派上用场了。智能指针本身是一个局部的对象,它管理着堆上分配的对象的指针,当智能指针超出作用域是,要么销毁管理的对象,要么交出对象的管理权,让其他智能指针接管对象。 使用的最多的是scoped_ptr,而ScopedVector是类似std::vector来包含指针的容器,在他内部就是一个std::vector<T*>... Read More | Share it now!

chromium中的智能指针scoped_ptr

scoped_ptr会管理指针,它在超出自己作用域的时候自动调用自己的析构函数去销毁指针。 scoped_ptr也可以管理数组。 把scoped_ptr当作参数或者返回值,也可以在函数中使用它。 Pass()可以正确的处理向上的类型转换,比如: 也可以使用PassAs()明确向上转换 注意,PassAs只对scoped_ptr<T>有效,不能用于scoped_ptr<T[]>。 ... Read More | Share it now!

chromium中的LinkedList

为什么使用LinkedList而不是std::list? 使用LinkedList最大的理由是性能。一般来说std:list的erase操作的时间复杂度是O(n),因为std:list要遍历容器获得删除元素的迭代器。 而LinkedList的erase操作的时间复杂度是O(1),因为它直接用LinkNode的RemoveFromList方法去删除。 为什么LinkedList不跟std::list一样需要遍历迭代器呢?这是因为LinkedList中的元素不是复制到到容器中的,LinkedList中存放的是元素的指针,所以元素本身就可以调用RemoveFromList把自己从容器中删除。这个特性带来的另外一个好处:插入新元素的时候,LinkedList不需要从heap中分配内存。 LinkedList就是对元素指针进行简单的封装管理,优点是没有对管理的元素有复制操作,元素加入到容器,元素本身跟放入容器中的元素是一样的。 使用LinkedList 使用LinkedList前,需要用LinkNode把栈中的元素封装起来。如下: MyStruct就是我们要放入LinkedList中管理的真正数据类型。 LinkedList可以管理栈中的元素,也可以管理堆中的元素。  注意 不能从一个函数中返回LinkedList<MyNodeType>,因为LinkedList.root_已经失效。 总结 总体来说使用LinkedList还是挺繁琐的,应用场景也比较特殊,而且不能使用stl中那些标准的算法。所以除非为了追求极致的性能,还是推荐使用std::list。 LinkedList代码: ... Read More | Share it now!

深入chromium中的多线程

  Callback 绑定到一个函数上。 绑定到一个类成员函数上。 Bind 动态绑定参数。 这个局部绑定函数内部是根据重载函数实现的,所以参数的顺序是绑定的放在前面,定义MyFunc时,未绑定的参数放在后面。 WeakPtr可取消task。 参数包装函数 base::Unretained()。解除传递给base::Bind()的第一个参数类成员函数的类必须是引用计数类型的限制。但是你需要确保参数的生命周期必须持续到callback执行完成。 base::Owned()。把一个原始指针的管理器转移给base::Callback。TaskRunners关闭的时候不能保证callbacks会被执行,所以把管理器转移给Callback,可以防资源泄漏。 base::Passed()。传递scoped对象的给callback。base::Passed()需要scoped的参数类型,这样意味着callback只能执行一次。 base::ConstRef()。把参数当作const... Read More | Share it now!

chromium中的多线程概述

刚开始接触chromium代码的时候,觉得它的多线程非常别扭,有些事情只能在某些线程上才能做,还得bind函数PostTask来PostTask去的。有时候在不同地方获取几个不同的参数,写出的代码支离破碎,PostTask导致逻辑不连贯,非常不习惯这样的。 即使非常讨厌也不得不接受,只有掌握了chromium的多线程,才能随心所欲的写出正确的代码。以前走过很多弯路,再把chromium的多线程文档翻译一遍,写篇博客总结一下。 一般来说我们不必在chromium中创建新的线程,chromium一开始就为我们创建好了几个线程。大多数线程都是属于BrowserProcess对象管理的。 ui_thread:程序起来的主线程。 io_thread:处理browser进程跟其他子进程通信的线程,网络资源的请求也在通过这个线程调度。 file_thread:文件操作线程。 db_thread:数据库操作线程,比如cookie数据库的读取。 safe_browsing_thread:不知道干嘛的。 History:历史记录数据库读取线程。 Proxy... Read More | Share it now!

chromium进程间通信

因为chromium是多进程的架构,因此需要一种可靠的进程间通信机制。chromium在Windows上的进程间通信是基于命名管道实现的。异步的命名管道通信模式确保不会阻塞通信的双方。 browser中的IPC 在browser进程中,与renderers进程通信是在独立的I/O线程里。跟views的来往消息会通过主线程的ChannelProxy。这种架构的优势是资源请求等性能要求较高的消息会直接在I/O线程里处理了,不会导致UI的阻塞。 renderer中的IPC 每个renderer进程的主线程管理消息通信,大多数消息会调度到renderer线程去处理。 消息的类型 Chromium处理进程间通信类似于MFC/WTL的那套消息映射机制。一个进程创建一个IPC消息,然后打包上参数,发送到接收的进程。这里有两种类型的IPC消息,routed消息和control消息。两者的差别是发送routed的消息的时候需要一个routing_id参数,通过这个routing_id才能发送到正确的接收方。一般跟view或者frame概念相关的类才有routing_id。 举个例子,我要从主进程发送一个ViewMsg_ClosePage消息到渲染进程,通知它关闭某个网页。往往一个渲染进程里面存在多个RenderView对象,到底该哪个对象来处理ViewMsg_ClosePage消息呢。这种情况下需要用routed消息的routing_id参数来控制将消息传递到正确的RenderView里面。 control消息不带有routing_id参数,并不意味着RenderView、RenderFrame这样的类不能处理control消息。消息都可以自定义参数,你完全可以把routing_id加到control消息里面。但是通常的做法是routed消息是跟网页有关的,其他的情况则用control消息。 从另一个角度来看,IPC消息又可以分为同步消息跟异步消息。使用同步消息的时候应当特别注意,这可能会导致浏览器阻塞。应当尽量避免使用同步消息,事实上Chromium里面使用到同步消息的场景也很少。 声明消息 我们可以在各种*_messages.h的头文件看到IPC消息的定义。通过IPC_MESSAGE_ROUTED*、IPC_MESSAGE_CONTROL*这类的宏来定义异步消息。比如处理0个参数的消息,定义成IPC_MESSAGE_*0,处理2个参数的消息定义成IPC_MESSAGE_*2。 一些简单的参数类型,可以直接的打包到消息里面,比如: Chromium内部已经可以支持直接序列化GURL、base::FilePath、base::Time等类型了。更多支持直接序列化的类型,可以从ipc_message_utils.h文件中看到。只要某个类型T有sruct... Read More | Share it now!