一种应用启动方法及电子设备与流程

本申请涉及终端技术领域，尤其涉及一种应用启动方法及电子设备。

背景技术：

手机等电子设备中安装的各类应用(application，app)已经广泛应用在用户的日常生活中。以手机举例，从用户点击应用的启动图标开始直到手机运行应用的代码后显示出该应用的第一帧画面的这段时间可称为应用的启动时间。启动时间的快慢直接影响用户对该应用的使用体验，也是评价手机性能的重要指标之一。

在应用启动时，如果手机后台没有该应用的进程(process)，则手机系统需要重新创建一个新的进程分配给该应用，这种启动方式可称为冷启动。在冷启动过程中手机需要创建应用的应用进程，在应用进程的主线程(activitythread)中执行main函数，并通过创建应用进程的类加载器(classloader)将应用的类(class)文件加载至手机的内存中，这使得应用在冷启动时耗费的启动时间较长，用户打开应用时的使用体验不高。

技术实现要素：

本申请提供一种应用启动方法及电子设备，可缩短应用冷启动时耗费的启动时间，提高用户打开应用时的使用体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种应用启动方法，包括：电子设备中的系统服务(systemserver)进程可获取第一应用的启动消息；响应于该启动消息，系统服务进程可向守护进程(例如zygote进程)发送应用进程的创建请求，该创建请求中包括第一应用的应用信息；响应于该创建请求，守护进程可为第一应用创建应用进程，该应用进程包括第一线程和第二线程；进而，创建的应用进程可并行地执行第一线程和第二线程，其中，第一线程执行对第一应用的主线程的初始化，第二线程根据上述应用信息创建第一类加载器加载第一应用的类文件；当主线程初始化完成，且类文件加载完成后，第一应用的应用进程可以开始运行第一应用的代码，以显示第一应用的应用界面。

也就是说，守护进程创建了第一应用的应用进程后，应用进程可通过多线程并行的方式完成主线程初始化和加载类文件的工作。这样，在应用主线程初始化的同时可创建第一应用的类加载器加载类文件，从而缩短应用冷启动时耗费的启动时间，提高用户打开应用时的使用体验。

在一种可能的实现方式中，上述应用信息中记录有第一应用运行时所需的一个或多个类加载器。例如，上述应用信息中记录有第一类加载器的标识；此时，第二线程根据应用信息创建第一类加载器加载第一应用的类文件，包括：第二线程根据第一类加载器的标识创建第一类加载器，并使用第一类加载器加载第一应用的第一类文件。

在一种可能的实现方式中，上述应用信息中还可以记录第二类加载器的标识；守护进程创建的应用进程中还包括第三线程；此时，在第一应用的应用进程可并行地执行第一线程、第二线程以及第三线程；其中，第三线程可根据第二类加载器的标识创建第二类加载器，并使用第二类加载器加载第一应用的第二类文件。也就是说，如果第一应用启动时需要多个类加载器，则应用进程可通过多线程的方式并行地创建多个类加载器同时加载类文件，从而缩短应用冷启动的启动时间。

在一种可能的实现方式中，上述应用信息中还记录有类加载器之间的依赖关系。例如，上述应用信息中除了第一类加载器的标识外，还记录有第二类加载器的标识，且第二类加载器依赖于第一类加载器；那么，守护进程创建的应用进程中还包括第三线程；当第三线程获取到第二线程释放的对象锁后，第三线程可根据第二类加载器的标识创建第二类加载器，并使用第二类加载器加载第一应用的第二类文件。也就是说，如果第一应用启动时需要的多个类加载器之前具有依赖关系，则应用进程可先并行地创建不具有依赖关系的类加载器加载类文件，相比于通过串行的方式创建每一个类加载器加载类文件，这种方式也可缩短应用冷启动的启动时间。

在一种可能的实现方式中，上述应用信息中除了第一类加载器的标识外，还记录有第二类加载器的标识；此时，在第二线程根据第一类加载器的标识创建第一类加载器，并使用第一类加载器加载第一应用的第一类文件之后，还包括：第二线程根据第二类加载器的标识创建第二类加载器，并使用第二类加载器加载第一应用的第二类文件。也就是说，与第一线程并行的第二线程可串行的创建多个类加载器加载类文件。

在一种可能的实现方式中，上述应用进程开始运行第一应用的代码，包括：当第一线程获取到第二线程释放的对象锁后，应用进程开始运行第一应用的代码。

当然，如果应用进程还使用了其他线程创建类加载器加载类文件，则第一线程除了获取到第二线程释放的对象锁外，还需要获取到其他线程释放的对象锁，进而开始运行第一应用的代码。也就是说，当第一应用的主线程初始化结束，且第一应用的类文件加载完成后，可以开始运行第一应用的代码。

在一种可能的实现方式中，在电子设备中的系统服务进程向守护进程发送应用进程的创建请求之前，还包括：系统服务进程可从第一应用的apk文件中获取第一应用的应用信息；进而，系统服务进程可将该应用信息添加至应用进程的创建请求中。

在一种可能的实现方式中，上述第一线程可以为应用进程的主线程，上述第二线程可以为应用进程的临时线程；此时，在电子设备中的守护进程为第一应用创建应用进程后，还包括：应用进程的主线程可创建该临时线程，并将第一类加载器的标识分配给该临时线程，使得该临时线程可根据第一类加载器的标识创建第一类加载器加载类文件。

