多软件包管理方法及装置与流程

1.本发明涉及软件包管理技术领域，尤指一种多软件包管理方法及装置。


背景技术：

2.随着技术的发展，出现了多包管理概念。一个代码库通常会把自己的功能分拆为核心部分和其他部分，其中每个部分是发布为一个npm软件包。软件包使用者通常在引用使用核心软件包后，可以自己选择要使用哪些其他的软件包。随着项目逐渐复杂，多包管理变得复杂，尤其是管理项目依赖和软件包发布。在依赖管理方面，因为npm只识别根目录的package.json文件，因此安装依赖时就必须进入每个软件包进行安装依赖。而发布软件包时，也必须逐个修改每个包的版本号，并到每个目录中进行发布到npm仓库；并且引用的这个软件包(假设软件包1)的软件包(假设软件包2)也得手动更改软件包1的版本。
3.为了解决这些问题，开源社区出现了lerna的工具，用来管理管理所有的包。但是lerna在依赖管理方便做的依然不好，具体表现在依赖的安装比较占用磁盘资源；内部依赖的关联不易处理。另外lerna没有涉及到整体项目工程中的编译管理、提交管理和日志管理等软件开发过程。


技术实现要素：

4.本发明实施例的主要目的在于提供一种多软件包管理方法及装置，实现多软件包依赖关系的高效管理，日志提交更加规范，简化前端工程管理复杂程度。
5.为了实现上述目的，本发明实施例提供一种多软件包管理方法，所述方法包括：
6.确定软件工程项目中多个软件包的依赖关系，并根据所述依赖关系获取各软件包依赖的依赖包；
7.根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下，得到项目工程目录；
8.对软件工程进行编译及运行，将编译及运行后的软件工程提交至服务器，并生成符合预设规范的日志文件；其中，所述软件工程是利用所述项目工程目录以及日志插件得到的。
9.可选的，在本发明一实施例中，所述依赖关系包括：根目录依赖、单个软件包依赖、内部依赖及外部依赖；其中，所述根目录依赖为依赖包被所有软件包依赖的依赖关系。
10.可选的，在本发明一实施例中，所述根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下包括：若获知依赖包与软件包的依赖关系为根目录依赖，则将依赖包安装至软件工程项目根目录下；若获知依赖包与软件包的依赖关系为单个软件包依赖，则将依赖包安装至对应的软件包目录下。
11.可选的，在本发明一实施例中，所述对软件工程进行编译包括：利用webpack工具，将软件工程中各软件包的代码从高版本编译到低版本。
12.可选的，在本发明一实施例中，所述对软件工程进行编译及运行，将编译及运行后
的软件工程提交至服务器，并生成符合预设规范的日志文件包括：运行编译后的软件工程，将运行后的软件工程提交至服务器，并利用已配置的日志插件，生成符合预设规范的日志文件。
13.本发明实施例还提供一种多软件包管理装置，所述装置包括：
14.依赖关系模块，用于确定软件工程项目中多个软件包的依赖关系，并根据所述依赖关系获取各软件包依赖的依赖包；
15.项目工程目录模块，用于根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下，得到项目工程目录；
16.工程编译模块，用于对软件工程进行编译及运行，将编译及运行后的软件工程提交至服务器，并生成符合预设规范的日志文件；其中，所述软件工程是利用所述项目工程目录以及日志插件得到的。
17.可选的，在本发明一实施例中，所述依赖关系包括：根目录依赖、单个软件包依赖、内部依赖及外部依赖；其中，所述根目录依赖为依赖包被所有软件包依赖的依赖关系。
18.可选的，在本发明一实施例中，所述项目工程目录模块包括：根目录单元，用于若获知依赖包与软件包的依赖关系为根目录依赖，则将依赖包安装至软件工程项目根目录下；软件包目录单元，用于若获知依赖包与软件包的依赖关系为单个软件包依赖，则将依赖包安装至对应的软件包目录下。
19.可选的，在本发明一实施例中，所述工程编译模块还用于利用webpack工具，将软件工程中各软件包的代码从高版本编译到低版本。
20.可选的，在本发明一实施例中，所述工程编译模块还用于运行编译后的软件工程，将运行后的软件工程提交至服务器，并利用已配置的日志插件，生成符合预设规范的日志文件。
21.本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法。
22.本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述方法的计算机程序。
23.本发明通过对软件工程项目中多个软件包的依赖管理、编译管理以及日志提交管理，大大就简化了大型前端工程管理复杂程度，工程开箱即用，日志提交更加规范，代码回退更加便捷，提高了开发效率。
附图说明
24.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
25.图1为本发明实施例一种多软件包管理方法的流程图；
26.图2a及图2b为利用lerna初始化的项目工程目录及版本更新示意图；
27.图3为本发明实施例中项目工程目录的版本更新示意图；
28.图4为利用lerna安装依赖包后的项目工程目录示意图；
29.图5为本发明实施例中依赖包安装流程图；
30.图6为本发明实施例中依赖包安装后根目录示意图；
31.图7为本发明实施例中安装依赖包后的项目工程目录示意图；
32.图8a及图8b为本发明实施例中javascript文件及typescript文件的编译流程图；
33.图9为本发明实施例中提交管理流程图；
34.图10为本发明实施例中日志文件示意图；
35.图11为本发明实施例一种多软件包管理装置的结构示意图；
36.图12为本发明一实施例所提供的电子设备的结构示意图。
具体实施方式
37.本发明实施例提供一种多软件包管理方法及装置。
38.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
39.目前，代码管理工具主要有2种，分别是git和svn，其中svn是集中式的代码管理工具，即有个中心服务器存放代码；而git是分布式代码管理工具，没有中心服务器管理代码，代码仓库的每个成员都有完整代码库。现在软件企业一般使用git作为代码管理工具。
40.npm有2个概念，一是前端开发领域软件包仓库，即软件包存放的位置；二是npm也是一种命令行根据，可以管理软件包，包括安装软件包，发布软件包，更新软件包和删除软件包等操作。npm仓库上的代码通常是一个软件包，这个软件包会提供各种api功能，这种代码项目结构一般为如表1所示。
41.表1
[0042][0043]
其中，工程说明文件package.json目录结构核心如表2所示。
[0044]
表2
[0045][0046]
即代码代码主要在src目录下，代码的复用主要是文件级复用，即一个文件引用另外一个文件。但随着功能的复杂以及按需加载需求，把所有东西全部放到一个包中管理变得越来越复杂，不适应大型项目管理需求，因此出现了多个包管理的需求。
[0047]
一个代码库通常会把自己的功能分拆为核心部分和其他部分，其中每个部分是发布为一个npm软件包，这种代码结构一般如表3所示。
[0048]
表3
[0049]
[0050][0051]
本发明实施例提供的多软件包管理方法的执行主体包括但不限于计算机。如图1所示为本发明实施例一种多软件包管理方法的流程图，图中所示方法包括：
[0052]
步骤s1，确定软件工程项目中多个软件包的依赖关系，并根据所述依赖关系获取各软件包依赖的依赖包。
[0053]
其中，软件包(package)是软件设计思想之一是模块化思想，即不同功能的代码分别存放到不同的文件、类中，每个文件、类都是一个单一功能的模块。软件包是模块化思想一种体现，即将单一功能的代码划分为一个软件包，其他模块可以引用这个软件包，做到提高代码复用率，同时降低代码的维护成本。软件包依赖是指一个软件包的生效需要另外一个软件包作为基础。软件包依赖从运行时机上分为开发环境依赖(devdependencies)和生产环境依赖(dependencies)。开发环境依赖是指在项目软件开发时需要的软件包；生产环境依赖是指在项目真正运行时需要的软件包。软件包依赖从软件包所有者上分为外部依赖和内部依赖，其中，外部依赖是其他人开发和维护的软件包，内部依赖是开发者自己开发的软件包，是项目组内部开发使用的软件包。
[0054]
在本实施例中，软件工程项目中多个软件包的依赖关系可以采用现有依赖关系检测识别的技术进行确定，也可以通过人工确定软件包的依赖关系。确定软件包的依赖关系后，可根据依赖包属于全局环境软件包、生产环境软件包或开发环境软件包，采用不同渠道
去获取对应的依赖包。
[0055]
步骤s2，根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下，得到项目工程目录。
[0056]
其中，lerna是一种多个软件包管理工具，可以一次管理多个软件包，包括多个软件包的安装、软件包依赖管理、软件包发布到代码仓库。lerna工程的代码结构一般如表4所示，其中，每个package的结构如表5所示。
[0057]
表4
[0058][0059]
表5
[0060][0061][0062]
当开发者开发多包工程时，如工程包含一个核心包和多个辅助功能包。核心包一般会引用其他辅助功能包，即工程内部存在依赖关系(内部依赖)。使用lerna时需要需要lerna link指令来关联内部依赖包。内部依赖管理会复杂，尤其是在typescript软件包里，经常出现找不到内部依赖而导致项目报错的情况。lerna开源工具仅仅给出一个目录结构示例，各个软件包的工程化处理未实现，尤其是编译管理。但是在前端开发编译管理(如使用webpack或者rollup编译javascript和typescript代码)是必须的流程。
[0063]
使用lerna安装依赖到根目录时，需要特殊配置，即配置hoist属性，安装比较复杂。使用lerna初始化项目，默认情况下各个软件包都是使用相同的版本，即各个软件包的
版本相同，软件包的版本在根目录的lerna.json中体现，如"version":"0.0.0"。项目工程如图2a所示。若任何一个软件包代码更新，会导致其他软件包都更新，如packages
‑
1由版本1.0更新为1.1，则packages
‑
2、packages
‑
3和packages
‑
4的版本都会更新到1.1，即如图2b所示。图中标识为：lerna.json是多包管理配置文件，package.json是工程配置文件，package
‑
1等是指各个软件包，node
‑
module是软件依赖包
[0064]
在本实施例中，如图3所示，本发明采用软件包独立管理模式。这种管理模式开发者可以分别维护各个软件包的版本。若只有packages
‑
1代码内容发生了更新，则可以设置packages
‑
2，packages
‑
3和packages
‑
4的版本不做更新。这样做的好处是：各个版本包管理会更加精细化，每一个软件包的更新不会影响其他软件包的版本；最小化变更；多包的开发者和使用中可以清晰知道是哪个软件包做了更新，对工程项目管理更加全面。
[0065]
进一步的，lerna默认使用lerna bootstrap命令管理依赖。每一个软件包的依赖都默认安装在本软件包目录下(即node
‑
modules文件夹)，项目工程如图4所示。而本发明核心采用lerna工具管理软件包版本，但是使用yarn工具管理项目依赖。在安装项目依赖时，区分根目录依赖，单个软件包所需依赖，内部依赖，外部依赖。其中，外部依赖又分为开发环境依赖和生产环境依赖。此外，根目录依赖是安装到项目根目录，即各个软件包都需要的依赖，因此，这些软件包都安装到项目根目录下。单个软件包所需依赖是指仅此软件包需要的插件，其他软件包不需要，因此，这些软件包安装到对应软件包目录下。
[0066]
步骤s3，对软件工程进行编译及运行，将编译及运行后的软件工程提交至服务器，并生成符合预设规范的日志文件；其中，所述软件工程是利用所述项目工程目录以及日志插件得到的。
[0067]
其中，经过步骤s2得到的项目工程目录用以软件工程的开发。此外，在进行软件工程开发时，将日志插件安装至软件工程中。日志插件可以为例如commitizen插件，日志插件可以安装预设规范生成日志。
[0068]
进一步的，开发得到的软件工程需要进行编译。其中，编译过程为将javascript和typescript代码从高版本编译到低版本的过程，以兼容低版本浏览器。编译过程主要使用webpack工具，将各个软件包代码编译并输出可执行文件的过程。将编译运行后的软件工程，利用日志插件，按照提交规范提交至服务器。
[0069]
作为本发明的一个实施例，所述依赖关系包括：根目录依赖、单个软件包依赖、内部依赖及外部依赖；其中，所述根目录依赖为依赖包被所有软件包依赖的依赖关系。
[0070]
在本实施例中，所述根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下包括：
[0071]
若获知依赖包与软件包的依赖关系为根目录依赖，则将依赖包安装至软件工程项目根目录下；
[0072]
若获知依赖包与软件包的依赖关系为单个软件包依赖，则将依赖包安装至对应的软件包目录下。
[0073]
其中，如图5所示为依赖包安装流程图。在安装项目依赖时，区分根目录依赖，单个软件包所需依赖，内部依赖，外部依赖，其中外部依赖又分为开发环境依赖和生产环境依赖。根目录依赖是安装到项目根目录，即各个软件包都需要的依赖，如javascript和typescript编译需要的babel插件，webpack插件，代码规范插件eslint，提交管理相关插件
commitizen、conventional
‑
changelog
‑
cli、cz
‑
conventional
‑
changelog，lerna插件，typescript插件，因此，这些软件包都安装到项目根目录下。单个软件包所需依赖是指仅此软件包需要的插件，其他软件包不需要。如packages
‑
1需要日期处理函数dayjs插件，packages
‑
2，packages
‑
3和packages
‑
4不需要日期处理插件，则只需要给packages
‑
1安装dayjs软件包即可，此时dayjs会安装到packages
‑
1目录下的node
‑
modules中。此外，若依赖包被多个软件包依赖，此时这个依赖包的安装按照单个软件包依赖的情况进行处理。内部依赖是开发者内部开发用到的软件包，一般不对外发布，内部依赖一般以@字符开始。外部依赖，分为开发环境依赖和生产环境依赖。在安装内部依赖时，需要指定软件软件包的版本，如@test/pkg1@1.0.0，表示1.0.0版本的@test/pkg1。内部依赖会安装到根目录的node
‑
modules文件夹中，并且内部依赖都有软连接符号，如图6所示。安装完依赖的项目工程目录结构如图7所示。
[0074]
本发明的依赖管理过程具有的优势包括：
[0075]
(1)去掉重复依赖安装。分析依赖包的引用情况，若依赖包是各个软件包都需要的，安装依赖包到根目录即可，不需要安装到各个软件包，节省磁盘空间。若依赖包是部分软件包需要的，仅在相关软件包下安装依赖即可，此时软件包安装到部分软件包的文件夹下。
[0076]
(2)减少依赖嵌套层次和循环依赖。windows环境下依赖嵌套太深时，在删除依赖时会报错。
[0077]
(3)内部依赖关联管理更加方便。使用yarn指令安装依赖，安装依赖的同时将内部依赖完成关联，不再需要lerna link等额外指令。
[0078]
作为本发明的一个实施例，所述对软件工程进行编译包括：利用webpack工具，将软件工程中各软件包的代码从高版本编译到低版本。
[0079]
其中，代码编译是指将源代码编译为可以在运行在浏览器上的代码，包括javascript由高版本编译为低版本，以保证可以在低版本浏览器上兼容运行；代码编译也包括资源压缩，如图片压缩，javascript代码压缩，css代码压缩，图片合并等提升产品运行性能的操作。
[0080]
本发明编译过程为将javascript和typescript代码从高版本编译到低版本的过程，以兼容低版本浏览器。进一步的，javascript文件编译流程如图8a所示，具体包括：
[0081]
(1)入口文件是指各个软件包的入口文件，一般是index.js，也可以指定为其他文件。
[0082]
(2)输出选项可以配置文件名，输出文件路径，文件是否带hash值等。
[0083]
(3)插件配置主要有cleanwebpackplugin和friendlyerrorswebpackplugin，目的是删除上次打包文件和编译过程错误输出。
[0084]
(4)javascript文件编译配置，主要有编译的目录，编译选项(如编译到es3)。
[0085]
(5)编译文件扩展名的配置，如将扩展名为js和jsx的文件都可以编译。
[0086]
(6)编译环境的配置，编译环境主要分为开发环境，生产环境和其他环境(如测试环境)，在编译环境中主要配置devtool，devtool目的将源代码以某种形式编译到目标结果中，方便调试和定位问题，但是容易泄露源代码。在开发环境将devtool配置为source
‑
map(源代码也在编译到目标文件夹中)，生产环境配置为false(即源代码不会编译到目标文件
夹中)。这样的目的是开发时方便调试，同时在线上环境不会泄露源代码。
[0087]
此外，typescript文件整体编译流程如图8b所示，具体包括：
[0088]
(1)入口文件是指各个软件包的入口文件，一般是index.ts，也可以指定为其他文件。
[0089]
(2)输出选项可以配置文件名，输出文件路径，文件是否带hash值等。
[0090]
(3)插件配置主要有cleanwebpackplugin和friendlyerrorswebpackplugin，目的是删除上次打包文件和编译过程错误输出。
[0091]
(4)typescript文件编译配置，主要有编译的目录，编译选项。说明是本专利对typescript编译采用的babel
‑
loader以及@babel/preset
‑
typescript插件。传统的typescript编译都会使用ts
‑
loader，或者tsc编译。使用ts
‑
loader或者tsc编译时，都需要配置编译选项，并将编译选项写到tsconfig.json文件中，配置选项复杂繁琐，不容易配置。本发明采用"@babel/preset
‑
env"和"@babel/preset
‑
typescript"，不需要额外配置即可实现typescript编译。
[0092]
(5)编译文件扩展名的配置，如将扩展名为ts和tsx的文件都可以编译。
[0093]
(6)编译环境的配置，编译环境主要分为开发环境，生产环境和其他环境(如测试环境)，在编译环境中主要配置devtool，devtool目的将源代码以某种形式编译到目标结果中，方便调试和定位问题，但是容易泄露源代码。在开发环境将devtool配置为source
‑
map(源代码也在编译到目标文件夹中)，生产环境配置为false(即源代码不会编译到目标文件夹中)。这样的目的是开发时方便调试，同时在线上环境不会泄露源代码。
[0094]
在本实施例中，对软件工程进行编译及运行，将编译及运行后的软件工程提交至服务器，并生成符合预设规范的日志文件包括：运行编译后的软件工程，将运行后的软件工程提交至服务器，并利用已配置的日志插件，生成符合预设规范的日志文件。
[0095]
其中，在工程项目开发中当代码修改后，提交代码到代码仓库时一般使用git commit命令，但是git commit提交的内容没有任何规范约束，甚至不填写内容都行。这会导致很多问题，如查看版本日志，查看更新内容，问题定位，代码回退等方面都无从溯源。
[0096]
本发明日志的提交管理过程如图9所示，使用git提交代码内容时，开发者可以随意输入字符串，甚至不输入内容，即可以是空字符串。这样提交内容会非常不规范，版本变更内容无从查询，版本回退也无从考证。本发明使用相关提交插件，将提交信息规范化。提交管理主要流程为：
[0097]
(1)安装commitizen插件。当使用commitizen插件时，系统将提示开发者在提交时填写所有的必填字段，并按照一定格式即时反馈。使用commitizen插件的好处是不必等到commit命令执行时发现不符合提交内容时拒绝本次提交请求。选择提交类型，提交类型有如表6所示。
[0098]
表6
[0099]
提交类型说明feat新增一个功能fix修复问题docs修改文档style修改样式，如删除空格、删除分号
refactor代码重构，没有加新功能或者修复bugperf优化相关，比如提升性能、优化体验
[0100]
(2)配置scripts脚本来执行提交操作，如使用yarn git
‑
cz。需要说明的是，需要使用配置的脚本命令执行提交操作，不要使用传统的git commit命令，传统的git commit不会规范化提交的内容。
[0101]
(3)安装cz
‑
conventional
‑
changelog插件。cz
‑
conventional
‑
changelog插件默认会使用anagularjs的提交规范来格式化提交内容。
[0102]
(4)配置config.commitizen的路径信息为cz
‑
conventional
‑
changelog。
[0103]
在本实施例中，软件工程开发、编译并运行后，还需要进行发布管理。执行发布命令时，选择发布相应的版本，版本选项有：patch,minor,major,prepatch,preminor,premajor,custom prerelease,custom version。表7是各个选项的说明。
[0104]
表7
[0105][0106]
如表8所示选择一个版本发布。
[0107]
表8
[0108][0109]
如表9所示，对每一个软件包的版本进行选择，做到各个软件包精细化版本控制。
[0110]
表9
[0111][0112]
在本实施例中，根据提交管理过程中提交的规范化数据，使用conventional
‑
changelog
‑
cli插件生成日志文件，如图10所示。日志管理主要过程为：
[0113]
(1)安装conventional
‑
changelog
‑
cli插件。
[0114]
(2)配置conventional
‑
changelog
‑
cli插件，主要配置为：采用angular规范，日志
保存到changelog.md文件中，不覆盖之前的提交日志。
[0115]
(3)提取commit时"feature","fix","performance improvement"或者"breaking changes"的内容，写入到changelog.md文档。
[0116]
本发明的多软件包管理包括了多包管理、依赖管理，编译管理，提交管理、发布管理和日志管理6个方面。多软件包工程中依赖管理方案，包括外部依赖、内部依赖和依赖关联的管理。多软件包工程中javascript和typescript编译管理，极简化编译配置，尤其是typescript编译配置简单，开箱即用，降低typescript编译配置难度。多种工程结合提交管理和日志管理，代码版本日志管理更加规范，不再需要手写版本日志，提高开发效率；同时代码回退也更加方便，可以根据清晰的日志快速回退到相应版本。
[0117]
如图11所示为本发明实施例一种多软件包管理装置的结构示意图，图中所示装置包括：
[0118]
依赖关系模块10，用于确定软件工程项目中多个软件包的依赖关系，并根据所述依赖关系获取各软件包依赖的依赖包；
[0119]
项目工程目录模块20，用于根据所述依赖关系，将依赖包安装至软件工程项目根目录下或软件包目录下，得到项目工程目录；
[0120]
工程编译模块30，用于对软件工程进行编译及运行，将编译及运行后的软件工程提交至服务器，并生成符合预设规范的日志文件；其中，所述软件工程是利用所述项目工程目录以及日志插件得到的。
[0121]
作为本发明的一个实施例，所述依赖关系包括：根目录依赖、单个软件包依赖、内部依赖及外部依赖；其中，所述根目录依赖为依赖包被所有软件包依赖的依赖关系。
[0122]
在本实施例中，所述项目工程目录模块包括：
[0123]
根目录单元，用于若获知依赖包与软件包的依赖关系为根目录依赖，则将依赖包安装至软件工程项目根目录下；
[0124]
软件包目录单元，用于若获知依赖包与软件包的依赖关系为单个软件包依赖，则将依赖包安装至对应的软件包目录下。
[0125]
作为本发明的一个实施例，所述工程编译模块还用于利用webpack工具，将软件工程中各软件包的代码从高版本编译到低版本。
[0126]
在本实施例中，所述工程编译模块还用于运行编译后的软件工程，将运行后的软件工程提交至服务器，并利用已配置的日志插件，生成符合预设规范的日志文件。
[0127]
基于与上述一种多软件包管理方法相同的申请构思，本发明还提供了上述一种多软件包管理装置。由于该一种多软件包管理装置解决问题的原理与一种多软件包管理方法相似，因此该一种多软件包管理装置的实施可以参见一种多软件包管理方法的实施，重复之处不再赘述。
[0128]
本发明通过对软件工程项目中多个软件包的依赖管理、编译管理以及日志提交管理，大大就简化了大型前端工程管理复杂程度，日志提交更加规范，提高了开发效率。
[0129]
本发明通过对软件工程项目中多个软件包的依赖管理、编译管理以及日志提交管理，大大就简化了大型前端工程管理复杂程度，工程开箱即用，日志提交更加规范，代码回退更加便捷，提高了开发效率。
[0130]
本发明还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上
述方法的计算机程序。
[0131]
如图12所示，该电子设备600还可以包括：通信模块110、输入单元120、音频处理单元130、显示器160、电源170。值得注意的是，电子设备600也并不是必须要包括图12中所示的所有部件；此外，电子设备600还可以包括图12中没有示出的部件，可以参考现有技术。
[0132]
如图12所示，中央处理器100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器100接收输入并控制电子设备600的各个部件的操作。
[0133]
其中，存储器140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器100可执行该存储器140存储的该程序，以实现信息存储或处理等。
[0134]
输入单元120向中央处理器100提供输入。该输入单元120例如为按键或触摸输入装置。电源170用于向电子设备600提供电力。显示器160用于进行图像和文字等显示对象的显示。该显示器例如可为lcd显示器，但并不限于此。
[0135]
该存储器140可以是固态存储器，例如，只读存储器(rom)、随机存取存储器(ram)、sim卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为eprom等。存储器140还可以是某种其它类型的装置。存储器140包括缓冲存储器141(有时被称为缓冲器)。存储器140可以包括应用/功能存储部142，该应用/功能存储部142用于存储应用程序和功能程序或用于通过中央处理器100执行电子设备600的操作的流程。
[0136]
存储器140还可以包括数据存储部143，该数据存储部143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器140的驱动程序存储部144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。
[0137]
通信模块110即为经由天线111发送和接收信号的发送机/接收机110。通信模块(发送机/接收机)110耦合到中央处理器100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。
[0138]
基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)110还经由音频处理器130耦合到扬声器131和麦克风132，以经由扬声器131提供音频输出，并接收来自麦克风132的音频输入，从而实现通常的电信功能。音频处理器130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器130还耦合到中央处理器100，从而使得可以通过麦克风132能够在本机上录音，且使得可以通过扬声器131来播放本机上存储的声音。
[0139]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
[0140]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程
图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0141]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0142]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0143]
本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。