PinnerService 工作流程介绍

这篇博客详细介绍了Android系统组件PinnerService的配置和使用,包括是否使用pinlist、是否全量固定odex文件、以及针对相机、主页和助手应用的固定设置。在启动时,PinnerService会尝试通过mmap操作固定指定文件,并通过PinRangeSource进行内存映射,确保关键文件的安全和高效访问。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

PinnerService配置

// Pin using pinlist.meta when pinning apps.
private static boolean PROP_PIN_PINLIST = SystemProperties.getBoolean(
        "pinner.use_pinlist", true);
// Pin the whole odex/vdex/etc file when pinning apps.
private static boolean PROP_PIN_ODEX = SystemProperties.getBoolean(
        "pinner.whole_odex", true);

配置 PinnerService 默认列表

<!-- Default files to pin via Pinner Service -->
<string-array translatable="false" name="config_defaultPinnerServiceFiles">
</string-array>

<!-- True if camera app should be pinned via Pinner Service -->
<bool name="config_pinnerCameraApp">false</bool>

<!-- True if home app should be pinned via Pinner Service -->
<bool name="config_pinnerHomeApp">false</bool>

<!-- True if assistant app should be pinned via Pinner Service -->
<bool name="config_pinnerAssistantApp">false</bool>
mConfiguredToPinCamera = context.getResources().getBoolean(
                    com.android.internal.R.bool.config_pinnerCameraApp);
mConfiguredToPinHome = context.getResources().getBoolean(
                    com.android.internal.R.bool.config_pinnerHomeApp);
mConfiguredToPinAssistant = context.getResources().getBoolean(
                    com.android.internal.R.bool.config_pinnerAssistantApp);
private void handlePinOnStart() {
    // Files to pin come from the overlay and can be specified per-device config
    String[] filesToPin = mContext.getResources().getStringArray(
        com.android.internal.R.array.config_defaultPinnerServiceFiles);
    // Continue trying to pin each file even if we fail to pin some of them
    for (String fileToPin : filesToPin) {
        PinnedFile pf = pinFile(fileToPin,
                                Integer.MAX_VALUE,
                                /*attemptPinIntrospection=*/false);
        if (pf == null) {
            Slog.e(TAG, "Failed to pin file = " + fileToPin);
            continue;
        }
        synchronized (this) {
            mPinnedFiles.add(pf);
        }
        if (fileToPin.endsWith(".jar") | fileToPin.endsWith(".apk")) {
            // Check whether the runtime has compilation artifacts to pin.
            String arch = VMRuntime.getInstructionSet(Build.SUPPORTED_ABIS[0]);
            String[] files = null;
            try {
                files = DexFile.getDexFileOutputPaths(fileToPin, arch);
            } catch (IOException ioe) { }
            if (files == null) {
                continue;
            }
            for (String file : files) {
                PinnedFile df = pinFile(file,
                                        Integer.MAX_VALUE,
                                        /*attemptPinIntrospection=*/false);
                if (df == null) {
                    Slog.i(TAG, "Failed to pin ART file = " + file);
                    continue;
                }
                synchronized (this) {
                    mPinnedFiles.add(df);
                }
            }
        }
    }
}

解压文件后,做 mmap 操作

private static PinnedFile pinFile(String fileToPin,
                                  int maxBytesToPin,
                                  boolean attemptPinIntrospection) {
    ZipFile fileAsZip = null;
    InputStream pinRangeStream = null;
    try {
        if (attemptPinIntrospection) {
            fileAsZip = maybeOpenZip(fileToPin);
        }

        if (fileAsZip != null) {
            pinRangeStream = maybeOpenPinMetaInZip(fileAsZip, fileToPin);
        }

        Slog.d(TAG, "pinRangeStream: " + pinRangeStream);

        PinRangeSource pinRangeSource = (pinRangeStream != null)
            ? new PinRangeSourceStream(pinRangeStream)
            : new PinRangeSourceStatic(0, Integer.MAX_VALUE /* will be clipped */);
        return pinFileRanges(fileToPin, maxBytesToPin, pinRangeSource);
    } finally {
        safeClose(pinRangeStream);
        safeClose(fileAsZip);  // Also closes any streams we've opened
    }
}

