主页

前言

通过上一篇文章我们了解了 PKMS 是如何通过 Settings.readLPw 解析备份文件 package.xml 的

读取了上一次备份的信息之后, 下面便会调用 PackageManagerService.scanDirTracedLI 扫描指定目录下的应用程序, 我们就探讨一下它是如何进行扫描处理的

前言

在 SystemService 进程启动时, 会将 PackageManagerService 启动起来, 这是一个应用资源管理的服务

public class PackageManagerService {

    public static PackageManagerService main(Context context, Installer installer,
            boolean factoryTest, boolean onlyCore) {
        ......
        // 创建了 PackageManagerService 对象, 并且将它添加到 ServiceManager, 用于对外界提供功能支持
        PackageManagerService m = new PackageManagerService(context, installer,
                factoryTest, onlyCore);
        ......
        ServiceManager.addService("package", m);
        // 返回了一个 PackageManagerService 对象
        return m;
    }
    
}

因此我们从 PackageManagerService 的构造函数来探查 PKMS 的启动流程

前言

在前面的分析中, 我们了解了 SurfaceFlinger 的启动流程, 得知 SurfaceFlinger 对热插拔事件的处理

• onHotplugReceived
• onRefreshReceived
• onVsyncReceived

这里我们主要分析一下对 onVsyncReceived 函数对垂直同步信号 Vsync(屏幕刷新一次之后便会产生一个 Vsync 信号) 的处理

前言

前言

在前面的分析中, 我们了解了 SurfaceFlinger 的启动流程, 得知 SurfaceFlinger 实现了硬件驱动的回调 ComposerCallback

• onHotplugReceived
• onRefreshReceived
• onVsyncReceived

当 IComposer 接收到硬件设备发送的事件时, 会直接回调到 SurfaceFlinger 中统一处理, 这里我们主要分析 Hotplug 热插拔事件

前言

在之前学习 Android 图形渲染的时候, 我们看到了最终所有的渲染数据都会通过 Surface 推送给 SurfaceFlinger, 然后在 SurfaceFlinger 进程中真正的进行渲染

这里我们学习一下 SurfaceFlinger 进程的启动流程

前言

前面一篇文章, 我们深入学习了如何选取预览尺寸和旋转角度来获取合适的预览帧, 这篇就要结合上 OpenGL ES 的知识, 对相机输出的数据进行渲染操作了, 主要流程如下

• 获取预览数据
• 渲染方式的选取
• 渲染环境的搭建
• 渲染器的实现

接下来我们从第一部分开始分析, 看看如何获取预览数据

前言

经过 OpenGL ES 的系统学习, 这里通过 Camera 开发, 来对学习的成果进行一次验收

Camera 在音视频的世界中, 就像我们的眼睛一样, 是负责图像采集的入口, 要想实现一款高可用的 Camera, 我认为需要关注以下几个方面

• 相机的预览
• 相机的拍摄
• 相机的录制

OpenGL ES 主要用于图像的渲染, 因此这里主要聚焦于相机的预览, 想要让相机的数据呈现到我们屏幕上, 主要有如下几个步骤

• 相机预览帧尺寸的选取
• 相机预览帧旋转角度的设定
• 使用 OpenGL ES 渲染数据

可以看到每一步想要做好都是挺有挑战性的, 本篇主要分析 相机预览帧尺寸的选取 和 相机预览帧旋转角度的设定 这两个问题

前言

APP 的性能优化之路是永无止境的, 这里学习一个腾讯开源用于提升本地存储效率的轻量级存储框架 MMKV

目前项目中在轻量级存储上使用的是 SharedPreferences, 虽然 SP 兼容性极好, 但 SP 的低性能一直被诟病, 线上也出现了一些因为 SP 导致的 ANR

网上有很多针对 SP 的优化方案, 这里笔者使用的是通过 Hook SP 在 Application 中的创建, 将其替换成自定义的 SP 的方式来增强性能, 但 SDK 28 以后禁止反射 QueuedWork.getHandler 接口, 这个方式就失效了

因此需要一种替代的轻量级存储方案, MMKV 便是这样的一个框架

一. 集成与测试

以下介绍简单的使用方式, 更多详情请查看 Wiki