PeaceMaker

简介在Android性能监控和优化领域，一个会影响App性能表现的因素与Handler Message Looper机制有关。当Looper里面的Message处理不及时、或数量太多占用过多处理时间时，可能会出现卡顿感，并且不容易定位到卡顿的Message和慢方法。 Android本身提供了LooperStats机制来统计和监测Message的处理，并且可以通过LooperStatsService来统计和记录，方便调试和分析。 LooperStatsService详解由SystemServer创建、Settings数据库变更触发启动LooperStatsService是一个系统服务，由SystemServer在开机阶段启动。按照系统服务的接口要求，它是通过LooperStatsService.Lifecycle这个类被启动的。 启动流程主要是初始化LooperStats、LooperStatsService和SettingsObserver。 SettingsObserver在Settings数据库的值发生变化时回调，回调方法中根据特定格式来解析数据库的内容，根据解析的内容确定是否开始 ...

简介LUT是“Look-Up-Table”——查找表的缩写。它是数据的一种容器，类似字典、map等，将索引与值对应起来的一种描述方式。 3D LUT，顾名思义，描述索引与值之间的对应方式是三维的，可以被理解为三个维度的索引-值对应方式的结合，通过三个维度的索引，可以查找到一个值。与一本普通的字典一样，输入固定的值作为索引，可以查到固定的结果作为输出。 3D LUT被广泛地在电影工业和显示工业广泛使用，用于在不同的显示器、不同的颜色空间之间做色彩校正、显示调节、效果和优化等方面。也就是说，3D LUT实际上是颜色的转换，是RGB的映射。借助3D LUT的颜色映射，将颜色进行调节，达成3D LUT即定的显示效果。 1D LUT只能控制gamma值、RGB平衡（灰阶）和白场（white point），而3D LUT能以全立体色彩空间的控制方式影响色相、饱和度、亮度等。简单描述来说3D LUT可以影响到颜色，而1D LUT只能影响亮度值。 由于颜色空间、gamma、色域等会影响颜色的呈现效果，因此想要让LUT有较好的效果，一般要求输入的颜色和输出的颜色在同一个显示环境下（颜色空间、色域、伽马一 ...

背景 观测 1. trace体现UI绘制操作严重耗时 2. 排查measure和layout慢的原因：可疑的多次binder 3. binder：在哪、谁为、为何频繁调用 4. binder：频繁调用的具体定位 结论 方案 参考 背景某轮测试发现，我们的设备运行一个第三方的App时，卡顿感非常明显： 界面加载很慢，菊花转半天 滑屏极度不跟手，目测观感帧率低于15 对比机（竞品）也会稍微一点卡，但是好很多，基本不会有很大感觉的卡顿 可以初步判定我们的设备存在性能问题，亟需优化，拉平到竞品水准。 最后发现，这个问题实际上是应用自身奇怪的实现（getResources()的重载），加上Binder过度调用（沉重的Binder耗时）导致的。 本文做记录和分享。 其中对比机配置、Android版本均与本机不同，不做变量参考。 观测由于这个可爱的App是第三方的App（应用市场下载的），我们没有源码，只能从系统端去干涉。先抓一份trace。 1. trace体现UI绘制操作严重耗时trace一抓一看，显然App主线程已经陷入困境。可以看到： CPU使用率并不高 主线程几乎完全在执行T ...

9:20 AMWednesday, December 28, 2022 (GMT+8)Time in Guangzhou, Guangdong Province, China [toc] 背景通常在Android中使用logcat输出查阅日志，但有时日志很长，可能会被截断，显示不完整。 注意，这里指的是单条日志太长了被截断了，不是指日志太多了被冲掉了 本文研究日志被截断的原因，并给出修改方法。 首先日志被截断的原因有如下几种，其中第一种是首要原因： 单条日志长度上限，日志如果太长，触及上限则会被截断 日志如果涉及序列化、binder传输，则受到binder传输上限的限制 底层（Linux、log设备）限制、系统调用限制 注意，单条日志长度上限是指一次打印的日志的长度，不是指设置-开发者选项-日志缓冲区大小。 查看日志缓冲区大小、单条日志大小12345#:/ logcat -gmain: ring buffer is 16 MiB (15 MiB consumed), max entry is 5120 B, max payload is 4068 Bsystem: ring ...

3:49 pmThursday, 20 October 2022 (HKT)Time in Hong Kong 三方应用UI自动化的价值 业务痛点 三方应用UI自动化的技术难题和隐患 App UI自动化测试的一般实践 App UI自动化的基础技术 三方App UI自动化的侧重 三方应用UI自动化的选型 1. 自动遍历 2. 图像技术 小结 参考工具 参考 三方应用UI自动化的价值从设备厂商的视角来看，Android App的UI实现方式错综复杂，采用的UI技术栈层出不穷，以及需要进行显示适配的新型场景（如平行世界、窗口模式、画中画、桌面模式和折叠屏）井喷式涌现。 大部分的三方应用测试通常仅关注UI功能、冒烟测试，测试流程枯燥、重复，且业界有成熟的UI自动化基础，因此通常在三方应用兼容性测试中接入一定程度的自动化测试。 在这个大背景下，相对于一方/二方应用而言，数量庞大、纯黑盒、架构复杂多样的三方应用，主要在以下几个场景中存在几个痛点。 业务痛点1. 技术、市场因素等构成的现状，决定了厂商对三方应用的兼容性的工作量是不自主的、单调增长的三方应用UI测试投入不 ...