在一种可能的实现方式中，电子设备中的系统服务进程获取第一应用的启动消息，包括：响应于用户点击第一应用的启动图标的操作，电子设备的启动器(launcher)可生成第一应用的启动消息，进而，系统服务进程可接收启动器发送的第一应用的启动消息。

第二方面，本申请提供一种应用启动方法，包括：电子设备中的系统服务进程可获取第一应用的启动消息；进而，系统服务进程可开始对该启动消息进行校验，同时，若该启动消息来自于启动器，由于系统服务进程对launcher发来的启动消息一般都会校验通过，因此，系统服务进程可调用进程池中的第一进程提前开始创建第一应用的类加载器加载第一应用的类文件；后续，当该启动消息校验成功后，系统服务进程可继续调用第一进程对第一应用的主线程进行初始化；当主线程初始化完成，且类文件加载完成后，第一进程可开始运行第一应用的代码，以显示第一应用的应用界面。

也就是说，系统服务进程可将launcher发来的启动消息作为触发条件，预先调用进程池中的第一进程创建应用运行时需要使用的类加载器，并使用类加载器加载类文件。这样，第一进程作为该应用的应用进程在运行应用代码前，进行主线程初始化以及类文件加载的耗时将减少，从而缩短了应用启动时的启动时间。

在一种可能的实现方式中，系统服务进程调用进程池中的第一进程开始创建第一应用的类加载器加载第一应用的类文件，包括：系统服务进程可将进程池中第一进程的id保存为第一应用的应用进程id；进而，系统服务可将第一应用的应用信息传递给第一进程，该应用信息中记录有第一类加载器的标识和第二类加载器的标识；那么，第一进程可并行地执行第一线程和第二线程；其中，第一线程根据第一类加载器的标识创建第一类加载器，并使用第一类加载器加载第一应用的第一类文件；第二线程根据第二类加载器的标识创建第二类加载器，并使用第二类加载器加载第一应用的第二类文件。这样，通过多线程并行创建多个类加载器加载类文件，可缩短应用类文件的加载时间，从而缩短应用启动所耗费的时间。

在一种可能的实现方式中，系统服务进程调用第一进程对第一应用的主线程进行初始化，包括：由于系统服务进程已经将进程池中第一进程的id保存为第一应用的应用进程id，因此，系统服务进程可根据第一应用的应用进程id，调用第一进程中的主线程执行activitythread的main函数，完成对第一应用的主线程进行初始化。

在一种可能的实现方式中，第一进程开始运行第一应用的代码，包括：在主线程进行初始化后，如果主线程获取到第一线程释放的对象锁和第二线程释放的对象锁，说明应用的类文件也加载完毕，则第一进程可开始运行第一应用的代码。

在一种可能的实现方式中，若上述启动消息校验失败，则系统服务进程释放被占用的第一进程，并删除已创建的类加载器和已加载的类文件，本次应用启动被系统服务拒绝。

第三方面，本申请提供一种电子设备，包括：触摸屏、一个或多个处理器、存储器以及一个或多个计算机程序；其中，处理器与触摸屏和存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当电子设备运行时，该处理器执行该存储器存储的一个或多个计算机程序，以使电子设备执行上述任一项所述的应用启动方法。

第四方面，本申请提供一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如第一方面中任一项所述的应用启动方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如第一方面中任一项所述的应用启动方法。

第六方面，本申请提供一种芯片系统，该芯片系统包括至少一个处理器和至少一个接口电路；接口电路用于读取存储器中存储的指令，并将指令发送给处理器；当指令被处理器执行时，使得上述电子设备执行上述任一项所述的应用启动方法。

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

附图说明

图1为本申请实施例提供的一种电子设备的结构示意图一；

图2为本申请实施例提供的一种电子设备内操作系统的架构示意图；

图3为本申请实施例提供的一种应用启动方法的流程示意图一；

图4为本申请实施例提供的一种应用启动方法的流程示意图二；

图5为本申请实施例提供的一种应用启动方法的应用场景示意图一；

图6为本申请实施例提供的一种应用启动方法的流程示意图三；

图7为本申请实施例提供的一种应用启动方法的流程示意图四；

图8为本申请实施例提供的一种应用启动方法的流程示意图五；

图9为本申请实施例提供的一种应用启动方法的流程示意图六；

图10为本申请实施例提供的一种应用启动方法的应用场景示意图二；

图11为本申请实施例提供的一种应用启动方法的流程示意图七；

图12为本申请实施例提供的一种电子设备的结构示意图二；

图13为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

为清楚阐述本申请实施例提供的一种应用启动方法，首先对后续实施例中可能会出现的一些概念进行解释。

进程(process)，是应用程序关于某数据集合上的一次运行活动，是操作系统(例如android系统)进行资源分配和调度的基本单位。每一个进程都会占用一块内存空间，应用程序以一个或多个进程的形式运行在操作系统上，实现相应的功能。

线程(thread)，是进程的一个实体，它是比进程更小的能独立运行的基本单位。线程可与同属一个进程的其他的线程共享该进程所拥有的全部资源。一个线程可以创建和撤销另一个线程，同一个进程中的多个线程之间可以并行执行。

对象锁，是保证同一时间内只有一个线程访问某一方法或变量的一种机制。在java等面向对象的语言中，当一个线程访问被同步的代码时，必须获取该代码所属的对象锁，否则该线程将阻塞，直到该对象锁被释放。其中，被同步的代码可以是指被关键字synchronized修饰的方法或语句块。

