内存申请方法及相关设备

本申请涉及内存管理领域，尤其涉及一种内存申请方法及相关设备。

电子设备(例如手机)上通常有很多应用，在运行应用之前，需要从操作系统申请指定大小的内存池，该内存池用于应用的启动与运行时所需内存的分配。然而，现有的内存垃圾回收机制不能将应用启动过程中产生的内存碎片进行有效利用。对于内存受限的设备，初始化申请的内存池大小有限，离散的内存碎片降低了内存空间的利用率，导致可同时运行的应用数量受限。

本申请实施例提供了一种内存申请方法及相关设备，能够提高内存空间的利用率。

本申请第一方面提供了一种内存申请方法，应用于电子设备，所述电子设备包括至少一个应用，所述方法包括：记录所述至少一个应用在第一启动过程的内存申请和释放情况；在所述至少一个应用的第二启动过程，当所述至少一个应用申请内存时，根据所述至少一个应用在所述第一启动过程的内存申请和释放情况，确定申请的内存是否会在所述第二启动过程释放，其中所述第二启动过程是所述第一启动过程之后的另一次启动过程；根据申请的内存是否会在所述第二启动过程释放，确定用于分配所述申请的内存的区域。

根据应用在第一启动过程的内存申请和释放情况，在应用的第二启动过程中从合适的内存空间为应用分配内存，可以保证应用启动后占用的内存空间连续无碎片，提高内存空间的利用率，使电子设备在有限内存空间可以运行更多应用。

在一些可选的实施方式中，所述记录所述至少一个应用在第一启动过程的内存申请和释放情况包括：通过内存记录表记录所述至少一个应用在所述第一启动过程的内存申请和释放情况，所述内存记录表包括内存申请序号、内存释放标记和内存地址。

内存记录表可以高效地记录应用在第一启动过程的内存申请和释放情况，方便后续利用这些信息。

在一些可选的实施方式中，所述记录所述应用在第一启动过程的内存申请和释放情况包括：通过内存申请表和内存释放表记录所述应用在第一启动过程的内存申请和释放情况，所述内存申请表包括内存申请序号和内存申请地址，所述内存释放表包括内存释放序号和内存释放地址。

内存申请表和内存释放表记录可以有效记录应用在第一启动过程的内存申请和释放情况，方便后续利用这些信息。

在一些可选的实施方式中，所述根据申请的内存是否会在所述第二启动过程释放，确定用于分配所述申请的内存的区域包括：若所述申请的内存会在所述第二启动过程释放，确定用于分配所述申请的内存的区域为所述电子设备的临时内存空间；若所述申请的内存不会在所述第二启动过程释放，确定用于分配所述申请的内存的区域为所述电子设备的内存池。

在应用第二启动过程，对于会释放的资源，不在内存池中分配内存，而在临时内存空间分配内存，对于非释放资源，还是从内存池中分配，能够使所有未释放的内存存储在一段连续的内存空间，而临时内存空间在应用启动完成后释放掉，从而保证应用的代码、数据资源、运行堆栈等启动后未释放资源的内存空间连续且无碎片，提高内存池利用率，使得在有限内存空间可运行更多的应用。

在一些可选的实施方式中，所述方法还包括：对所述电子设备的内存池中各个应用占用的内存进行整体平移，使所述内存池中所述各个应用之间的空闲内存连续分布；对所述内存池中连续分布的空闲内存进行整合。

通过对内存池中各个应用占用的内存进行整体平移，以及对内存池中连续分布的空闲内存进行整合，可以进一步提高内存空间的利用率，解决了多应用场景下应用退出后内存池中不同应用之间产生内存碎片的技术问题。

在一些可选的实施方式中，所述对所述电子设备的内存池中各个应用占用的内存进行整体平移之前，所述方法还包括：确定所述至少一个应用在所述第一启动过程占用的内存池大小；判断所述内存池中每个空闲内存的大小是否都小于所述至少一个应用在所述第一启动过程占用的内存池大小，以及判断所述内存池中所有空闲内存的大小之和是否不小于所述至少一个应用在所述第一启动过程占用的内存池大小；若所述内存池中每个空闲内存的大小都小于所述至少一个应用在所述第一启动过程占用的内存池大小，并且所述内存池中所有空闲内存的大小之和不小于所述至少一个应用在所述第一启动过程占用的内存池大小，对所述内存池中各个应用占用的内存进行整体平移。

通过确定应用启动过程占用的内存池大小，当内存池可用内存空间足够但每个空闲内存较小而导致应用无法启动时，进行内存整理，能够在新的应用启动时对内存池中不同应用之间产生的内存碎片进行整理。

在一些可选的实施方式中，所述方法还包括：若所述内存池中所有空闲内存的大小之和小于所述至少一个应用在所述第一启动过程占用的内存池大小，发出内存申请错误提醒。

若所述内存池中所有空闲内存的大小之和小于所述至少一个应用在所述第一启动过程占用的内存池大小，表明无法通过内存碎片整理为应用申请足够的内存，此时发出内存申请错误提醒，可以便于用户及时采取措施解决内存不足的问题。

在一些可选的实施方式中，所述对所述内存池中各个应用占用的内存进行整体平移包括：计算所述内存池中每个应用对应的平移偏移量；根据所述平移偏移量对所述每个应用相关的指针变量进行修改；根据所述每个应用原来的加载首地址和平移偏移量确定所述每个应用新的加载首地址；将所述每个应用从所述原来的加载首地址拷贝到所述新的加载首地址。

当对内存池中的应用进行整体平移时，通过计算每个应用对应的平移偏移量，修改应用相关的指针变量，可以使得指针变量指向应用整体平移后正确的位置。

在一些可选的实施方式中，所述计算所述内存池中每个应用对应的平移偏移量包括：记录所述内存池中每个应用启动时的加载首地址和占用的内存池大小；根据所述内存池中每个应用启动时的加载首地址和占用的内存池大小，计算所述平移偏移量。

