基于状态标记的拉请求修订进度跟踪方法、装置和设备

1.本技术涉及计算机技术领域，特别是涉及一种基于状态标记的拉请求修订进度跟踪方法、装置和计算机设备。


背景技术：

2.拉请求（pull-request）已经成为开源社区中进行代码贡献的主要方式，为保证开源软件项目的质量，项目管理团队通常会对社区开发者提交的拉请求进行质量审查，而开发者会根据管理者的审查评论对拉请求进行修订和更新。由于开源社区的开放性和自组织性，项目管理团队中的任何成员以及社区中的任何开发者都能够对拉请进行评论，各种类型的拉请求混杂在一起，这给开发者快速识别出包含修订请求的审查评论带来了挑战。此外，当开发者每次完成修订动作，在历史评论列表中对照修订请求评论的内容来评估拉请求的修订进度，对管理者也是一个严峻的挑战。
3.在当前开源社区中，如github平台，对代码级评论支持“折叠”功能，即在展示拉请求的审查评论时，自动“折叠”已经被解决的代码评论，折叠的效果是不显示其具体文本内容，而只标记有一条已过期（outdated）的评论，其它感兴趣的用户可以点击展开被折叠的评论。但评论折叠这种方式对开发者快速识别出包含修订请求的审查评论以及管理者评估拉请求的修订进度作用有限。现有技术存在管理效率不高、适应性不佳的问题。


技术实现要素：