也就是说，对象锁是一个互斥锁，即最多只有一个线程能够获得该锁，当线程a尝试去获得线程b持有的对象锁时，线程a必须等待或者阻塞，直到线程b释放这个锁后，线程a才能够获取该对象锁访问相应的方法或变量。

线程阻塞，通常是指一个线程在执行过程中出现暂停的时长大于某一预设值引发的超时现象。例如，线程a在执行过程中需要将线程b的执行结果作为输入参数才能继续执行，那么，如果线程a没有得到线程b的执行结果则会暂停执行，当线程a在预设时间内迟迟得不到线程b的执行结果，则会造成线程a发生阻塞现象。

下面将结合附图对本实施例的实施方式进行详细描述。

示例性的，本申请实施例提供的一种应用启动方法可应用于手机、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、手持计算机、上网本、个人数字助理(personaldigitalassistant，pda)、可穿戴电子设备、车载设备、虚拟现实设备等电子设备，本申请实施例对此不做任何限制。

示例性的，图1示出了电子设备100的结构示意图。

电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserialbus，usb)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，传感器模块180，摄像头193以及显示屏194等。

可以理解的是，本发明实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(applicationprocessor，ap)，调制解调处理器，图形处理器(graphicsprocessingunit，gpu)，图像信号处理器(imagesignalprocessor，isp)，控制器，视频编解码器，数字信号处理器(digitalsignalprocessor，dsp)，基带处理器，和/或神经网络处理器(neural-networkprocessingunit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integratedcircuit，i2c)接口，集成电路内置音频(inter-integratedcircuitsound，i2s)接口，脉冲编码调制(pulsecodemodulation，pcm)接口，通用异步收发传输器(universalasynchronousreceiver/transmitter，uart)接口，移动产业处理器接口(mobileindustryprocessorinterface，mipi)，通用输入输出(general-purposeinput/output，gpio)接口，用户标识模块(subscriberidentitymodule，sim)接口，和/或通用串行总线(universalserialbus，usb)接口等。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过usb接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141可接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。

电源管理模块141可用于监测电池容量，电池循环次数，电池充电电压，电池放电电压，电池健康状态(例如漏电，阻抗)等性能参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2g/3g/4g/5g等无线通信的解决方案。移动通信模块150可以包括一个或多个滤波器，开关，功率放大器，低噪声放大器(lownoiseamplifier，lna)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocalareanetworks，wlan)(如无线保真(wirelessfidelity，wi-fi)网络)，蓝牙(bluetooth，bt)，全球导航卫星系统(globalnavigationsatellitesystem，gnss)，调频(frequencymodulation，fm)，近距离无线通信技术(nearfieldcommunication，nfc)，红外技术(infrared，ir)等无线通信的解决方案。无线通信模块160可以是集成一个或多个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(globalsystemformobilecommunications，gsm)，通用分组无线服务(generalpacketradioservice，gprs)，码分多址接入(codedivisionmultipleaccess，cdma)，宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)，时分码分多址(time-divisioncodedivisionmultipleaccess，td-scdma)，长期演进(longtermevolution，lte)，bt，gnss，wlan，nfc，fm，和/或ir技术等。所述gnss可以包括全球卫星定位系统(globalpositioningsystem，gps)，全球导航卫星系统(globalnavigationsatellitesystem，glonass)，北斗卫星导航系统(beidounavigationsatellitesystem，bds)，准天顶卫星系统(quasi-zenithsatellitesystem，qzss)和/或星基增强系统(satellitebasedaugmentationsystems，sbas)。

电子设备100通过gpu，显示屏194，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏194和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquidcrystaldisplay，lcd)，有机发光二极管(organiclight-emittingdiode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganiclightemittingdiode的，amoled)，柔性发光二极管(flexlight-emittingdiode，fled)，miniled，microled，micro-oled，量子点发光二极管(quantumdotlightemittingdiodes，qled)等。在一些实施例中，电子设备100可以包括1个或n个显示屏194，n为大于1的正整数。

电子设备100可以通过isp，摄像头193，视频编解码器，gpu，显示屏194以及应用处理器等实现拍摄功能。

isp用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给isp处理，转化为肉眼可见的图像。isp还可以对图像的噪点，亮度，肤色进行算法优化。isp还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，isp可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。在一些实施例中，手机100可以包括1个或n个摄像头，n为大于1的正整数。摄像头193可以是前置摄像头也可以是后置摄像头。摄像头193一般包括镜头(lens)和感光元件(sensor)，该感光元件可以为ccd(charge-coupleddevice，电荷耦合元件)或者cmos(complementarymetaloxidesemiconductor，互补金属氧化物半导体)等任意感光器件。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备100可以支持一种或多种视频编解码器。这样，电子设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(movingpictureexpertsgroup，mpeg)1，mpeg2，mpeg3，mpeg4等。