内存池中每个应用启动时的加载首地址和占用的内存池大小表明应用之间的内存碎片大大小，根据内存池中每个应用启动时的加载首地址和占用的内存池大小可以准确计算每个应用的平移偏移量。

在一些可选的实施方式中，所述记录所述内存池中每个应用启动时的加载首地址和占用的内存池大小包括：将所述内存池中每个应用启动时的加载首地址和占用的内存池大小记录到从应用内存信息链表，所述应用内存信息链表中的每个链表节点对应一个应用；所述根据所述内存池中每个应用启动时的加载首地址和占用的内存池大小，计算所述内存池中每个应用对应的平移偏移量包括：逐一获取所述应用内存信息链表中的链表节点；若所述链表节点是所述应用内存信息链表的首节点，并且所述链表节点的加载首地址不等于所述内存池的首地址，确定所述链表节点对应的平移偏移量等于所述链表节点的加载首地址与所述内存池的首地址之差；若所述链表节点不是所述应用内存信息链表的首节点，并且所述链表节点的加载首地址大于所述链表节点的前一节点的加载首地址与所述链表节点占用的内存池大小之和，确定所述链表节点对应的平移偏移量等于所述链表节点的加载首地址与所述前一节点的加载首地址再减去所述链表节点占用的内存池大小；若所述链表节点是所述应用内存信息链表的首节点，并且所述链表节点的加载首地址等于所述内存池的首地址，或者，若所述链表节点不是所述应用内存信息链表的首节点，并且所述链表节点的加载首地址不大于所述链表节点的前一节点的加载首地址与所述链表节点占用的内存池大小之和，确定所述链表节点对应的平移偏移量等于0。

应用内存信息链表可以高效地应用启动时的加载首地址和应用占用的内存池大小，通过应用内存信息链表可以快速计算内存池中每个应用对应的平移偏移量。

在一些可选的实施方式中，所述每个应用为WebAssembly应用，所述根据每个应用对应的平移偏移量对所述应用相关的指针变量进行修改包括：根据所述每个应用对应的平移偏移量修正所述每个应用对应的module_data结构体指针及所述module_data结构体内部所有指向资源数据的指针变量的值。

WAMR在运行WASM应用时，会创建一个线程，并将module_data结构体指针作为参数传递进去。通过module_data结构体指针可以查运行时运行WASM应用所需要的所有资源。通过修正module_data结构体指针及module_data结构体内部所有指向资源数据的指针变量的值，可以使得指针变量指向应用整体平移后正确的位置。

本申请第二方面提供了一种计算机可读存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面所述的内存申请方法。

本申请第三方面提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于调用所述存储器中的指令，使得所述电子设备执行如第一方面所述的内存申请方法。

本申请第四方面提供了一种芯片系统，该芯片系统应用于电子设备；芯片系统包括接口电路和处理器；接口电路和处理器通过线路互联；接口电路用于从电子设备的存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令；当处理器执行该计算机指令时，芯片系统执行如第一方面所述的内存申请方法。

本申请第五方面提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面所述的内存申请方法。

应当理解地，上述提供的第二方面的计算机可读存储介质、第三方面所述的电子设备、第四方面所述的芯片系统、及第五方面所述的计算机程序产品均与上述第一方面的方法对应，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

图1是本申请实施例提供的内存申请方法的应用场景示意图。

图2是本申请实施例提供的内存申请方法的流程图。

图3是本申请实施例使用的内存记录表的示意图。

图4是利用内存记录表记录应用在第一启动过程的内存申请和释放情况的示意图。

图5是利用内存申请表和内存释放表分别记录应用在第一启动过程的内存申请和释放情况的示意图。

图6是根据现有的内存回收机制内存使用情况的示意图。

图7是根据本申请提供的内存申请方法内存使用情况的示意图。

图8是根据现有的内存管理方法，在多应用场景下，当应用退出后，内存池中不同应用之间出现内存碎片的示意图。

图9是在图3的基础上进行内存碎片整理的流程图。

图10是本申请另一实施例提供的内存记录表的示意图。

图11是根据图9进行内存碎片整理的示意图。

图12是本申请实施例提供的对内存池中应用占用的内存进行整体平移(即图9中步骤904)的细化流程图。

图13是本申请实施例使用的module_data结构体的示意图。

图14是本申请实施例提供的计算内存池中每个应用对应的平移偏移量(即图12中步骤1201)的细化流程图。

图15是本申请实施例使用的应用内存信息链表的示意图。

图16是本申请实施例提供的电子设备的硬件结构示意图。

图17是本申请实施例提供的电子设备的软件结构示意图。

为了便于理解，示例性的给出了部分与本申请实施例相关概念的说明以供参考。

需要说明的是，本申请中“至少一个”是指一个或者多个，“多个”是指两个或多于两个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不是用于描述特定的顺序或先后次序。

为了更好地理解本申请实施例提供的内存申请方法及相关设备，下面首先对本申请内存申请方法的应用场景进行描述。图1是本申请实施例提供的内存申请方法的应用场景示意图。

如图1所示，本申请实施例提供的内存申请方法应用于电子设备10。电子设备10包括多个应用100，例如邮箱、计算器、相机等。电子设备10可以是智能手机、智能手表、智能音箱、平板电脑、台式计算机、膝上型便携计算机、车载电脑等。

在本申请的一个实施例中，应用100可以是WebAssembly(简称为“WASM”)应用，电子设备10包括WebAssembly执行环境，电子设备10将WebAssembly应用编译成WebAssembly格式后，通过WebAssembly Micro Runtime(简称为“WAMR”)在WebAssembly执行环境中运行。

WebAssembly是一项底层代码执行规范，其核心目标是安全性、可移植性，具有紧凑代码格式和较高的执行效率。基于WASM的安全性要求，WASM程序不能损坏其执行环境、跳转到任意位置或执行其他未定义的行为。即使是不受信任的模块也可以与其他代码一起在相同的地址空间中安全地执行。

WebAssembly Micro Runtime是支持WASM规范的运行时，主要用于内存较小的终端设备，可以将编译成WASM格式的应用托管在WAMR上，每个WASM应用都只能访问自己的内存空间和系统允许的接口，从而提供了一种基于WASM的安全沙箱机制。目前WAMR运行时支持解释执行、预先编译等程序执行方式。