4.基于此，有必要针对上述技术问题，提供一种能够提高拉请求的管理效率的基于状态标记的拉请求修订进度跟踪方法、装置、计算机设备和存储介质。
5.一种基于状态标记的拉请求修订进度跟踪方法，所述方法包括：在开源平台下定义拉请求评论类型模型；其中，拉请求评论类型包括修订请求类评论和普通评论；定义拉请求修订状态模型；所述拉请求修订状态模型用于对拉请求的修订状态进行标记；其中，标记状态至少包括“未解决”、“解决中”和“已解决”三种；当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论；所述修订请求类评论中包含修订任务；通过所述拉请求修订状态模型，根据所述修订请求类评论中修订任务的完成情况，对所述修订请求类评论进行状态标记；获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据所述评论类型信息和所述状态标记信息对所述给定拉请求的评论进行分区显示。
6.在其中一个实施例中，还包括：当评论者提交对拉请求的评价时，弹出含有下拉选择项的组合式按钮；获取评论者在所述组合式按钮的选项信息，根据所述选项信息确定生成修订请求类评论或普通评论。
7.在其中一个实施例中，还包括：若评论者未明确选择评论的类型，通过基于历史评论标记数据训练得到的二分类模型对评论文本进行自动分类；若分类结果显示所述评论文本是修订请求类评论，通过平台的人机交互界面提醒项目管理者和拉请求的开发者进行确认；若获取到了确认信息，则自动将该评论设置为修订请求类评论，否则设置为普通评论。
8.在其中一个实施例中，还包括：当所述修订请求类评论中包含的修订任务不止一个时，以列表形式将所述修订任务逐一列出。
9.在其中一个实施例中，还包括：通过所述拉请求修订状态模型，根据所述修订请求类评论中修订任务的完成情况，对所述修订请求类评论进行状态标记；当所述修订请求类评论刚创建完成时，自动将所述修订请求类评论的状态标记为：“未解决”。
10.在其中一个实施例中，还包括：当所述修订请求类评论中包含的修订任务不止一个时，对修订任务列表中的每一项进行状态标记；根据每一项修订任务的状态标记信息，将所述修订请求类评论的状态标记为：“解决中：n/n”；其中，n表示已完成的修订任务个数；n表示所述修订请求类评论中包含的修订任务总数。
11.在其中一个实施例中，还包括：通过自动抽取拉请求的开发者更新的代码描述信息，计算所述代码描述信息与历史上所有未解决的修订请求类评论之间的文本相似度，当所述文本相似度与任一修订请求类评论的整体或者其中任一修订任务的相似度超过预设阈值时，通过人机交互界面提醒项目管理者、评论者以及拉请求的开发者判断最新的代码提交是否已经解决了所述修订请求类评论的整体或者其中任一修订任务；由项目管理者、评论者或者拉请求的开发者通过人机交互界面对修订任务列表中的每一项进行手动状态标记。
12.在其中一个实施例中，还包括：当所述修订请求类评论中包含的每个修订任务都完成时，自动将所述修订请求类评论的状态标记为：“已解决”。
13.在其中一个实施例中，还包括：获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息；将所有标记为“未解决”和“解决中”的修订请求类评论显示在第一页面；将所有标记为“已解决”的修订请求类评论和普通评论显示在第二页面。
14.一种基于状态标记的拉请求修订进度跟踪装置，所述装置包括：评论类型模型定义模块，用于在开源平台下定义拉请求评论类型模型；其中，拉请求评论类型包括修订请求类评论和普通评论；修订状态模型定义模块，用于定义拉请求修订状态模型；所述拉请求修订状态模型用于对拉请求的修订状态进行标记；其中，标记状态至少包括“未解决”、“解决中”和“已解决”三种；评论生成模块，用于当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论；所述修订请求类评论中包含修订任务；修订请求类评论状态标记模块，用于通过所述拉请求修订状态模型，根据所述修
订请求类评论中修订任务的执行情况，对所述修订请求类评论进行状态标记；分区显示模块，用于获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据所述评论类型信息和所述状态标记信息对所述给定拉请求的评论进行分区显示。
15.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：在开源平台下定义拉请求评论类型模型；其中，拉请求评论类型包括修订请求类评论和普通评论；定义拉请求修订状态模型；所述拉请求修订状态模型用于对拉请求的修订状态进行标记；其中，标记状态至少包括“未解决”、“解决中”和“已解决”三种；当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论；所述修订请求类评论中包含修订任务；通过所述拉请求修订状态模型，根据所述修订请求类评论中修订任务的完成情况，对所述修订请求类评论进行状态标记；获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据所述评论类型信息和所述状态标记信息对所述给定拉请求的评论进行分区显示。
16.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：在开源平台下定义拉请求评论类型模型；其中，拉请求评论类型包括修订请求类评论和普通评论；定义拉请求修订状态模型；所述拉请求修订状态模型用于对拉请求的修订状态进行标记；其中，标记状态至少包括“未解决”、“解决中”和“已解决”三种；当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论；所述修订请求类评论中包含修订任务；通过所述拉请求修订状态模型，根据所述修订请求类评论中修订任务的完成情况，对所述修订请求类评论进行状态标记；获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据所述评论类型信息和所述状态标记信息对所述给定拉请求的评论进行分区显示。
17.上述基于状态标记的拉请求修订进度跟踪方法、装置、计算机设备和存储介质，通过在开源平台下定义拉请求评论类型模型，将评论分为修订请求类评论和普通评论，能够将修订请求类的评论与普通的评论更加明显地区分开；评论者创建不同类型的评论后，通过定义的拉请求修订状态模型，根据修订请求类评论中修订任务的完成情况，对修订请求类评论进行状态标记，有利于清晰地表征修订请求的不同完成程度；最后根据评论类型信息和修订请求类评论的状态标记信息对给定拉请求的评论进行分区显示，使得开发者能够快速定位未完成的修订请求，并能够快速获取修订请求的进度信息。本发明通过高效地标记和跟踪拉请求的修订进度，有利于提高拉请求的管理效率，进而提高开源群体协同效率。
附图说明
18.图1为一个实施例中基于状态标记的拉请求修订进度跟踪方法的流程示意图；
图2为另一个实施例中基于状态标记的拉请求修订进度跟踪方法的流程示意图；图3为一个实施例中基于状态标记的拉请求修订进度跟踪装置的结构框图；图4为一个实施例中计算机设备的内部结构图。
具体实施方式
19.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
20.在一个实施例中，如图1所示，提供了一种基于状态标记的拉请求修订进度跟踪方法，包括以下步骤：步骤102，在开源平台下定义拉请求评论类型模型。
21.其中，拉请求评论类型包括修订请求类评论模型和普通评论。
22.本发明提出定义拉请求评论类型模型，将评论分为修订请求类评论和普通评论，将修订请求类的评论与普通的评论更加明显地区分开，能够更加细粒度地标记出评论的状态和修订进度。
23.修订请求类评论指的是包含项目管理者或其他评论者对开发者的拉请求提出修改任务的评论。普通评论是只包含平台用户之间普通交互信息的评论。
24.步骤104，定义拉请求修订状态模型。
25.通过拉请求修订状态模型可以实现对拉请求的修订状态进行标记，基础功能是进行三种状态的标记：包括“未解决”、“解决中”和“已解决”。
26.未解决：表示该评论刚被创建，拉请求的作者还未做出任何针对性的修订；解决中：拉请求的作者已经根据评论做出了部分修订；已解决：拉请求的作者已经完成了评论中所要求的全部修订。
27.优选地，也可进行标记方式的细化扩展，实现更细粒度的标记，以满足项目管理者和代码开发者对拉请求管理的实际需求。
28.步骤106，当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论。
29.修订请求类评论中包含修订任务，修订任务可以为多个，以列表或呈现方式显示在页面。
30.在评论者生成评论时就确定好评论类型，实现评论的第一层次区分。
31.步骤108，通过拉请求修订状态模型，根据修订请求类评论中修订任务的完成情况，对修订请求类评论进行状态标记。
32.通过状态标记实现对修订请求类评论进行第二层次的区分，状态标记动态更新。例如一个修订请求中共包含3个修订任务，其中两个任务已经完成，则平台会为该修订请求显示“解决中：2/3”的标记；当一个修订请求类评论中的所有修订任务都已经完成后，平台自动将该评论的状态置为“已解决”。
33.步骤110，获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据评论类型信息和状态标记信息对给定拉请求的评论进行分区显示。
34.平台将所有的“未解决”和“解决中”的修订请求类平台集中、单独显示在一个名为“进行中的修订”的页面中，将它们与普通评论以及“已解决”的修订类评论区分开。
35.评论类型的定义以及集中独立的组织页面有利于高效区分修订请求评论与普通评论。
36.上述基于状态标记的拉请求修订进度跟踪方法中，通过在开源平台下定义拉请求评论类型模型，将评论分为修订请求类评论和普通评论，能够将修订请求类的评论与普通的评论更加明显地区分开；评论者创建不同类型的评论后，通过定义的拉请求修订状态模型，根据修订请求类评论中修订任务的完成情况，对修订请求类评论进行状态标记，有利于清晰地表征修订请求的不同完成程度；最后根据评论类型信息和修订请求类评论的状态标记信息对给定拉请求的评论进行分区显示，使得开发者能够快速定位未完成的修订请求，并能够快速获取修订请求的进度信息。本发明通过高效地标记和跟踪拉请求的修订进度，有利于提高拉请求的管理效率，进而提高开源群体协同效率。
37.在其中一个实施例中，还包括：当评论者提交对拉请求的评价时，弹出含有下拉选择项的组合式按钮；获取评论者在组合式按钮的选项信息，根据选项信息确定生成修订请求类评论或普通评论。
38.在其中一个实施例中，还包括：若评论者未明确选择评论的类型，通过基于历史评论标记数据训练得到的二分类模型对评论文本进行自动分类；若分类结果显示所述评论文本是修订请求类评论，通过平台的人机交互界面提醒项目管理者和拉请求的开发者进行确认；若获取到了确认信息，则自动将该评论设置为修订请求类评论，否则设置为普通评论。
39.对评论者选择了评论类型的评论，也可以通过基于历史评论标记数据训练得到的二分类模型对评论文本进行自动分类，判断是否与评论者选择的选项信息相符，若不相符，通过平台的人机交互界面提醒项目管理者和拉请求的开发者进行再次确认。
40.在其中一个实施例中，还包括：当修订请求类评论中包含的修订任务不止一个时，以列表形式将修订任务逐一列出。
41.在其中一个实施例中，还包括：通过拉请求修订状态模型，根据修订请求类评论中修订任务的完成情况，对修订请求类评论进行状态标记；当修订请求类评论刚创建完成时，自动将修订请求类评论的状态标记为：“未解决”。
42.在其中一个实施例中，还包括：当修订请求类评论中包含的修订任务不止一个时，对修订任务列表中的每一项进行状态标记；根据每一项修订任务的状态标记信息，将修订请求类评论的状态标记为：“解决中：n/n”；其中，n表示已完成的修订任务个数；n表示修订请求类评论中包含的修订任务总数。
43.细粒度的任务表征与状态定义模型有利于清晰地表征修订请求的不同完成程度。
44.在其中一个实施例中，还包括：通过自动抽取拉请求的开发者更新的代码描述信息，计算代码描述信息与历史上所有未解决的修订请求类评论之间的文本相似度，当文本相似度与任一修订请求类评论的整体或者其中任一修订任务的相似度超过预设阈值时，通过人机交互界面提醒项目管理者、评论者以及拉请求的开发者判断最新的代码提交是否已经解决了修订请求类评论的整体或者其中任一修订任务；由项目管理者、评论者或者拉请求的开发者通过人机交互界面对修订任务列表中的每一项进行手动状态标记。
45.判断最新的代码提交是否已经解决了修订请求类评论的整体或者其中任一修订任务是基于当前的代码提交是否能够实现开源平台下对应项目所设定的功能和需求。由于
软件功能和需求是有确定指标的，因此，虽然判断功能和需求是否实现是由项目管理者、评论者或者拉请求的开发者手动标记确认的，但判断结果是客观的，不存在随机性。
46.在其中一个实施例中，还包括：当修订请求类评论中包含的每个修订任务都完成时，自动将修订请求类评论的状态标记为：“已解决”。
47.在其中一个实施例中，还包括：获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息；将所有标记为“未解决”和“解决中”的修订请求类评论显示在第一页面；将所有标记为“已解决”的修订请求类评论和普通评论显示在第二页面。
48.在一个具体实施例中，如图2所示，提供一种基于状态标记的拉请求修订进度跟踪方法，包括：s1：定义拉请求评论类型模型平台支持开发者对拉请求创建两种类型的评论，即修订请求类评论与普通评论，其中修订请求类评论表示评论作者在该评论中对拉请求提出了修订请求，而普通评论则表示开发者之间的普通交互。具体的创建方式为：s2: 定义拉请求修订状态模型。
49.对于拉请求的任何一个修订请求类评论，平台定义以下三种可选状态：未解决：表示该评论刚被创建，拉请求的作者还未做出任何针对性的修订；解决中：拉请求的作者已经根据评论做出了部分修订；已解决：拉请求的作者已经完成了评论中所要求的全部修订；s3: 提出拉请求的修订任务。
50.s3.1、项目管理者在文本输入框中输入具体的文本，如果管理者的意见中包含多个修订任务，则管理者以列表的形式逐一列出每一个任务。
51.s3.2、完成文本输入后，点击确认按钮会在拉请求上生成一个评论，而确认按钮是含有下拉选择项的组合式按钮，开发者可以选择“创建修订请求类评论”或者“创建普通类评论”。
52.s3.3、若用户未明确选择评论的类型，平台则利用基于历史评论标记数据训练得到的二分类模型对评论文本进行自动分类，若分类结果显示该评论是修订请求类评论，平台会提醒项目管理者和贡献者进行确认，如果得到了确认，则平台会正式将该评论设置为修订请求类评论，否则设置为普通类评论。
53.s4: 标记拉请求的修订进度。
54.s4.1、对于刚创建的修订请求类评论，平台为其关联一个初始的状态值：未解决。
55.s4.2、如果修订任务包含以列表形式存在的多个修改项，平台会对此进行解析，并根据每一项的状态标记整个修订请求的修订进度。例如一个修订请求中共包含3个修订任务，其中两个任务已经完成，则平台会为该修订请求显示“解决中：2/3”的标记。
56.s4.3、对于上一步骤中对修订任务状态的更改，只有项目管理者、评论作者以及拉请求的开发者才有权限执行此操作。具体操作是先触发对该评论的编辑操作，然后在评论文本中勾选某个修订任务对应的列表项。此外，平台还会自动抽取贡献者更新的代码提交描述信息，并计算其与历史上所有未解决的修订请求类评论之间的文本相似度，当其与某个修订请求类评论的整体或者某个列表项的相似度超过平台预定阈值ts时，则会提醒项目管理者、评论作者以及拉请求的贡献者是否最新的代码提交已经解决了该评论的整体或者
某个列表项。
57.s4.4、平台将所有的“未解决”和“解决中”的修订请求类平台集中、单独显示在一个名为“进行中的修订”的页面中，将它们与普通评论以及“已解决”的修订类评论区分开。
58.s4.5、当一个修订请求类评论中的所有修订任务都已经完成后，平台自动将该评论的状态置为“已解决”，并将其移出“进行中的修订”页面。
59.应该理解的是，虽然图1-2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
60.在一个实施例中，如图3所示，提供了一种基于状态标记的拉请求修订进度跟踪装置，包括：评论类型模型定义模块302、修订状态模型定义模块304、评论生成模块306、修订请求类评论状态标记模块308和分区显示模块310，其中：评论类型模型定义模块302，用于在开源平台下定义拉请求评论类型模型；其中，拉请求评论类型包括修订请求类评论和普通评论；修订状态模型定义模块304，用于定义拉请求修订状态模型；拉请求修订状态模型用于对拉请求的修订状态进行标记；其中，标记状态至少包括“未解决”、“解决中”和“已解决”三种；评论生成模块306，用于当评论者对拉请求进行评价时，根据评论者的选择信息确定生成修订请求类评论或普通评论；修订请求类评论中包含修订任务；修订请求类评论状态标记模块308，用于通过拉请求修订状态模型，根据修订请求类评论中修订任务的执行情况，对修订请求类评论进行状态标记；分区显示模块310，用于获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息，根据评论类型信息和状态标记信息对给定拉请求的评论进行分区显示。
61.评论生成模块306还用于当评论者提交对拉请求的评价时，弹出含有下拉选择项的组合式按钮；获取评论者在组合式按钮的选项信息，根据选项信息确定生成修订请求类评论或普通评论。
62.评论生成模块306还用于若评论者未明确选择评论的类型，通过基于历史评论标记数据训练得到的二分类模型对评论文本进行自动分类；若分类结果显示评论文本是修订请求类评论，通过平台的人机交互界面提醒项目管理者和拉请求的开发者进行确认；若获取到了确认信息，则自动将该评论设置为修订请求类评论，否则设置为普通评论。
63.评论生成模块306还用于当修订请求类评论中包含的修订任务不止一个时，以列表形式将修订任务逐一列出。
64.修订请求类评论状态标记模块308还用于通过拉请求修订状态模型，根据修订请求类评论中修订任务的完成情况，对修订请求类评论进行状态标记；当修订请求类评论刚创建完成时，自动将修订请求类评论的状态标记为：“未解决”。
65.修订请求类评论状态标记模块308还用于当修订请求类评论中包含的修订任务不
止一个时，对修订任务列表中的每一项进行状态标记；根据每一项修订任务的状态标记信息，将修订请求类评论的状态标记为：“解决中：n/n”；其中，n表示已完成的修订任务个数；n表示修订请求类评论中包含的修订任务总数。
66.修订请求类评论状态标记模块308还用于通过自动抽取拉请求的开发者更新的代码描述信息，计算代码描述信息与历史上所有未解决的修订请求类评论之间的文本相似度，当文本相似度与任一修订请求类评论的整体或者其中任一修订任务的相似度超过预设阈值时，通过人机交互界面提醒项目管理者、评论者以及拉请求的开发者判断最新的代码提交是否已经解决了修订请求类评论的整体或者其中任一修订任务；由项目管理者、评论者或者拉请求的开发者通过人机交互界面对修订任务列表中的每一项进行手动状态标记。
67.修订请求类评论状态标记模块308还用于当修订请求类评论中包含的每个修订任务都完成时，自动将修订请求类评论的状态标记为：“已解决”。
68.分区显示模块310还用于获取给定拉请求的评论类型信息和修订请求类评论的状态标记信息；将所有标记为“未解决”和“解决中”的修订请求类评论显示在第一页面；将所有标记为“已解决”的修订请求类评论和普通评论显示在第二页面。
69.关于基于状态标记的拉请求修订进度跟踪装置的具体限定可以参见上文中对于基于状态标记的拉请求修订进度跟踪方法的限定，在此不再赘述。上述基于状态标记的拉请求修订进度跟踪装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
70.在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于状态标记的拉请求修订进度跟踪方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
71.本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
72.在一个实施例中，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行计算机程序时实现上述方法实施例中的步骤。
73.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例中的步骤。
74.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，
本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（rom）、可编程rom（prom）、电可编程rom（eprom）、电可擦除可编程rom（eeprom）或闪存。易失性存储器可包括随机存取存储器（ram）或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram（sram）、动态ram（dram）、同步dram（sdram）、双数据率sdram（ddrsdram）、增强型sdram（esdram）、同步链路（synchlink） dram（sldram）、存储器总线（rambus）直接ram（rdram）、直接存储器总线动态ram（drdram）、以及存储器总线动态ram（rdram）等。
75.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
76.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。