More Related Content
Similar to 手机流媒体培训2003 (20)
手机流媒体培训2003
- 1. 1. 流媒体技术梗概 2. 手机流媒体及其技术特点 3. 开发平台和主要技术介绍（基于 Symbian 平台）
- 2. 流媒体技术梗概 ? 传输音 / 视频等多媒体信息有下载和流式传 输两种方案 下载：存储容量也较大；延迟也很大 流式传输：只需经过几秒或十数秒的启动延 时即可进行观看；避免下载整个文件
- 3. 流媒体技术梗概 ? 流媒体指在 Internet/Intranet 中使用流式传 输技术的连续时基媒体，如：音频、视频 或多媒体文件。流媒体实现的关键技术就 是流式传输。 ? 实现流式传输有两种方法：实时流式传输 （ Real-time streaming transport ）和顺序 流式传输（ progressive streaming transport ）。
- 4. 流媒体技术梗概 ? 1. 实时流式传输 实时流式传输总是实时传送，特别适合现场广播，也支持随机访问，用户可快 进或后退以观看后面或前面的内容。但实时流式传输必须保证媒体信号带宽与网 络连接匹配，以便传输的内容可被实时观看。这意味着在以调制解调器速度连接 网络时图像质量较差。而且，如果因为网络拥塞或出现问题而导致出错和丢失的 信息都被忽略掉，那么图像质量将很差。实时流式传输需要专用的流媒体服务器 与传输协议。 ? 2. 顺序流式传输 顺序流式传输是顺序下载，在下载文件的同时用户可观看在线内容，在给定时 刻，用户只能观看已下载的部分，而不能跳到还未下载的部分。由于标准的 HTTP 服务器可发送顺序流式传输的文件，也不需要其他特殊协议，所以顺序流式传输 经常被称作 HTTP 流式传输。顺序流式传输比较适合高质量的短片段，如片头、片 尾和广告，由于这种传输方式观看的部分是无损下载的，所以能够保证播放的最 终质量。但这也意味着用户在观看前必须经历时延。顺序流式传输不适合长片段 和有随机访问要求的情况，如讲座、演说与演示；也不支持现场广播，严格说来 ，它是一种点播技术。
- 5. 流媒体技术梗概 ? 流媒体播放有四种方式： 1 、单播方式：一台服务器传送的数据包只能传 递给一个客户机，媒体服务器必须向每个用户 发送所申请的数据包，多个点对点方式结合， 2 、组播方式：允许路由器将数据包复制到多个 通道，客户端共享一个数据包，按需提供 3 、点播方式：客户端与服务器主动连接用户通 过选择内容项目来初始化客户端连接 4 、广播方式：用户被动接受流，客户端接受流 ，但不能控制流。数据包的单独一个拷贝发动 给网络上的所有用户，不管用户是否需要。
- 7. 流媒体技术梗概 ? 目前，采用流媒体技术的音视频文件主要有三大“流派”。 一、微软的 ASF （ Advanced Stream Format ）。这类文件的后缀是 .asf 和 .wmv ，与它对应的播放器是微软公司的 “ Media Player” 。用户可以将图形 、声音和动画数据组合成一个 ASF 格式的文件，也可以将其他格式的视频和 音频转换为 ASF 格式，而且用户还可以通过声卡和视频捕获卡将诸如麦克风 、录像机等外设的数据保存为 ASF 格式。 二、是 RealNetworks 公司的 RealMedia ，它包括 RealAudio 、 RealVideo 和 RealFlash 三类文件，其中 RealAudio 用来传输接近 CD 音质的音频数 据， RealVideo 用来传输不间断的视频数据， RealFlash 则是 RealNetworks 公 司与 Macromedia 公司联合推出的一种高压缩比的动画格式，这类文件的后缀 是 .rm ，文件对应的播放器是“ RealPlayer” 。 三、是苹果公司的 QuickTime 。这类文件扩展名通常是 .mov ，它所对应的播放 器是“ QuickTime 。” 此外， MPEG 、 AVI 、 DVI 、 SWF 等都是适用于流媒体技术的文件格式。
- 8. 1. 流媒体技术梗概 2. 手机流媒体及其技术特点 3. 开发平台和主要技术介绍（基于 Symbian 平台）
- 9. 手机流媒体及其技术特点 流媒体技术应用到移动网络和终端上，称之为移动流媒体技术。 2.5G 、 3G 等无线网络的发展也使得流媒体技术可以被用到无线终端设备上，特 别是 3G 用户无线网络接入带宽的提高，移动流媒体技术所封装出的应用将会成为 3G 的一类主要应用。 手机流媒体的关键技术：采集、压缩、传输控制、 Cache 、发布
- 10. 手机流媒体及其技术特点 移动流媒体格式 业界移动流媒体目前主要有三种媒体格式： 1.3gp/3gp2 媒体格式：是 3GPP/3GPP2 组织制定的标准移动流媒体媒体格式，支 持终端最多。 2.WMV 媒体格式：是 Microsoft 公司的私有格式，有少量终端支持。 3.RM 媒体格式：是 Real 公司的私有格式，内置 RealPlay 播放器的终端支 持， RealPlay 播放器同时支持 3gp/3gp2 媒体格式。 从覆盖用户面来看，媒体格式 3gp/3gp2 是首选支持， WMV 格式选择支持。而 RM 格式相对于 3gp/3gp2 效果没有优势，目前业界在选用 3gp/3gp2 后不再单独选择 支持 RM 格式。
- 11. 手机流媒体及其技术特点 流媒体终端带宽适配 不同的移动终端其处理能力有较大差异，所支持的协议和编码格式也各有不同。 如何解决这个问题？——目前采用后台的流媒体系统进行终端适配可以解决这个 问题。 众所周知， IP 网络是一个尽力而为的网络。所以，网络的可用带宽发生波动是 常有的事情，那么对于流媒体这样对带宽要求较高的应用，如何来规避呢？大家想到 的肯定是 QoS ，但是从目前来看，在短期内实现端到端的 QoS 是不现实的。 所以，通过对网络资源的统计以及通过核心技术通过对服务器端做相应的处理， 就可以在保证终端和核心网不作任何改动的情况下，保证用户的 ( 流媒体 ) 业务体验 ，不会出现缓冲、等待、马赛克等现象。 RTSP 在体系结构上位于 RTP 、 RTCP 之上，属于应用层协议。它使用独立的 TCP 或者 RTP 完成数据传输。对于承载协议，大部分移动终端只支持 RTP 采用 UDP 承载 。
- 12. 手机流媒体及其技术特点 移动流媒体应用 移动流媒体业务基本形式由三种：直播、点播、下载。从应用的角度来看，分为 两大类：媒体类应用和行业类应用。 就目前而言，报纸、杂志基本上是获取这部分“眼球”的重要媒介，但随着 3G 时代 到来，以手机 + 流媒体为代表的移动流媒体将成为这一领域最有力的“眼球”获取媒介。 原因如下： 1. 流媒体技术特点决定的：媒体节目边缓存、边播放，即内容的获取和内容的 消费同步进行。使得可以最大限度地在有限的时空范畴内为消费者提供高效的信息服 务。 2. 手机媒体具有移动性、便携性自身特点决定其适合这种形式：离散型时空资 源的重要特征是时间长短的不确定性和空间位置的不确定性。手机媒体会随时随地且 无处不在地服务，可以很好地解决这一问题。 3. 由移动运营商掌控行业价值链的移动流媒体产业是可控的商务模式和健全的 收费体系为移动流媒体的可持续发展提供了重要保障。
- 13. 手机流媒体及其技术特点 移动流媒体应用 媒体类应用表现形式多种多样，主要针对个体用户，为了保证好的效果一般需 要进行终端适配、带宽适配等。这类应用要求流媒体系统： 1. 需要支持 SP/CP 通过互联网发布内容。 2.SP/CP 提供内容源，流媒体系统自动地进行终端适配类编码。 主要是监控类和视频应用类业务，主要特点是每一种应用相比媒体应用来说，用 户群体较少。 行业类应用表现形式也较多，有些应用内容制作方面相对投入较少，对直播 源的需求较多。这类应用要求流媒体系统提供低成本的多路直播源等接入技术。
- 14. 手机流媒体及其技术特点瓶颈凸显 而且随着 3G 无线网络的应用，用户的网络带宽可以达到 384k bit/s 。在如何运营好 移动流媒体业务存在如下问题： 1.“ 手机电视”无线网络带资源问题：需要有公共信道提供“手机电视”服务，降低 运营成本。 2. 漫游问题：如何解决用户在漫游状态使用流媒体业务问题需要运营商统一考虑 。 3. 媒体内容分发问题：由于流媒体对资源占用较多，面临诸多问题，如网络拥塞 、服务器超载等。为了解决这些问题， Internet 领域的流媒体业务应用采用了 CDN( 内容 分发 ) 技术。移动流媒体在用户增长到一定数量时，同样有此类问题。移动流媒体内容 分发网络 (Mobile Stream-ing Media Content Delivery Network ， MSM-CDN) 的概念应运而 生。 4. 容错问题：相对于有线网络而言，无线网络状况更不稳定，除去网络流量所造 成的传输速率的波动外，无线终端移动速度和所在位置也会严重地影响到传输速率，因 此高效的可自适应的编码技术至关重要。但是高压缩的码流对传输错误非常敏感，还会 造成错误向后面的图像扩散，移动流媒体在信源和信道编码上需要很好的容错技术。
- 15. 手机流媒体及其技术特点 瓶颈凸显 5 、终端问题：如何解决终端的功耗、终端屏幕等对于使用流媒体业务的制约作用。设 想一下，如果因为看手机流媒体节目而导致手机没电，影响正常的语音通信，有多少用 户能无限量的使用这项业务； 6 、内容源问题： 3G 流媒体业务如何形成适合手机播放的视频节目而不是简单的电视 节目的 copy 将是业务发展的一个重要关键因素； 7 、网络问题： 3G 流媒体业务存在大量的并发事件，尤其是基于 P2P 移动流媒体传送 ，这就对网络的稳定性、容量提出了巨大的挑战； 8 、计费问题： 3G 流媒体涉及到流量计费、内容计费、按次计费、融合计费等多种模 式。尤其是内容和流量计费，如何实现对内容的甄别、如何对基于内容的流量实现计费 也成为业务发展的一个重要因素
- 16. 1. 流媒体技术梗概 2. 手机流媒体及其技术特点 3. 开发平台和主要技术介绍（基于 Symbian 平台）
- 17. 开发平台和主要技术介绍（基于 Symbian 平台） Symbian 是一个实时性、多任务的纯 32 位操作系统，具有功耗低、内存占用少等特点，非 常适合手机等移动设备使用，经过不断完善，可以支持 GPRS 、蓝牙、红外以及 3G 技术。 Symbian 主要用于高端的智能手机，其开发语言为 C++ 。 Symbian 是真正的微核操作系统 ，所谓“微核”，就是说操作系统只有很小的一部分是运行在最高优先级的，其他的功能都是 以 Client-Server 的方式提供。 搭建 Symbian 开发环境 第一步：安装 Java SDK 。（版本 5.0 以上） 第二步：安装 Active Perl 。（最好版本是 5.6.1.635 ） 第三步：安装 Symbian SDK 。（ SDK 与项目工程在同一目录下） 第三部：安装 Carbide C++ 。
- 18. 开发平台和主要技术介绍（基于 Symbian 平台） Helloworld 程序： （命令行方式构建） 进入 %EPOCROOT%ExamplesBasicsHelloWorld 目录 ，运行： bldmake bldfiles 此命令将产生一个新文件，即 ABLD.BAT 。该命令文 件无需进行编辑。 编译并连接项目，运行： abld build winscw udeb 或 abld build winscw urel 这将为 Series 60 调试仿真器软件创建项目。其中 abld build wins udeb 命令将构建一个具有调试信息 的针对 WINS 平台的 Unicode 版本； abld build wins urel 将构建针对目标设备的 Unicode 应用的发布版 本。 进入 %EPOCROOT%epoc32releasewinscwudeb 目 录，运行： HelloWorld
- 19. 开发平台和主要技术介绍（基于 Symbian 平台） Helloworld 在目标设备上运行 : abld build armi urel 生成可发行的 HelloWorld 应用程序，可以将其直接复制到手机，亦可通过 Makesis 工 具进行打包成 .sis 安装文件。 模拟器和目标设备之间的主要差异存在于进程和线程等方面： WINS 环境是运行在 PC 之上的单进程。运行于此单进程的每个应用程序都运行在其自己的线程中。目标硬件 是多进程环境，在此环境下，每个应用程序运行时具有单独的进程。这将导致在应用 程序启动时方式的差异。
- 20. 开发平台和主要技术介绍（基于 Symbian 平台） Symbian 基本知识 : 手机设备的两个特点：长时间在线与硬件资源有限。前者要求避免重启设备，后者要求谨 慎使用内存。 命名约定： 1 、类名，以 C ， T ， R ， M 为前缀； 2 、函数名，函数形参前有一个“ a” 前缀。在函数名的末尾加“ L” 指明一个函数或方法有 可能发生泄漏。在函数名的末尾加“ C” 来指明一个函数或方法将某一变量压入了 Cleanup 栈中，调用该函数结束时，必须将该变量从 Cleanup 中弹出。 3 、数据成员，用“ i” 前缀来表示类中的数据成员，当定义或声明一个指针或引用时，将 “ *” 或“ &” 与类型名相连，而不要与变量名相连。 4 、常量，在用“ Const” 定义的常量名前加“ k” 前缀。 5 、枚举，在其名字前加“ T” 前缀，用“ E” 前缀来表示枚举成员。
- 21. 开发平台和主要技术介绍（基于 Symbian 平台） 基本数据类型 : 描述 Symbian OS 类型 32 位布尔型 TBool(ETrue 或 EFalse) 8 位无 / 有符号整型 TUint8/TInt8 16 位无 / 有符号整型 TUint16/TInt16 32 位无符号整型 TUint32, TUint 32 位有符号整型 TInt32, TInt 64 位无 / 有符号整型 TUint64/TInt64 双精度浮点型（ IEEE754 64 位表示法） TReal64 ， TReal 指向未定类型的指针 TAny* 字符串： Symbian 的字符串是通过 descriptor 实现的。它可以处理字符串，也可以处理二进制， T 类型的描述符 , 跟其他基本类 (Tint) 一样 , 都是在栈中创建。在创建时并不需要指定它时那 种类型 , 它是在创建时的设置决定的。 TBufC<> 、 Tbuf<> 、 TPtrC 、 TPtr 、 HBufC 。
- 22. 开发平台和主要技术介绍（基于 Symbian 平台） 线程 一个线程是执行的单元。 同一个进程的线程共享地 址空间。调度器 （ schceduler ）负责对线 程（而不是进程）进行调 度 进程 内存保护的单元。一个进 程不能访问其他进程的内 存空间。一个进程有一个 或多个线程 抢先式多任务 线程根据它们的优先级进 行调度。优先级高的线程 能够抢先优先级低的线程
- 23. 开发平台和主要技术介绍（基于 Symbian 平台） 上下文切换 当调度器在不同的线程之间进行切换时，就需要进行 上下文切换。 将导致内存表、寄存器内容改变 根据线程是否属于同一个进程而耗时不同 活动对象 Symbian OS 用来处理异步方法调用的特殊对象 使得进行合作的多个线程能够更加有效的利用资源 堆 / 栈 线程使用的内存空间 堆必须显式的申请和释放 栈空间由 OS 负责管理
- 24. 开发平台和主要技术介绍（基于 Symbian 平台） Leave Symbian OS 的错误处理机制 与 Trap Harness 一起使用 与标准 C++ 中的 catch/throw 机制类似 清洁栈 Cleanup 栈用来处理那些在堆中申请的对象，但是指向这些对象的指针却是保 存在栈里的自动变量。 二层构建： 一个类的构建函数 Leave ，那么 new 为它分配的内存就会泄漏。（构建的顺 序是：系统分配内存，然后运行构建函数）构建函数在任何情况下不可以 离开！ 1 、不在构建函数里使用任何 L 函数； 2 、不在构建函数里分配内存 Panic 致命错误 Panics 要么由 OS 触发，要么由一个出现了严重错误的用户线程触发
- 25. 开发平台和主要技术介绍（基于 Symbian 平台） 客户端 / 服务器： 多个客户端可以共享 服务端拥有的系统资 源。 客户端和服务端通过 会话层来通信。
- 26. 开发平台和主要技术介绍（基于 Symbian 平台）应用程序框架： 是开发应用程序的基础，由一些核心类构成，这些类形成了应用程序的 主体结构，同时封装了程序与操作系统的交互过程。 所有的 Series 60 UI 应用程序都应包含以下基本的功能： 1 、提供用户接口界面，用于显示信息以及与用户交互。 2 、对用户发起的事件进行响应，如菜单操作。 3 、对系统事件进行响应，如 Window 服务器的重绘事件。 4 、保存和恢复应用程序数据。 5 、想框架提供该应用程序的描述信息，如图标、标题等。 这些功能由应用程序框架的 View 、 Document 、 Application 和 UI 来实 现。
- 27. 开发平台和主要技术介绍（基于 Symbian 平台） 应用程序初始化： a 、 所有 S60 UI 入口函 数 E32DLL 。 b 、框架创建 Application 。 C 、由 Application 创建 Document 。 d 、由 Document 创建 AppUi 。 e 、 由 AppUi 初始化程 序，以及创建 View 。
- 28. 开发平台和主要技术介绍（基于 Symbian 平台） 基于控件的传统 Symbian OS 框架 特点： AppUi 直接拥 有 ( 实例化 ) 视图控 件，该视图控件继承 自 CCoeControl ，且 被称为容器。可以通 过继承 CCoeControl 来自定义控件。 缺点：没有使用系统 提供的视图管理系统 。
- 29. 开发平台和主要技术介绍（基于 Symbian 平台） 基于对话框 Dialog 的框架 : 特点：视图类的父 类为对话框类，而 不是 CCoeControl 。与 传统结构类似，仍 有 AppUi 创建视图 控件。
- 30. 开发平台和主要技术介绍（基于 Symbian 平台） Avkon 切换视图的应用程序框架 ： 第一层中的许多类都是抽象的，仅 仅定义了框架 API 的接口。 第二层增加了通用的 Symbian OS 实 现，它们被所有的 Symbian OS UI 平 台所共享。 第三层增加了 Series 60 特有的实现。 第四层是自定义的应用程序实现。
- 31. 开发平台和主要技术介绍（基于 Symbian 平台） 选择适当的应用程序架构 : （ 1 ）使用 Avkon 视图切换架构 大多数情况下，这种架构是最佳的架构，但它也具有局限性，如：视图切换方 案没有任何内置的方法来保存视图切换的上下文。也就是说，没有提供用于定 位到前面激活视图的机制，没有类似于浏览器上后退功能的按钮的功能。但是 DoActivateL() 确实收到了前面激活视图的标志符，因此可以自定义后退按钮功 能。 （ 2 ）使用基于控件的传统 symbian OS 架构： 程序可能只需要一个视图 应用程序具有 UI 控件，必须保证这些 UI 控件的私有性。 如果是将应用程序从不同的 symbian OS 平台移植到 series 60 。 （ 3 ）使用基于对话框的架构 可以在资源文件中定义控件，让对话框自动处理布局和绘画，这比实现自定义 绘画行为更为容易。仅当应用程序的视图之间没有任何循环导航路径时，才可 以对这种应用程序使用“基于对话框”的方法。
Editor's Notes
- #4: 一般来说，如为实时广播，或使用流式传输媒体服务器，或应用实时流协议（RTSP）等，即为实时流式传输。如使用超文本传输协议（HTTP）服务器，文件即通过顺序流发送。采用哪种传输方法可以根据需要进行选择。当然，流式文件也支持在播放前完全下载到硬盘。 流媒体技术三大特点： 1.能够实时播放音视频和多媒体内容。这样可以大大缩短启动延时，避免了用户必须等待整个文件全部从服务器源上下载完成后才能观看的缺点。 2.播放的流媒体文件不需要在客户端保存，减少了对客户端存储空间的要求，也减少了缓存容量的需求。 3.由于流媒体文件不在客户端保存，从而从一定程度上解决了媒体文件的版权保护问题。
- #7: 流式传输的过程一般如下： ①用户选择某一流媒体服务后，Web浏览器与Web服务器之间使用HTTP／TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来； ②Web浏览器启动音视频客户程序，使用HTTP从Web服务器检索相关参数对音视频客户程序初始化，这些参数可能包括目录信息、音视频数据的编码类型或与音视频检索相关的服务器地址； ③音视频客户程序及音视频服务器运行实时流协议，以交换音视频传输所需的控制信息，实时流协议提供执行播放、快进、快倒、暂停及录制等命令的方法； ④ 音视频服务器使用RTP／UDP协议将音视频数据传输给音视频客户程序，一旦音视频数据抵达客户端，音视频客户程序即可播放输出。 需要说明的是，在流式传输中，使用RTP／UDP和RTSP／TCP两种不同的通信协议与音视频服务器建立联系，目的是为了能够把服务器的输出重定向到一个非运行音视频客户程序的客户机的目的地址。另外，实现流式传输一般都需要专用服务器和播放器。
- #10: 采集：其实是所有过程中最耗费精力的一个步骤，如何采集，采集谁，是否授权这些问题我们都应该考虑到。我们目前的专业视频采集设备在功能上可以采集：有限电视，电台广播，摄像头，家用DV等等。 压缩：手机流媒体与大众流媒体不同，他受限于网络的传输速度，虽然目前中国联通CDMA 1X网络能支持133K/秒的传播速度，但是在真正的实施过程中，如果要使用户进行流畅的观看，后期的压缩技术是必不可少的。 传输控制：我们知道一般的视频每秒的帧数都在50帧左右，在目前的网络环境下，如果保持流畅的观看，必须首先将帧数控制在10桢以下，并对画面进行优化。 Cache: 该技术先在使用者端的电脑上创造一个缓冲区，于播放前预先下载一段资料作为缓冲，于网路实际连线速度小于播放所耗用资料的速度时，播放程序就会取用这一小段缓冲区内的资料，避免播放的中断，也使得播放品质得以维持。 发布：发布的过程其实就是一个传输过程，只要安装了流媒体服务器特定的客户端软件就能将压缩好的流媒体文件上传至服务器端。
- #13: “离散眼球经济”的时代正在来临。所谓“离散眼球经济”是指：“通过对消费个体进行非连续的、间歇的和零散的时间段和空间段的注意力来吸引获得经济活动中品牌利益的最大化。”。 现代社会信息源和信息需求的高速膨胀使得传统中闲置的、离散的时间和空间为需求所用。 在人们正常的工作、生活活动之余，那些闲散的时空资源随着信息终端触角的延伸，越来越被人们所充分利用，或是用于工作资讯获取，或是用于生活休闲娱乐。然而什么也不干的人很少，究其根本原因在于当代社会生存竞争加剧，形势逼迫每个人只能利用曾经闲置的那些离散时空资源来填补自身资讯的空缺或是获得娱乐休息。
- #15: 瓶颈凸显 而且随着3G无线网络的应用，用户的网络带宽可以达到384k bit/s。手机设备运算能力越来越强，支持流媒体的终端将会成为3G终端的一种基本配置，移动流媒体的应用将会成为3G的一种基本业务。在如何运营好移动流媒体业务存在如下问题： 1.“手机电视”无线网络带资源问题： 每一用户使用直播都需要占用信道资源，“手机电视”运营成本较高。需要有公共信道提供“手机电视”服务，降低运营成本。 2.漫游问题： 由于手机终端基本上流数据的传输采用UDP，在目前中国移动采用用户使用漫游地的GGSN的模式下，如何解决用户在漫游状态使用流媒体业务问题需要运营商统一考虑。 3.媒体内容分发问题： 由于流媒体的对资源占用较多，在有线网络上传输流媒体面临着诸多问题，如网络拥塞、服务器超载等。 为了解决这些问题，Internet领域的流媒体业务应用采用了CDN(内容分发)技术。移动流媒体在用户增长到一定数量时，同样有此类问题。移动流媒体内容分发网络(Mobile Stream-ing Media Content Delivery Network，MSM-CDN)的概念应运而生。 4.容错问题： 相对于有线网络而言，无线网络状况更不稳定，除去网络流量所造成的传输速率的波动外，无线终端移动速度和所在位置也会严重地影响到传输速率，因此高效的可自适应的编码技术至关重要。 但是高压缩的码流对传输错误非常敏感，还会造成错误向后面的图像扩散，移动流媒体在信源和信道编码上需要很好的容错技术。
- #18: Symbian OS的微内核是完全可重入的。可重入性是指函数可以被多个任务进程调用。在多任务操作系统中，函数是否具有可重入性是非常的，因为这是多个进程可以共用此函数的必要条件。只有操作系统是多任务时，编译器才有可能提供可重入函数。 线程延迟很小，标准的用户模式线程延迟最多几十毫秒。运行在内核态的实时线程，最大延迟只有100微秒。ROM大小根据产物的需要而定，例如，Nokia 6600有16MB ROM。 Symbian OS是基于ROM，这意味着它并不需要加载到RAM中才能运行 Symbian OS提供了内核级的省电机制 Symbian OS是真正的微内核，只有极少数的组件是以核心态运行的，多数的系统组件都是运行在用户模式。在Symbian OS中，每个应用程序都运行在自己的进程中，都具有自己的地址空间。 Symbian OS基于组件的设计使得它能够很好的使用多种平台和多种资源（如不同的尺寸、颜色、输入设备等）。而这也同样有赖于面向对象方法的使用。Symbian OS除了极少数的代码是用汇编等或C语言写的，绝大多数都是直接用C++编写的。 这些特点使得Symbian OS是目前所有操作系统中健壮性最好的OS。即使操作系统及其主要应用连续运行数年（不关机和重启），Symbian OS仍然能够正确运行，并且确保用户数据不丢失。
- #21: 1、类名以C，T，R，M为前缀，其含意如下： T类：不拥有外部类型的值类，也没有析构函数。它们是自定义的类型但可像内部类型一样使用。T类的对象可以分配在栈或堆中。 C类：派生自基类CBase的堆分配类，它们通常得负责清空其他的对象，因为他们拥有基于堆的对角的指针或资源句柄。 R类：资源类，包含真实的资源句柄，但资源在其他地方维护（如某服务器或），通常资源类在堆上分配并使用Close()函数来关闭资源。 M类：接口类，只定义了一些由继承类来实现的抽象协议。此类不包含成员数据，因为它只定义接口而不含实现。 只有静态函数的类的类名不用加特殊的前缀，例如：类User，Math等。
- #22: 描述 Symbian OS类型 32位布尔型 TBool(ETrue或EFalse) 8位无/有符号整型 TUint8/TInt8 16位无/有符号整型 TUint16/TInt16 32位无符号整型 TUint32, TUint 32位有符号整型 TInt32, TInt 64位无/有符号整型 TUint64/TInt64 双精度浮点型（IEEE754 64位表示法） 尽管浮点数中一般推荐此类型，但是只要有可能就应该使用整型来实现你的运算。TReal64，TReal 指向未定类型的指针 TAny* 描述符： TBufC&lt;5&gt; 中的5是它的长度，它表示的是&quot;NewLC&quot;这个字符串，是不可更改的。 TBuf&lt;8&gt; 8是它的最大长度，而当前只使用了5个字节，它的内容是可更改的，但是注意内容长度不可以大于他的最大长度。 TPtrC 是一个descriptor 指针类，它是一个不可修改的指针， 指向不可修改的&quot;NewLC&quot;的地址。 TPtr 是一个可修改的descriptor指针类，指向可修改的&quot;NewLC&quot;的地址。 HBufC 的H代表Heap，是专门用来在Heap上创建字符串，其他的descriptor类的字符串一般都放在stack上。 C中: Symbian中： 1、将串存放于代码中： static char stringinrom[]=&quot;moring&quot;; _LIT(KStringinrom,&quot;moring&quot;); constant char* stringautoptr=stringinrom; TPtrC stringautoptr=KStringinrom; 2、将串的内容拷贝到栈中: char stringinstock[sizeof(stringinrom)]; strcpy(stringinstock, stringinrom); TBuf&lt;7&gt; stringinstock(KStringinrom); 3、将串放入堆中： char* stringinheap=(char*)mallc(sizeof(stringinrom)); strcpy(stringinheap, stringinrom); TBufC* stringinheap:KStringinrom().AllocLC();
- #23: 在Symbian OS中，最低优先级的线程位空线程（null thread） 进程之间，除非特别授权，是不能访问对方的内存空间的。 一个进程中线程的优先级会因为该进程优先级的调整而调整。 由于线程是执行的单元，所以每个线程都有自己的栈和堆以保存自己的执行代码上下文。每个线程都具有一个缺省堆，同时也可以申请分配新的堆。缺省堆能够在属于同一个进程的线程之间共享，而其他堆则可以和所有进程的线程共享。
- #24: 上下文切换的状态包括处理器寄存器内容（线程上下文），线程的地址空间（进程上下文）。后者仅当在不同进程的线程间切换时才改变。 上下文切换我们在编程中并不会感觉到。 活动对象本质上是封装成两个C++类的异步事件循环。它是Symbian OS特有的异步事件处理机制，使用起来非常方便、简单。 当创建一个进程时，系统会为其主要线程分配内存块，其中就包含了存储堆栈。当进程创建新的线程时，将为其分配自己的内存块。其中包含了存储栈。如果新的线程不共享已有的堆，那么新分配的内存块将包含一个新堆。
- #25: 当应用程序出现错误时，能够通过Trap/Leave机制回溯到系统的某个安全状态。 注意Symbian 不支持catch/throw。能够Leave的代码通常位于一个Trap harness之中。这样当Leave发生时，系统就能够跳到对应的trap harness下面的代码，这些代码将负责对该错误进行处理。 抛出异常： User::Leaver(err); 捕获异常： int err; TRAP(err,functionNameLC()); if(err!=KErrNone){ .... } 或 TRAP(err,functionNameLC()); if(err!=KErrNone){ .... } 清洁栈： CClassName x=new (ELeave)CClassName; x-&gt;DoL(); Delete x; void CClassName::DoL() { TInt* p=new (ELeave)TInt; Delete p; } CClassName x=new (ELeave)CClassName; CleanupStack::PushL(x); x-&gt;DoL(); Delete x; CleanupStack::PopAndDestroy(); Panic是能够使系统停止运行的致命错误，如栈溢出。 RAM担负着内存和硬盘的双重职责，因而必须注意一下问题： 1、编程必须更加有效，节省使用内存。 2、尽可能早地释放资源。 3、必须处理内存不足错误。发生错误时，必须保证用户数据不能丢失，而且返回一个可接受的稳定状态，返回时必须保证清除所有已分配的资源。
- #26: 客户端会话类，从RSessionBase继承而来。其成员函数调用SendReceive()来发送消息给服务器。 内核类CSession，它负责建立客户端与服务器间的对话连接。 服务器端的会话类，从CSession继承而来。当从CServer活动对象继承来的类的对象检测到客户端的请求后，调用它RunL()，RunL()调用会话类的iServiceL()，它将分析消息参数，然后做相应的处理。结束后，调用RMessage的Complete()将处理状态通过内核传给客户端
- #27: 应用(Application)：是应用程序的主入口，它将应用程序相关的信息（如图标、标题等）返回给系统框架。Application自身不包含程序的数据和算法，这部分的泪继承自CAknApplication类。 文档（Document）：提供了存储数据的环境，该部分的泪继承自CAknDocument，文档同时也实例化了一个AppUi类。 应用程序UI（Application UI）：本身不是一个可绘制的控件，更准确地说，它负责接收信息，是一个框架触发的通告消息的接收器，如对用户按键事件或重要的系统事件进行接收。AppUi会处理此事件，或者传递给View处理。这部分的类继承自CAknAppUi。 视图（View）：这是用户在屏幕上实际看到的视图。在简单的应用情形下，它可以用于显示数据，或者在较为复杂的应用情形下，它能够用于收集用户数据。。例如，文字处理应用程序中的编辑器是文本字符键入的地方。此编辑器就是一个Avkon类提供的标准控件。 Model没有映射到Symbian OS的特定类，它的作用在于封装应用程序的数据和算法。该Model归Document所有，可以调用Document提供的方法来访问 在Series 60中，每个应用程序只能同时打开一个文档。
- #28: 1：所有Series 60应用程序都要实现一个全局函数E32Dll()，系统启动应用程序时，首先调用此函数。该函数被称作DLL入口点（entry point），必须包含在应用程序中，否则程序就会启动失败。 2，3：系统框架调用函数NewApplication()，在该函数内部生成了一个CHelloWorldBasicApplication类的实例，并返回一个指向它的指针。接下来框架会使用这个指针来完成程序的构造。 4：框架调用AppDllUid()以获得应用程序的UID，这个UID在.mmp文件中说明，常见于判断一个程序是否正在运行。 5～8：框架在调用CHelloWorldBasicApplication对象的CreateDocumentL()函数，生成应用程序文档并返回一个指向它的指针。从而使得框架可以直接调用Document的某些功能。 9：框架调用AppDllUid()，来观察是否要从文件系统中装入一个文件。 10,11：框架调用文档对象的CreateAppUiL()方法，从而生成了一个AppUi对象并返回一个指向它的指针。 12,13：框架通过调用AppUi对象的ConstructL()函数来完成其构造，事实上在这里完成了AppUi想做的所有初始化。ConstructL()函数首先调用的是AppUi基类的BaseConstructL()函数，这里处理了一些相关事宜，如读入程序相关的资源文件。 14～16：AppUi调用了AppView类的NewL()函数来生成其实例，这里采用两阶段构造。 17：框架调用了Draw()函数，调用的途径为Application、Document、UI、View。 18～20：无论用户何时选择一个菜单选项，HandleCommandL()都被框架所调用，并传递一个参数aCommand，它指明了用户所选择的命令。 常见的AppUi函数： 1、HandleKeyEventL()：处理用户键盘事件。 2、HandleForegroundEventL()：应用程序切换到前端是触发。 3、HandleSystemEventL()：分发Window Server生成的事件。 4、handleApplicationSpecialEventL()：用户自定义事件的通告，缺省为通告颜色方案的变化。 5、HandleCommandL()：处理用户菜单操作。
- #29: 这些控件总是从CcoeControl直接继承，用于表示从CcoeControl直接继承的试图类的标准术语是“容器”。 可以将CcoeControl认为是一个空的帐篷。通过继承这个类，可以创建各种各样的自定义控件，自定义控件的功能和复杂性只受到程序员能力和想象力的限制。这种灵活性的唯一不利之处是，控件确实类似于一个空帐篷，因为需要进行许多编码工作来提供重要的功能。 在处理视图切换方面，AppUi负责处理用户发出的视图切换请求。随后，AppUi最终的行为类似于一个巨大的开关，用于根据用户或系统的输入来激活或禁止容器。 注意：Container类从CcoeControl派生而来，CcoeControl是所有控件的基类。 在自己的容器类中必须实现从CcoeControl中的四个方法，框架将调用所有这些方法： l SizeChanged（）允许控件响应控件大小的改变 l Draw（）绘制控件 l CountComponentControls（）返回控件拥有的控件数量 l ComponentControl（）对于容器拥有的每一个控件，框架调用该方法获取。 在AppUi类中按照如下代码构造容器： void ChelloWorldAppUi:::Control() { BaseControlL(); IAppContainer=ChelloWorldContainer::NewL(ClientRect()); IAppContainer-&gt;SetMopParent(this); //在控件之间建立父子关系，在容器上调用此方法。 AddToStackL(iAppContainer); //将Container推入到控件栈顶，例如可以接收键事件 } 注意：如果使用这种架构实现带有多个视图的应用程序，则通过使用AddToStackL（）和RemoveFromStackL（）在不同的容器之间切换。
- #30: 它不同于传统Symbian OS框架的是，它拥有的控件直接从对话框类家族继承而来。 若把对话框结构用于主视图，建议将它作为非模式对话框运行。 对话框的主要优点是：方便地进行数据的显示、输入和编辑；与直接从CCoeControl继承相比，大大减少了工作量；自动管理子控件的布局；内容和布局可以在资源文件中定义，无需重新编译任何C++代码。 在AppUi类中完成构造和运行： void CsimpleDlgAppUi::ConstructL() { BaseConstructL(); IAppDialog=new(ELeave) CsimpleDlgDialog; IAppDialog-&gt;SetMopParent(this); IAppDialog-&gt;ExecuteLD(R_SIMPLEDLG_DIALOG); AddToStackL(iAppDialog); } 因为对话框是无模式的，ExecuteLD()将在调用后立刻返回。必须使用AddToStackL()将对话框添加到控件栈中，因为无模式的对话框无法自己完成这项工作。 还有，必须在AppUi的析构函数中销毁该对话框： CsimpleDlgAppUi::~CsimpleDlgAppUi() { if(iAppDialog) { RemoveFromStack(iAppDialog); delete iAppDialog; } }
- #31: 特点：在AppUi和Container之间，增加了一个新类，该类继承自CAknView。AppUi的父类是CAknViewAppUi而非先前的CAknAppUi。因为（CAknView和CAknViewAppUi）功能相互补充。 在前面两个框架中，AppUi直接负责视图间的切换，它必须管理视图控件的实例化、销毁和显示。而基于CAknView的类却可以大大分担AppUi这些工作。AppUi仍然负责视图间切换。但是不必先删除旧Container，后实例化新Container。AppUi仅需调用如ActiveViewL()触发向视图服务器提出视图的请求。视图服务器通过调用继承自CAknView的视图类的激活/去激活成员函数来实现这些切换过程。 第一层：CBase和CActive两个基类，其中CActive也是派生于CBase，而CActive又被第二层的CConEnv派生 第二层：包含两个基本组件：AppArc和CONE。AppArc代表“应用程序架构”，这些类提供了基本的应用程序结构、将系统信息提交到应用程序的机制，以及使用文件服务器持久化数据。其中的类在命名时都带有前缀“*Apa”。CONE是控制环境的缩写，在这个组件中的类提供用于处理用户输入并创建用户界面的机制－－这些类主要用于和窗口服务器进行交互，其中的类在命名时都带有前缀“*Coe”。这一层中的许多类都是抽象类，仅仅定义了一个API的接口。 第三层：Uikon组件。这是具有丰富功能、非抽象框架类的一般性设备无关实现，并且提供了一个在所有symbian OS上公用的UI库层。一些具体的UI控件（比如列表框和滚动条等）都可以在该层创建，这些控件有时也被称为Eikon控件。Uikon组件中的类在命名时都带有前缀“*Eik”。添加了一个公共的Symbian OS实现，和其他Symbian OS UI平台共享。 第四层：由Avkon类组成，这些类提供了核心的S60 UI功能，例如菜单支持。Avkon控件的类在命名时都带有前缀“*Akn”。在框架上添加S60特有的实现。 第五层：针对应用程序的层，设计自己的应用程序，添加自定义应用程序实现。
- #32: 循环导航路径： 对话框体系结构的屏幕导航必须遵循的规则：当沿着层次向下导航后(如从1a到3a)，必须按原路(从3a到1a)返回。因此，从1a到3a再到1b的导航是被禁止的。这是因为，如果这条导航被允许，则会造成一个大的导航循环。每次循环(1a-&gt;3a-&gt;1b-&gt;1a)会实例化两个对话框对象(从1a到3a时，对话框1创建对话框3的实例。从1b返回时，对话框3又创建了对话框1的实例)，在内存中这两个对象将同时存在。因此，除了逻辑上的混乱外，对节约内存资源来说，这种情况也是应该力图避免的。