根据本申请实施例提供的内存申请方法，电子设备10能够根据应用在第一启动过程的内存申请和释放情况从不同内存空间为应用分配内存，保证应用启动后占用的内存连续，提高电子设备10的内存利用率，使电子设备10在有限内存空间可以运行更多应用。

图2是本申请实施例提供的内存申请方法的流程图。

201，记录应用在第一启动过程的内存申请和释放情况。

可以在应用公开发行(例如上架到应用商店)之前启动应用进入第一启动过程，记录应用在第一启动过程的内存申请和释放情况。

在本申请的一个实施例中，内存的申请由malloc例程完成，内存的释放由free例程完成。每次申请内存，malloc例程获取应用申请的内存，返回内存地址，并记录内存大小。每次释放内存，free例程根据要释放的内存地址，查阅内存大小，将内存释放给操作系统。可以通过监控malloc例程和free例程来获取应用在第一启动过程的内存申请和释放情况。

在本申请的一个实施例中，可以通过内存记录表记录应用在第一启动过程的内存申请和释放情况。内存记录表可以包括内存申请序号、内存释放标记和内存地址。

每个应用可以对应一个内存记录表。

图3是本申请实施例使用的内存记录表的示意图。

在本申请的一个实施例中，内存记录表可以存储为应用特征文件。应用特征文件是表达应用加载和启动时刻资源分配和回收行为的文件。在本申请其他的实施例中，内存记录表可以存储为其他文件。

内存记录表可以不保存电子设备中，例如可以保存在应用商店中。

内存申请序号用于表示申请内存的顺序。每次申请内存，内存申请序号可以加1。例如，参阅图3所示，第一次申请内存对应的内存申请序号为“1”，第二次申请内存对应的内存申请序号为“2”，第三次申请内存对应的内存申请序号为“3”，……。

内存释放标记用于表示应用在第一启动过程中申请的内存是否会在第一启动过程释放。例如，若应用在第一启动过程申请的内存不会在第一启动过程释放，内存释放标记可以是“不释放”或者“No free”或者“╳”。若应用在第一启动过程申请的内存会在第一启动过程释放，内存释放标记可以是“释放”或者“Free”或者“√”。

在本申请的一个实施例中，在应用的第一启动过程，当应用申请内存时，对应的内存释放标记记录为“不释放”或者“No free”或者“╳”，当应用释放内存时，对应的内存释放标记从“不释放”或者“No free”或者“╳”修改为“释放”或者“Free”或者“√”。

当应用释放内存时，可以比较要释放的内存地址和内存记录表中的内存地址，查对应的内存释放标记(可以先查对应的内存申请序号，再查对应的内存释放标记)，将对应的内存释放标记从“不释放”或者“No free”或者“╳”修改为“释放”或者“Free”或者“√”，以表示该内存地址内的数据会在第一启动过程释放掉。

内存记录表中的内存地址记录的是在第一启动过程分配的内存地址。内存记录表所记录的内存地址与实际启动时所占用的内存地址并无关系，在第一启动过程记录的内存地址只是用来判断内存申请序号所代表的内存是否会被释放。

在本申请的一个实施例中，在第一启动过程，当应用释放内存时，还可以将要释放的内存对应的内存地址删除。

图4是利用内存记录表记录应用在第一启动过程的内存申请和释放情况的示意图。

参见图4所示，在应用的第一启动过程，内存操作包括：401，申请16字节的内存A；402，申请16字节的内存B；403，申请16字节的内存C；404，释放内存B；405，申请32字节的内存D。当申请内存A时，在内存记录表中增加一条内存记录，该内存记录对应的内存申请序号为“1”，内存释放标记为“No free”，内存地址为“0x8020000”(参见图4A)。当申请内存B时，在内存记录表中增加一条内存记录，该内存记录对应的内存申请序号为“2”，内存释放标记为“No free”，内存地址为“0x8020010”(参见图4B)。当申请内存C时，在内存记录表中增加一条内存记录，该内存记录对应的内存申请序号为“3”，内存释放标记为“No free”，内存地址为“0x8020020”(参见图4C)。当释放内存B时，根据要释放的内存地址在内存记录表中查到内存申请序号为“2”的内存记录，将内存申请序号为“2”的内存记录的内存释放标记修改为“Free”，将内存申请序号为“2”的内存记录的内存地址删除(参见图4D)。当申请内存D时，在内存记录表中增加一条内存记录，该内存记录对应的内存申请序号为“4”，内存释放标记为“No free”，内存地址为“0x8020040”(参见图4E)。

应当理解，在本申请的其他实施例中，可以使用内存申请表记录应用在第一启动过程申请内存的情况，使用内存释放表记录应用在第一启动过程释放内存的情况。

图5是利用内存申请表和内存释放表分别记录应用在第一启动过程的申请内存和释放内存的情况的示意图。其中，图5A为内存申请表，图5B为内存释放表，图5与图3相对应。参阅图5所示，内存申请表可以包括内存申请序号和内存申请地址，内存释放表可以包括内存释放序号和内存释放地址。若内存申请表中的内存申请地址包含在内存释放表中，则该内存申请地址对应的内存会在启动过程释放。

202，在应用的第二启动过程，当应用申请内存时，根据应用在第一启动过程的内存申请和释放情况，确定申请的内存是否会在第二启动过程释放。

第二启动过程是所述启动过程之后的另一次启动过程。例如，在应用公开发布(例如上架到应用商店)之前对应用进行第一启动，记录应用在第一启动过程的内存申请和释放情况。在应用公开发布(例如上架到应用商店)之后，用户从应用商店或者其他下载地址下载了该应用，对应用进行第二启动，在应用的第二启动过程中参考第一启动过程中的内存申请和释放情况进行内存申请，确定申请的内存是否会在第二启动过程释放。

