同名多窗口数据在一起，你取下 dumpsys SurfaceFlinger --latency SurfaceView 就能看到，两组数据空格间隔，我的监控脚本中 WN 列会记录从 1 开始

一看名字就是猜到了，扫了下二维码还真是，你从乐视出来后也有几年几年没见了。

有 adb shell 就能执行，为什么还纠结集成到 app，命令行执行就可以

明确下安卓版本，android7.1 之后名字有改，如果有 surfaceview - 包名 #0 这种需要加双引号，因为有空格。

dumpsys SurfaceFlinger --latency 可以的，应该是窗口名没配置正确。看下https://testerhome.com/topics/20187
PC 端不分 rom，windows、os、ubuntu 都可以，shell 脚本是在安卓端执行的，adb 命令执行、

其实还有一点，个人认为技术的发展本身，如果是越来越增加学习成本反而是技术倒退。在技术应用层面，学习成本应该是越来越降低的。

单就技术发展本身，可以看看目前的发展过程，新技术实际是要使用者越来越方便。开源库的支持，框架方案的支持等等。最后落地到实际使用上，都是越来越简单，越来越少考虑容错、特殊处理、兼容性等问题。

技术发展本身是为了越来越高效、简单应用、并适应社会发展和产品发展的节奏。至于个人是不是要深入技术本身去了解，和应用技术工作的从业者并不相关。我相信应用层面的学习成本会越来越低。

我回复的本身抽出来讲是显得虚，可本身这是测试论坛。放到测试领域来讲，各测试细分行业也是很专的。

对于已经专在一个领域内的人来说，跨领域和行业是要有决心和投入的。放到自己工作领域内来讲，已有的工作划分就是不同的层面，都有了解和思考后，就会发现本质是一样的。

工作吗本身不是追求，只是个生活技能。动手执行能力，创新设计能力，积累的经验实践价值，乃至团队管理能力。自身能力和行业需求产生不匹配，还是要在心态和自身需求上去做平衡。当然这说的也是很虚，到了面对的时候还是看自己。

至少让心态上平和，积极思考如何解决问题。当然，这也是说给自己的。学习新技术并不是很多领域必须的，核心还是自身能解决的问题和工作需求的匹配度罢了。

有句话叫：“以不变应万变，万变不离其宗。“；除非革命性、跨时代的变革，自有应对之道。很多时候感觉跟不上了，其实是懒得思考了及精力被分散的没法集中了。

talkback 开了服务，把 accessibilityFlags 加上 flagRequestEnhancedWebAccessibility，uiautomator 就能 dump 到布局

TV 端搞 web 页面，运营需求？性能上不一定抗的住，当初我在乐视，rom 都是 native 做，运营走的是 classload 的插件更新方式。web 运营的话还是 RN 靠谱吧

diy 开个 talkback，uiautomator 就可以获取 web 内容了，之后按 app 测试。

有办法但需要自己设计实现，可用 Hierarchy 的数据，dumpsys activity top 中 View Hierarchy:部分，下面的 # 部分，代表着区别

