一种用户配置文件管理方法、装置、设备及计算机介质与流程

1.本技术涉及计算机技术领域，更具体地说，涉及一种用户配置文件管理方法、装置、设备及计算机介质。


背景技术：

2.在计算机中，用户配置文件(user profile)指的是在用户登录时定义系统加载所需环境的设置和文件的集合。随着通信技术的发展，用户配置文件的应用也越来越多样，比如在windows操作系统中，可以对用户配置文件进行漫游，此时在本机上生成指定域用户的用户配置文件之后，还会将其同步至cifs(common internet file system，公共互联网文件系统)共享网盘上，使得用户可以在多台主机上使用保持最后修改版本的用户配置文件。
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.若所述目标用户配置文件中存在所述预设用户注册表文件，则将所述预设用户注册表文件转储为临时hive文件，将所述临时hive文件上传至所述云端服务器。
35.优选的，所述获取目标设备中的目标用户配置文件，包括：
36.获取所述目标设备中的初始用户配置文件；
37.对所述初始用户配置文件进行过滤，得到所述目标用户配置文件。
38.第二方面，本技术提供一种用户配置文件管理方法，应用于云端服务器，包括：
39.获取客户端发送的目标用户配置文件的预设信息；
40.判断自身是否第一次接收所述预设信息；
41.若自身第一次接收所述预设信息，则发送上传指令至所述客户端，并接收所述客户端接收到所述上传指令后、上传的所述目标用户配置文件进行备份；
42.其中，所述预设信息包括所述客户端判定对目标设备中的所述目标用户配置文件进行备份后发送的信息，且所述预设信息用于表征所述目标用户配置文件的特征信息。
43.第三方面，本技术提供一种用户配置文件管理装置，应用于客户端，包括：
44.用户配置文件获取模块，用于获取目标设备中的目标用户配置文件；
45.备份判断模块，用于判断是否对所述目标用户配置文件进行备份；若对所述目标用户配置文件进行备份，则发送所述目标用户配置文件的预设信息至云端服务器，所述预设信息用于表征所述目标用户配置文件的特征信息；
46.上传判断模块，用于判断是否接收到所述云端服务器发送的上传指令；若接收到所述上传指令，则上传所述目标用户配置文件至所述云端服务器进行备份；
47.其中，所述上传指令包括所述云端服务器判定自身第一次接收所述预设信息后发送的指令。
48.第四方面，本技术提供一种电子设备，包括：
49.存储器，用于存储计算机程序；
50.处理器，用于执行所述计算机程序时实现如上任一所述用户配置文件管理方法的步骤。
51.第五方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如上任一所述用户配置文件管理方法的步骤。
附图说明
52.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
53.图1为本技术实施例提供的用户配置文件管理方案的系统框架图；
54.图2为本技术实施例提供的一种用户配置文件管理方法的第一流程图；
55.图3为本技术实施例提供的一种用户配置文件管理方法的第二流程图；
56.图4为本技术实施例提供的一种用户配置文件管理方法的第三流程图；
57.图5为本技术实施例提供的一种用户配置文件管理装置的结构示意图；
58.图6为本技术实施例提供的一种用户配置文件管理装置的另一结构示意图
59.图7为本发明实施例电子设备的硬件组成结构示意图。
具体实施方式
60.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完
整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
61.本技术的用户配置文件管理方案中，采用的系统框架具体可以参见图1所示，具体可以包括：客户端01、与客户端01建立通信连接的目标设备02、与客户端01建立通信连接的云端服务器03。
62.本技术中，客户端01用于执行用户配置文件管理方法步骤，包括获取目标设备中的目标用户配置文件；判断是否对目标用户配置文件进行备份；若对目标用户配置文件进行备份，则发送目标用户配置文件的预设信息至云端服务器，预设信息用于表征目标用户配置文件的特征信息；判断是否接收到云端服务器发送的上传指令；若接收到上传指令，则上传目标用户配置文件至云端服务器进行备份；其中，上传指令包括云端服务器判定自身第一次接收预设信息后发送的指令。
63.进一步的，客户端01中还可以设有用户配置文件数据库、预设信息数据库以及指令数据库。其中，用户配置文件数据库用于保存各种用户配置文件。预设信息数据库中具体可以用于保存用户配置文件的预设信息。指令数据库则可以用来保存接收到的上传指令。
64.需要说明的是，客户端、目标设备的类型均可以根据实际需要，且客户端与目标设备可以为同一设备，也可以为两个不同的设备等，比如客户端与目标设备均可以为用户的电脑，或者客户端为用户的手机，目标设备为用户的电脑等，本技术在此不做具体限定。
65.请参阅图2，图2为本技术实施例提供的一种用户配置文件管理方法的第一流程图。
66.本技术实施例提供的一种用户配置文件管理方法，应用于客户端，可以包括以下步骤：
67.步骤s101：获取目标设备中的目标用户配置文件。
68.实际应用中，可以先获取目标设备中的目标用户配置文件，目标用户配置文件的获取条件可以根据实际需要确定，比如可以实时获取，可以定时获取，也可以在用户有需求时再获取等，本技术在此不做具体限定。此外，目标设备的类型、目标用户配置文件的内容均可以根据实际需要确定，本技术在此也不做具体限定。
69.步骤s102：判断是否对目标用户配置文件进行备份；若对目标用户配置文件进行备份，则执行步骤s103。
70.步骤s103：发送目标用户配置文件的预设信息至云端服务器，预设信息用于表征所述目标用户配置文件的特征信息。
71.实际应用中，在获取目标用户配置文件之后，可以先判断是否对目标用户配置文件进行备份，若不对目标用户配置文件进行备份，则可以结束后续操作，若对目标用户配置文件进行备份，则可以发送目标用户配置文件的预设信息至云端服务器，且预设信息用于表征所述目标用户配置文件的特征信息，这样云端服务器接收到该预设信息后，可以基于预设信息判断是否需要接收该目标用户配置文件进行备份。
72.需要说明的是，判断是否对目标用户配置文件进行备份的条件可以根据具体应用场景来确定，比如可以设置各个备份时间节点，判断当前时间是否属于备份时间节点，若属于，则判定对目标用户配置文件进行备份，若不属于，则判定不对目标用户配置文件进行备
份等；当然，可以在用户配置文件发生修改时便进行相应备份，比如确定目标用户配置文件发生改动需进行备份的时刻，并在该时刻下开始对目标用户配置文件进行备份，可以理解的是，确定目标用户配置文件发生改动需进行备份的时刻的方式可以根据具体应用场景确定，比如在windows操作系统的目标设备中，可以借助readdirectorychanges(ex)api确定该时刻，在linux操作系统的目标设备中，可以使用inotifywatch机制确定该时刻，而在macos操作系统的目标设备中，则可以使用fsevents api确定该时刻等。此外，目标用户配置文件的预设信息也可以根据具体应用场景来确定，比如预设信息可以为目标用户配置文件的文件头64字节信息等。
73.步骤s104：判断是否接收到云端服务器发送的上传指令；若接收到上传指令，则执行步骤s105。
74.步骤s105：上传目标用户配置文件至云端服务器进行备份；其中，上传指令包括云端服务器判定自身第一次接收预设信息后发送的指令。
75.实际应用中，云端服务器接收到预设信息后，可以判断自身是否第一次接收该预设信息，具体的，可以判断预设信息是否与自身备份的用户配置文件一致，若预设信息与自身备份的用户配置文件一致，则表明目标用户配置文件已在云端服务器备份过，此时，云端服务器可以自行完成本次上传记录的后台处理，并返回客户端无需进行文件上传的指令以结束备份操作，若预设信息与自身备份的用户配置文件不一致，则表明目标用户配置信息未在云端服务器备份过，此时，云端服务器可以返回上传指令来接收目标用户配置文件进行备份。
76.需要说明的是，对目标设备中的各类用户配置文件进行备份后，云端服务器中会存在该各类用户配置文件，这样，用户在需要时，可以直接从云端服务器获取备份的用户配置文件进行应用，比如利用备份的用户配置文件对目标设备进行用户配置还原、查看、分析等。此外，客户端在超过预设时间未接收到上传指令的情况下，可以直接结束对目标用户配置文件的备份，当然也可以重新执行发送预设信息至云端服务器的步骤等，本技术在此不做具体限定。
77.本技术提供的一种用户配置文件管理方法，获取目标设备中的目标用户配置文件；判断是否对目标用户配置文件进行备份；若对目标用户配置文件进行备份，则发送目标用户配置文件的预设信息至云端服务器，预设信息用于表征所述目标用户配置文件的特征信息；判断是否接收到云端服务器发送的上传指令；若接收到上传指令，则上传目标用户配置文件至云端服务器进行备份；其中，上传指令包括云端服务器判定自身第一次接收预设信息后发送的指令。本技术中，可以在云端服务器对目标用户配置文件进行备份，使得用户可以借助备份的目标用户配置文件对所需的用户配置文件进行管理，提高了用户配置文件的应用灵活性；且云端服务器在第一次接收预设信息后才会发送上传指令来备份目标用户配置文件，避免了多次对相同用户配置文件进行备份，提高了备份效率。
78.请参阅图3，图3为本技术实施例提供的一种用户配置文件管理方法的第二流程图。
79.本技术实施例提供的一种用户配置文件管理方法，应用于客户端，可以包括以下步骤：
80.步骤s201：获取目标设备中的目标用户配置文件。
81.步骤s202：获取记录历史用户配置文件的属性信息的文件版本信息。
82.步骤s203：确定目标用户配置文件的文件属性信息。
83.步骤s204：判断文件属性信息是否属于文件版本信息；若文件属性信息不属于文件版本信息，则执行步骤s205。
84.实际应用中，如果用户配置文件发生变动或直接是新配置的文件时，需要对用户配置文件进行备份，而用户配置文件的属性信息可以反映用户配置文件自身的特性，且用户配置文件的该特性与已有用户配置文件的特性进行比较后可以反映该用户配置文件是否变动或新生成，所以可以借助用户配置文件的属性信息来判断是否对目标用户配置文件进行备份，在此过程中，需要实时记录已经备份的历史用户配置文件的属性信息，比如借助文件版本信息记录历史用户配置文件的属性信息，之后确定目标用户配置文件的文件属性信息；判断文件属性信息是否属于文件版本信息；若文件属性信息不属于文件版本信息，则判定对目标用户配置文件进行备份；若文件属性信息属于文件版本信息，则判定对目标用户配置文件不进行备份。
85.需要说明的是，用户配置文件的属性信息的类型可以根据实际需要确定，比如用户配置文件的属性信息可以包括：文件大小、修改时间、创建时间、哈希值信息、文件头部数据项等。
86.步骤s205：发送目标用户配置文件的预设信息至云端服务器，预设信息用于表征目标用户配置文件的特征信息。
87.步骤s206：判断是否接收到云端服务器发送的上传指令；若接收到上传指令，则执行步骤s207。
88.步骤s207：上传目标用户配置文件至云端服务器进行备份；其中，上传指令包括云端服务器判定自身第一次接收预设信息后发送的指令。
89.本技术实施例提供的一种用户配置文件管理方法中，考虑到目标设备的重启会对保存的数据造成影响，比如目标设备重启后需还原数据，此时目标设备中的文件版本信息会被相应还原掉，影响用户配置文件的备份，为了降低目标设备的重启对用户配置文件的备份影响，可以根据目标设备的重启特性对文件版本信息的存储位置进行选取，也即在获取记录历史用户配置文件的属性信息的文件版本信息之前，还可以判断目标设备重启后是否进行数据还原；若目标设备重启后不进行数据还原，则在用户配置文件根目录指定名字的隐藏目录中存储文件版本信息，此时，文件版本信息在目标设备重启后不会被还原；若目标设备重启后进行数据还原，则判断目标设备是否配置有非还原存储；若目标设备配置有非还原存储，则在非还原存储中存储文件版本信息，此时，文件版本信息在目标设备重启后也不会被还原；若目标设备未配置有非还原存储，则在隐藏目录中存储文件版本信息，此时，文件版本信息只能在本次开机运行过程中存留，文件版本信息在目标设备重启后仍会被还原，目标设备的所有用户配置文件均需进行备份，但因为云端服务器上传指令的限制，已备份的用户配置文件并不会在云端服务器再次备份，保证了备份的精简与准确，需要说明的时，此时文件版本信息可以存储在目标设备的任一位置。
90.实际应用中，在上传目标用户配置文件至云端服务器进行备份之后，为了避免后续再次对目标用户配置文件执行备份操作，可以将文件属性信息记录在文件版本信息中。
91.实际应用中，为了便于用户获知、应用目标用户配置文件的文件属性信息，也便于
云端服务器应用文件属性信息，客户端可以将文件属性信息放置在预设信息中一起发送给云端服务器，这样，用户可以通过该文件属性信息在云端服务器中对备份的用户配置文件进行管理等。
92.本技术实施例提供的一种用户配置文件管理方法中，在上传目标用户配置文件至云端服务器进行备份的过程中如果目标用户配置文件中存在被打开占用的用户注册表文件的话，该类用户注册表文件无法被上传到云端服务器，比如在windows操作系统的目标设备中，用户配置文件中的注册表文件ntuser.dat和usrclass.dat便会因被系统打开占用而无法上传至云端服务器，此时，为了保证该类注册表文件能够被云端服务器备份，可以判断目标用户配置文件中是否存在被打开占用的预设用户注册表文件；若目标用户配置文件中存在预设用户注册表文件，则将预设用户注册表文件转储为临时hive文件，比如通过注册表api regsavekey将预设用户注册表文件转储为临时hive文件，将临时hive文件上传至云端服务器，以代替上传该预设注册表文件。
93.本技术实施例提供的一种用户配置文件管理方法中，为了提高用户配置文件的备份效率，还可以对进行备份的用户配置文件进行过滤筛选，也即在获取目标设备中的目标用户配置文件的过程中，可以获取目标设备中的初始用户配置文件；对初始用户配置文件进行过滤，得到目标用户配置文件。
94.需要说明的是，对初始用户配置文件进行过滤的方式及条件可以根据具体应用场景确定，比如可以根据用户配置文件的扩展名、文件格式对用户配置文件进行过滤等，本技术在此不做具体限定。
95.请参阅图4，图4为本技术实施例提供的一种用户配置文件管理方法的第三流程图。
96.本技术实施例提供的一种用户配置文件管理方法，应用于云端服务器，可以包括以下步骤：
97.步骤s301：获取客户端发送的目标用户配置文件的预设信息。
98.步骤s302：判断自身是否第一次接收预设信息；若自身第一次接收预设信息，则执行步骤s303。
99.步骤s303：发送上传指令至客户端，并接收客户端接收到上传指令后、上传的目标用户配置文件进行备份；其中，预设信息包括客户端判定对目标设备中的目标用户配置文件进行备份后发送的信息，且预设信息用于表征目标用户配置文件的特征信息。
100.本实施例中的相应描述可以参阅上述相应实施例，在此不再赘述。
101.请参阅图5，图5为本技术实施例提供的一种用户配置文件管理装置的结构示意图。
102.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，可以包括：
103.用户配置文件获取模块101，用于获取目标设备中的目标用户配置文件；
104.备份判断模块102，用于判断是否对目标用户配置文件进行备份；若对目标用户配置文件进行备份，则发送目标用户配置文件的预设信息至云端服务器，预设信息用于表征目标用户配置文件的特征信息；
105.上传判断模块103，用于判断是否接收到云端服务器发送的上传指令；若接收到上传指令，则上传目标用户配置文件至云端服务器进行备份；
106.其中，上传指令包括云端服务器判定自身第一次接收预设信息后发送的指令。
107.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，备份判断模块还可以具体用于：若超过预设时间未接收到上传指令，则结束对目标用户配置文件的备份。
108.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，备份判断模块可以包括：
109.版本信息获取单元，用于获取记录历史用户配置文件的属性信息的文件版本信息；
110.属性信息确定单元，用于确定目标用户配置文件的文件属性信息；
111.备份判断单元，用于判断文件属性信息是否属于文件版本信息；若文件属性信息不属于文件版本信息，则判定对目标用户配置文件进行备份。
112.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，还可以包括：
113.重启还原判断单元，用于版本信息获取单元获取记录历史用户配置文件的属性信息的文件版本信息之前，判断目标设备重启后是否进行数据还原；若目标设备重启后不进行数据还原，则在用户配置文件根目录指定名字的隐藏目录中存储文件版本信息；若目标设备重启后进行数据还原，则判断目标设备是否配置有非还原存储；若目标设备配置有非还原存储，则在非还原存储中存储文件版本信息；若目标设备未配置有非还原存储，则在隐藏目录中存储文件版本信息。
114.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，还可以包括：
115.记录单元，用于上传判断模块上传目标用户配置文件至云端服务器进行备份之后，将文件属性信息记录在文件版本信息中。
116.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，预设信息可以包括文件属性信息。
117.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，上传判断模块可以包括：
118.占用判断单元，用于判断目标用户配置文件中是否存在被打开占用的预设用户注册表文件；若目标用户配置文件中存在预设用户注册表文件，则将预设用户注册表文件转储为临时hive文件，将临时hive文件上传至云端服务器。
119.本技术实施例提供的一种用户配置文件管理装置，应用于客户端，用户配置文件获取模块可以包括：
120.用户配置文件获取单元，用于获取目标设备中的初始用户配置文件；
121.过滤单元，用于对初始用户配置文件进行过滤，得到目标用户配置文件。
122.请参阅图6，图6为本技术实施例提供的一种用户配置文件管理装置的另一结构示意图。
123.本技术实施例提供的一种用户配置文件管理装置，应用于云端服务器，可以包括：
124.预设信息获取模块201，用于获取客户端发送的目标用户配置文件的预设信息。
125.接收判断模块202，用于判断自身是否第一次接收预设信息；若自身第一次接收预设信息，则发送上传指令至客户端，并接收客户端接收到上传指令后、上传的目标用户配置文件进行备份；其中，预设信息包括客户端判定对目标设备中的目标用户配置文件进行备份后发送的信息，且预设信息用于表征目标用户配置文件的特征信息。
126.基于上述程序模块的硬件实现，且为了实现本发明实施例的方法，本发明实施例还提供了一种电子设备，图7为本发明实施例电子设备的硬件组成结构示意图，如图7所示，电子设备包括：
127.通信接口1，能够与其它设备比如网络设备等进行信息交互；
128.处理器2，与通信接口1连接，以实现与其它设备进行信息交互，用于运行计算机程序时，执行上述一个或多个技术方案提供的用户配置文件管理方法。而所述计算机程序存储在存储器3上。
129.当然，实际应用时，电子设备中的各个组件通过总线系统4耦合在一起。可理解，总线系统4用于实现这些组件之间的连接通信。总线系统4除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线系统4。
130.本发明实施例中的存储器3用于存储各种类型的数据以支持电子设备的操作。这些数据的示例包括：用于在电子设备上操作的任何计算机程序。
131.可以理解，存储器3可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(rom，read only memory)、可编程只读存储器(prom，programmable read
‑
only memory)、可擦除可编程只读存储器(eprom，erasable programmable read
‑
only memory)、电可擦除可编程只读存储器(eeprom，electrically erasable programmable read
‑
only memory)、磁性随机存取存储器(fram，ferromagnetic random access memory)、快闪存储器(flash memory)、磁表面存储器、光盘、或只读光盘(cd
‑
rom，compact disc read
‑
only memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(ram，random access memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(sram，static random access memory)、同步静态随机存取存储器(ssram，synchronous static random access memory)、动态随机存取存储器(dram，dynamic random access memory)、同步动态随机存取存储器(sdram，synchronous dynamic random access memory)、双倍数据速率同步动态随机存取存储器(ddrsdram，double data rate synchronous dynamic random access memory)、增强型同步动态随机存取存储器(esdram，enhanced synchronous dynamic random access memory)、同步连接动态随机存取存储器(sldram，synclink dynamic random access memory)、直接内存总线随机存取存储器(drram，direct rambus random access memory)。本发明实施例描述的存储器2旨在包括但不限于这些和任意其它适合类型的存储器。
132.上述本发明实施例揭示的方法可以应用于处理器2中，或者由处理器2实现。处理器2可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器2中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器2可以是通用处理器、dsp，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器2可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器3，处理器2读取存储器3中
的程序，结合其硬件完成前述方法的步骤。
133.处理器2执行所述程序时实现本发明实施例的各个方法中的相应流程，为了简洁，在此不再赘述。
134.在示例性实施例中，本发明实施例还提供了一种存储介质，即计算机存储介质，具体为计算机可读存储介质，例如包括存储计算机程序的存储器3，上述计算机程序可由处理器2执行，以完成前述方法所述步骤。计算机可读存储介质可以是fram、rom、prom、eprom、eeprom、flash memory、磁表面存储器、光盘、或cd
‑
rom等存储器。
135.在本技术所提供的几个实施例中，应该理解到，所揭露的装置、终端和方法，可以通过其它的方式实现。以上所描述的设备实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
136.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
137.另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
138.本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
139.或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
140.本技术实施例提供的用户配置文件管理系统、设备及计算机可读存储介质中相关部分的说明请参见本技术实施例提供的用户配置文件管理方法中对应部分的详细说明，在此不再赘述。另外，本技术实施例提供的上述技术方案中与现有技术中对应技术方案实现原理一致的部分并未详细说明，以免过多赘述。
141.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备
所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
142.对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。