又如，在一种可能的实现方式中，可以以应用的任意某次或某几次历史的启动过程作为第一启动过程，记录应用在第一启动过程的内存申请和释放情况。以该某次或某几次历史的启动过程之后的启动过程作为第二启动过程，在应用的第二启动过程中参考第一启动过程中的内存申请和释放情况进行内存申请，确定申请的内存是否会在第二启动过程释放。

第一启动过程和第二启动过程只有时间先后的限定，并不局限于特定的启动过程。

在本申请的一个实施例中，参阅图3所示，在第二启动过程中，当应用申请内存时，可以从内存记录表中确定本次内存申请对应的内存申请序号，根据本次内存申请对应的内存申请序号从内存记录表中获取对应的内存释放标记，根据获取的内存释放标记确定申请的内存是否会在第二启动过程释放。

例如，参阅图3所示，若应用在第二启动过程第一次申请内存，内存记录表中对应的内存申请序号为“1”，对应的内存释放标记为“No free”，则确定申请的内存不会在第二启动过程释放。若应用在第二启动过程第二次申请内存，内存记录表中对应的内存申请序号为“2”，对应的内存释放标记为“Free”，则确定申请的内存会在第二启动过程释放。若应用在第二启动过程第三次申请内存，内存记录表中对应的内存申请序号为“3”，对应的内存释放标记为“No free”，则确定申请的内存不会在第二启动过程释放。若应用在第二启动过程第四次申请内存，内存记录表中内存申请对应的内存申请序号为“4”，对应的内存释放标记为“No free”，则确定申请的内存不会在第二启动过程释放。

在本申请的另一个实施例中，参阅图5所示，在第二启动过程中，当应用申请内存时，可以从内存申请表确定本次内存申请对应的内存申请序号，根据本次内存申请对应的内存申请序号从内存申请表中获取对应的内存地址，根据获取的内存地址和内存释放表确定申请的内存是否会在第二启动过程释放。若获取的内存地址包含在内存释放表中，则申请的内存会在第二启动过程释放。若获取的内存地址不包含在内存释放表中，则申请的内存不会在第二启动过程释放。

例如，参阅图5所示，若应用在第二启动过程第一次申请内存，内存申请表中内存申请对应的内存申请序号为“1”，对应的内存地址为“0x8020000”，内存地址“0x8020000”不包含在内存释放表中，则确定申请的内存不会在第二启动过程释放。若应用在第二启动过程第二次申请内存，内存申请表中内存申请对应的内存申请序号为“2”，对应的内存地址为“0x8020010”，内存地址“0x8020010”包含在内存释放表中，则确定申请的内存会在第二启动过程释放。若应用在第二启动过程第三次申请内存，内存申请表中内存申请对应的内存申请序号为“3”，对应的内存地址为“0x8020020”，内存地址“0x8020020”不包含在内存释放表中，则确定申请的内存不会在第二启动过程释放。若应用在第二启动过程第四次申请内存，内存申请表中内存申请对应的内存申请序号为“4”，对应的内存地址为“0x80200040”，内存地址“0x8020040”不包含在内存释放表中，则确定申请的内存不会在第二启动过程释放。

在本申请的一个实施例中，在应用第二启动过程，可以将应用代码与内存记录表一同传入运行时(例如WAMR运行时)中，每次申请内存时，从内存记录表中获取内存申请对应的内存申请序号所对应的内存释放标记。

203，若申请的内存会在第二启动过程释放，确定从电子设备的临时内存空间分配申请的内存。

确定从电子设备的临时内存空间分配申请的内存，也就是确定用于分配申请的内存的区域为电子设备的临时内存空间。

例如，参阅图3所示，若应用在第二启动过程第二次申请内存，内存记录表中内存申请对应的内存申请序号为“2”，对应的内存释放标记为“Free”，申请的内存不会在第二启动过程释放，则从电子设备的临时内存空间分配申请的内存。

再如，参阅图5所示，若应用在第二启动过程第二次申请内存，内存申请表中内存申请对应的内存申请序号为“2”，对应的内存地址为“0x8020010”，内存地址“0x8020010”包含在内存释放表中，申请的内存会在第二启动过程释放，则从电子设备的临时内存空间分配申请的内存。

临时内存空间是一个在应用启动结束后就释放的内存集合，通过分配一个临时地址进行统一释放。如果应用有启动完释放的动态内存分配请求，则分配到临时内存空间。临时内存空间的大小可以根据第一启动过程记录的内存记录表或内存申请表的大小确定。内存记录表或内存申请表中的记录越多，则可以分配越大的临时内存空间。

204，若申请的内存不会在第二启动过程释放，确定从电子设备的内存池分配申请的内存。

确定从电子设备的内存池分配申请的内存，也就是确定用于分配申请的内存的区域为电子设备的内存池。

例如，参阅图3所示，若应用在第二启动过程第一次申请内存，内存记录表中内存申请对应的内存申请序号为“1”，对应的内存释放标记为“No free”，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。若应用在第二启动过程第三次申请内存，内存记录表中内存申请对应的内存申请序号为“3”，对应的内存释放标记为“Nofree”，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。若应用在第二启动过程第四次申请内存，内存记录表中内存申请对应的内存申请序号为“4”，对应的内存释放标记为“No free”，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。

再如，参阅图5所示，若应用在第二启动过程第一次申请内存，内存申请表中内存申请对应的内存申请序号为“1”，对应的内存地址为“0x8020000”，内存地址“0x8020000”不包含在内存释放表中，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。若应用在第二启动过程第三次申请内存，内存申请表中内存申请对应的内存申请序号为“3”，对应的内存地址为“0x8020020”，内存地址“0x8020020”不包含在内存释放表中，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。若应用在第二启动过程第四次申请内存，内存申请表中内存申请对应的内存申请序号为“1”，对应的内存地址为“0x80200030”，内存地址“0x8020030”不包含在内存释放表中，申请的内存不会在第二启动过程释放，则从电子设备的内存池分配申请的内存。