native：
android.support.v7.widget.ViewStubCompat{ca26463 G.E..... ... 0,0-0,0 #7f090012 app:id/action_mode_bar_stub}
RN
com.facebook.react.views.view.ReactViewGroup{f158dd3 V.E..... ... 0,0-1079,552 #17e87}

FPS 只是数据，最终是要筛出问题提供给研发解决，这里的问题就是度量数据如何用？单从实现 fps 度量的方案上：
16 年我设计了 (https://testerhome.com/topics/4775)
今年又设计了 (https://testerhome.com/topics/21045)
可实际问题上是用它们如何去解决问题，能解决什么问题？

1）要将需要研发解决的问题聚焦在什么程度线上？这就需要了解一般用户的体验需求
a、人眼有 100ms 延迟，一些人经过训练或长期适应高帧率场景会有卡顿敏感度提升
b、竞速类游戏有限制 30 帧的做法，核心是人眼对变化感知明显，所以有些场景控制帧率稳定比提高帧率有效果
c、视频及体验是从 24 帧电影录制及网络流视频 25 帧视频来的
d、20 帧体验，作为一般帧率影响体验的游戏，20 帧就是个底线了，就像 ui 上的 gif 动画一般是 20 帧播放，至少这是被人接受的

2）要和配合优化的研发达成一致的优化目标，要不实际会浪费在优化意义的争论上

3）说说我的经验中，用我自己的方案解决了哪些实际问题
a、手机 rom 游戏效果优化，目标：让游戏帧率稳定，通过策略调整看帧率波动。实际优化是温升限频策略、续航、游戏性能间找平衡点，带着目标做事才能有的放矢。
b、TV 项目 costdown，低端芯片 mstar 648 1.5G 内存项目，我给的目标，内存要给前台 app 提供至少 500M 可用内存，最终通过 bsp、rom、系统 app 各层面的努力，配合后台查杀策略提供了 800M 左右可用内存；而帧率上通过单帧绘制 jank 比例发现 SurfaceFlinger 绘制性能有问题，结果通过研发优化思路探索，打开 Gop 的 overlap 实现减少一次 io 复制，使 SurfaceFlinger 绘制性能明显改善。
c、通过 16 年的方案分场景检查静止画面下，SurfaceFlinger 的无实际意义绘制，控制了重复绘制图层、不关闭未在显示中的 gif 动画绘制两大类不合理性能开销的问题
d、基于流畅度评价，70 分以上每 10 分跨度都可以感受到体验区别，从而把桌面插件上线标准控制在 70 分以上，目标 80 分以上的标准，有效把控了插件上线的流畅度体验。

基于这些应该能理解吧，不在于如何把数据拿到，最核心的是如何用。我扩展的抓取方式只是为了提供拿到数据的手段。

Android 上我还真没遇到取不到性能数据的时候，到目前 9.0,。信息获取思路都是通的，只是数据源信息需要了解哪些产生变化，再怎么控制权限，adb shell 权限总有吧。
我开源的（https://github.com/sandmanli/monitor-for-android）

无非就是要测试，要测试先搞清测试目的，要解决的问题。做测试开发非得局限在编程语言，测试框架上？
1、移动端也是跑在 linx 之上，至少 shell 是有的，移植编译的 arm 工具是有的
2、跑个 app，ios swift 和 android 的 kotlin 是有的，但真需要用 app 的开发方式测 app？
3、移动端和 PC 端配合完成测试场景，PC 端就十分开放了，就看用什么编程语言快速解决问题

再来看看个人的职位任务
1、测试执行？
设计测试 case 能力是基础吧；
复用测试经验排 case 优先级，优先发现严重问题是经验价值吧；
掌握移动端相关技术知识点、项目需求设计细节是玩转测试的基础吧；
基于测试工具和 UI 测试框架提高执行效率都快发展成必备能力了，要掌握吧
2、负责测试专项？
专项基础把控范围，测试方式，把控标准要有了解吧；
如需外部测试设备，要掌握外部设备使用，串口调试控制吧；
3、执行 team 管理？
组织团队，招聘，工作安排，项目节奏和测试计划的协调，项目团队间沟通等工作内容增加，要有自己的掌控团队的风格、沟通、汇报、人员和计划管理能力吧
4、测试开发？工具方向还是支持业务需求？
工具方向：要有工具设计思路吧，要积累方案思路让工具真正能用起来吧，要持续支持迭代维护吧
支持业务：要按需求建立框架，按维护策略持续输出支持吧，要做 CI/CD?

多些反问，自然而然就知道需要什么，解决问题的有效思路积累下来是资本。

真是招执行的人员，考虑更多是人力成本和基础素质，毕竟执行的事教下都能干起来，做事区别就在积极度、项目中的问题沟通。

理解原理，用什么无所谓。面试时讲原理，讲测试方案，经验案例。只关注执行是不够的，要体现的是经验的价值，一直执行下去就会被 “后浪拍在沙滩上”。

此方案确实可以把一类特殊场景绘制部分数据分出来，这里说的场景是这样的：
1、背景有个动效始终循环绘制，哪怕被其他页面覆盖，可以用开发者模式的 GPU 呈现模式分析查看，画面静止但有数据绘制；
2、实际显示页面间隔绘制内容
3、此方案就可以取到绘制的内容，而非不显示的 buffer 绘制

用基于 SurfaceFlinger --latency 的方案就做不到，因为抓取了未显示部分的 buffer 绘制，影响了实际显示内容帧率的评估。

今天看到一份监控结果中 SurfaceTexture 很多名字挂了数字，如"SurfaceTexture-0-1980-2"，统一做了下归类处理，全部重名名为 SurfaceTexture。对应脚本有更新。

#!/system/bin/sh

# $1 存储目录
# $2 文件数量
# $3 起始文件名数量
DD(){
echo "pid=$$"
local i=0
while true;do
    local name=$((i+$3))
    dd if=/dev/zero of=$1/$name.dat bs=4096 count=1 1>/dev/null 2>&1
    local i=$((i+1))
    if [ $i -eq $2 ];then
        break
    fi
done
echo $$ finish
}

folder=$3
if [ ! -d $folder ];then
    mkdir -p $folder
fi
#开多进程

#$1 进程数量
#$2 单进程文件数
#$3 存储位置
n=0
while true;do
    DD $folder $2 $(((n-1)*$2)) &
    n=$((n+1))
    echo "进程: $n"
    if [ $n -eq $1 ];then
        break
    fi
done
wait

存 sh 文件（unix 文本格式，utf8）push 到手机执行，参数参考注释

shell 的 dd 文件进行创建就够了，配置随机的生成大小，无非写个创建文件函数，传参控制。同时做多进程生成。

测试需求的解决思路和方案更重要，测试工具只是服务于测试需求的，展示思路构思和实际落地过程的案例过程，方案迭代的优化思路。我是认为测试工具本身不重要。
我当年从手工转自动化就是给自己定位设计决绝方案，后来换工作一方面是同事关系另一方面就是靠测试方案的实际案例说明，解决思路介绍。

我的感受是：风向变了，面向业务快节奏推进，灰度发布快速迭代收敛问题。
这个风向下：上线把控底线要求是什么？自动化能支持的能力和效率是什么程度？问题自动上报到快速迭代推送更新的流程和效率要求是什么？
面临这么多问题，有些人是准备好 再交替，而互联网思维是带着试错想法做事，先干了，出问题解决。微软裁员应该是后者，过程中的问题逐步解决，bug 后果得用户体验买单。

主进程和子进程的概念，jenkins 的环境变量是主进程的，构建的脚本是执行的子进程变量。构建后脚本才开始设置参数值，可 job 已经创建完了，怎么可能用后设置的变量。

安全性用途，比如闸机设备，注意下验证生物识别。设备商也是用合作商的算法 sdk，就那几家。更重要的是不同环境光线下的成像质量，成像有问题，算法修正也白搭。

验收设备还是得关注使用需求场景实测、硬件成像质量、不同光线对成像质量的影响、安全性一定得多测测异常场景，比如验证生物识别的有效性。