10:59 amTuesday, 1 November 2022 (HKT)Time in Hong Kong 背景 目标 环境、工具 环境 工具 观测 1. Trace上看瓶颈是存储 1.1 检验fdatasync是否真的耗时 2. 数据库测试没有跑满IO极限 2.1 系统缓冲区对dd性能的影响 2.2 伸缩IO资源发现对数据库测试成绩影响有限 3. CPU资源制约数据库跑分 绑定到不同核心得出的跑分成绩: 大小核性能差异 定频带来跑分提升: 强制提高CPU频率 结论 参考 背景我们的设备经过性能测试，在IO测试阶段、数据库操作部分的跑分显著与对比机拉开差距，且跑分结果怪异：常规的串行读写、随机读写与对比机成绩差距细微，但是数据库操作居然差距巨大。 目标从表中可以看到，两者常规IO成绩接近，但是数据库事务差距一倍以上。我们需要分析跑分差异的原因，并定位设备和系统的性能瓶颈。 分析跑分差异根因；为什么数据库读写会意外地落差巨大？ 定位性能瓶颈；性能瓶颈是来自存储吗？ 环境、工具环境 设备 软件环境 硬件环境 跑分手法 MT8183 And ...

9:51 amThursday, 3 November 2022 (HKT)Time in Hong Kong 获取 在线CPU PPM使能 CPU频率(proc) CPU频率(sys) CPU档位OPPidx(频点) CPU和高速缓存电压 CPU算力 支持的调频策略 正在使用的调频策略 调频驱动 当前启用的核心 当前固定的频率 设置 开关CPU核心个数 定频 绑核 相关源码 术语 调频策略 获取在线CPU12cat /sys/devices/system/cpu/online0-7 PPM使能 性能管理模块 12345cat /proc/ppm/enabledppm is enabledecho 0 > /proc/ppm/enabledppm is disabled CPU频率(proc)12cat /proc/cpufreq/MT_CPU_DVFS_L/cpufreq_freqcat /proc/cpufreq/MT_CPU_DVFS_LL/cpufreq_freq 12345cat /proc/cpufreq/MT_CPU_DVFS_L/cpufr ...

UNISOC_SPRD_PAC_UNPAC紫光展锐展讯SPRD刷机包pac文件解包提取img文件。 Extract Images from .pac file from Spreadtrum Unisoc SPRD. 前置条件 pac文件 *1 Perl环境 工具展锐官方自带一套分别用Python和Perl实现的将各img打包为pac文件的工具，也实现了对应的解包工具。其中，pac_tools/unpac_perl/unpac.pl是Perl实现的解包工具，能将pac文件中的各img提取出来。 下载：地址（Clone源码或下载Release包） 使用 请根据系统权限机制确保unpac.pl具有执行权限 第一个参数为需要提取的pac文件 第二个参数为提取产物的存储路径 1./pac_tools/unpac_perl/unpac.pl ROM/your_pac_file.pac pac_unpac_path/ 添加-S参数加快提取unpac.pl在提取之前会校验pac文件的完整性。它非常耗时，可以在命令的最后追加-S跳过CRC校验。 1./pac_tools/unpac_perl/u ...

背景当谈及上网体验时，总是会涉及网络性能优化的探索。 其中，对于提升网速这一块，最直接最有效的莫过于增加带宽、增加物理链路来实现更大更快的网络网络流量。通常在家庭场景、商业场景会向ISP订购更多的宽带服务，通过单线多拨、多线多拨机制实现「网速叠加」。 而对于办公场景等具有多层交换机、NAT内网的环境而言，网速优化的首要目标不是增加更多的链路，而是「避开内网网速限制」和「压榨内网带宽」，让内网终端能够最大化利用内网出口带宽。 本文讨论「多WAN口」实现内网带宽压榨，并亲测wan口数量带来的网速提升效果。 多线多拨与单线多拨在最舒服的理想状况下，路由器每一次拨号，便能从ISP获取一个 IP，运营商会分配对应的带宽，每个IP独立计算一个带宽大小。 将路由器的端口模拟成多个拨号端口（或者是，本来路由器就支持多端口拨号），多个端口分别拨号，成功连接的前提下，如果将网络通信分配到这些端口进行传输，那么实际上就实现了「网速叠加」。 注意是在最舒服的状况下能实现：运营商支持/套餐支持、猫支持、路由器支持、操作系统支持… 单线多拨：实际上就是实现了多拨，但是“每个拨”的出口都是同一个链路（ ...

2:52 pmMonday, 15 August 2022 (HKT)Time in Hong Kong 拉取步骤拉取depot_tools1git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git 1export PATH="$PATH:/path/to/depot_tools" 拉取Android Chromium源码1mkdir /chromium && cd /chromium 1fetch --nohooks --no-history android 1gclient sync 接下来继续之前，额外一个可选步骤：切换到指定版本（查阅“切换到指定版本”节） 123cd src./build/install-build-deps-android.shgclient runhooks 代码拉取完成。 (可选)查看当前版本12cd srccat chrome/VERSION (可选)切换到指定版本1234cd srcgit fetch ...