内存池是操作系统初始化时为应用分配的内存。例如，在运行WASM应用前，需要将操作系统中的WAMR初始化。其中包括预先从操作系统申请指定大小的内存池，该内存池用于WASM应用的启动与运行时所需内存的分配。内存池大小有限，离散的内存碎片会导致可同时运行的应用数量受限。

本申请实施例提供的内存申请方法记录应用在第一启动过程的内存申请和释放情况，在应用第二启动过程，对于会释放的资源，不在内存池中分配内存，而在临时内存空间分配内存，对于非释放资源，还是从内存池中申请，最终使所有未释放的内存存储在一段连续的内存空间，而临时内存空间在应用启动完成后释放掉，从而保证应用的代码、数据资源、运行堆栈等启动后未释放资源的内存空间连续且无碎片，提高内存池利用率，使得在有限内存空间可运行更多的应用。

图6是根据现有的内存回收机制内存使用情况的示意图。

参见图6所示，内存池大小为70字节，应用在第二启动过程要执行的内存操作包括：601，申请16字节的内存A；602，申请16字节的内存B；603，申请16字节的内存C；604，释放内存B；605，申请32字节的内存D。当执行601时，从内存池申请16字节的内存A。当执行602时，从内存池申请16字节的内存B。当执行603时，从内存池申请16字节的内存C。当执行604时，从内存池释放内存B。执行604后，内存池中内存A和内存C之间产生内存碎片。当执行到605，此时虽然内存池中还有38字节内存可用，但是无法为D分配一块连续的32字节的内存，导致内存申请失败。

根据图6可知，根据现有的内存回收机制，内存池内产生内存碎片，当后续申请的内存(例如内存D)的大小大于每个空闲内存大小(例如16字节及22字节)时，虽然内存池内还有足够的内存空间(即离散的空闲内存之和大于申请的内存大小)，但无法分配一块连续的内存。现有的内存垃圾回收机制不能将离散的内存碎片整合成一块大的内存，内存没有得到有效利用。对于内存受限的设备，初始化申请的内存池大小有限，离散的内存碎片会导致可同时运行的应用数量受限。

图7是根据本申请提供的内存申请方法内存使用情况的示意图。应用的内存记录表参见图3。

参见图7所示，应用的第二启动过程要执行的内存操作与图6相同，包括：701，申请16字节的内存A；702，申请16字节的内存B；703，申请16字节的内存C；704，释放内存B；705，申请32字节的内存D。当执行701时，根据图3所示的内存记录表可知，内存申请对应的内存申请序号为“1”，内存申请序号“1”对应的内存释放标记为“No free”，因而从内存池分配内存A。当执行702时，根据图3所示的内存记录表可知，内存申请对应的内存申请序号为“2”，内存申请序号“2”对应的内存释放标记为“Free”，因而从临时内存空间分配内存B。当执行703时，根据图3所示的内存记录表可知，内存申请对应的内存申请序号为“3”，内存申请序号“3”对应的内存释放标记为“No free”，因而从内存池分配内存C。当执行到704，从临时内存空间释放内存B。当执行到705，根据图3所示的内存记录表可知，内存申请对应的内存申请序号为“4”，内存申请序号“4”对应的内存释放标记为“No free”，因而从内存池分配内存D。执行701-705后，内存池中内存的使用连续，不存在内存碎片。

根据图7可知，根据本申请实施例提供的内存申请方法，应用启动完成后，未释放的内存存储在一段连续的内存空间，内存池的利用率得到提高，实现了在有限的内存空间运行更多的应用。

根据图2的技术方案，启动一个应用后，可以保证应用的代码、数据资源、运行堆栈等启动后未释放资源在内存空间(即内存池)连续分布而无碎片，提高了内存空间的利用率。然而，在多应用场景下，当应用退出时，内存池中不同应用占用的内存之间会出现内存碎片，也会影响内存空间的利用率。

图8是根据现有的内存管理方法，在多应用场景下，当应用退出后，内存池中不同应用之间出现内存碎片的示意图。

参阅图8所示，用户依此执行以下操作：801，启动应用1；802，启动应用2；803，退出应用1；804，启动应用3。启动应用时电子设备从内存池为应用分配内存，退出应用时电子设备释放之前从内存池申请的内存。从图8可知，在退出应用1后，内存池中存在空闲内存1和空闲内存2。应用3需要的内存大于空闲内存1，也大于空闲内存2，空闲内存1和空闲内存2都不能满足应用3的内存需求，应用3启动失败。现有的内存管理方法不能将离散的内存整合再利用，内存池的利用率有待提高。

图9是在图3的基础上进行内存碎片整理的流程图。图3所示实施例保证应用启动后非释放资源在内存池连续存储，在此基础上，可以对内存池中应用之间的空闲内存进行整理，将内存池中应用之间零散的内存碎片整理成大的内存空间，进一步提高内存空间的利用率。图9提供的技术方案解决了多应用场景下应用退出后内存池中不同应用之间产生内存碎片的技术问题。可以在新的应用启动时(例如图8中应用3启动时)进行内存碎片整理，或者，可以在应用退出时(例如图8中应用1退出时)进行内存碎片整理。下面以在新的应用启动时进行内存碎片整理为例进行说明。例如，参阅图8所示，在应用1退出后应用3启动前，内存池包括空闲内存1、应用1退出后释放的空闲内存2和应用2占用的内存，可以在应用3启动时采用图9所示方法对空闲内存1和空闲内存2进行整理，提高空闲内存的利用率。

901，确定应用在第一启动过程占用的内存池大小。

在应用的第一启动过程，还可以记录应用每次申请内存的大小。例如，内存记录表还可以包括内存大小，用于记录应用每次申请内存的大小。

图10是本申请另一实施例提供的内存记录表的示意图，内存记录表中包括内存大小。参阅图10所示，第一启动过程中，应用(例如应用3)第一次申请内存的大小是16字节，第二次申请内存的大小是16字节，第三次申请内存的大小是16字节，第四次申请内存的大小是32字节，……。其中，应用第一次申请内存、第三次申请内存、第四次申请内存对应的内存释放标记为“No free”，第二次申请内存对应的内存释放标记为“Free”。假设图10为图10为图8中应用3的内存记录表。

