一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

弹窗的控制方法、装置、电子设备及计算机可读介质与流程

2022-10-26 07:01:46 来源:中国专利 TAG:


1.本公开涉及消息处理技术领域,具体而言,涉及一种弹窗的控制方法、弹窗的控制装置、电子设备及计算机可读介质。


背景技术:

2.弹窗作为一种常见的信息展示方式,相比于横幅等其他方式,更能突出重点,因此在各类软件中被广泛使用。
3.目前弹窗下发主要有两种形式,同步下发方式和异步下发方式,两种方式都存在一些局限和缺点。同步下发方式只有在客户端主动发起请求的情况下才能进行,而异步下发方式当用户不在线时会下发失败,出现数据丢失的情况,触达率较低。
4.鉴于此,本领域亟需一种弹窗的控制方法,能够解决异步下发方式中数据丢失的问题和触达率较低的问题。
5.需要说明的是,在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素:

6.本公开的目的在于提供一种弹窗的控制方法、弹窗的控制装置、电子设备及计算机可读介质,进而至少在一定程度上确保弹窗数据不会丢失,并提升弹窗的触达率。
7.根据本公开的第一个方面,提供一种弹窗的控制方法,包括:
8.在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取所述弹窗消息对应的弹窗数据;
9.若弹窗下发的目标用户在线,则向所述目标用户的客户端下发所述弹窗数据,并向所述弹窗消息队列返回下发成功消息;
10.若所述目标用户不在线,则将所述弹窗数据重新存储在所述弹窗缓存中,并向所述弹窗消息队列返回下发失败消息,将所述弹窗消息重新投递在所述弹窗消息队中;
11.根据预设时间间隔重新获取下发失败的所述弹窗消息,并获取所述弹窗消息对应的弹窗数据,向所述目标用户的客户端重新进行弹窗数据的下发。
12.在本公开的一种示例性实施例中,所述方法还包括:
13.响应于所述目标用户上线时触发的弹窗请求指令,从所述弹窗缓存中获取所有未下发的弹窗数据,并将所有所述未下发的弹窗数据返回至所述目标用户的客户端。
14.在本公开的一种示例性实施例中,从所述弹窗缓存中获取所有未下发的弹窗数据之后,所述方法还包括:
15.将所有所述未下发的弹窗数据对应的缓存数据从所述弹窗缓存中删除。
16.在本公开的一种示例性实施例中,所述向所述目标用户的客户端下发所述弹窗数据,包括:
17.通过服务端与所述目标用户的客户端之间的长连接,向所述目标用户的客户端下
发所述弹窗数据。
18.在本公开的一种示例性实施例中,从弹窗缓存中获取所述弹窗消息对应的弹窗数据之后,所述方法还包括:
19.将所述弹窗数据对应的缓存数据从所述弹窗缓存中删除。
20.在本公开的一种示例性实施例中,所述方法还包括:
21.对所述弹窗缓存中存储的所述弹窗数据设置相应的预设过期时间。
22.根据本公开的第二方面,提供一种弹窗的控制装置,包括:
23.弹窗数据获取模块,被配置为执行在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取所述弹窗消息对应的弹窗数据;
24.弹窗数据下发模块,被配置为执行若弹窗下发的目标用户在线,则向所述目标用户的客户端下发所述弹窗数据,并向所述弹窗消息队列返回下发成功消息;
25.弹窗数据存储模块,被配置为执行若所述目标用户不在线,则将所述弹窗数据重新存储在所述弹窗缓存中,并向所述弹窗消息队列返回下发失败消息,将所述弹窗消息重新投递在所述弹窗消息队中;
26.弹窗消息重试模块,被配置为执行根据预设时间间隔重新获取下发失败的所述弹窗消息,并获取所述弹窗消息对应的弹窗数据,向所述目标用户的客户端重新进行弹窗数据的下发。
27.在本公开的一种示例性实施例中,所述弹窗的控制装置还包括:
28.弹窗请求触发模块,被配置为执行响应于所述目标用户上线时触发的弹窗请求指令,从所述弹窗缓存中获取所有未下发的弹窗数据,并将所有所述未下发的弹窗数据返回至所述目标用户的客户端。
29.在本公开的一种示例性实施例中,所述弹窗请求触发模块包括:
30.弹窗缓存同步删除单元,被配置为执行将所有所述未下发的弹窗数据对应的缓存数据从所述弹窗缓存中删除。
31.在本公开的一种示例性实施例中,所述弹窗数据下发模块包括:
32.长连接下发单元,被配置为执行通过服务端与所述目标用户的客户端之间的长连接,向所述目标用户的客户端下发所述弹窗数据。
33.在本公开的一种示例性实施例中,所述弹窗数据获取模块包括:
34.弹窗缓存异步删除单元,被配置为执行将所述弹窗数据对应的缓存数据从所述弹窗缓存中删除。
35.在本公开的一种示例性实施例中,所述弹窗的控制装置还包括:
36.数据过期时间设置模块,被配置为执行对所述弹窗缓存中存储的所述弹窗数据设置相应的预设过期时间。
37.根据本公开的第三方面,提供一种电子设备,包括:处理器;用于存储所述处理器可执行指令的存储器;其中,所述处理器被配置为执行所述指令,以实现上述任意一项所述的弹窗的控制方法。
38.根据本公开的第四方面,提供一种计算机可读存储介质,当所述计算机可读存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行上述任意一项所述的弹窗的控制方法。
39.根据本公开的第五方面,提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现上述任意一项所述的弹窗的控制方法。
40.本公开示例性实施例可以具有以下有益效果:
41.本公开示例实施方式的弹窗的控制方法中,在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据,并判断弹窗下发的目标用户是否在线,若在线,则直接向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息;若不在线,则将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中。与此同时,引入消息重试机制,根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。本公开示例实施方式中的弹窗的控制方法,一方面,在异步下发弹窗的流程中引入了弹窗消息队列和弹窗缓存机制,能够在弹窗下发失败时将弹窗数据重新进行存储,确保下发失败的弹窗数据不会丢失;另一方面,通过引入消息重试机制保证了弹窗的高触达率,在缓存数据不过期,且用户会重新上线的情况下,理论上可以达到百分之百的触达率。
42.应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
43.此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
44.图1示出了可以应用本公开实施例的一种弹窗的控制方法及装置的示例性系统架构的示意图;
45.图2示出了本公开的一个相关实施例中弹窗的同步下发方式的流程示意图;
46.图3示出了本公开的另一相关实施例中弹窗的异步下发方式的流程示意图;
47.图4示出了本公开示例实施方式的弹窗的控制方法的流程示意图;
48.图5示出了本公开的一个具体实施方式中弹窗的控制方法的流程示意图;
49.图6示出了本公开示例实施方式的弹窗的控制装置的框图;
50.图7示出了适于用来实现本公开实施方式的电子设备的计算机系统的结构示意图。
具体实施方式
51.为了使本领域普通人员更好地理解本公开的技术方案,下面将结合附图,对本公开实施例中的技术方案进行清楚、完整地描述。
52.需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
53.以下示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中,提供许多具体细节从而给出对本公开的实施方式的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而省略所述特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
54.此外,附图仅为本公开的示意性图解,并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
55.图1示出了可以应用本发明实施例的一种弹窗的控制方法及装置的示例性应用环境的系统架构的示意图。
56.如图1所示,系统架构100可以包括客户端101、102、103中的多个,网络104和服务端105。网络104用以在客户端101、102、103和服务端105之间提供通信链路的介质。网络104可以包括各种连接类型,例如无线通信链路等。
57.应该理解,图1中的客户端、网络和服务端的数目仅仅是示意性的。根据实现需要,可以具有任意数目的客户端、网络和服务端。比如服务端105可以是多个服务端组成的服务端集群等。
58.客户端101、102、103可以是具有处理器的各种电子设备,包括但不限于智能手机、平板电脑、便携式计算机等等。服务端105可以是提供各种服务的服务端。例如客户端101、102、103可以通过处理器在目标用户上线时触发弹窗请求指令,并根据服务端105返回的弹窗数据展示弹窗。服务端105可以在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据,当目标用户在线时,向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息;当目标用户不在线时,将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中。服务端105还可以根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。
59.在一些相关的实施例中,弹窗下发有两种方案,同步下发方式和异步下发方式。下面以活动场景中的奖励弹窗为例进行说明。
60.如图2所示是本公开的一个相关实施例中弹窗的同步下发方式的流程示意图。客户端完成任务后请求后端服务,服务端将弹窗数据封装在响应中返回给客户端,客户端拿到弹窗数据后进行展示。该流程图的具体步骤如下:
61.步骤s210.用户操作。
62.步骤s220.触发请求。
63.步骤s230.返回弹窗数据。
64.步骤s240.展示弹窗。
65.上述由客户端发送请求获取弹窗数据的同步下发方式,虽然触达率很高,但是只
有在客户端主动发起请求的情况下才能进行。然而,很多弹窗并不是用户的行为触发的,而是由服务端主动下发的,例如用户b给用户a助力的场景,又或者是其他外部事件引起的弹窗下发,这种同步下发方式就无法使用,因此适用范围比较局限。
66.如图3所示是本公开的另一相关实施例中弹窗的异步下发方式的流程示意图,弹窗事件产生后,服务端通过长连接向客户端下发弹窗信息。比如,用户a给用户b分享了助力二维码,用户b扫码给用户a助力后,触发了弹窗事件,此时服务端查找出用户a的长连接,给用户a下发长连接弹窗。该流程图的具体步骤如下:
67.步骤s310.用户b扫码。
68.步骤s320.发起助力请求。
69.步骤s330.助力成功。
70.步骤s340.返回助力完成消息。
71.步骤s350.下发弹窗。
72.步骤s360.查找客户端长连接下发弹窗。
73.步骤s370.展示弹窗。
74.上述弹窗的异步下发方式虽然能够让服务端主动下发弹窗,但是只能对用户在线的情况生效,如果用户不在线,则弹窗无法下发,且弹窗数据丢失,触达率低。
75.针对弹窗的异步下发方式中下发弹窗的触达率低,并且出现数据丢失的情况,本示例实施方式首先提供了一种弹窗的控制方法。参考图4所示,上述弹窗的控制方法可以包括以下步骤:
76.步骤s410.在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据。
77.步骤s420.若弹窗下发的目标用户在线,则向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息。
78.步骤s430.若目标用户不在线,则将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中。
79.步骤s440.根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。
80.本公开示例实施方式的弹窗的控制方法中,在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据,并判断弹窗下发的目标用户是否在线,若在线,则直接向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息;若不在线,则将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中。与此同时,引入消息重试机制,根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。本公开示例实施方式中的弹窗的控制方法,一方面,在异步下发弹窗的流程中引入了弹窗消息队列和弹窗缓存机制,能够在弹窗下发失败时将弹窗数据重新进行存储,确保下发失败的弹窗数据不会丢失;另一方面,通过引入消息重试机制保证了弹窗的高触达率,在缓存数据不过期,且用户会重新上线的情况下,理论上可以达到百分之百的触达率。
81.接下来结合图5对本示例实施方式的上述步骤进行更加详细的说明。
82.在步骤s410中,在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据。
83.本示例实施方式中,弹窗数据指的是生成弹窗所需的数据,弹窗消息是用于通知弹窗下发服务可以下发弹窗的消息,每个弹窗消息对应一组弹窗数据。
84.首先,弹窗数据产生时,弹窗数据会被存储在弹窗缓存中,而弹窗消息则存储在弹窗消息队列中。以用户b给用户a助力场景为例,用户b助力成功以后,弹窗数据就产生了,此时需要给用户a下发弹窗。助力服务会将弹窗数据存储到弹窗缓存中,同时发送一个弹窗消息到弹窗消息队列中,以通知弹窗下发服务可以下发弹窗了。
85.当弹窗事件产生时,服务端会通过弹窗下发服务从弹窗消息队列中获取弹窗消息。其中,服务端(消费者)获取队列中生产者发送的信息的行为被称为消费。弹窗下发服务消费到弹窗消息时,会从弹窗缓存中获取弹窗消息对应的弹窗数据。如果弹窗消息对应的弹窗数据不存在,则不做任何动作,弹窗消息直接消费成功。通过将弹窗消息和弹窗数据区分开,并且将弹窗数据缓存下来,能够保证弹窗数据不会丢失,有效提高了弹窗的触达率。
86.本示例实施方式中,在从弹窗缓存中获取弹窗消息对应的弹窗数据之后,还需要将弹窗数据对应的缓存数据从弹窗缓存中删除。通过采用数据消耗的方式对缓存中的弹窗数据进行读取,能够保证弹窗不会重复下发。
87.在步骤s420中,若弹窗下发的目标用户在线,则向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息。
88.获取待下发的弹窗数据以后,服务端判断弹窗下发的目标用户是否在线,若目标用户在线,则直接向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息。
89.本示例实施方式中,可以通过查找服务端与目标用户的客户端之间的长连接来判断目标用户是否在线,并通过服务端与目标用户的客户端之间的长连接,向目标用户的客户端下发弹窗数据。下发成功以后,提交弹窗消息消费成功。
90.在步骤s430中,若目标用户不在线,则将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中。
91.本示例实施方式中,如果找不到目标用户客户端的长连接消息,则表示目标用户不在线,此时弹窗下发服务会将弹窗数据重新存储到弹窗缓存中,同时返回下发失败消息,并将弹窗消息重新投递,以便后续重试。
92.在步骤s440中,根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。
93.本示例实施方式中,可以引入消息重试机制,根据预设时间间隔从弹窗消息队中重新获取之前下发失败的弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据,然后向目标用户的客户端重新进行弹窗数据的下发。基于消息重试机制,仅通过长连接方式下发就可以保证弹窗触达率达到百分之百。
94.但是一般场景中,为了保证性能,消息重试机制的频率不会很高,这样就导致了用户重新上线以后可能需要较长时间才能收到长连接下发的弹窗。为了保证用户有更好的使用体验,本示例实施方式中还可以引入同步下发的方式,在用户上线时就发起一次请求,及时拉取到弹窗。
95.本示例实施方式中,可以响应于目标用户上线时触发的弹窗请求指令,从弹窗缓存中获取所有未下发的弹窗数据,并将所有未下发的弹窗数据返回至目标用户的客户端。
96.用户重新上线时,客户端会主动请求一次弹窗信息,然后后端服务会从弹窗缓存中读取所有未下发的弹窗数据,并将弹窗数据通过响应返回给客户端。通过在异步下发弹窗的基础上引入了同步下发方式,能够在用户重新上线的第一时间向用户展示出所有未下发的弹窗,使用户拥有良好的交互体验。
97.本示例实施方式中,在从弹窗缓存中获取所有未下发的弹窗数据之后,还需要将所有未下发的弹窗数据对应的缓存数据从弹窗缓存中删除。
98.对于同步下发和异步下发两种方式,弹窗缓存中弹窗数据的读取都采用消耗方式,两种弹窗下发机制互斥,一个弹窗只会通过其中一种方式下发成功。比如弹窗数据通过异步方式下发成功,那么用户重新上线发出请求后,服务端就拉取不到弹窗数据了,就不会重复下发。又或者弹窗数据通过同步方式下发成功了,弹窗下发服务在消费弹窗消息时,也拉取不到对应的弹窗数据,这个时候会直接提交消息,当做消费成功,弹窗数据也不会重新下发。
99.除此之外,本示例实施方式中的方法还可以支持弹窗过期功能,对弹窗缓存中存储的弹窗数据设置相应的预设过期时间。如果在实际业务中想要忽略太久未下发的弹窗,在存储弹窗数据时,设置一个过期时间即可。通过将时间较长的弹窗数据删除掉,可以节省弹窗缓存的内存占用。
100.如图5所示是本公开的一个具体实施方式中弹窗的控制方法的完整流程图,是对本示例实施方式中的上述步骤的举例说明,应用场景为用户助力场景,该流程图的具体步骤如下:
101.步骤s502.用户b扫码。
102.步骤s504.助力请求。
103.步骤s506.存储弹窗数据。
104.步骤s508.发送弹窗消息。
105.步骤s510.助力成功。
106.步骤s512.返回助力完成消息。
107.接下来,步骤s514至步骤s530为异步下发流程。
108.步骤s514.消费弹窗消息。
109.步骤s516.读取弹窗数据。
110.步骤s518.返回弹窗数据。
111.步骤s520.查找客户端长连接。
112.通过查找客户端长连接判断用户是否在线,若用户在线,则进入步骤s522;若用户不在线,则进入步骤s528。
113.步骤s522.通过长连接下发弹窗。
114.步骤s524.展示弹窗。
115.步骤s526.消费弹窗消息成功。
116.步骤s528.重新存储弹窗数据。
117.步骤s530.消费弹窗消息失败,重新投递。
118.接下来,步骤s532至步骤s542为同步下发流程。
119.步骤s532.用户重新上线。
120.步骤s534.触发请求。
121.步骤s536.读取弹窗数据。
122.步骤s538.获取弹窗数据。
123.步骤s540.返回弹窗数据。
124.步骤s542.展示弹窗。
125.应当注意,尽管在附图中以特定顺序描述了本公开中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
126.需要说明的是,本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等),均为经用户授权或者经过各方充分授权的信息。
127.进一步的,本公开还提供了一种弹窗的控制装置。参考图6所示,该弹窗的控制装置可以包括弹窗数据获取模块610、弹窗数据下发模块620、弹窗数据存储模块630以及弹窗消息重试模块640。其中:
128.弹窗数据获取模块610被配置为在弹窗事件产生时,通过弹窗下发服务从弹窗消息队列中获取弹窗消息,并从弹窗缓存中获取弹窗消息对应的弹窗数据;
129.弹窗数据下发模块620被配置为若弹窗下发的目标用户在线,则向目标用户的客户端下发弹窗数据,并向弹窗消息队列返回下发成功消息;
130.弹窗数据存储模块630被配置为若目标用户不在线,则将弹窗数据重新存储在弹窗缓存中,并向弹窗消息队列返回下发失败消息,将弹窗消息重新投递在弹窗消息队中;
131.弹窗消息重试模块640被配置为根据预设时间间隔重新获取下发失败的弹窗消息,并获取弹窗消息对应的弹窗数据,向目标用户的客户端重新进行弹窗数据的下发。
132.在本公开的一些示例性实施例中,本公开提供的一种弹窗的控制装置还可以包括弹窗请求触发模块,被配置为响应于目标用户上线时触发的弹窗请求指令,从弹窗缓存中获取所有未下发的弹窗数据,并将所有未下发的弹窗数据返回至目标用户的客户端。
133.在本公开的一些示例性实施例中,弹窗请求触发模块可以包括弹窗缓存同步删除单元,被配置为将所有未下发的弹窗数据对应的缓存数据从弹窗缓存中删除。
134.在本公开的一些示例性实施例中,弹窗数据下发模块620可以包括长连接下发单元,被配置为通过服务端与目标用户的客户端之间的长连接,向目标用户的客户端下发弹窗数据。
135.在本公开的一些示例性实施例中,弹窗数据获取模块610可以包括弹窗缓存异步删除单元,被配置为将弹窗数据对应的缓存数据从弹窗缓存中删除。
136.在本公开的一些示例性实施例中,本公开提供的一种弹窗的控制装置还可以包括数据过期时间设置模块,被配置为对弹窗缓存中存储的弹窗数据设置相应的预设过期时间。
137.上述弹窗的控制装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明,此处不再赘述。
138.图7示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
139.需要说明的是,图7示出的电子设备的计算机系统700仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
140.如图7所示,计算机系统700包括中央处理单元(cpu)701,其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram 703中,还存储有系统操作所需的各种程序和数据。cpu 701、rom 702以及ram 703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。
141.以下部件连接至i/o接口705:包括键盘、鼠标等的输入部分706;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707;包括硬盘等的存储部分708;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器710上,以便于从其上读出的计算机程序根据需要被安装入存储部分708。
142.特别地,根据本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分709从网络上被下载和安装,和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时,执行本技术的系统中限定的各种功能。
143.需要说明的是,本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、rf等等,或者上述的任意合适的组合。
144.附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所
标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
145.作为另一方面,本技术还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现如上述实施例中所述的方法。
146.应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之,上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。
147.本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。
148.应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
再多了解一些

本文用于创业者技术爱好者查询,仅供学习研究,如用于商业用途,请联系技术所有人。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献