BenchCouncil交易基准，标准和评估1（2021）100003Android软件栈中的VarunGohila，Ruman，1，NisargUjjainkarb，1，J oyceeMekieb，Man u Awasthiaa印度阿育王大学印度理工学院（IndianInstitute of TechnologyA R T I C L E I N F O保留字：CPU利用率Android智能手机工作负载表征A B S T R A C T智能手机的硬件和软件生态系统发展非常迅速。在过去的十年中，系统软件（包括操作系统、语言和运行时）进行了多项创新。尽管已经完成了微体系结构的每个特征描述，但是很少有分析可用于系统软件栈的应用性能瓶颈，特别是对于移动操作系统上的当代应用。在这项工作中，我们从软件的角度进行系统利用率分析，从而补充了以前的工作提供的硬件的角度。我们的分析集中在Android驱动的智能手机上，运行较新版本的Android。使用11个代表性应用程序和其中的感兴趣区域，我们对整个Android软件堆栈进行性能分析，以确定系统性能瓶颈。我们观察到，对于大多数应用程序，最耗时的系统级线程是帧渲染线程。然而，更令人惊讶的是，我们的结果表明，所有应用程序都花费大量时间进行进程间通信（IPC），这表明Android IPC堆栈是通过软件开发进行性能优化的成熟目标，也是硬件加速的潜在目标1. 介绍智能手机已经成为我们日常生活中不可或缺的一部分。人们依赖智能手机完成与商业、金融、娱乐和社交互动相关的许多任务。目前有超过全球有20亿台移动设备在使用[1]。 爱立信2019年移动报告指出，全球有61亿移动宽带用户，长期演进（LTE）用户数量已增长至39亿[2]。这种广泛采用移动设备的快速增长可以在很大程度上归因于不断增加的设备适应性，由于大量的硬件和软件创新，这已经成为可能。这包括Android操作系统的开源性质[1]，它允许智能手机供应商为他们的硬件定制软件堆栈。因此，Android迅速获得了智能手机的大部分市场份额[3]。从系统设计的角度来看，智能手机非常有趣，因为它们需要提供许多功能，这些功能需要通用和专用计算。因此，智能手机SoC已经迅速发展成为复杂的生态系统，其中包括许多专用IP模块，除了通用CPU之外，还包括DSP和GPU [1]。随着时间的推移，这些单元的结构的数量和多样性也在增加，以适应不断变化的应用需求。最近已经做出了许多努力来了解智能手机设备的性能瓶颈和利用率特征[4然而，大多数先前的研究都集中在从建筑设计的角度自下而上地理解智能手机的利用率。例如，[5]给出了ARM大小内核之间的计算分布。他们还研究了时钟频率，在该频率下，人们可以以节能的方式在移动终端上执行计算。这些研究是重要的，因为移动SoC架构发展迅速，新架构的特性是很重要的，以了解和减轻新架构的性能瓶颈。智能手机的软件堆栈的发展速度甚至超过了硬件。 Android一直遵循一年一次的发布周期近年来，随着每次迭代增加更多的功能和优化[18]。 因此，每次发布都会对软件栈造成重大更改，这可能导致性能瓶颈。了解这些瓶颈不仅有助于优化下一代应用程序，还有助于制定未来架构创新的决策。尽管其重要性，但人们对应用程序和系统软件中的软件瓶颈缺乏了解。理解和列举软件栈的性能瓶颈仍然是一项重要的工作，但系统研究界还没有认真对待然而，在这方面，这项工作得到了华为印度技术公司（DSA 2020112121）和阿育王大学（R/IFR/CMS/MAW/18）的资助∗通讯作者。电子邮件地址：varun. ashoka.edu.in（V. Gohil）。1 两位作者贡献相当。https://doi.org/10.1016/j.tbench.2021.100003接收日期：2021年8月6日;接收日期：2021年10月11日;接受日期：2021年10月20日2021年11月5日网上发售2772-4859/©2021作者。 Elsevier B.V.代表KeAi Communications Co. Ltd.提供的出版服务。BY许可证（http://creativecommons.org/licenses/by/4.0/）。可在ScienceDirect标准和评价期刊主页：https://www.keaipublishing.com/en/journals/benchcouncil-transactions-on-benchmarks-standards-and-evaluations/BenchCouncil交易基准，诉Gohil，N.Ujjainkar，J.Mekie等人BenchCouncil交易基准，标准和评估1（2021）1000032表1追踪的应用程序及其感兴趣的区域类别应用感兴趣区域（ROI）PDF查看器Adobe Flash Player [8]阅读PDF摄像机摄像机拍摄照片，录制视频游戏Candy Crush [9]玩游戏的一个级别社交网络Facebook [10]滚动浏览提要[11]第11话虚拟助手谷歌助手[12]执行查询浏览应用Google Chrome [13]搜索、滚动页面位置应用程序谷歌地图[14]搜索位置，放大位置音频流媒体Spotify [15]在后台播放歌曲，在前台播放歌曲即时通讯应用WhatsApp [16]发送消息视频流YouTube [17]播放视频除了上面提到的感兴趣的区域，我们还跟踪每个应用程序的启动技术公司最近的公告[19]表明，Android软件堆栈中存在很大的性能改进空间。我们相信，自上而下的分析应用程序的特点将增加我们的理解移动设备的补充以前的工作。因此，我们研究了基于Android的智能手机的软件子系统，跟踪整个系统（应用程序+操作系统）堆栈在运行时，捕捉性能瓶颈。先前的工作[4，6，7]已经使用线程级并行性（TLP）作为度量来测量CPU利用率，以识别硬件可以利用的并行性的量。虽然TLP是决定要放置在芯片上的核的数量的有用度量，但是它不提供关于由核执行的计算和由计算支持的功能的信息了解正在执行的计算的功能对于优化软件和设计与CPU一起使用的新型硬件加速器是必要的。通常，在Android智能手机中，特定线程或一组线程负责特定功能。通过识别具有高执行时间的线程，可以识别消耗更高CPU时间并且应当被优化的功能性。因此，本文试图回答以下问题。• 每个应用程序最耗时的线程是什么• 在一个应用程序的横截面中，是否有一些共同的线程最终消耗了最多的时间？• 哪些线程在应用启动期间占用的时间最多我们相信，这种类型的分析将有助于开发高性能软件的过程，并有助于确定移动设备的潜在硬件加速机会。由于之前的许多研究都指出了应用程序启动时间对用户参与和体验的重要性[20]，我们也特别关注应用程序启动作为一个感兴趣的区域。总体而言，这项工作的主要贡献如下：• 我们在实际硬件上识别并执行11个流行的移动应用程序的系统级跟踪，运行Pie版本的Android（Android 9），这有助于我们分析应用程序和操作系统线程消耗的时间。• 为了更好地表示性能信息，我们根据线程的功能将其分组到bin中。这有助于我们提高结果的可解释性，并分析每个功能所消耗的时间。• 我们发现，对于大多数应用程序，最耗时的线程是一个名为RenderThread的系统管理线程或另一个涉及帧渲染的线程• 使用线程箱，我们确定，尽管最耗时的线程几乎总是与帧渲染相关的线程，但执行时间的较大部分被负责进程间通信（IPC）的线程组消耗。这种洞察力使进程间通信成为软件优化和硬件加速的表2智能手机详细信息。技术规范设备型号Nokia 6.1 Plus操作系统Android Pie架构ARM 64位CPU高通骁龙636CPU核心8GPU Adreno（TM）509RAM 6 GB分辨率1080 ×2280显示PPI 4312. 方法2.1. 追踪的申请我们选择了11个应用程序进行研究，每个应用程序都代表了智能手机的一个常见用例。例如，我们包括作为浏览应用的谷歌Chrome[13]，作为视频流应用的Youtube [17]，作为消息应用的WhatsApp[16]，以及Gmail [11] 作为邮件应用程序。大多数选定的应用程序都预装在大多数Android智能手机中。我们根据其受欢迎程度来选择其余的应用程序，我们使用它们在Google Play [21]商店当我们进行研究时，选定的应用程序位于热门图表的顶部。以前的工作[1]建议应该将应用程序划分为感兴趣区域（ROI），以更深入地了解应用程序。感兴趣区域（ROI）是执行特定任务的应用程序扩展的较小部分。例如，Google Chrome有多个感兴趣的区域，如执行搜索，切换标签和滚动。这些ROI中的每一个都处理Google Chrome的特定功能。将应用程序划分为ROI的原因是这些单独的ROI可以直接影响用户体验，并且彼此独立地研究它们可以降低需要执行的分析的复杂性。我们提供了一个全面的清单我们跟踪的所有应用程序及其ROI在表1中。除了 表1中提到的ROI，我们还跟踪所有应用程序的应用程序启动2.2. 工具和设置对于系统级（应用程序+操作系统）跟踪，我们使用Systrace [22]工具。Systrace是Android Studio附带的工具，主要用于分析Android设备的性能。它是围绕Atrace [23]和Ftrace [24]的包装器。 Atrace执行用户空间跟踪，而ftrace跟踪Linux内核。跟踪不仅捕获应用程序产生的线程，还捕获Android操作系统执行的后台线程。从使用Systrace获得的跟踪中，我们可以找到每个线程在处理器内核上执行的时间。为了跟踪ROI，我们启动Systrace跟踪并执行与ROI相关的任务。我们立即停止Systrace跟踪时，任务诉Gohil，N.Ujjainkar，J.Mekie等人BenchCouncil交易基准，标准和评估1（2021）1000033Fig. 1. Binning的效果。 Google Chrome的滚动ROI结果王的结局。我们对每个应用程序的每个感兴趣区域执行跟踪至少五次。我 们 在 诺 基 亚 6.1 Plus [25] 智 能 手 机 上 进 行 实 验 。 Android Pie（Android 9）操作系统。有关智能手机的更多详细信息见表2。2.3. 绑定线程Android操作系统和应用程序产生了大量的线程。由于Systrace执行系统级跟踪，因此生成的跟踪包含大量线程的信息。 这会导致产生的情节混乱，难以解释。因此，为了减少混乱并提高可解释性，我们将为公共功能工作的线程分组到单个bin中。我们确定了两个主要的箱子，这有助于我们的分析。它们是：• 帧渲染仓（FR仓）• 进程间通信仓（IPC仓）图1显示了线程合并的效果。上的饼图图 中的顶部1显示了Google Chrome线程装箱后，顶部的饼图将转换为底部的饼图。后者显示了所选容器和剩余线程之间的执行时间分布。观察底部的饼图，我们可以很容易地推断出执行时间的主要部分花费在帧渲染上。我们能够根据功能创建两类线程箱表3容器内线程的列表。帧渲染仓RenderThreadsurfaceflingerUiThreadCompositorCrGpuMainCrRendererMainandroid.displaymdss_fb0DispSyncandroid.anim上述清单并非详尽无遗除其他 进程通信箱粘合剂HwBinderChrome浏览器_IOThreadChrome浏览器个别线程。在对线程进行装箱时，我们确保线程被映射到正确的bin，并且没有线程被映射到多个bin。Frame Rendering Bin：Frame Rendering（FR）bin是一组负责在移动终端屏幕上渲染帧的所有线程表3提供了这个bin中的线程列表这个bin中的主要线程是RenderThread、Surface-Flinger和UiThread。进程间通信Bin：进程间通信（IPC）bin是一组所有线程，它们被执行以在进程之间共享信息。表3提供了一个全面的清单 所有的线在这个箱子里。IPC bin中的主要线程是Binder和HwBinder。3. 结果和观察结果在本节中，我们将讨论我们最初在第1节中提出的问题的答案。3.1. 每个应用程序最耗时的线程/bin是什么表4显示了所有11个应用程序的每个感兴趣区域的最耗时线程。 我们注意到，对于大多数跨应用程序的ROI，RenderThread是最耗时的线程。RenderThread是一个系统管理的线程，负责将渲染工作卸载到GPU，以减轻UiThread的负担[26]。通过这样做，它可以确保即使在UiThread延迟时动画也是平滑的，这对于保持用户的服务质量（QoS）至关重要[26]。RenderThread是ROI中最耗时的线程，就像在Facebook中滚动一样，Chrome浏览器，使用WhatsApp和Gmail发送消息，录制视频，或在Spotify上的前台播放歌曲。所有这些ROI都涉及到对用户显示的频繁修改，由RenderThread使用。对于游戏Candy Crush，GLThread是最耗时的线程。GLThread也是一个渲染线程，负责执行OpenGL图形渲染操作[27]。类似地，对于Google MapsGLViewThreadImp负责管理OpenGL图形库的视图，这些视图是用户界面组件的基本构建块[28，29]。对于Google Chrome搜 索 ROI ， 我 们 观 察 到 CrRendererMain 是 最 耗 时 的 线 程 。CrRendererMain是网页的渲染器线程。根据Chromium诉Gohil，N.Ujjainkar，J.Mekie等人BenchCouncil交易基准，标准和评估1（2021）1000034表4每个ROI最耗时的线程和bin括号内的数字表示执行时间的百分比感兴趣的应用区域最耗时线程最耗时binAdobe Read PDF来自.adobe.reade（13.6%）法国（26.7%）相机拍照后期处理图像（14. 5%）IPC（30. 3%）摄像机记录视频渲染线程（11. 0%）IPC（22. 1%）糖果粉碎播放1级GLThread（45.2%）FR（54.2%）Facebook Scroll RenderThread（17.2%）IPC（23.1%）Gmail Send Mail RenderThread（17.3%）IPC（29.8%）Google Assistant Query RenderThread（11.2%）IPC（25.4%）谷歌浏览器滚动渲染线程（19.4%）法国（43.4%）谷歌浏览器搜索CrRendererMain（13.4%）IPC（33.8%）Google地图搜索位置JIT线程池（11.6%）IPC（26.4%）谷歌地图放大位置GlViewThreadImp（17.1%）法国（26.6%）Spotify在后台播放音乐AndroidOut_1D（6.2%）IPC（20.6%）Spotify在前台播放音乐RenderThread（27.4%）法国（39.2%）Whatsapp发送消息RenderThread（19.4%）IPC（35.8%）YouTube播放视频ExoPlayerImplIn（8.8%）IPC（38.6%）总的来说，涉及到这些ROI的最耗时的线程在用户显示器上呈现帧对于YouTube此线程运行ExoPlayer，这是Android的替代媒体播放器[31，32]。为了卡姆-时代的“拍照”ROI，PostProcessingImag线程是时间消耗最高的。从线程的名称来看，我们假设该线程可能涉及图像的后处理，涉及设置曝光、白平衡和应用选定滤镜等任务。不幸的是，我们没有找到任何关于om.adobe.reade和AndroidOut_1D线程，因此不能评论其功能。总的来说，在我们研究中涉及的11个应用程序的15个ROI中，有7个ROI是最耗时的线程。 此外，在15个ROI正在对画面进行适当的渲染 还应该注意，RenderThread的执行时间是不连续的。执行 倍 的 多 实例 的 添加了RenderThread计算总执行时间。我们发现RenderThread的每个实例都是短暂的，平均执行时间为0.73 ms，并且存在数千个（1000在每个感兴趣的区域内。上述结果可能会导致一个结论，帧渲染是应用程序的主要时间消耗者，因为大多数应用程序的最耗时线程与帧渲染有关。然而，我们发现，这是不是这样的情况下，我们分析的结果线程箱。表4显示了最耗时的bin是进程间通信（IPC）bin。IPC bin是应用程序中15个ROI中10个ROI的最高时间消耗。 这表明，尽管主要的耗时线程与帧渲染相关，但作为一个整体，用于在进程之间通信的线程比帧渲染中涉及的线程耗时更大。这一观察表明，进程间通信可能是移动应用程序的一个比帧渲染更大的瓶颈。3.2. 在应用程序中常见的耗时线程是什么我们隔离了应用程序中常见的耗时线程。我们相信优化这些线程将在应用程序中带来更高的性能优势。我们观察到以下耗时线程在应用程序中很常见RenderThread：它是最耗时的线程7出考虑15个ROI，它是15个ROI中11个最耗时的三个线程它卸载了渲染任务从UiThread到GPU，以保持动画避免掉帧[26]。surfaceflinger：这是占主导地位的耗时线程后，帧渲染箱中的RenderThread它是表5应用程序启动时最耗时的线程和垃圾箱。括号内的数字表示线 程 /b i n 占 用 的执行时间百 分 比 。应用程序最耗时线程最耗时binAdobe om.adobe.reade（12.6%）法国（23.5%）Camera RenderThread（14.9%）IPC（35.2%）Candy Crush GLThread（44.6%）FR（57.9%）Facebook Jit线程池（11.6%）IPC（12.6%）Gmail Jit线程池（10.2%）IPC（32.1%）Google Assistant RenderThread（11.6%）IPC（39.7%）Google Chrome RenderThread（11.6%）IPC（36.6%）Google Maps Jitthread pool（14.0%）IPC（23.2%）Spotify m.spotify.musi（13.9%）FR（18.0%）Whatsapp RenderThread（19.4%）IPC（36.0%）YouTube RenderThread（12.5%）IPC（25.1%）15个ROI中有5个的前三个最耗时的线程。SurfaceFlinger线程从各种图形缓冲区中获取多个项目，并将它们组合到单个缓冲区中，然后发送到用户显示器[33]。绑定器：绑定器线程是进程间通信bin的主要时间消耗者。它们是用来交流的在应用过程中以及在框架和应用过程中[34]。框架进程由Android框架管理，并且与设备无关。HwBinder：类似于Binder线程，HwBinder线程是也是进程间通信箱的主要时间消耗者。它们用于框架和供应商流程之间的通信[34]。供应商进程是由供应商添加到Android框架的代码产生的进程，通常依赖于设备。3.3. 在应用启动过程中，哪些线程比较耗时在智能手机的背景下，应用程序的发布是人们感兴趣的关键领域.有人可能会认为，减少应用程序启动时间的好处比减少应用程序的运行时间少。尽管这一说法 是真实和直观的，应用程序的启动是重要的，因为智能手机的使用模式。许多用户在他们的智能手机上有大量的短期会话。这些短暂的会议持续不到10秒[20]。在这些短会话期间，长的应用启动时间会显著降低用户体验，这就是为什么已经做出了一些努力来优化应用启动时间的原因。例如，Android即使在关闭后也会保留应用程序内存，因此未来启动应用程序所需的时间可以减少[35]。我们跟踪表1中列出的每个应用程序的应用程序启动。 表5显示了在启动应用程序。我们观察到RenderThreadcon-对于大多数诉Gohil，N.Ujjainkar，J.Mekie等人BenchCouncil交易基准，标准和评估1（2021）1000035应用.在应用程序启动期间，RenderThread是11个应用程序中5个最耗时的线程，而它是11个应用程序中9个最耗时的线程中的这是预料之中的，因为当启动新的应用程序时，需要在屏幕上呈现与所启动的应用程序相对应的与其他ROI类似，进程间通信bin是应用启动期间消耗时间最多的。这表明优化进程间通信也将优化应用程序启动，这将直接提高服务质量（QoS）。4. 相关工作几个先前的出版物集中于通过表征硬件来评估智能手机的性能和能量。例如，Gao等人[6，7]证明移动应用程序具有低线程级并行性（TLP），导致分配的内核利用率不足。[5]最近的一项工作研究了具有大内核和小内核的智能手机架构中的内核利用率。他们报告称，独立应用程序在执行期间很少使用所有大内核，但在应用程序启动或更新期间，所有大内核都被利用来满足延迟目标并避免用户体验下降。大多数这些作品主要是试图回答这个问题，“对于什么百分比的执行时间是核心正在利用？”.虽然回答上述问题对于识别性能低下至关重要，但它并没有提供对系统软件堆栈的深入了解，这可能有助于缓解这些瓶颈。我们的工作通过识别具有最高执行时间的功能（IPC和RenderThread）来补充先前的工作，优化将带来显着的性能优势。有一些研究采用软件优先的方法来分析智能手机应用程序的性能。[36]使用静态代码分析来识别应用程序中频繁出现的性能错误。此外，[37]开发一个工具，可以自动检测Android智能手机上的性能瓶颈。然而，鉴于Android生态系统的性质和频繁的主要发布周期，需要不断进行性能瓶颈分析 系统软件栈的一部分我们的工作补充了这些作品，执行以软件为中心的性能分析。我们不使用任何形式的静态分析，而是通过在真实世界的智能手机上实际运行应用程序来识别智能手机应用程序的耗时线程，并提供性能优化的目标。5. 局限性和今后的工作我们目前的研究仅限于Android版本9。由于Android生态系统的快速移动特性，由于每年的发布周期，在我们进行这项研究的同时，Android的新版本已经发布。此外，Android生态系统缺乏性能分析工具，这与x86/x64不同，x86/x64中存在大量开源的、维护良好的性能分析工具，而ARM上的Android却不是这种情况。本文所做的分析是使用Systrace [22]进行的，支持Android 9版本。然而，最近的Android版本提供了一个名为Perfetto的工具，用于系统级跟踪。此外，Android 9上的Perfetto需要打开系统跟踪服务，这是不可能的，因为我们执行了我们在Android上的实验[39]。这些因素迫使我们将研究限制在Android 9上。然而，我们相信，在Android版本中进行类似的研究可能会揭示重要的性能优化趋势。我们也相信，未来的工作将是一个更全面的研究，通过使用更多的智能手机型号和不同的Android版本的每一个模型。这项工作的范围仅限于回答“Android系统堆栈的哪个功能或子系统占用最高”的问题执行时间的一部分？”.虽然这项工作非常重要，但它并没有揭示子系统中的哪些部分需要优化，以及什么样的优化是有益的。例如，我们的工作表明IPC bin消耗了更高的执行时间，但它没有指出IPC子系统的哪些确切组件应该被优化以减少这一时间。正如我们之前提到的，这主要是由于缺乏可用于此类分析的工具。像Systrace这样的工具不提供此类信息。 所提出的分析仅限于Android智能手机。 我们无法在其他操作系统的智能手机上进行类似的分析，因为不存在任何开源工具，作为这些操作系统的Systrace最后，工作的重点是感兴趣的区域（ROI）的执行时间分析故障。作者试图为每个应用程序选择最相关的ROI，这与过去所做的研究类似，这些研究基于最常见的用户行为模式，其性能决定了用户参与度[1，20]。然而，我们承认，每个应用程序的ROI集是不一定是最具代表性的，也不一定是详尽的。今后的工作将侧重于为应用程序确定一组更具代表性和详尽的感兴趣区域6. 结论在这项工作中，我们进行了系统级的性能瓶颈分析的Android智能手机的11个流行的应用程序。 我们的研究结果表明，对于所有的应用程序，最高的时间con.suming线程是RenderThread或与之相关的其他线程帧渲染。此外，在基于线程的分组将线程分组到bin中功能，我们发现最耗时的功能是进程间通信。我们发现应用程序执行和应用程序启动的时间消耗分布相似。我们的研究结果表明，软件优化和硬件加速应针对进程间通信，以最大限度地提高性能和改善用户体验。引用[1] V.J. Reddi，H.尹，A. 20亿设备和计数，IEEE Micro 38（1）（2018）6-21。[2]爱立信移动性报告Q2更新2019年8月，pp。4、网址：https：//www.ericsson.com/4912aa/assets/local/mobility-report/documents/2019/ericsson-mobility-report-q2-2019-update.pdf。[3]IDC -智能手机市场份额-操作系统，IDC：全球市场的首要情报-gence公司（2021）网址：https://www.idc.com/promo/smartphone-market-分享。[4]M. Halpern，Y. Zhu，V.J. Reddi，Mobile CPU's rise to power：Quantifying theimpact of generation mobile CPU design trends on performance， energy， anduser satisfaction，in：2016 IEEE International Symposium on High PerformanceComputer Architecture，HPCA，2016，pp. 64http://dx.doi.org/10.1109/[5] J.Whitehouse ， Q. Wu ， S. Song ， E. John ， A.Gerstlauer ， L.K.John，异构智能手机架构中的核心利用率和驻留研究，发表于：2019年ACM/SPEC国际性能会议论文集工程ICPE[6]C. Gao，中国粘蝇A. Gutierrez，R.G. Dreslinski，T. Mudge，K. Flautner，G.Blake， A study of thread level parallelism on mobile devices， in： 2014 IEEEInternational Symposium on Performance Analysis of Systems and Software ，ISPASS，2014，pp. 126http://dx.doi.org/10.1109/ISPASS.2014.6844468[7]C. Gao，中国粘蝇A. Gutierrez，M. Rajan，R.G. Dreslinski，T.马奇角Wu，Astudy of 移 动 终 端 utilization ， in ： 2015 IEEE International Symposium onPerformanceAnalysisofSystemsandSoftware ， ISPASS ， 2015 ，pp.225http://dx.doi.org/10.1109/ISPASS.2015.7095808。[8]Adobe Acrobat Reader：PDF查看器，编辑器&创建器-Google Play上的应用程序，URL：https://play.google.com/store/apps/details? id=com.adobe.reader&hl=en.[9]Candy crush sagahttps://play.google.com/store/apps/details？id=com.king.candycrushsaga& hl=en{_} IN.[10] Facebook，（2021）URL：https://www.facebook.com/。[11] Gmail，URL：https://www.google.com/gmail/。[12] Google Assistant|您自己的个人谷歌，URL：https://assistant.google.com/intl/en{_}in/.[13] 谷歌 Chrome - 的 新 Chrome & 最 安全 web 浏览器， 网址：https：//www.google.com/chrome/网站。诉Gohil，N.Ujjainkar，J.Mekie等人BenchCouncil交易基准，标准和评估1（2021）1000036[14] Google Maps，（2021）URL：https://www.google.com/maps.[15] 人人听音乐- Spotify，网址：https://www.spotify.com/in/。[16] WhatsApp，，URL：https://www.whatsapp.com/.[17] YouTube，网址：https://www.youtube.com/。[18] 机器人“O”能整理机器人碎片吗网址：https：//www.cn.cncounterpointresearch.com/can-android-o-de-fragment-android/网站。[19] D. Burke，What's new in Android 12 Beta，2021 URL：https：//android-developers. googleblog.com/2021/05/whats-new-in-android-12-beta.html网站。[20] H.法拉基河Mahajan，S. Kandula，D.埃斯贝罗普洛斯河 Govindan，D. 埃斯特林，2021年。[21] Google Play，URL：https://play.google.com/store.[22] 系统跟踪概述，Android Developers，（2021）URL：https：//developer。android.com/studio/profile/systrace网站。[23] Atrace/atrace.c-平台/系统/额外功能- -一种git在谷歌，网址：http：//android.googlesource.com/platform/system/extras/+/jb-mr1-dev-plus-aosp/atrace/atrace.c。[24] FTrace，URL：https://www.kernel.org/doc/Documentation/trace/ftrace.txt.[25] 诺基亚6.1 plus，网址：https://www.nokia.com/phones/e_in/nokia-6-plus。[26] E. Marletti，Understanding the RenderThread，Medium（2017）URL：medium.com/@workingkills/understanding-the-renderthread-4dc17bcaf979.[27] GLSurfaceView，Android Developers，（2021）URL：https://developer.android. com/reference/android/opengl/GLSurfaceView.[28] GLView| Tizen插件，URL：https://docs.tizen.org/application/native/guides/ui/efl/mobile/component-glview/.[29] View，AndroidDevelopers（2021）URL：https://developer.android.com/reference/android/view/View.[30] 了解：追溯结果-铬项目，网址：https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/trace-event-reading.[31] ExoPlayer，AndroidDevelopers，（2021）URL：https://developer.android.com/guide/topics/media/exoplayer.[32] ExoPlayer，URL：https://exoplayer.dev/。[33] SurfaceFlinger 和 WindowManager ， Android 开 源 项 目 （ 2021 ） URL ：https://source.android.com/devices/graphics/surfaceflinger-windowmanager。[34] 使 用 粘 合 剂 IPC| Android 开 源 项 目 ， 网 址 ： https://source.android 。com/devices/architecture/hidl/binder-ipc.[35] 管 理 应 用 的 内 存 |Android 开 发 者 ， URL ： https ： //developer.android.com/topic/performance/memory网站。[36] Y. Liu，C. Xu，S.C. Cheung，Characterizing and detecting performance bugs forsmartphone applications，in：Proceedings of the 36th International Conferenceon Software Engineering，2014，pp. 1013-1024[37] Y.高，W. Dong，H. Huang，J. Bu，C. Chen，M. Xia、X.刘，该怪谁？智能手机性能瓶颈的自动诊断，IEEE Trans. 暴徒Comput. 16（2017）1773[38] Perfetto：系统分析，应用跟踪和跟踪分析，URL：https：//perfetto。dev/.[39] 快速入门：在android上记录跟踪，URL：https://perfetto.dev/docs/quickstart/android-tracing.
我的内容管理
展开