可以将内存记录表中不会在第一启动过程释放的内存申请对应的内存大小累加，得到应用在第一启动过程占用的内存池大小。例如，参阅图10所示，将应用第一次申请内存、第三次申请内存、第四次申请内存的内存大小、……累加，得到应用启动过程占用的内存池大小，即16字节+16字节+32字节+…。假设应用3启动过程占用的内存池大小为2.5KB(即2.5*1024字节)。

902，判断内存池中每个空闲内存的大小是否都小于应用在第一启动过程占用的内存池大小。

例如，参阅图8所示，在应用1退出后应用3启动前，内存池中存在空闲内存1和空闲内存2，则判断空闲内存1和空闲内存2的大小是否都小于应用3在第一启动过程占用的内存池大小。

需要说明的是，若内存池中某个空闲内存的大小不小于应用在第一启动过程占用的内存池大小，在该空闲内存中为应用分配内存，流程结束。

903，若内存池中每个空闲内存的大小都小于应用在第一启动过程占用的内存池大小，判断内存池中所有空闲内存的大小之和是否小于应用在第一启动过程占用的内存池大小。

以图8为例，假设应用3启动过程占用的内存池大小为2.5KB，空闲内存1的大小为1KB，空闲内存2的大小为2KB，此时内存池中每个空闲内存的大小都小于应用3在第一启动过程占用的内存池大小，则判断内存池中空闲内存1和空闲内存2的大小之和是否小于应用3在第一启动过程占用的内存池大小，即判断1KB加上2KB是否小于2.5KB。

904，若内存池中所有空闲内存的大小之和不小于应用在第一启动过程占用的内存池大小，对内存池中应用占用的内存进行整体平移，使内存池中应用之间的空闲内存连续分布。

以图8为例，内存池中空闲内存1和空闲内存2的大小之和不小于应用3在第一启动过程占用的内存池大小，则对内存池中应用2占用的内存进行整体平移，使内存池中应用之间的空闲内存连续分布。

整体平移是将每个应用占用的内存作为一个整体在内存池中移动。

假设[a,b]表示应用占用的内存，(a,b)表示空闲内存，假定内存映射空间为：

[0,100],(101,110),[111,160],(161,170),(171,175),[176,195],(196,200)。

其中[0,100]是应用App1占用的内存，[111,160]是应用App2占用的内存，[176,195]是应用App3占用的内存，(101,100)、(161,170)、(171,175)、(196,200)是空闲内存，可以通过整体平移把各个应用占用的内存移至整个内存池的头部，使空闲内存连续分布在内存池的末尾。

移动后的内存空间可以表示为：

[0,100],[101,150],[151,180],(181,190),(191,195),(196,200)。

在对内存池中应用占用的内存进行整体平移时，可以将应用占用的内存整体往前平移，使内存池中应用之间的空闲内存连续分布在内存池的末尾。或者，可以将应用占用的内存整体往后平移，使内存池中应用之间的空闲内存连续分布在内存池的开头。或者，可以将部分应用占用的内存整体往前平移，将部分应用占用的内存整体往后平移，使内存池中应用之间的空闲内存连续分布在内存池的中间。

以图8为例，应用1退出后应用3启动前，内存池中包括空闲内存1、空闲内存2和应用2占用的内存，可以将应用2占用的内存整体往前平移，使内存池中应用之间的空闲内存连续分布在内存池的末尾。或者，可以将应用2占用的内存整体往后平移，使内存池中应用之间的空闲内存连续分布在内存池的开头。

905，对内存池中连续分布的空闲内存进行整合。

对内存池中连续分布的空闲内存进行整合就是将内存池中连续分布的内存碎片合并为一块大的内存。

例如，假设[a,b]表示应用占用的内存，(a,b)表示空闲内存(即内存碎片)，整合前的内存映射空间为：

[0,100],[101,150],[151,180],(181,190),(191,195),(196,200)；

整合后的内存映射空间为：

[0,100],[101,150],[151,180],(181,200)。

经过整合，原来的内存碎片(181,190),(191,195),(196,200)合并为大块的内存(181,200)。

906，若内存池中所有空闲内存的大小之和小于应用在第一启动过程占用的内存池大小，发出内存申请错误提醒。

例如，若内存池中所有空闲内存的大小之和小于应用在第一启动过程占用的内存池大小，发出“内存不足”的语音或者显示“内存不足”的文字。

又如，若内存池中所有空闲内存的大小之和小于应用在第一启动过程占用的内存池大小，向相关用户发出用于提示内存不足的邮件或者消息。

图9所示实施例在应用的启动过程，当内存池可用内存空间足够但每个空闲内存较小而导致应用无法启动时，进行内存整理(对应用占用的内存进行整体移动，对连续的内存碎片进行整合)。

此外，可以在应用退出时进行内存碎片整理。若在应用退出时(例如图8中应用1退出时)进行内存碎片整理，只需对内存池中各个应用占用的内存进行整体平移，使内存池中应用之间的空闲内存连续分布，再对内存池中连续分布的空闲内存进行整合，而无需确定应用在第一启动过程占用的内存池大小，无需判断内存池中每个空闲内存的大小是否都小于应用在第一启动过程占用的内存池大小，也无需判断内存池中所有空闲内存的大小之和是否小于应用在第一启动过程占用的内存池大小(即无需执行901-903)。例如，参阅图8所示，可以在应用1退出时进行内存碎片整理，将应用2在内存池中占用的内存整体平移到内存池的开头或末尾，使内存池中的空闲内存1和空闲内存2连续分布，再对空闲内存1和空闲内存2进行整合。

图11是根据图9进行内存碎片整理的示意图。

参见图11所示，假设应用1退出后的状态为内存碎片整理前的初始状态，此时内存池包括空闲内存1、空闲内存2和应用2占用的内存。当启动应用3时，将应用2占用的内存整体平移到内存池的头部，将空闲内存1和空闲内存2整合为一块大的空闲内存，在整合得到的空闲内存中为应用3分配内存。本申请解决了多应用退出所导致的内存碎片问题，进一步提高内存池利用率，使得在有限的内存池空间内可启动更多的应用。