将文件做 mmap 操作

/**
 * Helper for pinFile.
 *
 * @param fileToPin Name of file to pin
 * @param maxBytesToPin Maximum number of bytes to pin
 * @param pinRangeSource Read PIN_RANGE entries from this stream to tell us what bytes
 *   to pin.
 * @return PinnedFile or null on error
 */
private static PinnedFile pinFileRanges(
    String fileToPin,
    int maxBytesToPin,
    PinRangeSource pinRangeSource)
{
    FileDescriptor fd = new FileDescriptor();
    long address = -1;
    int mapSize = 0;

    try {
        int openFlags = (OsConstants.O_RDONLY | OsConstants.O_CLOEXEC);
        fd = Os.open(fileToPin, openFlags, 0);
        mapSize = (int) Math.min(Os.fstat(fd).st_size, Integer.MAX_VALUE);
        address = Os.mmap(0, mapSize,
                          OsConstants.PROT_READ,
                          OsConstants.MAP_SHARED,
                          fd, /*offset=*/0);

        PinRange pinRange = new PinRange();
        int bytesPinned = 0;

        // We pin at page granularity, so make sure the limit is page-aligned
        if (maxBytesToPin % PAGE_SIZE != 0) {
            maxBytesToPin -= maxBytesToPin % PAGE_SIZE;
        }

        while (bytesPinned < maxBytesToPin && pinRangeSource.read(pinRange)) {
            int pinStart = pinRange.start;
            int pinLength = pinRange.length;
            pinStart = clamp(0, pinStart, mapSize);
            pinLength = clamp(0, pinLength, mapSize - pinStart);
            pinLength = Math.min(maxBytesToPin - bytesPinned, pinLength);

            // mlock doesn't require the region to be page-aligned, but we snap the
            // lock region to page boundaries anyway so that we don't under-count
            // locking a single byte of a page as a charge of one byte even though the
            // OS will retain the whole page. Thanks to this adjustment, we slightly
            // over-count the pin charge of back-to-back pins touching the same page,
            // but better that than undercounting. Besides: nothing stops pin metafile
            // creators from making the actual regions page-aligned.
            pinLength += pinStart % PAGE_SIZE;
            pinStart -= pinStart % PAGE_SIZE;
            if (pinLength % PAGE_SIZE != 0) {
                pinLength += PAGE_SIZE - pinLength % PAGE_SIZE;
            }
            pinLength = clamp(0, pinLength, maxBytesToPin - bytesPinned);

            if (pinLength > 0) {
                if (DEBUG) {
                    Slog.d(TAG,
                           String.format(
                               "pinning at %s %s bytes of %s",
                               pinStart, pinLength, fileToPin));
                }
                Os.mlock(address + pinStart, pinLength);
            }
            bytesPinned += pinLength;
        }

        PinnedFile pinnedFile = new PinnedFile(address, mapSize, fileToPin, bytesPinned);
        address = -1;  // Ownership transferred
        return pinnedFile;
    } catch (ErrnoException ex) {
        Slog.e(TAG, "Could not pin file " + fileToPin, ex);
        return null;
    } finally {
        safeClose(fd);
        if (address >= 0) {
            safeMunmap(address, mapSize);
        }
    }
}
I/O 问题 I/O 操作是造成抖动的常见原因。如果某个线程去访问内存映射文件,而该页面不在页面缓存中,则会发生故障,并且该线程会从磁盘读取该页面。这会造成该线程被阻塞(通常会阻塞 10 毫秒以上),并且如果问题发生在界面渲染的关键路径中,则可能会导致卡顿。造成 I/O 操作的原因多种多样,在这里我们就不一一讨论了,但在尝试改进 I/O 行为时,请注意检查以下位置: PinnerServicePinnerServiceAndroid 7.0 中新增的一项功能,可以让框架锁定页面缓存中的某些文件。这会清除这部分内存,以供任何其他进程使用。但是,如果事先已知会定期使用某些文件,可以有效地 mlock(内存锁定)这些文件。在运行 Android 7.0 的 Pixel 和 Nexus 6P 设备上,我们 mlock 了以下四个文件: /system/framework/arm64/boot-framework.oat /system/framework/oat/arm64/services.odex /system/framework/arm64/boot.oat /system/framework/arm64/boot-core-libart.oat 这些文件会被大多数应用和 system_server 持续使用,因此不应该被移出页面。并且我们发现,如果上述任何一个文件被移出页面,当从重型应用切换时,它们会被重新移回页面,从而引起卡顿。 加密:这是造成 I/O 问题的另一个可能原因。我们发现,与基于 CPU 的加密或者使用可通过 DMA 访问的硬件块相比,内嵌加密可提供最佳性能。最重要的是,内嵌加密可以减少与 I/O 相关的抖动,尤其是和基于 CPU 的加密相比。由于提取页面缓存通常发生在界面渲染的关键路径中,而基于 CPU 的加密会在关键路径中引入额外的 CPU 负载,因此会比 I/O 提取造成更多的抖动。基于 DMA 的硬件加密引擎也有类似问题,因为即使其他关键工作可以运行,内核仍然需要花费时间管理此类工作。我们强烈建议所有 SOC 供应商在构建新硬件时,都应支持内嵌加密功能。 简单解释一下
最新发布
03-13
<think>嗯,用户让我解释一下I/O问题,特别是在Android系统中导致的卡顿和抖动。首先,我需要回顾用户之前的问题,他之前问过“不必要的CPU空闲转换”,现在转向I/O问题,可能是在系统性能优化的大背景下。用户可能是一个开发者,或者是从事Android系统优化相关工作的人,需要了解I/O操作的潜在问题及解决方法。 用户提供的资料里提到,I/O操作如内存映射文件不在页面缓存中会导致页面故障,进而阻塞线程,造成卡顿。特别是提到了PinnerService和加密的影响。用户需要我简单解释这些内容。 首先,我需要明确核心问题:I/O操作如何导致抖动,特别是页面缓存未命中时的阻塞。然后要解释PinnerService的作用,它通过mlock锁定关键文件,避免被换出,从而减少页面故障。接着是加密的影响,不同类型的加密(CPU、DMA、内嵌)对性能的影响,尤其是内嵌加密的优势。 用户可能希望了解这些措施为什么有效,以及如何实施。比如,为什么mlock那些特定的文件?因为这些文件被频繁使用,锁定后减少换入换出,提升性能。加密部分,内嵌加密为什么更好?因为它减少CPU负担,避免在关键路径上增加负载。 还要注意用户提到的SOC供应商的建议,可能需要强调硬件支持的重要性。用户可能需要知道在实际开发中应如何检查和处理这些问题,比如使用PinnerService的配置,或者选择正确的加密方式。 需要确保回答结构清晰,分点说明,先问题背景,再具体原因,最后解决方案。避免使用过多术语,但保持专业性。同时,用户可能希望得到实践建议,比如如何监控页面缓存,如何测试加密性能等。 可能还需要补充一些例子,比如在Android系统中,PinnerService锁定的文件如果被换出,切换应用时的卡顿现象。或者加密过程中,CPU负载过高导致渲染线程被阻塞的情况。 最后,确保回答覆盖用户提到的所有要点:页面缓存、PinnerService、加密类型的影响,以及建议措施。检查是否有遗漏,比如用户提到的内嵌加密与其他加密方式的对比,以及SOC供应商的建议,都要涵盖到。</think>### **I/O 问题与系统卡顿解析** --- #### **1. 问题背景:I/O 操作如何引发卡顿?** I/O(输入/输出)操作是系统性能的关键瓶颈之一,尤其在实时性要求高的场景(如界面渲染)中,可能导致明显的**卡顿(Jank)**或**抖动(Jitter)**。核心问题如下: - **页面缓存未命中(Page Cache Miss)**: - 当线程访问内存映射文件时,若目标页面不在内存的**页面缓存(Page Cache)**中,会触发**缺页异常(Page Fault)**。 - 系统需从磁盘(或闪存)读取数据到内存,此过程**阻塞线程**(通常耗时 10 毫秒以上)。 - 若此阻塞发生在界面渲染的**关键路径**(如 UI 线程或渲染线程),将直接导致用户感知的卡顿。 **典型场景**: - 应用频繁读写未预加载的文件(如配置文件、资源文件)。 - 系统服务(如 `system_server`)在后台执行高优先级 I/O 任务时抢占资源。 --- #### **2. I/O 卡顿的常见原因与优化方向** ##### **(1) 页面缓存管理:PinnerService 的作用** - **PinnerServiceAndroid 7.0+)**: - **功能**:通过 `mlock` 系统调用锁定指定文件在内存中,**禁止页面缓存被回收**。 - **目的**:避免关键文件被换出内存后重新加载(如系统核心文件),减少缺页异常导致的延迟。 - **锁定文件示例**(Pixel/Nexus 6P): ```plaintext /system/framework/arm64/boot-framework.oat /system/framework/oat/arm64/services.odex /system/framework/arm64/boot.oat /system/framework/arm64/boot-core-libart.oat ``` - **效果**:这些文件被系统进程和多数应用频繁访问,锁定后可显著减少切换应用时的卡顿。 **潜在风险**: - 过度锁定会挤占其他进程的内存资源,需权衡锁定范围与系统整体内存压力。 ##### **(2) 加密对 I/O 性能的影响** - **加密类型与性能对比**: | **加密方式** | **性能特点** | |--------------------|-----------------------------------------------------------------------------| | **基于 CPU 的加密** | 占用 CPU 资源,在关键路径中增加额外负载,加剧抖动(如 AES-NI 指令集优化不足时)。 | | **DMA 硬件加密** | 减轻 CPU 负担,但内核需管理 DMA 传输,仍可能引入延迟(如调度开销)。 | | **内嵌加密** | 直接集成在存储控制器中,零 CPU 开销,延迟最低(如 UFS 3.1 的硬件加密引擎)。 | **优化建议**: - **优先使用内嵌加密**:SOC 供应商应在硬件层面支持内嵌加密,避免加密操作干扰 CPU 关键任务(如渲染、音频处理)。 - **禁用低效加密方案**:若硬件不支持内嵌加密,需评估基于 CPU 或 DMA 加密对实时性任务的影响。 --- #### **3. 开发者实践建议** - **监控页面缓存命中率**: - 使用 `vmtouch` 或 `/proc/meminfo` 分析文件的内存驻留情况,识别高频缺页文件。 - 对关键文件(如启动阶段依赖的 OAT/ODEX)实施 `mlock`(需 Root 权限)。 - **优化加密策略**: - 测试不同加密方式下 I/O 延迟(如 `fio` 工具 + 加密模式参数)。 - 在 Android 设备树(Device Tree)中配置硬件加密引擎优先级。 - **控制后台 I/O 负载**: - 通过 `ionice` 调整非关键 I/O 任务的优先级(如降低日志写入的 I/O 权重)。 --- #### **4. 总结与延伸** - **核心矛盾**:内存资源有限性与实时性需求的平衡。 - **Android 特殊性**: - 系统核心文件锁定(PinnerService)是减少卡顿的有效实践。 - 硬件加密支持不足可能导致“加密放大”效应(加密延迟叠加 I/O 延迟)。 - **长期方向**: - **硬件协同**:推动 SOC 集成高效内嵌加密与智能缓存预加载机制。 - **调度优化**:结合 CFS(完全公平调度器)与 I/O 优先级,隔离关键路径的 I/O 资源竞争。 **注**:I/O 相关卡顿需从**内存管理**、**加密硬件**、**调度策略**多维度优化,尤其在低端设备或高负载场景中更为关键。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值