外部存储器接口120可以用于连接外部存储卡，例如microsd卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储一个或多个计算机程序，该一个或多个计算机程序包括指令。处理器110可以通过运行存储在内部存储器121的上述指令，从而使得电子设备100执行本申请一些实施例中所提供的方法，以及各种功能应用和数据处理等。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统；该存储程序区还可以存储一个或多个应用程序(比如图库、联系人等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如照片，联系人等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如一个或多个磁盘存储器件，闪存器件，通用闪存存储器(universalflashstorage，ufs)等。在另一些实施例中，处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，来使得电子设备100执行本申请实施例中所提供的方法，以及各种功能应用和数据处理。

电子设备100可以通过音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

扬声器170a，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170a收听音乐，或收听免提通话。

受话器170b，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时，可以通过将受话器170b靠近人耳接听语音。

麦克风170c，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170c发声，将声音信号输入到麦克风170c。电子设备100可以设置一个或多个麦克风170c。在另一些实施例中，电子设备100可以设置两个麦克风170c，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备100还可以设置三个，四个或更多麦克风170c，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

耳机接口170d用于连接有线耳机。耳机接口170d可以是usb接口130，也可以是3.5mm的开放移动电子设备平台(openmobileterminalplatform，omtp)标准接口，美国蜂窝电信工业协会(cellulartelecommunicationsindustryassociationoftheusa，ctia)标准接口。

传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，本申请实施例对此不做任何限制。

当然，本申请实施例提供的电子设备100还可以包括按键190、马达191、指示器192以及sim卡接口195等一项或多项器件，本申请实施例对此不做任何限制。

上述电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的android系统为例，示例性说明电子设备100的软件结构。

图2是本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(androidruntime)和系统库，以及内核层。

如图2所示，应用程序层可以包括一系列应用。例如，应用程序层中可以安装通话，备忘录，浏览器，联系人，相机，图库，日历，地图，蓝牙，音乐，视频，短信息等应用(app)。

这些app一般是用java语言编写的，每个app包括一个或多个类(class)文件。每个app可以以进程的形式在应用程序层中运行各自的类文件。用户在app中操作时，app可通过调用应用程序框架层中的相关api或服务(service)，与系统库或内核层进行交互，实现与该操作相对应的功能。

另外，应用程序层中还包括launcher(启动器，launcher可以包括桌面等部件)等android核心应用。一般，android系统启动后launcher可作为核心应用常驻在android系统中运行。应用的启动图标一般设置在launcher中，launcher可监测到用户点击某一应用的启动图标的操作，并生成应用的启动消息发送给应用程序框架层中的相关服务，通过这些服务启动应用的应用进程。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramminginterface，api)和编程框架。应用程序框架层包括一些预先定义的函数。

如图2所示，应用程序框架层中运行有系统服务(systemserver)进程和zygote进程。

其中，systemserver进程可以为应用程序层中的app提供几乎所有的系统服务。例如，该系统服务可以包括活动管理服务(activitymanagerservice，ams)、电源管理服务(powermanagerservice，pms)、窗口管理服务(windowmanagerservice，wms)、网络管理服务(networkmanagementservice，nms)以及输入法管理服务(inputmanagerservice，ims)等。这些系统服务可以以线程的形式驻留在systemserver进程中。

zygote进程是android系统中的一个非常重要的守护进程服务(daemonservice)，几乎所有的应用进程都是通过zygote进程孵化(fork)出来的。由于各个应用是由java语言编写的，每个应用需要以进程的形式运行在各自独立的虚拟机(dalvik)中。应用在启动时可通过zygote进程孵化出应用的虚拟机，进而共享虚拟机内存和systemserver进程中提供的各项服务。

一般，launcher监测到用户点击某一应用(例如图库app)的启动图标后，可向systemserver进程发送该应用的启动消息。如果当前的应用进程中不存在该应用的应用进程，说明此时需要为该应用重新创建应用进程，则systemserver进程可调用活动管理服务(ams)与zygote进程通信，请求zygote进程为该应用创建对应的应用进程，实现应用的冷启动。

以图库app举例，launcher监测到用户点击图库app的启动图标后，可向systemserver进程发送图库app的启动消息。如果当前的应用进程中不存在图库app的应用进程，则systemserver进程可调用ams通过socket(套接字)向zygote进程发送应用进程的创建请求。zygote进程接收到该创建请求后，可响应该创建请求创建图库app的应用进程1，应用进程1中一般包括应用的主线程(activitythread)。为了能够开始正常运行图库app中的代码，图库app的应用进程1创建后需要先对应用的主线程进行初始化，并将图库app的类文件加载至内存中。

其中，主线程可通过执行activitythread的main函数完成对主线程的初始化。通过对应用主线程进行初始化可以搭建图库app能够运行的虚拟机环境，可以在ams中注册图库app的应用进程1，可以创建图库app运行时的各类目录以及创建图库app运行时与systemserver进程中各类服务的消息分发机制等。

并且，图库app中的各个类文件在应用启动前存储在电子设备的rom(read-onlymemory，只读内存)中。在启动图库app时，还需要将图库app中的各个类文件加载至电子设备的ram(random-accessmemory，运行内存)中。此时，需要先创建应用进程1的类加载器(classloader)，进而使用类加载器将相应的类文件加载至电子设备的ram中。或者，图库app中的类文件也可以以类库的形式存储在rom中。一个类库可以是一个或多个类文件的集合。此时，使用类加载器将类文件加载至ram中可以是指将类库中的类文件加载至ram中。

以主线程初始化的耗时为t1，创建类加载器加载类文件的耗时为t2举例，现有技术在启动图库app时是串行执行主线程初始化以及创建类加载器加载类文件的，因此，图库app的启动时间t包括t1+t2。

在本申请实施例中，为了降低应用启动时的启动时间，如图3所示，zygote进程创建了待启动应用的应用进程(例如上述图库app的应用进程1)后，应用进程1可通过多线程并行的方式完成主线程初始化和加载类文件等工作。这样，在应用主线程初始化的同时可创建应用的类加载器加载类文件，从而缩短应用冷启动时耗费的启动时间，提高用户打开应用时的使用体验。