图12是对内存池中应用占用的内存进行整体平移(即图9中步骤904)的细化流程图。参阅图12所示，对内存池中应用占用的内存进行整体平移可以包括如下步骤：

1201，计算内存池中每个应用对应的平移偏移量。

内存池中每个应用对应的平移偏移量就是对应用占用的内存进行整体平移的偏移量。

每个应用对应的平移偏移量由内存池中应用之间的内存碎片的大小确定。应用之间的内存碎片越大，则应用对应的平移偏移量越大。

在本申请的一个实施例中，可以记录每个应用启动时的加载首地址和占用的内存池大小，根据每个应用启动时的加载首地址和占用的内存池大小计算内存池中每个应用对应的平移偏移量。平移偏移量的具体计算过程将在图14中进行描述。

1202，根据每个应用对应的平移偏移量对应用相关的指针变量进行修改。

在本申请的一个实施例中，WAMR在运行WASM应用时，会创建一个线程，并将module_data结构体指针作为参数传递进去。通过module_data结构体指针可以查运行时运行WASM应用所需要的所有资源。因此，可以通过修正module_data结构体指针及module_data结构体内部所有指向资源数据的指针变量的值，使得指针变量指向应用整体平移后正确的位置。应用相关的指针变量的修正方式为原指针变量减去平移偏移量。

图13是本申请实施例使用的module_data结构体的示意图。

module_data是WASM模块的数据指针，用于链接和组织本模块的所有资源。module_data结构体定义了wasm_data结构体指针，wasm_data结构体定义了WASMModule结构体指针、WASMModuleInstance结构体指针、WASMExecEnv结构体指针，WASMModule结构体用于记录从WASM二进制文件中导入的模块信息，WASMModuleInstance结构体用于记录内存对象信息、全局表格对象信息、全局变量信息、全局函数信息等。

1203，根据应用原来的加载首地址和平移偏移量确定应用新的加载首地址，将应用从原来的加载首地址拷贝到新的加载首地址。

应用新的加载首地址等于应用原来的加载首地址与平移偏移量之差，即新的加载首地址＝原来的加载首地址－平移偏移量。

例如，应用原来的加载首地址为0x08020800，应用的平移偏移量为0x100，应用新的加载首地址等于0x08020800－0x100＝0x08020700。

图14是计算内存池中每个应用对应的平移偏移量(即图12中1201)的细化流程图。

在本实施例中，应用启动时的加载首地址和应用占用的内存池大小记录在应用内存信息链表中，内存信息链表中的一个链表节点对应一个应用。当应用退出时，应用对应的链表节点从应用内存信息链表中删除。应用内存信息链表可以包括启动序号、占用的内存池大小和加载首地址。

图15是本申请实施例使用的应用内存信息链表的示意图。其中，15A是依此启动应用1、应用2、应用3和应用4之后的应用内存信息链表，15B是依此启动应用1、应用2、应用3和应用4后，又依此退出应用1和应用3之后的应用内存信息链表。参阅图15A所示，启动应用1对应的启动序号为“1”，占用的内存池大小为2KB，加载首地址为0x08020000；启动应用2对应的启动序号为“2”，占用的内存池大小为2KB，加载首地址为0x08020800；启动应用3对应的启动序号为“3”，占用的内存池大小为2KB，加载首地址为0x08021000；启动应用4对应的启动序号为“4”，占用的内存池大小为2KB，加载首地址为0x08021800。参阅图15B所示，退出应用1和应用3之后，应用内存信息链表包括启动序号为“2”和启动序号为“4”的链表节点。

参阅图14所示，计算内存池中每个应用对应的平移偏移量包括以下步骤：

1401，逐一获取应用内存信息链表中的链表节点。

例如，从应用内存信息链表的第一个链表节点开始，逐一应用内存信息链表中的获取链表节点。

1402，对于获取的每个链表节点，判断链表节点是否是应用内存信息链表的首节点。

1403，若链表节点是应用内存信息链表的首节点，判断链表节点的加载首地址是否等于内存池的首地址。

1404，若链表节点的加载首地址是否等于内存池的首地址，链表节点对应的平移偏移量为0，即无需对链表节点对应的应用进行整体平移。

1405，若链表节点的加载首地址不等于内存池的首地址，链表节点对应的平移偏移量等于链表节点的加载首地址与内存池的首地址之差，即链表节点对应的平移偏移量＝链表节点的加载首地址－内存池的首地址。

例如，链表节点的加载首地址是0x08020100，内存池的首地址为0x08020000，链表节点对应的平移偏移量＝0x08020100－0x08020000＝0x100。

1406，若链表节点不是应用内存信息链表的首节点，判断链表节点的加载首地址是否大于链表节点的前一节点的加载首地址与链表节点占用的内存池大小之和。

链表节点占用的内存池大小是指链表节点对应的应用占用的内存池大小。

1407，若链表节点的加载首地址不大于链表节点的前一节点的加载首地址与链表节点占用的内存池大小之和，链表节点对应的平移偏移量为0，即无需对链表节点对应的应用进行整体平移。

1408，若链表节点的加载首地址大于其前一节点的加载首地址与链表节点占用的内存池大小之和，链表节点对应的平移偏移量等于链表节点的加载首地址减去前一链表节点的加载首地址，再减去链表节点占用的内存池大小，即链表节点对应的平移偏移量＝链表节点的加载首地址－前一节点的加载首地址－链表节点占用的内存池大小。

基于与方法实施例同一发明构思，本申请实施例还提供了一种内存申请装置。内存申请装置应用于电子设备(例如图1所示电子设备10)。

图16是本申请实施例提供的一种电子设备的硬件结构示意图。如图16所示，电子设备160可以包括：射频(Radio Frequency，RF)电路1601、存储器1602、输入单元1603、显示单元1604、传感器1605、音频电路1606、Wi-Fi模块1607、处理器1608以及电源1609等部件。本领域技术人员可以理解，图16中示出的结构并不构成对电子设备160的限定，电子设备160可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

