DirectFB运行机制分析和总结.docx

事实上我对DirectFB 的理解是比较肤浅的，几年前的确花了一些时间研究去DirectFB 的实现，但只是集中在一部分功能的代码上。后来 GUI(DirectFB/GTK)由一位同事接手了，我就没有花太多时间在上面了。可能是因为前面写过几篇关于DirectFB 的文章，结果还真有不少网友把我当专家了。答应过一位网友写篇介绍DirectFB 运行机制的文章，这个周末花了点时间写了这篇短文，放在这里供有需要的朋友参考。文中若有不当之处，望大家不吝指正。 DirectFBInit 这个函数其实并没有做什么特殊的初始化工作，只是加载了配置文件而已。加载的顺序如下，重复的配置内容以后加载的为优先： 系统全局配置文件，老版本文件为/etc/directfbrc，新版本文件为 SYSCONFDIR"/directfbrc" 用户全局配置文件，文件为~/.directfbrc (系统)应用程序特定的配置文件 SYSCONFDIR"/directfbrc.应用程序名" (用户)应用程序特定的配置文件 ~/.directfbrc.应用程序名 命令行参数 DirectFBCreate 真正的初始化是在这里面进行的，严格的说这也不叫初始化了，因为这是创建DirectFB 对象，对象当然是可以创建/销毁多次，而初始化通常只能做一次了。考虑到在一个进程中DirectFBCreate 通常只会调一次，进程退出时才销毁，所以我们还是把它看作初始化。现在我们来看看DirectFBCreate 做了什么: direct_initialize direct 是一个基础库，这个函数主要做了两件事情： 初始化 log。 direct 实现了三种LOG 方法，第一种是输出到 stderr 上，第二种是输出到指定的文件里，第三种是通过 UDP 输出到网络上。这种方法对嵌入式环境是特别有用的， 因为很多时候没有机会看终端上的信息。 安装信号处理函数。主要是针对像SIGTERM 这类会导致程序退出的SIGNAL， DirectFB 希望在程序退出之前做些善后处理。值得学习的是direct 是一个基础库，它不能直接调用上层组件的函数，所以提供了direct_signal_handler_add 之类的函数让上层组件注册/注销回调函数，避免了下层函数与上层函数的耦合。 dfb_core_create 核心组件初始化。核心组件都是以共享库形式存在的，这里主要是加载这些共享库，并调用相应的初始化函数。为了避免框架与组件之间的耦合，DirectFB 是通过遍历目录去加载的，删除不必要插件可以提高加载速度。 dfb_system_lookup 其实system 在这里并没有表示出它真正的意义，这里的 system 实际上是指显示方式，比如基于framebuffer 的fbdev 和基于 XWindow 的x11等等。它先调用 direct_modules_explore_directory 在找出目录中所有的system 实现，然后与配置中指定的名称匹配，找到指定的system 后调用GetSystemInfo 得到一些system 信息。 direct_find_best_memcpy 因为GUI 里面memcpy 的效率对系统整体的效率影响很大，所以DirectFB 针对不同的系统实现了一些优化过的memcpy 函数。 fusion_enter 初始化fusion，fusion 是用于进程间通信的机制，/dev/fusion/n 是用于进程间消息传递的文件,每个进程都有这样一个文件。在本函数中会打开这个文件，并用ioctrl 发送FUSION_ENTER 命令。随后映射/初始共享内存。最后创建消息分发线程，其线程入口函数为fusion_dispatch_loop。 fusion_arena_enter 我没有直接用过arena，它的主要功能似乎只是对共享数据的管理，通过一个名称与一块数据关联起来，放到hash 表中，每个进程都可以通过名字取相应的数据。 IDirectFB_Construct 构造一个IDirectFB 对象。通过 dfb_layer_at_translated 获取primary layer. 通过 dfb_layer_get_primary_context 获取primary layer, CoreLayerContext里面最 重要的东西可能就是CoreWindowStack，CoreWindowStack 管理着所有窗口，对应用程序产生直接的影响。 通过 dfb_layer_context_windowstack 获取窗口栈。 初始化 IDirectFB 接口的虚函数，让函数指针指到具体的函数上。随便说一句，最 近还有一些冒充专家的外行说C 语