如图2所示，系统库可以包括多个功能模块。例如：表面管理器(surfacemanager)，媒体库(medialibraries)，三维图形处理库(例如：opengles)，2d图形引擎(例如：sgl)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:mpeg4，h.264，mp3，aac，amr，jpg，png等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2d图形引擎是2d绘图的绘图引擎。

androidruntime包括核心库和虚拟机。androidruntime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等，本申请实施例对此不做任何限制。

以下将结合附图详细阐述本申请实施例提供的一种应用启动方法。

示例性的，如图4所示，以手机为电子设备举例，本申请实施例提供的一种应用启动方法包括以下步骤：

s401、手机检测到用户打开第一应用的启动操作。

s402、响应于上述启动操作，手机中的launcher向系统服务进程发送第一应用的启动消息。

示例性的，手机开机后可自动将launcher作为常驻应用运行在应用程序层。如图5所示，手机可在launcher中显示已安装的各个应用的启动图标。当用户需要打开某一应用时，用户可向launcher中输入点击对应启动图标的启动操作，launcher可监测到用户点击某一启动图标的启动操作。

以用户点击图5中相机app的启动图标501举例，launcher检测到用户点击启动图标501这一启动操作后，说明用户希望打开相机app，则launcher可与手机中的系统服务(systemserver)进程交互，向systemserver进程发送第一应用的启动消息。例如，launcher可调用start_activity接口向systemserver进程发送相机app的启动消息。该启动消息中可以包括相机app的包名(packagename)等信息。

需要说明的是，上述实施例是以用户从手机桌面中打开第一应用为例说明的。可以理解的是，用户可以通过手机中的其他入口打开第一应用。例如，用户可以在锁屏界面、负一屏菜单、下拉菜单或上拉菜单中打开第一应用。又例如，用户还可以在正在运行的应用中打开并跳转至另一个应用，本申请实施例对此不做任何限制。

s403、若手机中不存在第一应用的应用进程，则手机中的系统服务进程向zygote进程发送应用进程的创建请求，创建请求中包括第一应用的应用信息。

仍以启动相机app举例，手机中的systemserver进程接收到相机app的启动消息后，可调用活动管理服务(ams)查询正在运行的应用进程中是否包括相机app的应用进程。如果包括相机app的应用进程，说明用户最近一次退出相机app时手机并没有杀掉(kill)相机app的应用进程，systemserver进程可通过热启动的方式将相机app的应用进程切换至手机前台继续运行，这种应用的热启动方式一般耗时较短。

相应的，如果正在运行的应用进程中不存在相机app的应用进程，则systemserver进程需要通过冷启动的方式重新创建相机app的应用进程，从而使相机app的应用进程能够开始运行相机app的代码并显示相应的应用界面。此时，systemserver进程可调用ams向zygote进程发送微信应用进程的创建请求。例如，systemserver进程可通过socket的方式与zygote进程进行进程间通信。

其中，systemserver进程向zygote进程发送的创建请求中携带有第一应用的应用信息(applicationinfo)。该应用信息中可以包括第一应用的包名、第一应用的应用权限、第一应用中包含的类文件名称、类文件所需的一个或多个类加载器以及类加载器之间的依赖关系等。后续，zygote进程可利用这些应用信息创建出能够正确运行第一应用的代码的应用进程。

一般，应用的apk(androidapplicationpackage)文件中设置有配置文件，该配置文件中包含应用的应用信息。在手机中安装应用时，systemserver进程可为该应用创建相应的目录，并在创建的目录下存储该应用的应用信息。这样，后续systemserver进程可从相应的目录中获取到各个应用的应用信息。例如，当systemserver进程接收到相机app的启动消息后，可从预先为相机app设置的目录中获取相机app的应用信息，并将该应用信息携带在应用进程的创建请求中发送给zygote进程。

由于第一应用的应用信息中记录了第一应用所需的一个或多个类加载器，因此，zygote进程响应第一应用的创建请求为第一应用创建了应用进程后，可将创建请求中携带的应用信息传递给第一应用的应用进程。后续，第一应用的应用进程在初始化主线程的同时，还可以根据该应用信息创建相应的类加载器加载类文件。这样，在启动第一应用时应用进程无需等待主线程初始化完成便可并行地创建相应的类加载器加载类文件，从而缩短应用冷启动的启动时间。

s404、响应于上述创建请求，手机中的zygote进程创建第一应用的应用进程。

示例性的，zygote进程接收到systemserver进程发来的微信应用进程的创建请求后，可响应该创建请求创建相机app的应用进程a。例如，zygote进程可通过fork函数为相机app的应用进程a分配一块内存空间，并为相机app的应用进程a分配一个进程id。zygote进程可将为应用进程a分配的进程id返回给systemserver进程，以使得systemserver进程根据该进程id获知相机app的应用进程a已经创建。

s405、第一应用的应用进程并行地执行线程1和线程2，线程1用于对第一应用的主线程进行初始化，线程2用于根据上述应用信息创建类加载器加载第一应用的类文件。

一般，zygote进程为相机app创建的应用进程a中包括应用的主线程(activitythread)。该主线程将作为应用进程a的起点，应用进程a中的其他线程都是由主线程启动的。相机app的应用进程a在运行相机app的代码前，还需要对应用进程a中的activitythread进行初始化，并将相机app的类文件加载至zygote进程为应用进程a分配的内存中，从而为应用进程a搭建出能够正常运行相机app类文件的虚拟机环境。否则，相机app的应用进程a无法开始执行相机app的代码，即相机app中的各个类文件。

在本申请实施例中，如图6所示，zygote进程为相机app创建出应用进程a后，应用进程a中的主线程可创建临时线程1，并将上述创建请求中相机app的应用信息传递给临时线程1。进而，应用进程a可通过主线程执行activitythread的main函数完成对主线程的初始化。同时，应用进程a可根据相机app的应用信息，通过临时线程1创建相机app的类加载器，并使用该类加载器将相机app的类文件加载至内存中。也就是说，应用进程a可通过多线程的方式并行地完成主线程初始化和加载类文件等步骤，从而缩短应用冷启动的启动时间。

一方面，activitythread的main函数用于对主线程进行初始化。主线程通过执行activitythread的main函数可创建应用进程a运行时需要的文件目录，在systemserver进程的ams中注册应用进程a，并创建应用进程a运行时与systemserver进程中各类服务交互时的消息分发机制等。主线程进行初始化后可为相机app搭建出应用进程a运行时的虚拟机环境。

另一方面，上述临时线程1可根据相机app的应用信息，执行createclassloader函数创建应用信息中记录的类加载器，并使用类加载器将相机app中的类文件加载至为应用进程a分配的内存中，这样应用进程a才能在内存中开始运行相机app的类文件。示例性的，zygote进程在创建应用进程a时，可将systemserver进程发来的创建请求中的应用信息传递给应用进程a的主线程。该应用信息中记录了相机app的类文件所需的一个或多个类加载器，例如，该应用信息中记录了类加载器1的标识，说明相机app在运行类文件时需要使用类加载器1加载类文件。

那么，应用进程a的主线程在创建临时线程1时，可将类加载器1的标识作为输入参数传递给临时线程1。这样，临时线程1可根据类加载器1的标识创建类加载器1，并使用类加载器1将相机app的类文件加载至应用进程a占用的内存中。

在一些实施例中，相机app的应用信息中可能记录了多个类加载器的标识，例如，类加载器1和类加载器2的标识，说明相机app在运行时需要使用类加载器1和类加载器2加载不同的类文件。

此时，与图6所示的并行线程类似的，如图7所示，zygote进程为相机app创建出应用进程a后，应用进程a中的主线程可创建临时线程1和临时线程2。并且，应用进程a的主线程可将类加载器1的标识作为输入参数传递给临时线程1，同时将类加载器2的标识作为输入参数传递给临时线程2。这样，临时线程1可根据类加载器1的标识创建类加载器1，并使用类加载器1将相机app的第一类文件(第一类文件可以有一个或多个)加载至应用进程a占用的内存中。同时，临时线程2可根据类加载器2的标识创建类加载器2，并使用类加载器2将相机app的第二类文件(第二类文件可以有一个或多个)加载至应用进程a占用的内存中。也就是说，如果应用启动时需要多个类加载器，则应用进程可通过多线程的方式并行地创建多个类加载器同时加载类文件，从而缩短应用冷启动的启动时间。

在另一些实施例中，相机app的应用信息中还可以记录多个类加载器之间的依赖关系。也就是说，相机app在运行时需要多个类加载器，且这多个类加载器之间存在依赖关系。例如，相机app的应用信息中可以记录类加载器1、类加载器2和类加载器3的标识，并声明类加载器3依赖于类加载器1和类加载器2。也就是说，类加载器3的创建过程依赖于类加载器1和类加载器2的创建结果，当加载器1和类加载器2的创建成功创建后，才能成功创建类加载器3。

这样一来，创建类加载器3的过程无法与创建加载器1和类加载器2的过程并行执行。此时，如图8所示，zygote进程为相机app创建出应用进程a后，应用进程a中的主线程可创建临时线程1、临时线程2和临时线程3。并且，应用进程a的主线程可将类加载器1的标识作为输入参数传递给临时线程1，将类加载器2的标识作为输入参数传递给临时线程2，并将类加载器3的标识作为输入参数传递给临时线程3。

不同的是，仍如图8所示，临时线程1在运行时可占用对象锁1。当临时线程1根据类加载器1的标识创建类加载器1并完成相应类文件的加载后，可释放占用的对象锁1，此时，临时线程3才能够获取到对象锁1访问临时线程1的运行结果。同样，临时线程2在运行时可占用对象锁2。当临时线程2根据类加载器2的标识创建类加载器2并完成相应类文件的加载后，可释放占用的对象锁2，此时，临时线程3才能够获取到对象锁2访问临时线程2的运行结果。那么，当临时线程3获取到对象锁1和对象锁2后，临时线程3可根据临时线程1和临时线程2的运行结果，创建与类加载器3的标识对应的类加载器3，并使用类加载器3完成相应类文件的加载。

也就是说，如果应用启动时需要的多个类加载器之前具有依赖关系，则应用进程可通过多线程的方式先并行地创建不具有依赖关系的类加载器加载类文件，相比于通过串行的方式创建每一个类加载器加载类文件，这种方式也可缩短应用冷启动的启动时间。

另外，上述实施例中是以主线程通过创建n(n为大于1的整数)个临时线程并行地创建n个类加载器举例说明的，其中每个临时线程用于创建一个类加载器。可以理解的是，主线程也可以通过创建m(m＜n)个临时线程并行地创建上述n个类加载器，此时，一个临时线程可串行的创建多个类加载器。

