CN117076158A - 一种广播分发处理方法及相关设备 - Google Patents

一种广播分发处理方法及相关设备 Download PDF

Info

Publication number
CN117076158A
CN117076158A CN202311274208.8A CN202311274208A CN117076158A CN 117076158 A CN117076158 A CN 117076158A CN 202311274208 A CN202311274208 A CN 202311274208A CN 117076158 A CN117076158 A CN 117076158A
Authority
CN
China
Prior art keywords
broadcast
thread
application
sub
electronic device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202311274208.8A
Other languages
English (en)
Other versions
CN117076158B (zh
Inventor
杨路文
秦园
于佳欣
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202311274208.8A priority Critical patent/CN117076158B/zh
Publication of CN117076158A publication Critical patent/CN117076158A/zh
Application granted granted Critical
Publication of CN117076158B publication Critical patent/CN117076158B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/548Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请公开了一种广播分发处理方法及相关设备。根据该方法,电子设备给应用程序提供通过子线程处理广播的能力。具体地,电子设备中的AMS在向目标广播接收者发送广播时,也可以向目标广播接收者所在进程发送目标广播接收者所在应用对应的子线程选项信息,以指示目标广播接收者所在应用是否允许子线程处理广播。这样,若目标广播接收者所在应用对应的子线程选项信息指示允许子线程处理广播,目标广播接收者所在进程可以通过子线程处理广播。通过这种方式,广播消息可以在较为空闲的子线程中进行处理,从而减少广播消息在相应消息队列中排队等待处理的时长,提高了广播处理效率,进而提高整个广播分发过程的效率。

Description

一种广播分发处理方法及相关设备
技术领域
本申请涉及终端技术领域,尤其涉及一种广播分发处理方法及相关设备。
背景技术
作为安卓(Android)操作系统的四大组件之一,广播(Broadcast)是一种在组件之间进行消息传递(例如,传递数据、发送通知等)的机制。这些组件可以在同一个进程或不同进程中。也就是说,广播机制可理解为一种进程间通讯机制。广播机制利用了观察者模式,基于消息发布/订阅事件模型。该模型包括消息发布者、消息订阅者和消息中心。消息发布者、消息订阅者和消息中心分别对应广播机制中的发送者(即广播发送者)、接收者(即广播接收者)和活动管理器服务(Activity Manager Service,AMS)。
针对广播的静态注册场景,发送者将广播发送给AMS后,AMS可以确定该广播对应的接收者,再将该广播串行分发给该广播对应的接收者。一方面,由于广播是串行分发的,AMS接收到接收者发送的广播处理完成的消息后,才能继续向下一个接收者发送广播。这也就意味着,若广播对应的接收者较多,则排在接收者队列末端的接收者需要等待较长时间才能接收到AMS发送的广播,导致广播分发处理效率低下。另一方面,接收者接收AMS发送的广播后,需要等待接收者所在进程对应的消息列表中排在前面的消息处理完成后,才能处理AMS发送的广播。这也就意味着,若该消息列表中排在前面的消息较多,接收者接收的广播需排队较长时间后才能被处理,也会导致广播分发处理效率低下。
因此,如何提高广播分发和处理效率是目前亟待解决的问题。
发明内容
本申请提供了一种广播分发处理方法及相关设备。根据该广播分发处理方法,电子设备给应用程序提供可以通过子线程处理广播的能力。具体地,若目标广播接收者所在应用对应的子线程选项信息指示允许子线程处理广播,目标广播接收者所在进程可以通过子线程处理广播。这种方式可以减少广播消息在相应消息队列中排队等待处理的时长,避免广播消息在目标广播接收者所在进程的主线程任务繁重的情况下仍排队较长时间以等待其处理,提高了广播处理效率,进而提高整个广播分发过程的效率。
第一方面,本申请提供了一种广播分发处理方法。根据该方法,电子设备可以通过AMS接收广播发送者发送的第一广播,基于第一广播确认目标广播接收者,以及确定目标广播接收者所在应用对应的子线程选项信息。其中,子线程选项信息用于表示应用是否允许子线程处理广播。在电子设备向目标广播接收者发送第一广播的过程中,可以通过AMS向第一进程发送第一广播和第一信息,并且,在第一信息指示允许子线程处理广播的情况下,电子设备可以通过第一进程的子线程处理第一广播。其中,第一进程为第一广播接收者所在进程,第一广播接收者为目标广播接收者中的一个,第一信息为第一应用对应的子线程选项信息,第一应用为第一广播接收者所在应用。
在本申请提供的方案中,电子设备中的AMS接收第一广播后,可以确定目标广播接收者,以及目标广播接收者所在应用对应的子线程选项信息。若目标广播接收者所在应用对应的子线程选项信息指示允许子线程处理广播,则目标广播接收者所在进程接收到AMS发送的第一广播之后,可以通过子线程处理第一广播。通过这种方法,广播消息可以由目标广播接收者所在进程的较为空闲的子线程进行处理,可以避免在目标广播接收者所在进程的主线程任务繁重的情况下,广播消息需要在该主线程对应的消息队列中等待较长时间后才被处理。这种方法可以减少广播消息在相应消息队列中排队等待处理的时长,提高了广播处理效率,进而提高整个广播分发过程的效率。
结合第一方面,在一种可能的实现方式中,电子设备通过AMS向第一进程发送第一广播和第一信息之前,第一进程还未创建。电子设备通过AMS向第一进程发送第一广播和第一信息之前,该方法还可以包括:电子设备可以创建第一进程。电子设备通过AMS向第一进程发送第一广播和第一信息之后,该方法还可以包括:电子设备可以通过第一进程的主线程接收第一广播和第一信息,通过第一进程的主线程基于第一信息对第一广播进行封装,得到第一广播消息,并将第一广播消息放入第一消息队列。电子设备通过第一进程的子线程处理第一广播,具体可以包括:电子设备可以启动第一进程的子线程,通过第一进程的主线程对第一广播消息重新进行封装,得到第二广播消息,以及通过第一进程的主线程将第二广播消息放入第二消息队列,并删除第一消息队列中的第一广播消息。其中,第一消息队列为第一进程的主线程对应的消息队列,第二消息队列为第一进程的子线程对应的消息队列。
在本申请提供的方案中,第一进程创建后需要通过主线程加载和解析资源,第一进程的主线程对应的消息队列中的待处理消息较多,无法立即确定是否需要开启子线程(即启动子线程),因此,第一进程先将封装后的广播消息放在其主线程对应的消息队列中以等待完成一部分应用环境初始化准备。在完成一部分应用环境初始化准备后,第一进程才可以确定是否需要开启子线程来处理广播。这样,无需等待第一进程确定是否需要开启子线程来处理广播后,才封装广播消息并放入相应线程对应的消息队列。通过这种方式,在第一进程确定需要开启子线程来处理广播的情况下,可以通过较为空闲的子线程来处理广播,减少广播处理时长,而在第一进程确定无需开启子线程来处理广播的情况下,也可以及时将封装后的广播消息放入主线程对应的消息队列中,不必等待后续判断,避免因执行确定是否需要开启子线程这一步骤而造成广播消息入队时间晚,控制广播消息在主线程对应消息队列中排队时长,避免该排队时长增长。
在本申请的一些实施例中,第一广播消息可以为添加有决策结果的广播消息(如步骤S308所示)。第二广播消息可以为重新封装后的广播消息(如步骤S303所示)。
可理解,电子设备通过AMS向第一进程发送第一广播和第一信息之前,第一进程还未创建,具体可以指:电子设备通过AMS准备向第一进程发送第一广播和第一信息时,第一进程还未创建。也就是说,在确定目标广播接收者和其所在应用对应的子线程选项信息之后,且在AMS向第一进程发送第一广播和第一信息之前,第一进程还未创建。
结合第一方面,在一种可能的实现方式中,电子设备通过第一进程的主线程基于第一信息对第一广播进行封装,得到第一广播消息,具体可以包括:电子设备可以通过第一进程的主线程对第一广播进行封装,得到第三广播消息,通过第一进程的主线程确定第一信息是否指示允许子线程处理广播;在第一信息指示允许子线程处理广播的情况下,电子设备可以通过第一进程的主线程得到第一决策结果,并将第一决策结果添加到第三广播消息,得到第一广播消息,而在第一信息未指示允许子线程处理广播的情况下,电子设备可以通过第一进程的主线程得到第二决策结果,并将第二决策结果添加到第三广播消息,得到第一广播消息。电子设备得到第一广播消息之后,该方法还可以包括:在第一广播消息包括第二决策结果的情况下,电子设备可以通过第一进程的主线程处理第一广播消息。在第一信息指示允许子线程处理广播的情况下,电子设备通过第一进程的子线程处理第一广播,具体可以包括:在第一广播消息包括第一决策结果的情况下,电子设备可以通过第一进程的子线程处理第二广播消息。
在本申请提供的方案中,电子设备通过AMS向第一进程发送第一广播和第一信息之后,第一进程可以首先对第一广播进行封装,得到封装后的广播消息,再基于第一信息得到决策结果,并将决策结果添加到封装后的广播消息中,然后再将该添加有决策结果的广播消息放入第一进程的主线程对应的消息队列中。通过这种方式,对第一广播进行封装的过程和基于第一信息得到决策结果可以同时进行,不必先得到决策结果后再进行封装,在一定程度上减少了时长。
在本申请的一些实施例中,第三广播消息可以为对第一广播封装后得到的广播消息(如步骤S306所示)。
结合第一方面,在一种可能的实现方式中,电子设备通过第一进程的主线程基于第一信息对第一广播进行封装,得到第一广播消息,具体可以包括:电子设备可以通过第一进程的主线程确定第一信息是否指示允许子线程处理广播;在第一信息指示允许子线程处理广播的情况下,电子设备通过第一进程的主线程得到第一决策结果,并对第一广播和第一决策结果进行封装,得到第一广播消息,而在第一信息未指示允许子线程处理广播的情况下,电子设备通过第一进程的主线程得到第二决策结果,并对第一广播和第二决策结果进行封装,得到第一广播消息。电子设备得到第一广播消息之后,该方法还可以包括:在第一广播消息包括第二决策结果的情况下,电子设备可以通过第一进程的主线程处理第一广播消息。在第一信息指示允许子线程处理广播的情况下,电子设备通过第一进程的子线程处理第一广播,具体可以包括:在第一广播消息包括第一决策结果的情况下,电子设备可以通过第一进程的子线程处理第二广播消息。
在本申请提供的方案中,电子设备通过AMS向第一进程发送第一广播和第一信息之后,第一进程可以首先基于第一信息得到决策结果,然后对第一广播和决策结果进行封装,得到封装后的广播消息,然后再将该添加有决策结果的广播消息放入第一进程的主线程对应的消息队列中。通过这种方式,无需先对第一广播进行封装,再将决策结果添加到封装后的广播消息中,而是直接对第一广播和决策结果进行封装,在一定程度上简化了流程。
结合第一方面,在一种可能的实现方式中,电子设备通过AMS向第一进程发送第一广播之前,第一进程已创建。电子设备通过AMS向第一进程发送第一广播和第一信息之后,该方法还可以包括:电子设备可以通过第一进程的主线程接收第一广播和第一信息,以及确定第一信息是否指示允许子线程处理广播;在第一信息未指示允许子线程处理广播的情况下,电子设备通过第一进程的主线程对第一广播进行封装,得到第一广播消息,并将第一广播消息放入第一消息队列。在第一信息指示允许子线程处理广播的情况下,电子设备通过第一进程的子线程处理第一广播,具体可以包括:在第一信息指示允许子线程处理广播的情况下,电子设备可以启动第一进程的子线程,还可以通过第一进程的主线程对第一广播进行封装,得到第一广播消息,并将第一广播消息放入第二消息队列。其中,第一消息队列为第一进程的主线程对应的消息队列,第二消息队列为第一进程的子线程对应的消息队列。
在本申请提供的方案中,若电子设备准备向AMS准备向第一进程发送第一广播时,第一进程已创建,则第一进程无需通过主线程加载和解析资源,不必等待完成一部分应用环境初始化准备后再确定是否需要开启子线程。在这种情况下,电子设备可以首先基于第一信息确定是通过子线程处理广播,还是通过主线程处理广播,并在确定之后再对第一广播进行封装,以及将封装后的广播消息放入相应线程对应的消息队列中。通过这种方式,第一进程无需在对第一广播进行封装并将封装后的广播消息放入主线程对应的消息队列中之后,再确定是否开启子线程,而是首先确定通过哪个线程处理广播后,再对广播进行封装并放入相应消息对列,可以简化流程,减少将广播消息放入消息队列前所需的处理时长。
在本申请的一些实施例中,第一广播消息可以为由第一广播封装得到的广播消息。在这种情况下,第一广播消息不一定添加有决策结果。
可理解,电子设备通过AMS向第一进程发送第一广播和第一信息之前,第一进程已创建,具体可以指:电子设备准备向AMS准备向第一进程发送第一广播和第一信息时,第一进程已创建。也就是说,在确定目标广播接收者和其所在应用对应的子线程选项信息之后,且在AMS向第一进程发送第一广播和第一信息之前,第一进程已创建。
结合第一方面,在一种可能的实现方式中,电子设备通过AMS基于第一广播确认目标广播接收者,具体可以包括:电子设备从第一对应关系中确定第一广播对应的一个或多个广播接收者为目标广播接收者。电子设备通过AMS接收广播发送者发送的第一广播之前,该方法还可以包括:电子设备可以接收到启动电子设备的指令,响应于该启动电子设备的指令,电子设备可以启动,并解析电子设备中的应用的包文件,得到第二对应关系,以及电子设备中应用对应的子线程选项信息;电子设备可以保存第二对应关系,以及电子设备中的应用对应的子线程选项信息。
在本申请提供的方案中,电子设备启动时可以解析应用的包文件(即APK文件),得到应用中的广播接收者与广播的对应关系(即第二对应关系),以及应用对应的子线程选项信息,并保存该对应关系和应用对应的子线程选项信息,以便后续AMS查找目标广播接收者。
在本申请的一些实施例中,电子设备启动时还未安装第一应用。在这种情况下,电子设备后续安装第一应用时可以得到第一应用中的广播接收者与广播的对应关系,以及第一应用对应的子线程选项信息,并将第一应用中的广播接收者与广播的对应关系放入第二对应关系中,得到更新后的第二对应关系。该更新后的第二对应关系可以为第一对应关系,也可以不同于第一对应关系。具体地,若电子设备安装第一应用后,还更新第一应用,且更新第一应用时所获得的第一应用中的广播接收者与广播的对应关系未发生变化,或者电子设备安装第一应用后未更新第一应用,则更新后的第二对应关系可以为第一对应关系。若电子设备安装第一应用后,还更新第一应用,且更新第一应用时所获得的第一应用中的广播接收者与广播的对应关系发生变化,则更新后的第二对应关系不同于第一对应关系。类似的,若电子设备安装第一应用后,还更新第一应用,且更新第一应用时所获得的第一应用对应的子线程选项信息未发生变化,或者电子设备安装第一应用后未更新第一应用,则安装第一应用时获得的第一应用对应的子线程选项信息即为第一信息。若电子设备安装第一应用后,还更新第一应用,且更新第一应用时所获得的第一应用对应的子线程选项信息发生变化,则更新第一应用时获得的第一应用对应的子线程选项信息即为第一信息,而安装第一应用时获得的第一应用对应的子线程选项信息不同于第一信息。
在本申请的一些实施例中,电子设备启动时已安装有第一应用。在这种情况下,电子设备启动时可以得到第一应用中的广播接收者与广播的对应关系,以及第一应用对应的子线程选项信息。也就是说,第二对应关系可以包括第一应用中的广播接收者与广播的对应关系。第二对应关系可以为第一对应关系,也可以不同于第一对应关系。具体地,若电子设备后续更新第一应用时,第一应用中的广播接收者与广播的对应关系未发生变化,或者电子设备后续未更新第一应用,则第二对应关系可以为第一对应关系。若电子设备后续更新第一应用时,第一应用中的广播接收者与广播的对应关系发生变化,则第二对应关系不同于第一对应关系。类似的,若电子设备后续未更新第一应用,或者更新第一应用时所获得的第一应用对应的子线程选项信息未发生变化,则电子设备启动时获得的第一应用对应的子线程选项信息即为第一信息。若电子设备后续更新第一应用时所获得的第一应用对应的子线程选项信息发生变化,则更新第一应用时获得的第一应用对应的子线程选项信息即为第一信息,而电子设备启动时获得的第一应用对应的子线程选项信息不同于第一信息。
结合第一方面,在一种可能的实现方式中,电子设备中的应用不包括第一应用。电子设备通过活动管理器服务AMS接收广播发送者发送的第一广播之前,该方法还可以包括:电子设备接收到安装第一应用的指令;响应于该安装第一应用的指令,电子设备解析第一应用的包文件,得到第一应用中的广播接收者与广播的对应关系,以及第一信息;电子设备基于第一应用中的广播接收者与广播的对应关系更新第二对应关系,得到第一对应关系,并保存第一对应关系和第一信息。
在本申请提供的方案中,电子设备启动时未安装第一应用。这也就意味着,第二对应关系中不包括第一应用中的广播接收者与广播的对应关系。在这种情况下,电子设备后续可以安装第一应用,并在安装第一应用时可以得到第一应用中的广播接收者与广播的对应关系,以及第一应用对应的子线程选项信息。电子设备可以将得到的第一应用中的广播接收者与广播的对应关系放入第二对应关系中,得到第一对应关系。电子设备可以保存第一对应关系和第一信息。也就是说,在本申请的一些实施例中,电子设备安装第一应用时得到的第一应用中的广播接收者与广播的对应关系,可以为第一对应关系所包括的第一应用中的广播接收者与广播的对应关系,而电子设备安装第一应用时得到的第一应用对应的子线程选项信息可以为第一信息。
结合第一方面,在一种可能的实现方式中,该方法还包括:电子设备接收到更新第一应用的指令,响应于该更新第一应用的指令,电子设备可以解析第一应用的包文件,得到第一应用中的广播接收者与广播的对应关系,以及第二信息;电子设备可以保存第一应用中的广播接收者与广播的对应关系,以及第二信息。
在本申请提供的方案中,电子设备可以更新第一应用,本申请对该更新第一应用的时刻不作限制。在本申请的一些实施例中,AMS向第一应用中的第一进程发送第一广播和第一信息之前,电子设备可以更新第一应用。在这种情况下,第二信息可以为第一信息。在本申请的一些实施例中,AMS向第一应用中的第一进程发送第一广播和第一信息之后,电子设备可以更新第一应用。在这种情况下,由于更新第一应用时,第一应用对应的子线程选项信息可能不发生变化,也可能发生变化,所以第二信息可以为第一信息,也可以不同于第一信息。
在本申请的一些实施例中,AMS向第一应用中的第一进程发送第一广播和第一信息之前,电子设备可以更新第一应用。在这种情况下,电子设备可以再次得到第一应用中的广播接收者与广播的对应关系,以及第一应用对应的子线程选项信息。可理解,电子设备更新第一应用时得到的第一应用中的广播接收者与广播的对应关系,可能不同于电子设备安装第一应用时得到的第一应用中的广播接收者与广播的对应关系。类似的,电子设备更新第一应用时得到的第一应用对应的子线程选项信息,可能不同于电子设备安装第一应用时得到的第一应用对应的子线程选项信息。
结合第一方面,在一种可能的实现方式中,电子设备向目标广播接收者发送第一广播,具体可以包括:电子设备向目标广播接收者串行发送第一广播。
在本申请提供的方案中,在目标广播接收者存在多个的情况下,电子设备在向该多个目标广播接收者发送第一广播时,可以按照顺序串行发送第一广播。可理解,串行发送的具体实现方式可以参考下文,在此不展开说明。
第二方面,本申请提供了一种电子设备,该电子设备包括:一个或多个存储器,以及一个或多个处理器;该一个或多个存储器与该一个或多个处理器耦合,该存储器用于存储计算机程序代码,该计算机程序代码包括计算机指令,该一个或多个处理器调用该计算机指令以使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。
第三方面,本申请提供了一种计算机存储介质。该计算机存储介质包括计算机指令,当该计算机指令在电子设备上运行时,使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。
第四方面,本申请实施例提供一种芯片。该芯片可以应用于电子设备,该芯片包括一个或多个处理器,该处理器用于调用计算机指令以使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。
第五方面,本申请实施例提供一种包含指令的计算机程序产品。当该计算机程序产品在电子设备上运行时,使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。
可理解,上述第二方面提供的电子设备、第三方面提供的计算机存储介质、第四方面提供的芯片,以及第五方面提供的计算机程序产品均用于执行如第一方面或第一方面的任意一种实现方式所描述的方法。因此,其所能达到的有益效果可参考上述第一方面中任一种可能的实现方式的有益效果,此处不再赘述。
附图说明
图1为本申请实施例提供的一种广播注册及分发流程的示意图;
图2为本申请实施例提供的又一种广播分发流程的示意图;
图3A和图3B为本申请实施例提供的一种广播分发流程中具体阶段的示意图;
图4为本申请实施例提供的一种广播分发处理方法的流程图;
图5为本申请实施例提供的一种电子设备的软件结构示意图;
图6为本申请实施例提供的一种软件模块交互图;
图7为本申请实施例提供的一种PMS解析清单文件的流程图;
图8A和图8B为本申请实施例提供的又一种广播分发处理方法的流程图;
图9为本申请实施例提供的一种广播分发流程中具体阶段的时长示意图;
图10为本申请实施例提供的一种电子设备的硬件结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。其中,在本申请实施例的描述中,除非另有说明,“/”表示或的意思,例如,A/B可以表示A或B;文本中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,另外,在本申请实施例的描述中,“多个”是指两个或多于两个。
应当理解,本申请的说明书和权利要求书及附图中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本申请中提及“实施例”意味着,结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例,也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是,本申请所描述的实施例可以与其它实施例相结合。
首先,对本申请中所涉及的部分用语和相关技术进行解释说明,以便于本领域技术人员理解。
1、广播
根据上文,广播机制涉及广播发送者、广播接收者(又称广播接收器)和AMS。
下面基于图1介绍广播注册及分发流程。
如图1所示,广播接收者可以在AMS中进行注册(即广播注册)。广播发送者可以向AMS发送广播。AMS可以基于注册的广播接收者(BroadcastReceiver)的相关信息来查找该广播对应的广播接收者,并将该广播传输到相应的广播队列中(即广播入队)以待AMS处理。可理解,该广播可以对应多个广播接收者。AMS处理时可以将该广播依次发送给其对应的广播接收者,即实现广播分发。一般来说,广播接收者在AMS中进行注册、广播发送者向AMS发送广播,以及AMS向广播接收者发送广播均是基于Binder机制实现的。Binder机制是一种进程间通信(InterProcess Communication,IPC)机制,其具体含义可以参考相关技术文档,在此不展开说明。
2、广播注册方式
广播的注册方式包括静态注册和动态注册两种方式。
静态注册指的是在应用程序(可简称为应用)的清单文件中注册广播接收器的相关信息,然后在应用安装的时候对该相关文件进行解析,从而完成注册。
动态注册指的是通过调用函数方法(例如,上下文注册接收器Context.registerReceiver方法)向AMS注册该广播接收器的相关信息。
可理解,针对静态注册的接收者,AMS在向其分发广播时会串行分发。
示例性的,如图2所示,静态注册接收者1、静态注册接收者2、静态注册接收者3和静态注册接收者4可以通过静态注册方式向AMS注册广播接收器。其注册的广播接收器对应的广播可以包括广播A。相应广播事件可以触发广播发送者向AMS发送广播A。AMS接收广播A后,可以基于注册的广播接收者的相关信息来查找广播A对应的广播接收者,得到如图2所示的接收者列表,并将该广播A放入广播队列,等待AMS分发该广播A。如图2所示的接收者列表可以包括静态注册接收者1、静态注册接收者2、静态注册接收者3和静态注册接收者4。由于广播A对应的广播接收者均为采用静态注册方式来注册广播的接收者,则AMS将广播队列中排在广播A前面的广播分发完成之后,可以开始按照该接收者列表中接收者的排列顺序来串行发送广播A。如图2所示,该接收者列表中排在第一位的广播接收者为静态注册接收者1,静态注册接收者1所在应用进程为接收者进程a。由于接收者进程a尚未运行,则AMS可以首先拉起(即启动)接收者进程a,并向接收者进程a发送广播A。待接收者进程a对广播A处理完毕后,可以通知AMS。这样,AMS可以继续向该接收者列表中排在第二位的广播接收者发送广播A。如图2所示,该接收者列表中排在第二位的广播接收者为静态注册接收者2,静态注册接收者2所在应用进程为接收者进程b。虽然接收者进程b与接收者进程a同属于应用1对应的进程,但是此时接收者进程a已经开始运行,而接收者进程b却还尚未运行,因此,AMS可以首先拉起接收者进程b,再向接收者进程b发送广播A。待接收者进程b对广播A处理完毕后,可以通知AMS。这样,AMS可以继续向该接收者列表中排在第三位的广播接收者(即静态注册接收者3)发送广播A。与上述针对静态注册接收者1和静态注册接收者2的广播发送过程类似,由于静态注册接收者3所在进程(即接收者进程c)尚未运行,AMS可以首先拉起接收者进程c,再向接收者进程c发送广播A。类似的,待接收者进程c对广播A处理完毕后,可以通知AMS。这样,AMS可以继续向该接收者列表中排在第四位的广播接收者(即静态注册接收者4)发送广播A。与上述针对静态注册接收者1、静态注册接收者2和静态注册接收者3的广播发送过程类似,由于静态注册接收者4所在进程(即接收者进程d)尚未运行,AMS可以首先拉起接收者进程d,再向接收者进程d发送广播A。待接收者进程b对广播A处理完毕后,可以通知AMS。至此,AMS完成对广播A的分发。
可理解,应用程序作为一个静态文件存储在计算机系统的硬盘等存储空间中。进程(process)指的是正在运行的应用程序的实例。进程是处于动态条件下由操作系统维护的系统资源管理实体。也就是说,应用程序是一个没有生命的实体,只有处理器执行它的时候才能成为一个活动的实体,称之为进程。每一个进程都有自己独立的地址空间、内存和数据栈,不同进程之间的通信可以通过IPC机制实现。
可理解,如图3A所示,整个广播流程可以分为两个阶段。其中第一个阶段为广播入队阶段,第二个阶段为广播分发阶段。广播入队阶段指的是广播发送者将广播发送给AMS,AMS根据广播信息(例如,广播属性)和广播发送者的相关信息(例如,广播发送者所在进程的相关信息)等将该广播分配到相应的广播队列中,依次排队等待分发的过程。广播分发阶段指的是AMS将广播分发给该广播对应的每一个广播接收者,直到AMS接收到该广播对应的最后一个广播接收者处理该广播后向AMS发送的通知消息。可理解,广播分发阶段包括广播对应的每一个广播接收者的派发阶段。针对广播对应的每一个广播接收者,其派发阶段可以包括等待阶段和处理阶段。其中,等待阶段指的是AMS将广播发送给广播接收者后等待广播接收者进行处理的阶段。等待阶段可以包括排队阶段。排队阶段指的是广播被封装成广播消息后在广播接收者的消息队列中排队的阶段。处理阶段指的是广播接收者处理消息队列中的广播消息的阶段。可理解,广播接收者的派发时长(即派发阶段的时长)可以包括等待时长(即等待阶段的时长)和处理时长(即处理阶段的时长)。其中,等待时长可以包括排队时长(即排队阶段的时长)。
如图3B所示,若广播接收者所在进程尚未运行,则其等待阶段不仅可以包括排队阶段,还可以包括拉起进程阶段和调整状态值(例如,ADJ)阶段。其中,拉起进程阶段为等待阶段中的第一个阶段,调整状态值阶段位于拉起进程阶段之后,排队阶段位于调整状态值阶段之后。拉起进程阶段指的是AMS触发电子设备拉起广播接收者所在进程的阶段。调整状态值阶段指的是电子设备调整广播接收者所在进程对应的状态值的阶段。可理解,针对所在进程尚未运行的广播接收者,其等待时长可以包括拉起进程时长(即拉起进程阶段的时长)、调整状态值时长(即调整状态值阶段的时长)和排队时长。
可理解,与所在进程已经运行的广播接收者相比,所在进程尚未运行的广播接收者的等待时长还包括拉起进程时长和调整状态值时长,那么所在进程尚未运行的广播接收者的等待时长很可能会更长一些。
根据上文,针对广播的静态注册场景,AMS通过串行分发方式来完成对广播的分发。一方面,一旦广播对应的广播接收者较多,则广播分发阶段所需的时长较长,整个广播流程就会花费较长时间,从而导致广播分发处理效率低下。另一方面,广播接收者接收AMS发送的广播后,需要等待广播接收者所在进程对应的消息列表中排在前面的消息处理完成后,才能处理AMS发送的广播。这也就意味着,若该消息列表中排在前面的消息较多,广播接收者接收的广播需排队较长时间后才能被处理,即派发阶段的等待时长较长,会导致广播分发处理效率低下。
尤其是存在所在进程尚未运行的广播接收者的情况下,若AMS向该所在进程尚未运行的广播接收者发送广播,电子设备首先会启动该接收者所在应用进程,然后将该广播封装成广播消息并将其放入该接收者所在应用进程的主线程对应的消息队列,以等待该接收者所在应用进程的主线程进行处理。可理解,应用进程启动后往往需要进行资源加载、信息更新等任务。部分应用进程的主线程任务量较大,主线程对应的消息队列中待处理消息较多,导致封装后的广播消息在主线程对应的消息队列中排队较长时间后才能被处理,从而导致广播分发处理效率低下。
可理解,进程只提供资源装载的空间,具体的资源调度还需要线程来完成。线程(thread)包含于进程之中,是操作系统能够进行运算调度的最小单元。一条进程中可以并发多个线程,而同一条线程将共享该进程中的全部系统资源。一个进程创建时,操作系统会创建一个线程来调度资源,这个线程就是主线程。而主线程可以创建一个或多个子线程。
本申请实施例提供了一种广播分发处理方法。根据该广播分发处理方法,电子设备可以允许应用使用广播接收者所在进程的子线程来处理接收的广播,无需使用广播接收者所在进程的主线程来处理接收的广播。这样,广播消息可以在较为空闲的子线程中排队等待处理,而无需在较为忙碌的主线程中排队等待处理。这种方式可以减少广播消息在相应消息队列中排队等待处理的时长,提高了广播处理效率,进而提高整个广播分发过程的效率。
下面介绍本申请实施例提供的一种广播分发处理方法。
请参阅图4,图4为本申请实施例提供的一种广播分发处理方法的流程图。该广播分发处理方法可以包括但不限于以下步骤:
S101:广播发送者向AMS发送第一广播。
电子设备中的广播发送者可以向电子设备中的AMS发送第一广播。相应的,AMS可以接收广播发送者向AMS发送的第一广播。
可理解,广播发送者可以是电子设备中的操作系统,还可以是电子设备中的应用程序、组件等,本申请对此不作限制。
S102:AMS基于第一广播和第一对应关系确定目标广播接收者。目标广播接收者包括第一广播接收者。第一广播接收者所在进程为第一进程。目标广播接收者为用于接收第一广播的广播接收者。第一对应关系为广播接收者和广播之间的对应关系。
AMS接收广播发送者发送的第一广播之后,可以基于第一对应关系确定第一广播对应的广播接收者,该广播接收者即为目标广播接收者,可以用于接收第一广播。
可理解,第一对应关系可以为广播接收者与广播之间的对应关系。一个广播接收者可以对应一个或多个广播。不同广播接收者对应的广播可以相同,也可以不同。
示例性的,如表1所示,广播接收者receiver1对应的广播为广播1,广播接收者receiver2对应的广播为广播2,广播接收者receiver3对应的广播为广播1,广播接收者receiver4对应的广播为广播3和广播4,广播接收者receiver5对应的广播为广播2和广播3。若第一广播为广播1,即广播发送者向AMS发送广播1,则AMS接收广播1之后,可以根据表1所示的对应关系确定广播1对应的广播接收者包括receiver1和receiver3,则AMS可以确定目标广播接收者包括receiver1和receiver3。
表1
在本申请的一些实施例中,广播接收者进行广播注册时,可以将其与注册的广播的对应关系记录在清单文件(例如,AndroidManifest.xml文件)中。电子设备启动后,电子设备可以扫描若干个应用的清单文件,从而获取该若干个应用中的广播接收者与广播的对应关系。在本申请的一些实施例中,电子设备可以将该对应关系保存在包管理器服务(Package Manager Service,PMS)中。在这种情况下,AMS接收广播发送者发送的广播之后,可以进行调度管理,从PMS中根据该对应关系获取该广播对应的广播接收者,并向该广播接收者发送该广播。在本申请的一些实施例中,电子设备可以将该对应关系保存在AMS中。在这种情况下,AMS接收广播发送者发送的广播之后,可以直接基于其保存的该对应关系来确定该广播对应的广播接收者,并向该广播接收者发送该广播。可理解,该对应关系还可以保存在其他模块中。在这种情况下,AMS可以基于相应接口或具体存储地址来获取该对应关系。
类似的,电子设备安装或更新应用时,可以扫描该应用的清单文件,获取该应用中的广播接收者与广播的对应关系。电子设备可以将该应用中的广播接收者与广播的对应关系保存在PMS或AMS或其他模块中。可理解,若PMS或AMS或其他模块中原本保存有电子设备之前获取的该应用中的广播接收者与广播的对应关系,则电子设备可以将之前获取的该应用中的广播接收者与广播的对应关系,替换为最新一次获取的该应用中的广播接收者与广播的对应关系。
可理解,上述广播接收者和广播的对应关系即为第一对应关系。第一对应关系可以包括第一应用中的广播接收者(例如,第一广播接收者)与其可以接收的广播之间的对应关系。
需要说明的是,AMS还可以基于广播接收者与其所在进程的对应关系,确定目标广播接收者所在进程(即目标广播接收者所属的进程)。可理解,进程和应用之间存在对应关系。AMS确定目标广播接收者所在进程之后,可以确定目标广播接收者所在进程对应的应用,该应用即为目标广播接收者所在应用。在本申请的一些实施例中,AMS还可以直接基于广播接收者和其所在应用之间的对应关系,确定目标广播接收者所在应用(即目标广播接收者所属的应用)。具体地,AMS可以基于广播接收者与其所在进程的对应关系确定第一广播接收者所在进程(即第一进程),还可以基于广播接收者与其所在应用的对应关系,或者进程与应用的对应关系,确定第一广播接收者所在应用(即第一应用)。
可理解,广播接收者所在应用可以对应一个或多个应用进程。广播接收者所在进程为该广播接收者所在应用对应的一个或多个应用进程中的一个应用进程。
可理解,一个广播接收者可以对应一个进程和一个应用。在本申请的一些实施例中,不同广播接收者所在进程可能不同,而其所在应用可能相同。在本申请的又一些实施例中,不同广播接收者所在进程可能相同,其所在应用也可能相同。
可理解,广播接收者所在进程指的是注册广播接收者的进程,即发起广播接收者注册的进程。可理解,不同广播接收者所在进程可以相同,也可以不同。
示例性的,如表2所示,广播接收者receiver1对应的进程为进程1,即receiver1所在进程为进程1,广播接收者receiver2对应的进程为进程1,即receiver2所在进程为进程1,广播接收者receiver3对应的进程为进程2,即receiver3所在进程为进程2,广播接收者receiver4对应的进程为进程3,即receiver4所在进程为进程3,广播接收者receiver5对应的进程为进程2,即receiver5所在进程为进程2。在这种情况下,若目标广播接收者包括receiver1和receiver3,则AMS可以根据表2所示的对应关系查找receiver1和receiver3对应的进程和应用。如表2所示,receiver1对应的进程为进程1,receiver1对应的应用为应用1,receiver3对应的进程为进程2,receiver3对应的应用为应用2。
表2
在本申请的一些实施例中,广播接收者进行广播注册时,不仅可以将其与注册的广播的对应关系记录在清单文件中,还可以记录其所在进程和所在应用。与上文类似,电子设备启动后,电子设备可以扫描每一个应用的清单文件,从而获取每一个广播接收者与其所在进程和其所在应用的对应关系。在一种可能的实现方式中,电子设备可以将广播接收者与其所在进程和其所在应用的对应关系保存在PMS中。AMS接收广播发送者发送的第一广播之后,不仅可以从PMS中根据第一对应关系获取第一广播对应的广播接收者,即目标广播接收者,还可以从PMS中根据广播接收者与其所在进程和其所在应用的对应关系,获取目标广播接收者所在进程和目标广播接收者所在应用,以便执行后续步骤。
在本申请的一些实施例中,AMS中可以保存有广播接收者与其所在进程和其所在应用的对应关系。AMS接收广播发送者发送的第一广播之后,可以直接基于其保存的广播接收者与其所在进程和其所在应用的对应关系,来确定目标广播接收者所在进程和目标广播接收者所在应用。
可理解,广播接收者与其所在进程和其所在应用的对应关系还可以保存在其他模块中。在这种情况下,AMS可以基于相应接口或具体存储地址来获取该对应关系。
S103:若AMS准备向第一广播接收者发送第一广播时,第一进程尚未运行,则AMS触发启动第一进程。
AMS接收广播发送者发送的第一广播之后,可以确定目标广播接收者,以及将第一广播分配到相应广播队列中,排队等待分发给目标广播接收者。等到AMS将第一广播所在的广播队列中的排在第一广播前面的广播分发完毕之后,可以准备分发第一广播。在本申请的一些实施例中,AMS准备向第一广播接收者发送第一广播时,第一广播接收者所在进程(即第一进程)尚未运行(即尚未创建)。在这种情况下,AMS可以触发启动第一进程,即拉起第一进程。在本申请的又一些实施例中,AMS准备向第一广播接收者发送第一广播时,第一进程已在运行。在这种情况下,电子设备可以不必执行步骤S103,而是直接执行步骤S104即可,即向第一进程发送第一广播。
可理解,AMS分发第一广播时串行发送给每一个目标广播接收者。也就是说,AMS将第一广播分发给一个目标广播接收者并接收该目标广播接收者发送的广播处理完毕的通知消息后,再继续将第一广播分发给下一个目标广播接收者。这也就意味着,AMS将第一广播发送给排在第一广播接收者前面的目标广播接收者,并接收到该目标广播接收者发送的广播处理完毕的通知消息后,才能准备将第一广播发送给第一广播接收者。可理解,本申请对AMS向目标广播接收者分发第一广播的顺序不作限制。
在本申请的一些实施例中,上述分发顺序可以根据目标广播接收者的优先级确定。优先级越高的目标广播接收者排在越前面,优先级越低的目标广播接收者排在越后面。可理解,目标广播接收者的优先级可以根据实际需要进行设置,本申请对此不作具体限制。
在本申请的一些实施例中,上述分发顺序可以根据AMS查找到目标广播接收者的先后顺序确定。
在本申请的又一些实施例中,上述分发顺序可以根据AMS查找得到的目标广播接收者列表的顺序确定。具体地,AMS可以根据第一对应关系确定目标广播接收者列表,并按照目标广播接收者列表中的目标广播接收者的顺序来依次向每一个目标广播接收者分发第一广播。目标广播接收者列表可以包括一个或多个目标广播接收者。目标广播接收者列表可以包括第一广播接收者。
S104:AMS向第一进程发送第一广播。
如上文所述,第一进程开始运行后,AMS可以向第一进程发送第一广播。
S105:第一进程获取第一应用对应的子线程选项信息。子线程选项信息用于表示应用是否支持子线程处理广播。第一应用为第一进程对应的应用。
第一进程启动后,可以获取第一进程所对应的应用(即第一应用)对应的子线程选项信息,从而确定第一应用是否支持第一进程的子线程处理接收到的第一广播。
在本申请的一些实施例中,广播接收者进行广播注册时,可以将该广播接收者所在应用对应的子线程选项信息记录在清单文件。
与上文类似,电子设备启动后,可以扫描电子设备中的应用的清单文件,从而获取电子设备中的应用对应的子线程选项信息。在本申请的一些实施例中,电子设备可以将应用对应的子线程选项信息保存在PMS中。在这种情况下,AMS接收广播发送者发送的第一广播后,不仅可以向PMS获取广播接收者与广播的对应关系(即第一对应关系),以及广播接收者与其所在进程、其所在应用的对应关系,还可以向PMS获取目标广播接收者所在应用对应的子线程选项信息。在本申请的一些实施例中,AMS可以首先获取第一应用对应的子线程选项信息,然后再将其获取的第一应用对应的子线程选项信息发送给第一进程。在一种可能的实现方式中,AMS在向每一个目标广播接收者发送第一广播时,可以向该每一个目标广播接收者发送其所在应用对应的子线程选项信息。也就是说,AMS向第一进程发送第一广播时,可以将第一应用对应的子线程选项信息一起发送给第一进程。
可理解,电子设备中的应用对应的子线程选项信息还可以保存在其他模块(例如,AMS)中。在这种情况下,目标广播接收者所在进程可以基于相应接口或具体存储地址来获取目标广播接收者所在应用对应的子线程选项信息。
可理解,子线程选项信息可以通过文字、数字、字符串等形式表示,本申请对此不作限制。
S106:若第一应用对应的子线程选项信息包括第一参数信息,第一进程通过其子线程处理第一广播。
第一进程获取第一应用对应的子线程选项信息之后,可以确定第一应用对应的子线程选项信息是否包括第一参数信息。若第一应用对应的子线程选项信息包括第一参数信息,则第一进程可以通过第一进程的子线程处理第一广播,并在处理完毕后通知AMS。若第一应用对应的子线程选项信息不包括第一参数信息,则第一进程可以通过第一进程的主线程处理第一广播,并在处理完毕后通知AMS。
在本申请的一些实施例中,第一进程获取第一应用对应的子线程选项信息之后,可以将第一广播和第一应用对应的子线程选项信息封装为广播消息,并将该广播消息放入第一进程的主线程对应的消息队列中。可理解,第一进程启动后,可以进行应用绑定(bindapplication),在应用绑定过程中,第一进程完成一部分应用环境初始化准备后,可以从其主线程对应的消息队列中取出该广播消息,并确定该广播消息中包括的第一应用对应的子线程选项信息是否包括第一参数信息。若第一应用对应的子线程选项信息包括第一参数信息,则第一进程可以从主线程对应的消息队列中取出该广播消息,对其重新封装后再发送给第一进程的子线程进行处理,并删除主线程对应的消息队列中的该广播消息。
可理解,应用环境初始化准备可以包括本地材料解析和包文件解析等。在这种情况下,第一进程完成一部分应用环境初始化准备,具体可以包括:第一进程针对本地材料和包文件等的解析进度达到s%。可理解,s可以大于0,且小于100。例如,s可以为60。
可理解,应用绑定指的是创建进程之后,将进程和指定的应用绑定的过程。应用绑定可以通过活动线程(ActivityThread)对象调用bindApplication()方法完成的。该方法通过发送一个BIND_APPLICATION的消息到消息队列中,最终通过handleBindApplication()方法处理该消息,然后调用makeApplication()方法来加载应用的类(Classes)到内存中。
可理解,第一参数信息可以通过文字、数字、字符串等形式表示,本申请对此不作限制。例如,第一参数信息可以为true。再例如,第一参数信息可以为1。
示例性的,若第一应用对应的子线程选项信息为true,则第一进程通过其子线程处理第一广播,若第一应用对应的子线程选项信息为false,则第一进程通过其主线程处理第一广播。
示例性的,若第一应用对应的子线程选项信息为1,则第一进程通过其子线程处理第一广播,若第一应用对应的子线程选项信息为0,则第一进程通过其主线程处理第一广播。
在本申请的一些实施例中,第一进程中可以加载多个子线程。在这种情况下,第一进程可以选择第一进程可加载的多个子线程中的一个子线程来处理广播消息。
可理解,第一进程中用于处理广播消息的子线程可以根据实际需要进行设置。在本申请的一些实施例中,第一进程可以选择该多个子线程中最空闲的子线程来处理广播消息。可理解,最空闲的子线程可以指对应消息队列中排队等待处理的消息最少的子线程。在本申请的一些实施例中,第一应用可以预先设置第一进程的默认子线程,并通过该默认子线程处理广播消息。在本申请的一些实施例中,在一些场景(例如,目标广播接收者的数量大于第一数量,内存占用较大等)下,第一进程可以直接通过其默认子线程处理广播消息,而在又一些场景(例如,目标广播接收者的数量不大于第一数量,内存占用较小等)下,第一进程可以不直接通过其默认子线程处理广播消息,而是首先确定第一进程的多个子线程中最空闲的子线程,最终通过该最空闲的子线程来处理广播消息。
可理解,第一数量可以根据实际需要进行设置,本申请对此不作具体限制。例如,第一数量可以为3。
可理解,内存占用可以指第一应用的内存空间中已使用的内存大小与该内存空间总大小的比值。内存占用较大可以指该比值大于第一比值,而内存占用较小可以指该比值不大于第一比值。可理解,第一比值可以根据实际需要进行设置,本申请对此不作具体限制。例如,第一比值可以为0.6。
下面介绍本申请实施例涉及的电子设备的软件结构。
请参阅图5,图5为本申请实施例提供的一种电子设备的软件结构示意图。
如图5所示,电子设备的软件系统可以采用分层架构,事件驱动架构,微核架构,微服务架构,或云架构。本申请实施例以分层架构的Android操作系统为例,示例性说明电子设备的软件结构。
分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,电子设备的软件框架可以包括应用程序层、应用程序框架层、系统库、运行时(Runtime)、硬件抽象层(HAL)和内核层。
应用程序层可以包括一系列应用程序包。例如,应用程序包可以包括相机、图库、设置、通话、地图、导航、WLAN、蓝牙、音乐、视频和短信息等应用程序。
应用程序层还可以包括第一应用。第一应用可以为系统应用,也可以为三方应用。第一应用可以包括信息决策模块。信息决策模块可以用于确定第一应用中的进程接收广播后是否需要开启子线程来处理广播。在本申请的一些实施例中,第一应用还可以包括子线程调度模块。子线程调度模块可以用于将在主线程对应的消息队列中排队的广播消息发送给子线程进行处理,并删除主线程对应的消息队列中的该广播消息。
可理解,第一应用启动后,Android操作系统可以创建第一应用对应的进程,比如第一进程。可理解,第一进程创建后,第一应用可以运行在第一进程中。在本申请的一些实施例中,第一进程创建后,第一应用中的信息决策模块和子线程调度模块可以运行在第一进程的主线程中。在本申请的一些实施例中,第一应用还可以包括其他进程。
应用程序框架层为应用程序层的应用程序提供应用编程接口(ApplicationProgramming Interface,API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层可以包括一系列系统服务。系统服务是专注于特定功能的模块化组件。应用框架API所提供的功能可与系统服务通信,以访问底层硬件。
应用程序框架层可以包括系统服务(SystemServer)进程和资源管理进程。
SystemServer进程负责启动和管理整个应用程序框架层。SystemServer进程被创建后,主要可以处理以下内容:(1)初始化一些系统设置,虚拟机配置等;(2)启动Binder线程池,这样就可以与其他进程进行Binder跨进程通信;(3)创建系统服务管理器(SystemServiceManager),它用来对系统服务进行创建、启动和生命周期管理;(4)创建主线程Looper并进入循环等待消息;(5)启动各种系统服务,如AMS、PMS、窗口管理器服务(Window Manager Service,WMS)和输入管理器服务(Input Manager Service,IMS)等。
SystemServer进程可以包括AMS和PMS。AMS用于管理应用程序中所有的Activity和进程。它可以启动、暂停、停止和销毁Activity,以及管理应用程序的生命周期。AMS还可以为不同应用程序分配内存、进程和线程等系统资源。PMS主要负责应用程序的安装、管理和卸载。当一个新的应用程序被安装时,PMS将识别应用程序的所有组件(例如,服务、广播接收器等),并为这些组件分配相应的权限。PMS还可以查看已安装的应用程序的状态,确保应用程序的完整性和安全性。在本申请的一些实施例中,PMS还可以包括参数识别模块。参数识别模块可以用于解析清单文件中的与广播相关的若干参数。
可理解,SystemServer进程还可以包括其他服务(例如,WMS、IMS等),本申请对此不展开说明。
资源管理模块可以用于在开机时初始化配置(例如,广播相关配置),以及处理SystemServer进程传输的维测信息,即针对SystemServer进程管理应用程序框架层的过程中出现的异常和问题(例如,广播分发过程中出现的异常和问题)进行维护和测试。
值得注意的是,本申请所涉及的信息决策模块、子线程调度模块、参数识别模块和资源管理进程是区别于现有软件框架所新增的软件模块。
应用程序框架层还可以包括窗口管理器、内容提供器、视图系统、电话管理器、资源管理器和通知管理器等。窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小,判断是否有状态栏,锁定屏幕,截取屏幕等。内容提供器用来存放和获取数据,并使这些数据可以被应用程序访问。这些数据可以包括视频,图像,音频,拨打和接听的电话,浏览历史和书签,电话簿等。视图系统包括可视控件,例如显示文字的控件,显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如,包括短信通知图标的显示界面,可以包括显示文字的视图以及显示图片的视图。电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通,挂断等)。资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息,可以用于传达告知类型的消息,可以快速停留后自动消失,无需用户交互。比如通知管理器被用于告知下载完成,消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知,例如后台运行的应用程序的通知,还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息,发出提示音,电子设备振动,指示灯闪烁等。
系统库可以包括多个功能模块。例如:表面管理器(Surface Manager),媒体库(Media Libraries),三维图形处理库(例如,OpenGL ES),二维图形引擎(例如,SGL)等。这些功能模块的具体含义和作用可以参考相关技术文档,在此不展开说明。这些功能模块的具体含义和作用可以参考相关技术文档,在此不展开说明。
运行时(Runtime)负责系统的调度和管理。Runtime包括核心库和虚拟机。核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。
运行时可以包括孵化器(zygote)进程。zygote进程由用户空间的第一个进程初始(init)进程启动,是Android操作系统运行的第一个AndroidRuntime进程,同时也是打通Native层和Java层的桥梁。Java层主要是用Java语言编写的代码,而Native层则是用C/C++等语言编写的代码。两者之间的交互是通过Java本地调用(Java Native Interface,JNI)来实现的。zygote进程的作用主要包括创建SystemServer进程,以及孵化(fork)其他应用程序进程。
硬件抽象层(HAL)是位于操作系统内核与上层软件之间的接口层,其目的在于将硬件抽象化。硬件抽象层是设备内核驱动的抽象接口,用于实现向更高级别的Java API框架提供访问底层设备的应用编程接口。HAL可以提供标准界面,向更高级别的Java API框架显示设备硬件功能。HAL包含多个库模块,例如相机HAL、音频HAL等。其中每个库模块都为特定类型的硬件组件实现一个界面。为当系统框架层API要求访问便携设备的硬件时,操作系统将为该硬件组件加载库模块。
内核层是硬件和软件之间的层。内核层是Android操作系统的基础。内核层负责硬件的驱动程序、网络、电源、系统安全以及内存管理等功能。内核层是硬件与软件之间的一个中间层,其作用是将应用程序的请求传递给硬件。内核层可以包括显示驱动、摄像头驱动、音频驱动和传感器驱动等。
需要说明的是,本申请提供的图5所示的电子设备的软件架构示意图仅作为一种示例,并不限定Android操作系统不同分层中的具体模块划分,具体可以参考常规技术中对Android操作系统软件架构的介绍。另外,本申请提供的广播分发处理方法还可以基于其他操作系统实现,本申请不再一一举例。
下面基于图5所示的电子设备的软件结构来介绍上述实施例的一种具体实现方式。
1、电子设备获取广播与广播接收者的对应关系,以及广播接收者所在应用对应的子线程选项信息。
如图6所示,广播接收者可以在其所在应用的清单文件中注册广播。例如,第一广播接收者可以在第一应用的清单文件中注册广播。这样,第一应用的清单文件中可以包括第一广播接收者和第一广播接收者能接收的广播之间的对应关系,以及第一应用对应的子线程选项信息。可理解,其他应用的清单文件中也可以包括该其他应用中的广播接收者与广播之间的对应关系,以及该其他应用对应的子线程选项信息。
如图6所示,电子设备启动(即开机)或应用安装或应用更新时,电子设备中的PMS可以解析应用(例如,第一应用)对应的Android应用程序包(Android applicationpackage,APK)文件。在PMS解析应用对应的APK文件的过程中,PMS可以解析应用的清单文件,从清单文件中获取广播与广播接收者的对应关系,还可以通过PMS中的参数识别模块来识别应用对应的子线程选项信息,从而获取广播接收者所在应用对应的子线程选项信息。PMS可以将获取到的广播与广播接收者的对应关系,以及广播接收者所在应用对应的子线程选项信息存储在PMS中。
可理解,APK是Android操作系统使用的一种应用程序包文件格式,用于分发和安装移动应用及中间件。一个Android应用程序的代码想要在Android设备上运行,需要先进行编译,然后被打包成为一个被Android操作系统所能识别的文件才可以被运行,这种能被Android操作系统识别并运行的文件格式就是APK。
下面结合图7介绍PMS解析清单文件的一种具体实现方式。
首先,对PMS解析清单文件过程中涉及的软件模块进行介绍。
如图7所示,PMS可以包括初始应用助手(InitAPPHelper)、安装包助手(InstallPackageHelper)、并行包解析器(ParallelPackageParser)、包解析器(PackageParser)、解析包工具(ParsingPackageUtils)和解析活动工具(ParserActivityUtils)。其中,解析活动工具可以包括参数识别模块。可理解,InitAPPHelper和InstallPackageHelper属于Helper类(助手类),通常用于实现辅助功能,可以具有状态(即类的成员变量),并且通常需要创建类的实例才能使用。ParallelPackageParser和PackageParser属于PackageParser类,它主要用来解析电子设备上的APK文件。ParsingPackageUtils和ParserActivityUtils属于Util类(工具类),通常用于实现通用功能或算法,只包含静态方法和常量,使用时一般不用创建类的实例。
其次,结合上述PMS中的软件模块具体说明PMS解析清单文件的流程。该流程可以包括但不限于以下步骤:
S201:初始应用助手接收到启动电子设备或安装应用或更新应用的请求。
在本申请的一些实施例中,用户可以触发启动电子设备。具体地,用户可以通过按下电子设备的电源键等方式来触发启动电子设备,相应的,电子设备启动引导加载程序bootloader,装载启动Linux内核,启动init进程,创建zygote进程和SystemServer进程。SystemServer进程可以启动PSM。PMS启动后,PMS中的初始应用助手可以接收到电子设备启动的请求。
在本申请的一些实施例中,用户可以触发在电子设备中安装应用。相应的,初始应用助手可以接收到安装应用的请求。
在本申请的一些实施例中,用户可以触发更新电子设备中的应用,或者电子设备可以自动更新电子设备中的应用。相应的,初始应用助手可以接收到更新应用的请求。
S202:初始应用助手开始扫描安装路径。
初始应用助手接收到启动电子设备或安装应用或更新应用的请求之后,可以开始扫描应用的安装路径。具体地,若初始应用助手接收到启动电子设备的请求,则初始应用助手可以扫描电子设备中每一个应用的安装路径。然而,若初始应用助手接收到安装应用的请求,则初始应用助手可以扫描即将安装的应用的安装路径。类似的,若初始应用助手接收到更新应用的请求,则初始应用助手可以扫描即将更新的应用的安装路径。
在本申请的一些实施例中,初始应用助手扫描电子设备中每一个应用的安装路径,具体可以包括:初始应用助手可以扫描system/app/目录下的各个系统应用的安装路径,扫描system/priv-app/目录下的各个预置应用的安装路径,以及扫描data/app/目录下的用户安装的各个第三方应用的安装路径。
在本申请的一些实施例中,初始应用助手可以调用scanDirTracedLI()方法以及scanDirTracedLI()方法中的scanDirLI()方法来扫描应用的安装路径。
S203:初始应用助手指示安装包助手扫描APK文件。
初始应用助手开始扫描应用的安装路径后,可以指示安装包助手扫描APK文件。也就是说,在扫描应用的安装路径的过程中,初始应用助手可以指示安装包助手扫描APK文件。
S204:安装包助手指示并行包解析器解析APK文件。
针对启动电子设备场景,安装包助手遍历文件目录(例如,system/app/目录,system/priv-app/目录,data/app/目录等)下的所有APK文件后,可以指示并行包解析器解析每一个APK文件。
针对安装应用场景,安装包助手扫描相应待安装的应用的APK文件后,可以指示并行包解析器解析该待安装的应用对应的APK文件。类似的,针对更新应用场景,安装包助手扫描相应待更新的应用的安装路径后,可以指示并行包解析器解析该待更新的应用对应的APK文件。
在本申请的一些实施例中,安装包助手指示并行包解析器解析APK文件,具体可以包括:安装包助手可以创建ParallelPackageParser对象,并调用submit()方法提交请求,执行解析APK文件。
S205:并行包解析器开始解析APK文件。
安装包助手可以调用并行包解析器来指示并行包解析器解析APK文件,相应的,并行包解析器被调用后,可以开始解析APK文件。可理解,并行包解析器内部可以使用线程池和队列执行APK文件解析。
S206:并行包解析器在解析APK文件的过程中调用包解析器。
并行包解析器在解析APK文件的过程中可以调用包解析器,以通过包解析器进一步解析APK文件。可理解,包解析器是用于磁盘上包文件(APKs)的解析器。它即支持打包成单个“单块”APK的应用程序的解析,同时也支持打包成多个APK在单个目录中的“集群”应用程序的解析。
在本申请的一些实施例中,并行包解析器调用包解析器,具体可以包括:并行包解析器可以调用包解析器中的parserPackage()方法解析APK文件,最终将静态文件转换成包(Package)。Package是内存中的数据结构,它包含了一个包的所有信息,比如包名、包路径、权限、四大组件等。
S207:包解析器指示解析包工具解析清单文件。
并行包解析器在解析APK文件的过程中调用包解析器后,包解析器可以进一步调用解析包工具来指示解析包工具来解析清单文件。
S208:解析包工具开始解析清单文件。
解析包工具被调用后,可以开始解析清单文件。可理解,在解析清单文件的过程中,解析包工具可以解析清单文件的标签(tag)。
示例性的,清单文件的标签可以包括<manifest>标签。<manifest>标签的下一级子标签可以包括<application>标签。<application>标签的下一级子标签可以<activity>标签、<provider>标签、<service>标签和<receiver>标签。其中,<manifest>标签可以指显示标签,<application>标签可以指应用标签,<activity>标签可以指活动标签,<provider>标签可以指提供者标签,<service>标签可以指服务标签,<receiver>标签可以指接收者标签(可称为接收者节点)。
在本申请的一些实施例中,解析包工具可以调用PackageParser.parseBaseApk()方法来解析清单文件。
S209:解析包工具指示解析活动工具解析清单文件中的接收者节点。
解析包工具开始解析清单文件后,可以指示解析活动工具解析清单文件中的接收者节点,以获取广播和广播接收者的相关信息。
S210:解析活动工具解析清单文件所包括的应用对应的子线程参数信息,以及应用中的广播接收者和广播的对应关系。
解析活动工具在解析APK文件所包括的清单文件中的接收者节点的过程中,可以解析得到该APK文件对应的应用所对应的子线程参数信息,以及该应用中注册的广播接收者和广播的对应关系(即第一对应关系)。在本申请的一些实施例中,解析活动工具还可以解析得到广播该APK文件对应的应用中注册的广播接收者所在进程。
可理解,解析活动工具可以将解析得到的广播和广播接收者的相关信息存储在PMS中。例如,解析活动工具可以将解析得到应用所对应的子线程参数信息、该应用中注册的广播接收者和广播的对应关系,以及该应用中注册的广播接收者所在进程的标识(例如,进程名称)存储在PMS中。
2、电子设备中的AMS接收广播后,基于广播与广播接收者的对应关系确定目标广播接收者,并将广播发送给目标广播接收者,目标广播接收者基于其所在应用对应的子线程选项信息确定是否开启子线程处理广播。
如图6所示,广播发送者可以向AMS发送第一广播。一方面,AMS接收广播发送者发送的第一广播后,可以将第一广播放入相应广播队列。另一方面,AMS接收广播发送者发送的第一广播之后,可以基于PMS中存储的广播与广播接收者的对应关系,来确定第一广播对应的广播接收者,即目标广播接收者,以及基于PMS中存储的应用对应的子线程选项信息,来确定目标广播接收者所在应用对应的子线程选项信息。在本申请的一些实施例中,AMS还可以基于PMS中储存的广播接收者所在进程确定目标广播接收者所在进程。可理解,目标广播接收者可以包括第一广播接收者,第一广播接收者所在进程为第一进程,第一广播接收者所在应用为第一应用。
可理解,本申请对广播发送者在系统架构中的具体分层不作限制。在本申请的一些实施例中,广播发送者可以在应用程序层。在本申请的又一些实施例中,广播发送者可以在应用程序框架层。
在本申请的一些实施例中,如图6所示,AMS可以通过向PMS发送目标广播接收者获取请求,来向PMS获取目标广播接收者和相应子线程选项信息。
根据上文,若目标广播接收者有多个,AMS可以向该多个目标广播接收者串行分发第一广播。下面以AMS向第一广播接收者分发第一广播为例,对AMS分发广播的具体过程以及相应目标广播接收者处理广播的具体过程进行介绍。
如图6所示,若第一广播接收者所在进程(即第一进程)已经创建,则AMS可以将第一广播和第一广播接收者所在应用(即第一应用)对应的子线程选项信息发送给第一进程的主线程。若第一进程尚未创建(即尚未运行),则AMS可以触发zygote进程fork第一进程,即创建第一进程。这个过程可以称为第一应用中的第一进程的冷启动过程。在zygote进程创建第一进程后,AMS可以将第一广播和第一应用对应的子线程选项信息发送给第一进程的主线程。若第一进程已经创建完成,则AMS可以直接将第一广播和第一应用对应的子线程选项信息发送给第一进程的主线程。这个过程可以称为第一应用中的第一进程的热启动过程。
第一进程的主线程接收第一广播和第一应用对应的子线程选项信息后,可以根据第一应用对应的子线程选项信息来确定是通过第一进程的主线程来处理第一广播,还是通过第一进程的子线程来处理第一广播。若第一应用对应的子线程选项信息未指示允许子线程处理广播,第一进程的主线程可以直接处理第一广播。若第一应用对应的子线程选项信息指示允许子线程处理广播,第一进程的主线程可以加载子线程,并由第一进程的子线程处理第一广播。
在本申请的一些实施例中,在第一应用对应的子线程选项信息包括第一参数信息的情况下,第一应用对应的子线程选项信息指示允许子线程处理广播,而在第一应用对应的子线程选项信息不包括第一参数信息的情况下,第一应用对应的子线程选项信息未指示允许子线程处理广播。
在本申请的一些实施例中,在第一应用对应的子线程选项信息中的特定字段为特定内容的情况下,第一应用对应的子线程选项信息指示允许子线程处理广播,否则,第一应用对应的子线程选项信息未指示允许子线程处理广播。
当然,第一应用对应的子线程选项信息指示允许子线程处理广播还可能有其他具体实现方式,本申请对此不作限制。
在本申请的一些实施例中,若第一应用对应的子线程选项信息未指示允许子线程处理广播,第一进程的主线程可以将第一广播封装为广播消息后放入第一进程的主线程对应的消息队列中,以等待处理。若第一应用对应的子线程选项信息指示允许子线程处理广播,第一进程的主线程可以加载子线程,并将第一广播封装为广播消息后放入第一进程的子线程对应的消息队列中,以等待处理。
在本申请的一些实施例中,如图6所示,第一进程的主线程可以通过运行在第一进程的主线程中的信息决策模块,基于第一应用对应的子线程选项信息来得到决策结果。第一进程的主线程还可以通过运行在第一进程的主线程中的子线程调度模块,基于决策结果来确定是否开启第一进程的子线程来处理第一广播。可理解,这里所提及的运行在第一进程的主线程中的信息决策模块和子线程调度模块,指的是第一应用中的信息决策模块和子线程调度模块。可理解,第一进程创建后,第一应用可以运行在第一进程中,那么,第一应用中的信息决策模块和子线程调度模块可以运行在第一进程中,具体可以运行在第一进程的主线程中。
在一种可能的实现方式中,第一进程的主线程可以通过运行在第一进程的主线程中的信息决策模块接收,确定第一应用对应的子线程选项信息是否指示允许子线程广播,得到决策结果,并将决策结果和第一广播一起封装得到广播消息,即得到添加有决策结果的广播消息,然后将该添加有决策结果的广播消息放入第一进程的主线程对应的消息队列(如图6所示的消息队列1)中。运行在第一进程的主线程中的子线程调度模块可以从消息队列1中获取添加有决策结果的广播消息,并根据该决策结果确定是否需要开启第一进程的子线程。
在一种可能的实现方式中,第一进程的主线程可以首先将第一广播封装为广播消息。在该封装过程中,第一进程的主线程可以通过运行在第一进程的主线程中的信息决策模块接收确定第一应用对应的子线程选项信息是否指示允许子线程广播,得到决策结果,并将决策结果添加到由第一广播封装得到的广播消息中,然后将该添加有决策结果的广播消息放入消息队列1中。运行在第一进程的主线程中的子线程调度模块可以从消息队列1中获取添加有决策结果的广播消息,并根据该决策结果确定是否需要开启第一进程的子线程。
可理解,若第一应用对应的子线程选项信息包括第一参数信息,决策结果为开启子线程(即第一决策结果),若开启第一进程的子线程选项信息不包括第一参数信息,决策结果为不开启子线程(即第二决策结果)。
若该决策结果为开启子线程,则运行在第一进程的主线程中的子线程调度模块可以开启第一进程的子线程。第一进程的主线程可以对该添加有决策结果的广播消息重新进行封装,得到重新封装后的广播消息,并将该重新封装后的广播消息放入第一进程的子线程对应的消息队列(如图6所示的消息队列2)中,以在消息队列2中排队等待第一进程的子线程进行处理。第一进程的主线程还可以删除消息队列1中相应广播消息,即删除由第一广播封装而成且添加有决策结果的广播消息。在本申请的一些实施例中,运行在第一进程的主线程中的子线程调度模块可以完成上述重新封装广播消息和删除消息队列1中的广播消息的步骤。
若该决策结果为不开启子线程,则由第一广播封装而成且添加有决策结果的广播消息继续在消息队列1中排队等待第一进程的主线程进行处理。
可理解,决策结果可以通过数字、文字、字符等形式来表示,本申请对此不作具体限制。例如,决策结果为1时,表示开启子线程,而决策结果为0时,表示不开启子线程。再例如,决策结果为start thread时,表示开启子线程,而决策结果为no thread时,表示不开启子线程。
需要说明的是,若在AMS向第一进程发送第一广播之前,第一进程尚未创建,则AMS触发zygote进程创建第一进程后,第一进程可以与第一应用进行绑定,待第一进程完成一部分应用环境初始化准备后,运行在第一进程的主线程中的信息决策模块才可以基于第一应用对应的子线程选项信息确定决策结果。
在本申请的一些实施例中,上述广播消息可以为RECEIVER消息。具体地,处理广播可以通过调用scheduleReceiver()方法完成。该方法通过发送一个RECEIVER消息到消息队列中,调用handleReceiver()方法处理该消息,进一步调用handleReceiver()方法中的onReceive()方法处理该消息。第一进程的主线程或子线程处理其对应的消息队列中的广播消息,具体可以包括:第一进程的主线程或子线程执行onReceive()方法。可理解,一般来说,onReceiver()方法涉及与其他组件的交互,例如,发送通知(Notification)、启动服务(Service)等。
在本申请的一些实施例中,消息队列1和消息队列2可以采用Handle机制。Handle机制为一种异步回调机制Handler,使用它,可以在完成一个很长时间的任务后做出相应的通知。可理解,Handle机制的具体含义和使用方法可以参考相关技术文档,本申请在此不展开说明。
下面结合图8A和图8B介绍在第一进程尚未创建的情况下,AMS向第一广播接收者分发第一广播的一种具体实现方式。
(1)AMS将第一广播分发到第一进程的主线程中,进行封装后将广播消息放入相应消息队列(如图8A所示)。
S301:若第一进程尚未创建,AMS触发创建第一进程。
若AMS准备向第一广播接收者发送第一广播时,第一广播接收者所在进程尚未创建,则AMS可以首先触发电子设备创建第一进程。可理解,AMS可以触发电子设备中的zygote进程来fork第一进程。
可理解,电子设备创建并启动第一进程后,ActivityThread中的main()方法开始调用,并开启消息循环队列。可理解,main()方法开始调用后,其中的attch()方法可以开始调用。attch()方法可以用于完成第一进程创建后的收尾工作。例如,attach()方法可以用于传输进程标识(Process Identification,pid)和用户标识(User Identification,uid)等信息来准备绑定应用。可理解,每个进程有唯一的pid。应用进程一开始运行,操作系统就会给该进程自动分配一个pid。uid可以用来识别应用程序。
需要说明的是,ActivityThread是在运行在主线程的main()方法中创建的对象,可以认为是主线程的一部分。在本申请的一些实施例中,ActivityThread也可以理解为主线程。在这种情况下,上述消息循环队列可以理解为上文所提及的主线程对应的消息队列。
在本申请的一些实施例中,AMS可以调用startProcessLocked()方法来创建第一进程。startProcessLocked()方法可以通过socket通道传递参数给zygote进程,zygote进程再基于该参数fork第一进程,并调用ZygoteInit.main()方法来实例化ActivityThread对象,并返回第一进程的进程标识。ActivityThread随后可以调用Looper.prepareLoop()和Looper.loop()来开启消息循环队列。
S302:第一进程通知AMS第一进程创建完成。
第一进程创建完成后,可以通知AMS。可理解,第一进程可以通过向AMS发送相应通知消息来通知AMS第一进程已经创建完成。
S303:AMS触发第一进程绑定第一应用。
AMS接收到第一进程创建完成的通知消息后,可以触发第一进程开始绑定第一应用。
S304:第一进程向消息队列1发送绑定应用消息。
第一进程开始绑定第一应用后,可以向第一进程的主线程对应的消息队列(即消息队列1)发送绑定应用消息。
在本申请的一些实施例中,第一进程可以调用bindApplication()方法实现第一进程和第一应用的绑定。bindApplication()方法的相关描述可以参考上文,本申请在此不再赘述。
S305:AMS向第一进程的主线程发送第一广播和第一应用对应的子线程选项信息。
AMS触发第一进程绑定第一应用之后,可以向第一进程的主线程发送第一广播和第一应用对应的子线程选项信息。相应的,第一进程的主线程可以接收AMS发送的第一广播和第一应用对应的子线程选项信息。
可理解,AMS接收到广播发送者发送的第一广播之后,可以确定是将第一广播加入前台广播队列,还是将第一广播加入后台广播队列,以及根据第一广播的分发顺序,来确定是将第一广播加入广播队列中的串行列表,还是并行列表。
可理解,AMS可以通过广播队列(BroadcastQueue)来实现第一广播的分发。广播队列主要负责将AMS接收到的广播发送给对应的广播接收者。在本申请的一些实施例中,AMS中的广播队列可以包括前台广播队列和后台广播队列。前台广播队列用于分发前台广播,而后台广播队列用于分发后台广播。前台广播和后台广播的具体含义和区别可以参考相关技术文档,本申请在此不展开说明。
可理解,广播队列中可以包括并行列表和串行列表。并行列表中存放的广播任务包括无序广播任务,以及动态广播接收者任务。串行列表中存放的广播任务包括有序广播任务,以及静态广播接收者任务。其中,静态广播接收者任务指的是针对静态注册的广播接收者的广播任务。在串行列表中,不同广播对应的广播任务按时间先后排队,而对应有多个静态注册的广播接收者的同一个广播所对应的广播任务按照广播接收者的优先级排队。可理解,串行列表中的一个广播任务处理完毕后才能处理下一个广播任务。
以第一广播为例,若第一广播对应有多个静态注册的目标广播接收者,则第一广播可以放入相应广播队列(例如,前台广播队列或后台广播队列)中的串行列表中。在该串行列表中,第一广播对应的每一个静态注册的目标广播接收者对应有一个广播任务。这也就意味着,第一广播对应有多个广播任务,该多个广播任务可以按照第一广播对应的多个静态注册的目标广播接收者的优先级排队。
在本申请的一些实施例中,串行列表中的第一广播对应的多个广播任务的顺序,与上文所提及的目标广播接收者列表中的相应目标广播接收者的顺序一致。可理解,第一广播对应的多个广播任务可以包括第一广播接收者对应的广播任务。第一广播接收者对应的广播任务在串行列表中的顺序与第一广播接收者在目标广播接收者列表中的顺序一致。例如,在第一广播对应的多个广播任务中,第一广播接收者对应的广播任务排在第一位,而第一广播接收者在目标广播接收者列表中的顺序也是第一位。
S306:第一进程的主线程将第一广播封装为广播消息。
第一进程的主线程接收AMS发送的第一广播和第一应用对应的子线程选项信息之后,可以对第一广播进行封装,得到广播消息。
在本申请的一些实施例中,第一进程的主线程可以对第一广播和第一应用对应的子线程选项信息进行封装,得到广播消息。
S307:运行在第一进程的主线程中的信息决策模块基于第一应用对应的子线程选项信息得到决策结果。
在本申请的一些实施例中,如步骤S305所示,第一进程的主线程接收AMS发送的第一应用对应的子线程选项信息之后,运行在第一进程的主线程中的信息决策模块可以基于该第一应用对应的子线程选项信息得到决策结果。
在本申请的又一些实施例中,电子设备可以先执行步骤S307,再执行步骤S306。在这种情况下,运行在第一进程的主线程中的信息决策模块可以基于第一应用对应的子线程选项信息得到决策结果,然后再将第一广播和该决策结果一起封装为广播消息,得到添加有决策结果的广播消息(如步骤S308所示)。
在本申请的又一些实施例中,电子设备在执行步骤S306时,第一进程的主线程可以将第一广播和第一应用对应的子线程选项信息封装得到广播消息。在这种情况下,运行在第一进程的主线程中的信息决策模块可以从该广播消息中取出第一应用对应的子线程选项信息,并基于该第一应用对应的子线程选项信息得到决策结果。
在本申请的一些实施例中,信息决策模块可以根据第一应用对应的子线程选项信息是否包括第一参数信息,来得到决策结果。具体地,如上文所述,若第一应用对应的子线程选项信息包括第一参数信息,决策结果为开启第一进程的子线程,若开启第一进程的子线程选项信息不包括第一参数信息,决策结果为不开启第一进程的子线程。
S308:第一进程的主线程将决策结果添加到由第一广播封装得到的广播消息中,并将该添加有决策结果的广播消息放入消息队列1。
运行在第一进程的主线程中的信息决策模块得到决策结果后,第一进程的主线程可以将决策结果添加到由第一广播封装得到的广播消息(如步骤S307所示)中,得到添加有决策结果的广播消息,并将该添加有决策结果的广播消息放入消息队列1中。
在本申请的一些实施例中,电子设备可以先执行步骤S307,再执行步骤S306。在这种情况下,第一进程的主线程封装得到的广播消息为添加有决策结果的广播消息,可以直接将该添加有决策结果的广播消息放入消息队列1中。
可理解,本申请对步骤S304和步骤S305的先后顺序不作限制,对步骤S306和步骤S307的先后顺序不作限制。
(2)运行在第一进程的主线程中的子线程调度模块确定是否开启第一进程的子线程来处理封装后的广播消息(如图8B所示)。
S309:若在处理绑定应用消息的过程中,第一进程完成一部分应用环境初始化准备,则第一进程的主线程通过运行在第一进程的主线程中的子线程调度模块获取消息队列1中的第一广播对应的广播消息。
如步骤S304所示,将绑定应用消息发送至消息队列1后,该绑定应用消息在消息队列1中排队等待第一进程的主线程进行处理。等到消息队列1中排在该绑定应用消息前的消息均被处理后,第一进程的主线程可以开始处理该绑定应用消息。若在处理该绑定应用消息的过程中,第一进程完成一部分应用环境初始化准备,则运行在第一进程的主线程中的子线程调度模块可以从消息队列1中获取第一广播对应的广播消息。可理解,该第一广播对应的广播消息可以指步骤S308所提及的由第一广播封装得到的且添加有决策结果的广播消息。
根据上文,在本申请的一些实施例中,第一进程的主线程可以通过handleBindApplication()方法处理该绑定应用消息。
S310:运行在第一进程的主线程中的子线程调度模块基于该第一广播对应的广播消息中的决策结果确定是否开启第一进程的子线程。
运行在第一进程的主线程中的子线程调度模块从消息队列1中获取第一广播对应的广播消息之后,可以从该第一广播对应的广播消息中得到运行在第一进程的主线程中的信息决策模块确定的决策结果(如步骤S307所示)。若该决策结果为开启子线程,则运行在第一进程的主线程中的子线程调度模块确定开启第一进程的子线程,然而,若该决策结果为不开启子线程,则运行在第一进程的主线程中的子线程调度模块确定不开启第一进程的子线程。值得注意的是,若运行在第一进程的主线程中的子线程调度模块确定不开启第一进程的子线程,则该第一广播对应的广播消息在消息队列1中排队等待第一进程的主线程进行处理。
示例性的,若运行在第一进程的主线程中的子线程调度模块得到的决策结果为1,则运行在第一进程的主线程中的子线程调度模块可以确定该决策结果表示开启子线程,则运行在第一进程的主线程中的子线程调度模块可以确定开启第一进程的子线程。若运行在第一进程的主线程中的子线程调度模块得到的决策结果为0,则运行在第一进程的主线程中的子线程调度模块可以确定该决策结果表示不开启子线程,则运行在第一进程的主线程中的子线程调度模块可以确定开启第一进程的子线程。
S311:若运行在第一进程的主线程中的子线程调度模块确定开启第一进程的子线程,则第一进程的主线程开启第一进程的子线程。
若运行在第一进程的主线程中的子线程调度模块确定需要开启第一进程的子线程,则第一进程的主线程可以加载第一进程的子线程。
S312:若运行在第一进程的主线程中的子线程调度模块确定开启第一进程的子线程,则第一进程的主线程重新封装该第一广播对应的广播消息,得到重新封装后的广播消息。
若运行在第一进程的主线程中的子线程调度模块确定需要开启第一进程的子线程,则第一进程的主线程可以对该第一广播对应的广播消息重新进行封装,得到重新封装后的广播消息。可理解,第一进程的主线程对该第一广播对应的广播消息重新进行封装,具体可以包括:第一进程的主线程更改该第一广播对应的广播消息的时间戳。第一进程的主线程对该第一广播对应的广播消息重新进行封装,具体还可以包括:第一进程的主线程更改该第一广播对应的广播消息的相关属性值。
在本申请的一些实施例中,上述重新封装广播消息的过程可以由运行在第一进程的主线程中的子线程调度模块完成。
S313:第一进程的主线程向消息队列2发送该重新封装后的广播消息。
第一进程的主线程得到重新封装后的广播消息后,可以将该重新封装后的广播消息发送至第一进程的子线程,并放入第一进程的子线程对应的消息队列(即消息队列2)中。
在本申请的一些实施例中,由运行在第一进程的主线程中的子线程调度模块重新封装广播消息,在这种情况下,运行在第一进程的主线程中的子线程调度模块可以将该重新封装后的广播消息放入消息队列2中。
S314:若运行在第一进程的主线程中的子线程调度模块确定开启第一进程的子线程,则第一进程的主线程删除消息队列1中的第一广播对应的广播消息。
若运行在第一进程的主线程中的子线程调度模块确定开启第一进程的子线程,则第一进程的主线程可以删除消息队列1中的第一广播对应的广播消息。
在本申请的一些实施例中,上述删除广播消息的过程可以由运行在第一进程的主线程中的子线程调度模块完成。
S315:第一进程的子线程处理消息队列2中的该重新封装后的广播消息。
第一进程的主线程将该重新封装后的广播消息放入消息队列2后,该重新封装后的广播消息可以在消息队列2中排队等待第一进程的子线程进行处理。等到消息队列2中排在该重新封装后的广播消息前面的消息均被处理之后,第一进程的子线程可以处理消息队列2中的该重新封装后的广播消息。
根据上文,在本申请的一些实施例中,第一进程的子线程处理消息队列2中的该重新封装后的广播消息,具体可以包括:第一进程的子线程执行onReceive()方法。
可理解,本申请对步骤S311和步骤S312的先后顺序不作限制,对步骤S312和步骤S314的先后顺序不作限制,对步骤S313和步骤S314的先后顺序不作限制。
可理解,通过上述方法,电子设备中的一个或多个应用无需通过其广播接收者所在进程的较为空闲的子线程来处理广播消息,而是可以通过其广播接收者所在进程的较为空闲的子线程来处理广播消息。在这种情况下,该广播消息无需在该子线程对应的消息队列中排队就能被该子线程处理,或者,该广播消息仅需在该子线程对应的消息队列中排队较短时间后就能被该子线程处理,减少了处理广播消息前的等待时长,提高了广播分发处理效率。
示例性的,AMS准备向第一进程中的第一广播接收者发送第一广播。如图9所示,t1时刻,AMS可以触发创建第一进程,即t1时刻为拉起进程阶段的起始时刻。若第一广播接收者所在应用(即第一应用)开启第一进程的子线程来处理第一广播对应的广播消息,则该第一广播对应的广播消息可以在t2时刻处理完毕。若第一应用不开启第一进程的子线程,而是由第一进程的主线程来处理第一广播对应的广播消息,则该第一广播对应的广播消息可以在t3时刻处理完毕。其中,t2时刻早于t3时刻。可理解,若第一应用开启子线程来处理广播消息,排队阶段的时长(即排队时长)会减少,会更快地将广播消息处理完毕,进而更快地开始向下一个广播接收者发送第一广播。
下面介绍本申请实施例涉及的电子设备的硬件结构。
请参阅图10,图10为本申请实施例提供的一种电子设备的硬件结构示意图。
如图10所示,电子设备可以包括处理器、外部存储器接口、内部存储器、音频模块、扬声器、受话器、麦克风、耳机接口、显示屏。
本申请实施例示意的结构并不构成对电子设备的具体限定。在本申请的一些实施例中,电子设备可以包括比图示更多的部件。例如,电子设备可以包括触摸传感器、加速度传感器和陀螺仪传感器等传感器。在本申请的一些实施例中,电子设备可以包括比图示更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件的组合实现。本申请实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对电子设备的结构限定。
处理器可以包括一个或多个处理单元。例如,处理器可以包括应用处理器(Application Processor,AP),调制解调处理器,图形处理器(Graphics ProcessingUnit,GPU),图像信号处理器(Image Signal Processor,ISP),控制器,视频编解码器,数字信号处理器(Digital Signal Processor,DSP),基带处理器,和/或神经网络处理器(Neural-network Processing Unit,NPU)等。处理器中还可以设置存储器,用于存储指令和数据。
电子设备可以通过GPU、显示屏和应用处理器等实现显示功能。GPU为图像处理的微处理器,连接显示屏和应用处理器。GPU用于执行数学和几何计算,用于图形渲染。处理器可包括一个或多个GPU,其执行程序指令以生成或改变显示信息。显示屏用于显示图像,视频等。在本申请的一些实施例中,电子设备可以包括1个或多个显示屏。
在本申请中,电子设备显示用户界面的能力,依赖于上述GPU、显示屏和应用处理器提供的显示功能。
内部存储器可以用于存储计算机可执行程序代码,可执行程序代码包括指令。处理器通过运行存储在内部存储器的指令,从而执行电子设备的各种功能应用以及数据处理。内部存储器可以包括存储程序区和存储数据区。其中,存储程序区可存储操作系统,至少一个功能所需的应用程序(例如,声音播放功能,图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(例如,音频数据,电话本等)等。
可理解,内部存储器可以包括一个或多个随机存取存储器(Random AccessMemory,RAM)和一个或多个非易失性存储器(Non-Volatile Memory,NVM)。例如,至少一个磁盘存储器件,闪存器件,通用闪存存储器(Universal Flash Storage,UFS)等。随机存取存储器可以由处理器直接进行读写,可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如,机器指令),还可以用于存储用户及应用程序的数据等。非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等,可以提前加载到随机存取存储器中,用于处理器直接进行读写。
在本申请中,实现本申请实施例所述的广播分发处理方法的代码可存储在非易失性存储器上。在实现该方法时,电子设备可将非易失性存储器中存储的可执行代码加载到随机存取存储器。
外部存储器接口可以用于连接外部存储卡,例如Micro SD卡,实现扩展电子设备的存储能力。外部存储卡可以通过外部存储器接口与处理器通信,实现数据存储功能。例如,将音乐,视频等文件保存在外部存储卡中。
电子设备可以通过音频模块、扬声器、受话器、麦克风、耳机接口,以及应用处理器等实现音频功能。
音频模块用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。扬声器,也称“喇叭”,用于将音频电信号转换为声音信号。受话器,也称“听筒”,用于将音频电信号转换成声音信号。麦克风,也称“话筒”,“传声器”,用于将声音信号转换为电信号。耳机接口用于连接有线耳机。
显示屏用于显示图像、视频等。在本申请的一些实施例中,电子设备可以包括1个或多个显示屏。电子设备可以通过图形处理器、显示屏和应用处理器等实现显示功能。
以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种广播分发处理方法,其特征在于,所述方法包括:
电子设备通过活动管理器服务AMS接收广播发送者发送的第一广播;
所述电子设备通过所述AMS基于所述第一广播确认目标广播接收者;
所述电子设备通过所述AMS确定所述目标广播接收者所在应用对应的子线程选项信息;所述子线程选项信息用于表示应用是否允许子线程处理广播;
所述电子设备向所述目标广播接收者发送所述第一广播的过程中,通过所述AMS向第一进程发送所述第一广播和第一信息;所述第一进程为第一广播接收者所在进程,所述第一广播接收者为所述目标广播接收者中的一个,所述第一信息为第一应用对应的子线程选项信息,所述第一应用为所述第一广播接收者所在应用;
在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的子线程处理所述第一广播。
2.如权利要求1所述的方法,其特征在于,所述电子设备通过所述AMS向所述第一进程发送所述第一广播和所述第一信息之前,所述第一进程还未创建;所述电子设备通过所述AMS向所述第一进程发送所述第一广播和所述第一信息之前,所述方法还包括:所述电子设备创建所述第一进程;
所述电子设备通过所述AMS向所述第一进程发送所述第一广播和所述第一信息之后,所述方法还包括:
所述电子设备通过所述第一进程的主线程接收所述第一广播和所述第一信息;
所述电子设备通过所述第一进程的主线程基于所述第一信息对所述第一广播进行封装,得到第一广播消息;
所述电子设备将所述第一广播消息放入第一消息队列;所述第一消息队列为所述第一进程的主线程对应的消息队列;
所述电子设备通过所述第一进程的子线程处理所述第一广播,具体包括:
所述电子设备启动所述第一进程的子线程;
所述电子设备通过所述第一进程的主线程对所述第一广播消息重新进行封装,得到第二广播消息;
所述电子设备通过所述第一进程的主线程将所述第二广播消息放入第二消息队列,并删除所述第一消息队列中的所述第一广播消息;所述第二消息队列为所述第一进程的子线程对应的消息队列。
3.如权利要求2所述的方法,其特征在于,所述电子设备通过所述第一进程的主线程基于所述第一信息对所述第一广播进行封装,得到第一广播消息,具体包括:
所述电子设备通过所述第一进程的主线程对所述第一广播进行封装,得到第三广播消息;
所述电子设备通过所述第一进程的主线程确定所述第一信息是否指示允许子线程处理广播;
在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的主线程得到第一决策结果,将所述第一决策结果添加到所述第三广播消息,得到所述第一广播消息;
在所述第一信息未指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的主线程得到第二决策结果,将所述第二决策结果添加到所述第三广播消息,得到所述第一广播消息;
所述电子设备得到所述第一广播消息之后,所述方法还包括:
在所述第一广播消息包括所述第二决策结果的情况下,所述电子设备通过所述第一进程的主线程处理所述第一广播消息;
所述在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的子线程处理所述第一广播,具体包括:
在所述第一广播消息包括所述第一决策结果的情况下,所述电子设备通过所述第一进程的子线程处理所述第二广播消息。
4.如权利要求2所述的方法,其特征在于,所述电子设备通过所述第一进程的主线程基于所述第一信息对所述第一广播进行封装,得到第一广播消息,具体包括:
所述电子设备通过所述第一进程的主线程确定所述第一信息是否指示允许子线程处理广播;
在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的主线程得到第一决策结果,并对所述第一广播和所述第一决策结果进行封装,得到所述第一广播消息;
在所述第一信息未指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的主线程得到第二决策结果,并对所述第一广播和所述第二决策结果进行封装,得到所述第一广播消息;
所述电子设备得到所述第一广播消息之后,所述方法还包括:
在所述第一广播消息包括所述第二决策结果的情况下,所述电子设备通过所述第一进程的主线程处理所述第一广播消息;
所述在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的子线程处理所述第一广播,具体包括:
在所述第一广播消息包括所述第一决策结果的情况下,所述电子设备通过所述第一进程的子线程处理所述第二广播消息。
5.如权利要求1所述的方法,其特征在于,所述电子设备通过所述AMS向所述第一进程发送所述第一广播和所述第一信息之前,所述第一进程已创建;所述电子设备通过所述AMS向所述第一进程发送所述第一广播和第一信息之后,所述方法还包括:
所述电子设备通过所述第一进程的主线程接收所述第一广播和所述第一信息;
所述电子设备通过所述第一进程的主线程确定所述第一信息是否指示允许子线程处理广播;
在所述第一信息未指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的主线程对所述第一广播进行封装,得到第一广播消息,并将所述第一广播消息放入第一消息队列;所述第一消息队列为所述第一进程的主线程对应的消息队列;
所述在所述第一信息指示允许子线程处理广播的情况下,所述电子设备通过所述第一进程的子线程处理所述第一广播,具体包括:
在所述第一信息指示允许子线程处理广播的情况下,所述电子设备启动所述第一进程的子线程;
所述电子设备通过所述第一进程的主线程对所述第一广播进行封装,得到所述第一广播消息,并将所述第一广播消息放入第二消息队列;所述第二消息队列为所述第一进程的子线程对应的消息队列。
6.如权利要求1-5中任一项所述的方法,其特征在于,所述电子设备通过所述AMS基于所述第一广播确认目标广播接收者,具体包括:所述电子设备从第一对应关系中确定所述第一广播对应的一个或多个广播接收者为所述目标广播接收者;
所述电子设备通过活动管理器服务AMS接收广播发送者发送的第一广播之前,所述方法还包括:
所述电子设备接收到启动所述电子设备的指令;
响应于所述启动所述电子设备的指令,所述电子设备启动,并解析所述电子设备中的应用的包文件,得到第二对应关系,以及所述电子设备中应用对应的子线程选项信息;
所述电子设备保存所述第二对应关系,以及所述电子设备中的应用对应的子线程选项信息。
7.如权利要求6所述的方法,其特征在于,所述电子设备中的应用不包括所述第一应用;所述电子设备通过活动管理器服务AMS接收广播发送者发送的第一广播之前,所述方法还包括:
所述电子设备接收到安装所述第一应用的指令;
响应于所述安装所述第一应用的指令,所述电子设备解析所述第一应用的包文件,得到所述第一应用中的广播接收者与广播的对应关系,以及所述第一信息;
所述电子设备基于所述第一应用中的广播接收者与广播的对应关系更新所述第二对应关系,得到所述第一对应关系,并保存所述第一对应关系和所述第一信息。
8.如权利要求1-5中任一项或权利要求7所述的方法,其特征在于,所述方法还包括:
所述电子设备接收到更新所述第一应用的指令;
响应于所述更新所述第一应用的指令,所述电子设备解析所述第一应用的包文件,得到所述第一应用中的广播接收者与广播的对应关系,以及第二信息;
所述电子设备保存所述第一应用中的广播接收者与广播的对应关系,以及所述第二信息。
9.如权利要求1-5中任一项或权利要求7所述的方法,其特征在于,所述电子设备向所述目标广播接收者发送所述第一广播,具体包括:所述电子设备向所述目标广播接收者串行发送所述第一广播。
10.一种电子设备,包括一个或多个存储器、一个或多个处理器,其特征在于,所述存储器用于存储计算机程序;所述处理器用于调用所述计算机程序,使得所述电子设备执行权利要求1-9中任一项所述的方法。
11.一种计算机存储介质,其特征在于,包括:计算机指令;当所述计算机指令在电子设备上运行时,使得所述电子设备执行权利要求1-9中任一项所述的方法。
CN202311274208.8A 2023-09-28 2023-09-28 一种广播分发处理方法及相关设备 Active CN117076158B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311274208.8A CN117076158B (zh) 2023-09-28 2023-09-28 一种广播分发处理方法及相关设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311274208.8A CN117076158B (zh) 2023-09-28 2023-09-28 一种广播分发处理方法及相关设备

Publications (2)

Publication Number Publication Date
CN117076158A true CN117076158A (zh) 2023-11-17
CN117076158B CN117076158B (zh) 2024-03-12

Family

ID=88715503

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311274208.8A Active CN117076158B (zh) 2023-09-28 2023-09-28 一种广播分发处理方法及相关设备

Country Status (1)

Country Link
CN (1) CN117076158B (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107330064A (zh) * 2017-06-29 2017-11-07 郑州云海信息技术有限公司 一种基于cifs协议创建小文件的方法及系统
CN112445588A (zh) * 2019-09-05 2021-03-05 阿里巴巴集团控股有限公司 应用任务的处理方法、装置、设备及可读存储介质
CN113268325A (zh) * 2021-05-21 2021-08-17 北京达佳互联信息技术有限公司 一种调度任务的方法、装置及存储介质
US11228644B1 (en) * 2020-11-10 2022-01-18 Capital One Services, Llc Systems and methods to generate contextual threads
CN114168291A (zh) * 2021-12-09 2022-03-11 有半岛(北京)信息科技有限公司 一种主线程卡顿处理方法、装置、设备及存储介质
CN116185669A (zh) * 2023-04-27 2023-05-30 荣耀终端有限公司 一种广播分发方法及相关设备
CN116680055A (zh) * 2023-06-13 2023-09-01 北京自如信息科技有限公司 一种异步任务处理方法、装置、计算机设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107330064A (zh) * 2017-06-29 2017-11-07 郑州云海信息技术有限公司 一种基于cifs协议创建小文件的方法及系统
CN112445588A (zh) * 2019-09-05 2021-03-05 阿里巴巴集团控股有限公司 应用任务的处理方法、装置、设备及可读存储介质
US11228644B1 (en) * 2020-11-10 2022-01-18 Capital One Services, Llc Systems and methods to generate contextual threads
CN113268325A (zh) * 2021-05-21 2021-08-17 北京达佳互联信息技术有限公司 一种调度任务的方法、装置及存储介质
CN114168291A (zh) * 2021-12-09 2022-03-11 有半岛(北京)信息科技有限公司 一种主线程卡顿处理方法、装置、设备及存储介质
CN116185669A (zh) * 2023-04-27 2023-05-30 荣耀终端有限公司 一种广播分发方法及相关设备
CN116680055A (zh) * 2023-06-13 2023-09-01 北京自如信息科技有限公司 一种异步任务处理方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN117076158B (zh) 2024-03-12

Similar Documents

Publication Publication Date Title
EP3403177B1 (en) Managing delivery of code and dependent data using application containers
WO2018161812A1 (zh) 一种用户界面渲染方法及装置
US11829787B2 (en) Multi-process model for cross-platform applications
US9798555B2 (en) Application implementation method and apparatus
KR102481065B1 (ko) 애플리케이션 기능 구현 방법 및 전자 디바이스
WO2019232948A1 (zh) 监控邮件自动发送方法、系统、计算机设备和存储介质
JP7100154B2 (ja) プロセッサコアのスケジューリング方法、装置、端末及び記憶媒体
CN110955499B (zh) 处理器核心配置方法、装置、终端及存储介质
WO2022089207A1 (zh) 一种跨设备应用交互方法、电子设备与服务器
CN108268261B (zh) 一种智能终端的ui定制方法、存储介质及智能终端
CN116185669B (zh) 一种广播分发方法及相关设备
CN117076158B (zh) 一种广播分发处理方法及相关设备
JP7319431B2 (ja) アプリケーション機能の実施方法及び電子装置
KR20130012603A (ko) 복수의 운영체제와 호환 가능한 가상머신 생성 방법 및 가상머신 프로그램을 저장한 기록매체
CN114356520A (zh) 微应用的运行方法、装置、设备、存储介质及程序产品
US20110124327A1 (en) Method for Telecommunications Device Synchronization
CN116700694B (zh) 小程序引擎
CN115981576B (zh) 共享数据的方法、电子设备及存储介质
WO2022104883A1 (zh) 一种多类型场景共存的添加方法、装置、终端及存储介质
JP2003280926A (ja) 情報処理装置及びその方法、記憶媒体、プログラム
CN117992189A (zh) 多系统下的窗口实现方法及电子设备
CN117724852A (zh) 一种云电脑计算资源分配方法及装置
CN117992251A (zh) 广播分发方法及电子设备
CN116737404A (zh) 用于应用接续的方法及终端设备
CN116263683A (zh) 应用界面跨设备显示方法、设备系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant