基于Linux的开源智能终端软件栈研究
2010-06-11林玮平陈宇华潘军彪
罗 喧,林玮平,陈宇华,潘军彪
(中国电信股份有限公司广东研究院 广州 510630)
1 前言
随着 3G、WAPI(wireless LAN authentication and privacy infrastructure,无线局域网鉴别和保密基础结构)/Wi-Fi等相关网络的逐渐成熟,移动互联网上新的业务模式、新的应用、新的服务体系逐步建立,基于移动互联网的新变革正在改变人们的生活,这其中孕育着庞大的市场,是通信、IT、内容和媒体、电子设备制造业等传统产业未来的方向。
在移动互联网的业务提供中,最大的瓶颈不是网络侧的各种服务,而是用户手中的终端。此处的终端除了包括传统的移动手机、掌上电脑之外,还包括新型的移动互联网设备(MID)、上网本、多媒体终端,例如游戏机、阅读器等,本文统称为智能终端。用户使用什么终端,终端上能支持什么服务,决定了移动互联网能提供什么服务。终端是移动互联网业务的短板环节,主要的限制体现在硬件以及软件两个方面。在芯片硬件层面,尚需要技术上进一步的突破,以形成大屏幕、小尺寸、计算能力强、待电时间长、使用简单的设备。在软件层面,操作系统及软件平台是另一个主要的限制。首先,终端操作系统及软件平台不统一。目前的终端上多种嵌入式操作系统和软件平台并存,应用开发在终端兼容性上消耗了巨大的时间和人力成本,由于不够开放,开发门槛高,应用缺乏。其次,3G及WAPI/Wi-Fi等网络技术推进宽带移动互联网的发展,业务从原有的以简单文字为主的WAP网页应用拓宽到面向多媒体的娱乐生活和商务应用。智能终端随之从以前的小屏幕、架构简单的硬件计算平台向大屏幕、强计算能力方向发展。原有功能简单的智能终端操作系统渐渐不适合越发复杂的业务需求。
在上述的背景下,新兴的移动互联网龙头厂商纷纷和开源社区合作,面向大屏幕高性能的移动智能终端推出基于Linux开源操作系统的软件栈,此处的智能终端软件栈是指包括操作系统、系统服务以及关键的上层应用在内的完整的智能终端软件组合。
这类基于Linux的终端软件栈应用在特定规格的硬件设备上,形成独立的软件开发平台,并以软件平台为核心,聚集了产业链上的设备制造、应用软件开发、服务和内容提供等方面的厂商,组成产业联盟,利用Linux开源社区的技术实力和开源社区对全球开发人员的号召能力,打破原来传统封闭手机操作系统的格局,逐步在移动互联网业务开发领域占据举足轻重的地位。
下面为几个主要的基于Linux的开源智能终端软件栈以及其背后的产业联盟。
(1)Maemo(http://maemo.org/)
Maemo是诺基亚支持的一个基于开源软件的移动设备软件平台,应用在诺基亚N770、N800、N810和N900系列高端设备上。
(2)Android(http://www.openhandsetalliance.com/)
Android是Google于2007年11月5日公布的基于Linux内核的软件平台,目前由开放手机联盟(Open Handset Alliance)维护,开放手机联盟为Google主导的手机产业联盟,其加盟者囊括了世界上主要的运营商以及手机厂商,例如:Sprint Nextel、T-Mobile、Vodafone、华为技术、中国移动等。
(3)LiMo(http://www.limofoundation.org/)
LiMo是由LiMo基金会开发维护的Linux操作系统的软件平台,其加盟者主要有 Samsung、Vodafone、LG、Orange、DoCoMo等。
(4)Moblin(http://moblin.org/)
Moblin是一个开源的、基于Linux的软件平台,主要应用于英特尔的移动互联网设备和其他手持设备。英特尔在2007年7月推出了Moblin.org的网站,2009年4月,英特尔将Moblin移交给Linux基金会,旨在加强开源社区对Moblin的支持。
(5)OpenMoko(http://wiki.openmoko.org/wiki/Main_Page)
OpenMoko不仅定位为移动手机的开源Linux软件栈,同时提供OpenMoko的硬件,第一款OpenMoko硬件是Neo1973,第二款OpenMoko硬件是Neo FreeRunner。
(6)GPEPhone(http://gpe.linuxtogo.org/)
GPEPhone为 LiPS(Linux phone standard)Forum 制定的手机Linux标准的开源实现。2008年6月,LiPS宣布加入LiMo基金会,在合并过程中,原有的GPEPhone网站的技术资料发生了变化,文中研究的GPEPhone源码及文档资料均来自旧版的网站。
开源Linux智能终端软件栈从结构上看可以分成以下几层:第一层为Linux操作系统内核及硬件驱动,第二层为中间服务层,第三层为应用开发框架,第四层为具体的应用。上述的开源Linux智能终端的软件栈都包含了一个经过梳理和优化的Linux内核,在架构的第二层与第三层,包含了终端关键服务子系统:2D/3D的图形子系统、窗口子系统、窗口应用开发框架、多媒体子系统、窗口程序的进程间通信服务、电话通信服务模块等。下面将重点研究软件栈中间层中重要的子系统,对各种开源Linux智能终端软件栈使用的典型技术进行分析和总结。
2 2D/3D图形子系统与窗口子系统
2.1 智能终端对图形子系统的新需求
目前移动终端设备的图形显示能力得到了长足的发展,色彩绚丽的大显示屏幕在高端的移动终端设备上得到了广泛的应用,图形处理器(graphic processing unit,GPU)作为独立的运算芯片集成在高端移动设备上,使移动设备能够在不占用CPU资源的情况下实现高质量的2D和3D图形效果。
从业务需求上看,一方面,游戏、GPS地图导航、视频共享等要求高质量图形显示的业务成为高端智能终端上的主要应用;另一方面,3D用户操作界面在高端智能终端上逐步开始广泛使用,相比PC上的3D桌面,智能终端上的物理屏幕小,单个屏幕上所容纳的内容少,由多个虚拟屏幕组成的3D的操作界面符合用户的3D空间逻辑想象,不仅具有时尚的操作风格,更具有实用的操作意义。例如:目前新上市的高端智能手机中有一种时尚的立方体桌面,立方体的每一个面都是一个虚拟屏幕,存放一类的应用快捷入口。
目前的智能终端上比较新颖的屏幕效果主要有:
·透明窗口和透明图像;
·3D桌面;
·高清晰的2D矢量图形;
·2D图形在3D空间的运动,即某种动画效果。
上文提及的部分Linux开源智能终端软件栈能够支持上述的图形效果,在具体实现时软硬件平台使用了不同程度的硬件图形加速。
2.2 智能终端上的窗口子系统
智能终端的窗口子系统是智能终端操作系统上的最核心模块,窗口子系统决定了智能终端用户的整个操作界面——“用户桌面”的实现方式。
智能终端的窗口子系统分成两类:第一类是整个窗口子系统在同一个进程实现,应用窗口通常采用线程结构,共享同一个内存地址空间。此类用户图形操作界面响应速度快,资源消耗相对小,但是当某个线程出现错误时容易造成整个进程的瘫痪,因此通常应用在某些实时响应要求高,终端界面交互简单的终端上。第二类窗口子系统是多进程的客户端/服务器结构,能够实现复杂的用户界面,具有更佳的稳定性。Linux的X Window是其中最普遍应用的代表,应用场合包括:Linux PC、移动互联网设备、上网本、高端智能手机等。上文提及的大多数的开源Linux智能终端软件栈都沿用了X Window,只有一个引人注目的例外:Android,Android的窗口系统不能和X Window兼容。可以说,在未来的很长一段时间内,X Window都将是大多数Linux终端最重要的图形窗口系统。
X Window(常称为X11或X)是一种以位图方式显示的软件窗口系统,1984年在麻省理工学院研究成功,之后发展成UNIX、类UNIX等操作系统所一致适用的标准化软件工具包及显示架构的运作协议。X Window有2个具体的实现:X.Org和XFree86。
X Window系统是一种同时支持多任务进程的客户端/服务器结构。惟一的服务器X Server控制了用户交互的主要输入输出的设备,例如,显示屏幕、触摸屏、键盘、鼠标。其他的应用作为客户端X Client以独立进程的方式存在,通过X Server与输入输出设备以及其他的客户端X Client通信,其通信协议称为X。其基本架构如图1所示。
图1中有两种特别客户端X Client,第一种是运行在其他远程机器上的客户端应用,X Window支持远程的客户端X Client;第二种是本机上运行的特殊的客户端窗口管理器Window Manager,窗口管理器Window Manager负责每个窗口的外观装饰、位置以及窗口的打开、关闭、最小化、最大化、重置大小等通用管理功能。
2.3 X Window与OpenGL的技术融合
2.3.1 OpenGL
在图形软硬件行业,应用最广泛的跨平台的硬件加速标准程序接口规范是OpenGL(open graphics library),其官方网站是http://www.opengl.org/。OpenGL由数百个函数组成,用于以简单的图元绘制复杂的3D景象。OpenGL ES(OpenGL for embedded systems)是OpenGL开发接口的子集,应用在手机、掌上电脑和游戏主机等嵌入式设备上。智能终端如果支持图形硬件加速一般都支持某种版本的OpenGL接口,例如:苹果公司的iPhone 3G S设备硬件支持OpenGL ES 2.0;英特尔公司的新型MID硬件平台Moorestown中代号为“Lincroft”的核心处理芯片集成了图形核心、显示单元,其中图形核心可以直接支持OpenGL ES 2.0。下面着重讨论一下OpenGL。
OpenGL函数只提供3D图形渲染输出功能,其功能完全独立于宿主操作系统,此设计使OpenGL更容易实现跨平台的开发接口,然而,由于OpenGL核心API没有涉及窗口系统、键盘/鼠标或其他输入设备,OpenGL必须与宿主操作系统的窗口系统进行集成。与OpenGL集成的窗口系统有下面几类。
· GLUT(OpenGL utility toolkit),只提供基本的跨平台的窗口实现和系统I/O事件抓取。
·X Window,具体实现为GLX,该实现在下文中有介绍。
· Microsoft Windows,具体实现为WGL,本文不涉及。
2.3.2 GLX与OpenGL的直接/间接图形渲染
为了使X Window应用能够支持 OpenGL,X Window核心协议上扩展了GLX接口,GLX可以分成以下三个部分。
·X Window的应用程序能够调用OpenGL功能的一系列函数调用接口。
·X Window的核心X协议的扩展,使X Window的应用程序能够向X Server发送3D渲染命令。
·X Server的扩展模块,接收3D渲染命令,转发给硬件加速实现的OpenGL接口或者MESA类库(当系统硬件不支持硬件加速实现的OpenGL时,使用纯软件实现OpenGL图形渲染,此时使用了一个开源的、纯软件实现的OpenGL类库:MESA)。
GLX实现的OpenGL 3D图形渲染一般称作“OpenGL的间接渲染”(OpenGL indirect rendering),其特点是:X Window应用程序不直接与OpenGL的接口交互,3D图形渲染通过X Server实现。与此对比,还有一种OpenGL的直接图形渲染,应用程序不通过X Server,直接使用OpenGL进行图形渲染操作。
根据笔者的了解,目前智能终端软件栈上一般使用GLX实现OpenGL的间接图形渲染。其中比较典型的是Moblin 2,其主要的3D应用开发框架Clutter是以GLX为后端实现的。关于Clutter,下文中有描述。
OpenGL直接渲染的方案,存在复杂的技术难点,主要是X Server及其他OpenGL直接渲染的应用进程共享屏幕窗口管理的相关问题。这些问题在近年X Server以及图形系统的变革中逐步得到解决,并将为移动互联网终端提供更高的显示性能。
2.3.3 2D/3D复合桌面效果的实现
介绍使用GLX和OpenGL实现复杂的用户操作界面效果之前,必须先引入X Server的Render、Composite系列扩展以及介绍Composite Manager。
X Render扩展用于在X Server实现 Porter-Duff图像合成。Porter-Duff图像合成又称为Alpha图像合成(Alpha compositing)。Alpha图像合成将前景图像与背景图像进行复合计算,以获得前景图像部分透明的效果。X Render扩展将透明屏幕图像合成的功能放在了X Server端(甚至可以放到图形硬件上直接生成),避免屏幕图像的大量数据频繁从X Server跨进程传送到客户端,提高了处理的性能。
Composite扩展用于将X窗口以及其窗口子系统整个重定向到一块内存中,由于渲染不是输出到屏幕,该输出的缓存又称作“off-screen buffer”。
Composite Manager(见图2)是一个独立的程序或者与X的Window Manager为同一进程,Composite Manager可以利用X Render和Composite等X协议扩展提供不同的桌面窗口合成效果。例如,某个Composite Manager可以实现透明窗口,其大致的工作过程如下:
(1)使用Composite扩展将某个窗口及子窗口重定向到一个off-screen buffer;
(2)使用X Render扩展将off-screen buffer中的图像以Alpha图像合成的方式合并到可视的桌面;
(3)当窗口被移动或者遮挡需要重画,X Server通过Damage扩展通知到CompositeManager,重新执行第二步操作。
对X Window来说,实现一个3D的立方体桌面,立方体的每个面放置不同的应用入口以及启动的2D应用窗口,并不需要对原有的大量2D程序进行改动,只需要替换Composite Manager。
为了加快3D图形渲染的速度,还需要X Server做更进一步的结构优化。对此,业界正在酝酿在OpenGL基础上构建X Server的变革,这就是XGL。
2.3.4 XGL:在OpenGL基础上构建X Server
XGL的定义为:一种在OpenGL基础上构建X Server的架构。X Server的主体部分如下:2D的图形渲染使用原来的传统架构,由DDX(device-dependent X)载入特定的图形硬件驱动,在XGL架构定义中,X Server不载入特定的硬件设备驱动,而是直接利用“OpenGL驱动”。XGL架构如图3所示。
图3中,DDX是通过glitz的类库与OpenGL的接口交互。图4提供了一个XGL与2D/3D混合渲染的Composite Manager的组合架构。在该架构中,2D图像通过glitz使用OpenGL进行图形渲染,而3D的桌面图像、Composite Manager通过GLX进行图像渲染。
3 窗口应用开发框架
一般说来,上层应用开发者并不需要对X Window体系架构进行了解即可进行应用开发,原因是系统的底层实现,例如与X Window的X协议交互的细节都被封装和屏蔽到某种窗口应用开发框架中,窗口应用开发框架为应用开发提供了丰富的可以开箱即用的各种功能组件,使上层的应用开发者可以专注于窗口应用逻辑,降低了应用开发的技术难度。
在Linux智能终端开发领域,窗口应用开发框架与图形及窗口子系统紧密相关,窗口应用开发旗帜鲜明地分成两类:一类是不使用X Window,自定义图形子系统和窗口应用开发框架,例如Android。另一类是使用X Window,大多使用Linux桌面系统传统的一些窗口应用开发工具,例如GTK+和Qt。Linux的开源终端软件栈中,Maemo主要使用 Hildon窗口应用开发框架,同时兼容 GTK+;LiMo、OpenMoko、GPEPhone主要使用GTK+;Moblin其窗口应用开发框架主要使用GTK+和Clutter。
在Linux嵌入式UI开发领域,Gtk+和Qt经过多年的发展已经比较成熟,在以硬件加速的图形显示为基础的3D窗口应用领域,Clutter代表了新的技术开发趋势。Clutter是一个直接架构在OpenGL之上的窗口应用工具包,它使开发者能够以一种简单的方式开发OpenGL的应用,不需要涉及复杂的OpenGL API。在开源社区有人断言:“Gtk+之于 XLib/X,有如 Clutter之于 OpenGL/GLX”。
如果说Gtk+是一个面向静态窗口组件布局的开发工具包,那Clutter则是面向动态窗口的组件,其重点是描述平面的窗口组件在空间的运动。Clutter的技术特性如下。
①Clutter与Gtk+一脉相承,以GLib/GObject为基础。
·使用GLib作为通用性工具函数库,提供基础数据结构操作支持。
· 使用GObject的类型描述。GObject的类型描述主要有两大作用:第一个作用是提供了一种在C语言下实现面向对象理念的操作方法;第二个作用是为实现开发绑定多种语言提供支持,例如,C、Python、VALA等。
②使用新型的对象概念描述动态运动的窗体控件。窗体定义为舞台(Stage),控件定义为演员(Actor),而时间线(TimeLines)与演员(Actor)绑定用以定义演员(Actor)的行为(Behaviour)。通过时间线的各种事件回调函数控制行为。
③Clutter上使用了OpenGL的封装类库COGL,COGL封装和简化了OpenGL的API,并且能够在不同版本的OpenGL中保持兼容。Clutter应用可以选择直接使用COGL进行OpenGL的编程。
④Clutter缺省编译参数中,以GLX作为与本地窗口的后端支持(作为研究的 Clutter版本为:1.1.3),此时Clutter与X Server的关系可以描述如图5所示。
⑤Clutter能与其他X Client的窗口进行集成。根据对Clutter1.1.3版本的测试结果,Clutter的Stage可以集成到GTK的某些子窗口容器构件上。而其他的X Client类型的窗口也可以集成到Clutter的Stage窗口上。
4 多媒体子系统
4.1 智能终端对多媒体子系统的新需求
为了迎合移动互联网时代的多媒体娱乐需求,支持音乐、电影、网络视频共享、视频电话、社交游戏等多媒体业务,移动智能终端从硬件平台上强化了对语音和视频等媒体功能的支持。由于移动终端是一种资源受限硬件平台,其主要是ARM硬件平台或者新型的经过低功耗改良的X86硬件平台。为了提高对多媒体数据的处理能力,目前移动终端主流的处理方法是:采用某种硬件加速的媒体编解码芯片。上文提到的英特尔公司Moorestown硬件平台,其主处理芯片Lincroft上集成了硬件实现的视频编码和解码的功能,支持 MPEG4、H.264格式的编码及 MPEG2、MPEG4、H.264等格式的解码,另一颗主要芯片Langwell则集成了音频引擎,实现硬件音频播放的功能。再说说Maemo,Maemo使用ARM的硬件架构,使用ARM DSP硬件加速解码,OpenMAX IL作为其硬件加速解码的抽象层。
与此对应,移动互联网终端的多媒体子系统一般可以分成两部分:一部分是上层的多媒体处理框架,另一部分是系统与声音、显示系统以及硬件实现的编解码的交互接口。下面分别针对这两部分进行阐述。
4.2 GStreamer的简介
多媒体处理框架在Linux系统一般使用GStreamer类库或者Helix类库,前文在开源的Linux智能终端软件栈中,如 Maemo、LiMo、Openmoko、GPEPhone 都不约而同地采用了GStreamer作为其上层多媒体框架,而Moblin则同时支持GStreamer和Helix。Gstreamer是Linux多媒体处理的主流典型技术。
GStreamer是一种链接管道式的多媒体处理框架,将多媒体数据流处理划分成各种能够自由组合重用的节点,然后将节点组合成串行处理的媒体处理链。这是GStreamer用于播放MP3媒体文件的一种命令行:
gst-launch-0.10 filesrc location="concept.mp3" !decodebin!alsasink
其中的 filesrc、decodebin、alsasink都是一种 GStreamer的节点(Element)。Element的输入和输出称为 Pads,上游节点的输出可以挂接到下游节点的输入上,以此方式多个节点可以挂接组成媒体处理链。BIN用于将一组Element挂接组成链状逻辑单元。PipeLine是一种特定的最上层的BIN,PipeLine启动后,在单独的线程中运行,PipeLine线程和宿主的程序之间通过一个GStreamer提供的消息总线进行通信。图6是一个典型的 PipelLine示例,多媒体数据流经过ogg-demuxer的Element之后分流成声音和视频两路媒体流。
GStreamer将媒体处理过程中的各个环节包括输入、解包/组包、编码/解码、输出都封装成节点(Element),其中输入包括:从文件、网络、摄像头、麦克风输入等,输出包括:输出到屏幕、耳机、网络、文件等。一组Element则可以打包GStreamer的一个插件库,输入输出设备以及硬件编解码设备的程序接口都封装成GStreamer的插件库。
4.3 多媒体子系统的底层接口
下面以Maemo的多媒体子系统(如图7所示)为例,介绍多媒体子系统主要的底层接口。
图7中左边ALSA为 “高级Linux声音体系(advanced linux sound architecture)”,是声卡Linux内核驱动组件,是目前Linux主流的声音处理架构。
摄像头的视频捕获程序接口:V4L2。Video4Linux是一种与Linux内核集成的通用摄像头驱动,V4L2是Video4Linux的第二个版本。
OpenMAX IL作为Maemo硬件加速解码的抽象层。
XVideo是X Window核心协议的扩展,用于支持视频播放,下面对视频播放技术播放过程中存在的性能瓶颈及XVideo解决方案进行分析。
· 在显示过程中,视频流原始支持的显示大小和窗口大小很可能不一致(例如,全屏模式播放时),此时需要对每一帧图像进行缩放,该操作将消耗大量的CPU资源。XVideo实现了由X Server端实现视频显示大小转换的功能,方便利用硬件直接实现每一帧图像的缩放。
· XClient与X Server是操作系统上独立的进程,在进程间大量的媒体数据传送是另一个造成性能低下的原因,XVideo可以选择使用共享内存的方式在这两个进程之间传递视频数据流。共享内存是同一块物理内存被映射到多个进程各自的进程地址空间的技术,避免在内核空间和用户空间进行多次数据拷贝。
5 桌面数据总线与应用管理
上面提到的Linux开源智能终端软件栈中的主用户操作界面(根据PC上的习惯,称之为“桌面”)由多应用进程构成,依赖于桌面数据总线在各个应用之间、应用与操作系统之间传递业务消息,以协调同步各个窗口应用的关系,结合应用管理模块形成一个整体的、协调一致的桌面会话。系统的各个应用和服务以桌面数据总线为中心连接在一起,桌面数据总线是其中的中心子系统,在上文提到的各大Linux开源智能终端,如Maemo、Moblin、OpenMoko、LiMo、GpePhone使用的都是一个主流开源的桌面数据总线:D-Bus。D-Bus不仅在上述的开源软件栈中应用,更是作为关键的子系统应用在桌面Linux上,为Linux上此方面最成熟的技术。
D-Bus分成两类进程:一类是系统总线,在系统中是安全级别高的单实例系统进程,用于通知系统内核和设备的消息;另一类是是每用户一个的会话总线,用于传递应用间业务消息。
D-Bus架构中,每个应用将其业务对象以及接口注册到D-Bus守护进程上,D-Bus守护进程提供业务消息的寻址、路由和可靠传送工作。
D-Bus有两种开发接口:低级开发接口和高级开发接口。前者只涉及D-Bus的基本操作,不涉及与具体语言定义的对象绑定,仅可使用C语言进行开发。后者将D-Bus的对象、接口绑定到 GLib、Python、Qt、Java等具体语言或者类库定义的本地对象中,该绑定机制屏蔽了D-Bus操作的复杂性,开发者通过直接操作这些特定的本地对象进行D-Bus消息的收发。
通常,桌面数据总线与应用管理的实现结合在一起,形成完整的桌面会话,应用管理是指应用实例进程生命期管理、实现应用进程单实例等。实例进程生命期管理主要指启动、运行和结束等状态管理。在资源紧张的智能终端中,一般依照某种策略对已经运行但是不被使用的应用进程进行强制休眠或者退出。
在GPEPhone中,libiac模块提供了D-Bus底层开发接口的封装,应用使用libiac进行应用进程间通信,图8是libiac与Gpe应用管理器的典型交互图,图中保证了应用A与一个存活的应用B进行通信。
6 电话通信模块
对于智能终端而言,电信网上的语音及增值业务是基础业务,移动互联网上的各种数据业务是重点业务,为了支持这两类业务,智能终端通常都必须集成某种通信模块,目前集成的多数是电信运营商3G的电话通信模块。通信模块一方面连接电信运营商的网络,支持传统语音业务以及3G移动通信下的新型多媒体业务,另一方面可以作为无线调制解调器,使用户通过通信模块连接到电信运营商互联网接入点,随时随地使用互联网业务。
从硬件结构上看,通信模块与具体的运营商网络制式相关,相对独立于智能终端的主处理器,两者由不同的厂商提供,通过SPI接口或者USB接口相连,共用麦克风、扬声器等外围设备,形成一种“双核心”的结构。
从软件结构上看,电话通信模块驱动、电话通信核心服务以及上层电话应用通常称为电话应用软件栈。图9为电话应用软件栈的一种典型结构。
通常,电话通信模块作为串口设备接入到Linux的操作系统中,通过3GPP TS 27.010规范定义的多路复用协议,虚拟出多个通道。下面介绍两种主要的串口通道。
最主要的串口通道用来发送和接收AT命令控制通信模块,AT命令是一种在串口上应用的文本命令,主要用于控制电话通信模块与电信运营商的网络进行通信,实现电话、视频电话、短信等功能,获取网络的状态,读取存储在通信模块中的SIM卡身份标识、号码本等各种信息。AT命令格式在3GPP 27.007文档中有规范的定义,不同的运营商不同的网络制式下有些扩展和差异。
另一个串口通道通常用于PPP拨号上网业务,PPPD系统服务通过PPP驱动进行拨号上网,建立PPP会话,上层网络应用在PPP会话基础上建立IP连接。
7 结束语
移动互联网的飞速发展中,业界逐步认识到移动互联网发展中终端的瓶颈限制,终端的限制使其不足以支撑丰富的多媒体业务和快速的业务部署。Linux开源移动终端软件栈作为新兴的终端关键技术,吸引了各大厂家聚集并组合成产业联盟,尝试打开移动互联网的新局面,对此值得详细的学习分析和长期的跟踪研究。
1 Matthieu Herrb,MatthiasHopf.New evolutionsin theX Window system, http://www.openbsd.org/papers/eurobsd2005/herrb-hopf.pdf,October 2005
2 Porter T,Duff T.Compositing digitalimages.Computer Graphics,July 1984
3 X Window system protocols and architecture,http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture
4 X Window system core protocol,http://en.wikipedia.org/wiki/X_Window_System_core_protocol
5 Andy Ritger.Using the existing driver framework to achieve a composited X desktop.XdevConf,2006
6 OpenGL,http://en.wikipedia.org/wiki/OpenGL
7 GDK Basics,http://developer.gnome.org/doc/GGAD/cha-gdk.html
8 GTK+reference manual,http://library.gnome.org/devel/gtk/stable/
9 Clutter reference manual,http://clutter-project.org/docs/clutter/stable/
10 GStreamer application development manual (0.10.25.1),http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html
11 Documentation/Maemo 5 developer guide/architecture/multimedia domain,http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Multimedia_Domain
12 Havoc Pennington.D-Bus Specification,http://dbus.freedesktop.org/doc/dbus-specification.html