RF电路1601可用于收发信息或在通话过程中，对信号进行接收和发送，特别地，接收的下行信息后，转给处理器1608进行处理；另外，将涉及上行的数据发送给。通常，RF电路1601包括，但不限于：天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。

存储器1602可用于存储软件程序以及模块，处理器1608通过运行存储在存储器1602中的软件程序以及模块，从而执行电子设备的各种功能应用以及数据处理。存储器1602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1602可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1603可用于接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入。具体地，输入单元1603可包括触控面板16031以及其他输入设备16032。触控面板16031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触控笔等任何适合的物体或附件在触控面板16031上或在触控面板16031附近的操作)，并根据预先设定的程序驱动相应的连接装置。可选地，触控面板16031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1608，并接收处理器1608发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板16031。除了触控面板16031，输入单元1603还可以包括其他输入设备16032。具体地，其他输入设备16032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1604可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种菜单。显示单元1604可包括显示面板16041，可选地，可以采用液晶显示器(LiquidCrystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板16041。进一步地，触控面板16031可覆盖显示面板16041，当触控面板16031检测到在其上或附近的触摸操作后，传送给处理器1608以确定触摸事件的类型，随后处理器1608根据触摸事件的类型在显示面板16041上提供相应的视觉输出。虽然在图6中，触控面板16031与显示面板16041是作为两个独立的部件来实现电子设备的输入和输出功能，但是在某些实施例中，可以将触控面板16031与显示面板16041集成而实现电子设备的输入和输出功能。

电子设备还可包括至少一种传感器1605，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板16041的亮度，接近传感器可在电子设备移动到耳边时，关闭显示面板16041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别电子设备姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；此外，电子设备还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1606、扬声器16061，传声器16062可提供用户与电子设备之间的音频接口。音频电路1606可将接收到的音频数据转换后的电信号，传输到扬声器16061，由扬声器16061转换为声音信号输出；另一方面，传声器16062将收集的声音信号转换为电信号，由音频电路1606接收后转换为音频数据，再将音频数据输出处理器1608处理后，经RF电路1601发送给另一电子设备，或者将音频数据输出至存储器1602以便进一步处理。

Wi-Fi属于短距离无线传输技术，电子设备通过Wi-Fi模块1607可以帮助用户收发、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图16示出了Wi-Fi模块1607，但是可以理解的是，其并不属于电子设备的必需构成，完全可以根据需要、在不改变发明本质的范围内进行省略。

处理器1608是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器1602内的软件程序和/或模块，以及调用存储在存储器1602内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。可选地，处理器1608可包括一个或多个处理单元；优选的，处理器1608可集成应用处理器和调制解调器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1608中。

电子设备还包括给各个部件供电的电源1609(比如电池)，可选地，电源可以通过电源管理系统与处理器1608逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，电子设备还可以包括摄像头、蓝牙模块等，在此不再赘述。

图16中描述的电子设备可以用于实施本申请图2、9、14介绍的方法实施例中的部分或全部流程，可参见前述图2、9、14所述实施例中的相关阐述，这里不再赘述。

图17是本申请实施例提供的电子设备的软件结构示意图。在本申请的一个实施例中，电子设备安装有安卓系统，安卓系统从上至下分别为应用程序层、应用程序框架层、原生C/C++库与安卓运行时、硬件抽象层和内核层。

应用程序层可以包括一系列应用程序包。如图17所示，应用程序包可以包括图库、日历、地图、WLAN、音乐、短信、通话、导航、蓝牙、视频等。

应用程序框架层可以包括窗口管理器、活动管理器、输入管理器、资源管理器、通知管理器视图系统、内容提供器等。

窗口管理器提供窗口管理服务(Window Manager Service，WMS),WMS可以用于窗口管理、窗口动画管理、surface管理以及作为输入系统的中转站。

活动管理器可以提供活动管理服务(Activity Manager Service，AMS)，AMS可以用于系统组件(例如活动、服务、内容提供者、广播接收器)的启动、切换、调度以及应用进程的管理和调度工作。

输入管理器可以提供输入管理服务(Input Manager Service，IMS)，IMS可以用于管理系统的输入，例如触摸屏输入、按键输入、传感器输入等。IMS从输入设备节点取出事件，通过和WMS的交互，将事件分配至合适的窗口。

资源管理器为应用程序提供各种资源，比如本地化字符串、图标、图片、布局文件、视频文件等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息、发出提示音、电子设备振动、指示灯闪烁等。

视图系统包括可视控件，例如显示文字的控件、显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。该数据可以包括视频、图像、音频、拨打和接听的电话、浏览历史和书签、电话簿等。

原生C/C++库可以包括多个功能模块。例如：表面管理器(surface manager)、媒体框架(Media Framework)、C标准函数库(libc)、OpenGL ES、SQLite、Webkit等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体框架支持多种常用的音频、视频格式回放和录制，以及静态图像文件等。媒体框架可以支持多种音视频编码格式，例如：MPEG4、H.264、MP3、AAC、AMR、JPG、PNG等。

C标准函数库是在C语言程序设计中，所有匹配标准的头文件(head file)的集合，以及常用的函数库实现程序。

OpenGL ES提供应用程序中2D图形和3D图形的绘制和操作。

SQLite为电子设备的应用程序提供轻量级关系型数据库。

安卓运行时包括安卓运行时和核心库。安卓运行时负责将源代码转换为机器码。安卓运行时主要包括采用提前(ahead or time，AOT)编译技术和及时(just in time，JIT)编译技术。核心库主要用于提供基本的Java类库的功能，例如基础数据结构、数学、IO、工具、数据库、网络等库。核心库为用户进行安卓应用开发提供了API。

硬件抽象层运行于用户空间(user space)，对内核层驱动进行封装，向上层提供调用接口。

内核层是硬件和软件之间的层。内核层至少包含显示驱动、摄像头驱动、音频驱动、传感器驱动。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的内存申请方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的内存申请方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的内存申请方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。