例如，如果相机app在运行时需要类加载器1至类加载器4，且这4个类加载器之间不存在依赖关系，则如图9所示，zygote进程为相机app创建出应用进程a后，应用进程a中的主线程可创建临时线程1和临时线程2。其中，临时线程1可用于创建类加载器1和类加载器2，并使用类加载器1和类加载器2完成相应类文件的加载；临时线程2可用于创建类加载器3和类加载器4，并使用类加载器3和类加载器4完成相应类文件的加载。这样一来，虽然每个临时线程运行时是通过串行的方式创建类加载器加载类文件，但多个临时线程之间可通过并行的方式运行，也可缩短应用冷启动的启动时间。

当应用进程a的主线程通过执行activitythread的main函数完成主线程的初始化，并且，应用进程a的各个临时进程通过创建类加载器完成类文件的加载后，应用进程a才可以开始执行相机app的类文件启动相机app。那么，当主线程执行完activitythread的main函数后，主线程可查询各个临时线程对是否完成类文件的加载。

仍以图6所示的临时线程1举例，主线程执行完activitythread的main函数后，可尝试获取临时线程1占用的对象锁。由于临时线程1在创建类加载器1以及加载类文件时一直占用该对象锁，直至临时线程1执行了类文件的加载后可释放该对象锁，那么，如果主线程获取到该对象锁，说明相机app本次启动所需的类文件已经加载完毕，则应用进程a可继续执行下述步骤s406。

相应的，如果主线程无法获取到临时线程1占用的对象锁，说明相机app本次启动所需的类文件还没有加载完成，则主线程可通过线程阻塞的方式等待获取临时线程1占用的对象锁，直至临时线程1完成了类文件的加载后，主线程可获取到临时线程1释放的对象锁，进而继续执行下述步骤s406。

s406、第一应用的应用进程开始运行第一应用的代码，显示出第一应用的应用界面。

仍以相机app的应用进程a举例，应用进程a通过线程并行的方式完成主线程的初始化以及类文件的加载后，可以在zygote进程为应用进程a分配的内存中开始运行相机app的代码(即相机app的类文件)。此时，如图10所示，手机可显示出相机app的应用界面1001，从而使用户获知手机已经启动了相机app。

当然，在应用进程a开始运行相机app的代码之前，为了减少用户等待相机app启动的时间，手机还可以向用户显示预设的图片、动画或广告等内容，本申请实施例对此不做任何限制。

可以看出，在本申请实施例中，手机通过冷启动的方式创建待启动应用的应用进程时，可通过多线程并行的方式完成主线程初始化和加载类文件等工作。这样一来，可以缩短从用户打开应用至手机开始运行应用的代码之间的启动时间，提高用户打开应用时的使用体验。

在另一些实施例中，手机在启动应用时除了可以通过launcher向systemserver进程发送应用的启动消息外，还可以通过其他方式向systemserver进程发送应用的启动消息。例如，手机在启动某一应用时可通过android系统中的系统广播(broadcast)向systemserver进程发送该应用的启动消息。又例如，手机在启动某一应用时可通过binder消息机制向systemserver进程发送该应用的启动消息。

一般，systemserver进程接收到某一应用的启动消息后，需要先对该启动消息进行校验，从而判断是否允许响应该启动消息启动相关应用，避免一些应用恶意启动增加手机功耗并影响用户的使用体验。例如，用户可在手机的设置或手机管家应用中设置应用启动的白名单或黑名单，例如，允许应用在后台自启动的应用白名单或者禁止开机时应用自启动的黑名单。那么，当systemserver进程接收到某一应用的启动消息后，systemserver进程可结合当前的场景(例如开机场景、后台场景等)判断此时待启动的应用是否为用户设置的白名单或黑名单上的应用。如果为白名单上的应用，则systemserver进程可允许该应用启动，即上述启动消息校验通过；如果为黑名单上的应用，则systemserver进程可禁止启动该应用，即上述启动消息校验未通过。又例如，当systemserver进程接收到某一应用启动另一应用的启动消息后，systemserver进程可根据应用类型对该启动消息进行校验。例如，如果检测到应用a通过binder服务发送广告类型应用的启动消息，则systemserver进程可禁止启动该应用，即上述启动消息校验未通过；如果检测到应用a通过binder服务发送支付类型应用的启动消息，则systemserver进程可允许该应用启动，即上述启动消息校验通过。

但是，launcher向systemserver进程发送的应用的启动消息一般是响应用户打开应用时的启动操作生成的，因此，systemserver进程对launcher发来的启动消息的校验结果一般均为允许启动应用，即启动消息校验通过。

那么，在本申请实施例中，如图11所示，当systemserver进程接收到来自launcher发来的启动消息后，systemserver进程可直接在预设的进程池中调用一个进程来创建启动该应用时需要的类加载器。也就是说，systemserver进程在接收到launcher发来的启动消息后，由于该启动消息很可能会触发后续systemserver进程启动应用，因此，systemserver进程可预先创建该应用启动时需要的类加载器，以缩短应用冷启动时的启动时间。

示例性的，systemserver进程可通过zygote进程预先创建一个进程池，进程池中可以包括一个或多个进程，这一个或多个进程并没有具体的归属，每个进程均具有自己的进程id以及内存空间。以launcher向systemserver进程发送相机app的启动消息举例，systemserver进程接收到该启动消息后，可从上述进程池中选择一个进程(例如进程1)作为相机app的应用进程，并保存进程1的进程id。进而，systemserver进程可将相机app的应用信息传递给进程1，由进程1按照上述步骤s405中的相关方法创建相机app在运行时需要使用的一个或多个类加载器，并使用创建出的类加载器加载相机app的类文件。

例如，进程1可通过多线程并行的方式创建相机app运行时需要使用的多个类加载器，并使用这些类加载器将相机app的各个类文件加载至进程1占用的内存中。

仍如图11所示，systemserver进程在接收到launcher发来的启动消息后，还可以按照现有的校验流程对该启动消息进行校验。当校验通过后，由于systemserver进程已经将上述进程1的id分配为相机app的应用进程的id，因此，systemserver进程可继续调用进程1完成对进程1中主线程的初始化。例如，进程1中的主线程可通过执行activitythread的main函数对主线程完成的初始化过程。

当进程1的主线程执行完activitythread的main函数后，主线程可在进程1中查询相机app本次启动所需的类文件是否已经加载完毕。如果类文件已经加载完毕，则进程1可作为相机app的应用进程开始运行相机app的代码，使手机显示出相机app的应用界面。

当然，如果systemserver进程在接收到launcher发来的启动消息后拒绝了该启动消息，即校验没有通过，则systemserver进程可删除预先通过进程1为相机app创建的类加载器以及加载的类文件，从而释放进程池中被占用的进程1。

另外，systemserver进程在接收到launcher发来的启动消息后，如果手机中不存在预先设置的进程池或进程池中的进程均已被占用，则systemserver进程还可以通过zygote进程创建进程1，进而通过新创建的进程1完成上述相机app的启动过程。

可以看出，在上述相机app的启动过程中，systemserver进程可将launcher发来的启动消息作为触发条件，预先调用进程1创建相机app运行时需要使用的类加载器，并使用类加载器加载相机app的类文件。这样，进程1作为相机app的应用进程在执行相机app的代码前，进行主线程初始化以及类文件加载的耗时将减少，从而缩短了应用启动时的启动时间。

需要说明的是，上述实施例中是以应用启动的场景为例阐述如何通过多线程并行的方式创建类加载器加载类文件的。可以理解的是，本领域技术人员可以根据实际经验在其他应用场景中使用上述方法并行地创建多个类加载器加载类文件，本申请实施例对此不做任何限制。

仍以相机app举例，相机app的应用进程a在运行相机app的代码时，如果查询到手机在ram的预设文件夹中为相机app下载了热补丁，则应用进程a需要将热补丁中的类文件加载至应用进程a占用的内存中。此时，应用进程a可从热补丁的配置文件中查询运行该热补丁时需要的一个或多个类加载器。如果需要多个类加载器，则应用进程a可创建多个临时线程，通过这些临时线程并行地创建各个类加载器加载热补丁中的类文件，从而缩短给相机app打热补丁的耗时。

又例如，当相机app需要升级软件版本时，可先将新的软件版本下载至手机ram内预设的文件夹中。那么，相机app在线更新其软件版本时，相机app的应用进程a需要将新软件版本中的类文件加载至应用进程a占用的内存中。此时，如果加载新软件版本中的类文件需要多个类加载器，则相机app的应用进程可通过多线程的方式并行地创建多个类加载器加载新软件版本中的类文件，从而缩短相机app升级软件版本时的耗时。

其中，应用进程通过多线程的方式并行地创建多个类加载器加载类文件的具体方法可参见上述实施例中步骤s405的相关描述，故此处不再赘述。

另外，除了使用java语言编写的各类应用程序中包含类文件外，使用其他面向对象的语言编写的文件中也可能包含类文件。例如，使用c++语言、python语言、eiffel语言等编写的文件中也包括类文件。那么，手机等电子设备在运行这些文件时可能也需要创建类加载器加载类文件。如果需要创建的类加载器有多个，则电子设备可按照上述实施例中所述的方法通过并行的方式同时创建多个类加载器并加载类文件，从而提高电子设备使用类加载器加载类文件时的工作效率。

本申请实施例公开了一种电子设备，包括处理器，以及与处理器相连的存储器、输入设备和输出设备。其中，输入设备和输出设备可集成为一个设备，例如，可将触摸传感器作为输入设备，将显示屏作为输出设备，并将触摸传感器和显示屏集成为触摸屏。

此时，如图12所示，上述电子设备可以包括：触摸屏1201，所述触摸屏1201包括触摸传感器1206和显示屏1207；一个或多个处理器1202；存储器1203；一个或多个应用程序(未示出)；以及一个或多个计算机程序1204，上述各器件可以通过一个或多个通信总线1205连接。其中该一个或多个计算机程序1204被存储在上述存储器1203中并被配置为被该一个或多个处理器1202执行，该一个或多个计算机程序1204包括指令，上述指令可以用于执行上述实施例中的各个步骤。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应实体器件的功能描述，在此不再赘述。

示例性的，上述处理器1202具体可以为图1所示的处理器110，上述存储器1203具体可以为图1所示的内部存储器121，上述显示屏1207具体可以为图1所示的显示屏194，上述触摸传感器1206具体可以为图1所示的传感器模块180中的触摸传感器，本申请实施例对此不做任何限制。

本申请实施例公开了一种芯片系统，如图13所示，该芯片系统包括至少一个处理器1301和至少一个接口电路1302。处理器1301和接口电路1302可通过线路互联。例如，接口电路1302可用于从其它装置(例如存储器、振动传感器)接收信号。又例如，接口电路1302可用于向其它装置(例如处理器1301)发送信号。示例性的，接口电路1302可读取存储器中存储的指令，并将该指令发送给处理器1301。当所述指令被处理器1301执行时，可使得上述电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

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

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

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

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