QtScrcpy 更方便： https://github.com/barry-ran/QtScrcpy

都是先砍业务吧，砍了业务，对应团队协调位置，有位置安排的留下；控制成本，会先处理外包，实习生，各种协调项目的 pm；再来就是拉名单排名，什么 leader 给的排名，加班排名等等，当然也会掺杂，同事关系，都是有名额数量要求的，就看各 leader 报不报，有想要裁员补偿主动要求加入名单的，也有想办法换部门留下的；

纯管理和技术管理确实不同，纯管理再加 “媚上压下” 组员就 “苦逼”；其实对于干活的人来说，应付都有手段，甚至可给领导 “挖坑” 的，无非压工时，摸鱼还是能拖进度的；还是看自身，想留就拖着等领导掉几次坑，最好被他同级以上合作同事反感；不愁换工作，其实也可以考虑走，不过频繁换工作对职业生涯不好。

手底下人干活 “拖沓” 会影响工作和人效的投入产出，测试效率拉胯需求上线，更有 “话语权” 的人就会急，压力就在你领导头上了，要是压提效，就怼回去让他想办法。

python 的 uiautomator 是有的，它的依赖 app 会创建 AccessabilityService 实例获取 ui 布局，你要不想从这改的话，就自己写个无功能只是开 flag 的 talkback app，启动服务就好

技术讨论氛围差了，伸手党多，都是 copy 拿来用的，真技术，内部提个专利拿钱不好？提了专利更不方便分享了

accessibilityservice.xml 中

android:accessibilityFlags="flagDefault|flagRetrieveInteractiveWindows|flagIncludeNotImportantViews|flagReportViewIds|flagRequestTouchExplorationMode|flagRequestEnhancedWebAccessibility|flagRequestFilterKeyEvents"

android 的 AccessabilityService 是要开 webview 相关的 flag 的，默认没开是取不到的，记得当年调 RN 的 app 时，也是要把对应 flag 加上，才能取到。简单的做法是自己写个 talkback 把 flag 加上，运行 talkback 服务就能取了；一个地方加上就可以，影响所有调用 AccessabilityService 的地方

adb shell dumpsys SurfaceFlinger --latency layer 名

layer 名是动态获取的，要打开 app 窗口再查， dumpsys SurfaceFlinger |grep "Output Layer"；

这个是要写个脚本动态获取计算的，获取的是历史 127 帧数据；dumpsys SurfaceFlinger --latency-clear 是清空 buffer

讨论项目测试，顺序思路不太对：预计什么时间上线（测试有多少时间）-》有限时间内能做什么（项目经验沉淀下来的测试策略，自动化专项）-》风险覆盖不住？（是否可以延期上线，增加必要的测试时间）-》漏测标准怎么算？（带风险上线，要有公共认知，减少找后账风险）

特点就是可以脱机省设备，拔了数据线一样能跑，awk 预处理格式化数据流通过 adb 命令行提取后做实时图形化交互展示之类的，也可以做成设备端脚本 + 上位机效果方案；手机硬件堆料这么多，占部分用于测试很合理吧。

shell + busybox + 定制依赖 app + shell 下命令行安卓自带/后 push 赋权命令，能干很多事，文本预处理提取、统计、计算用 awk，数据表存储用 csv 或 tab 分割的 xls 格式，PC 端后处理用 pandas + highcharts/echarts 出数据报告。

像性能数据采集分析；log 指定 tag 实时提取分析，异常实时 PC 端预警；设备端 shell 和 app 交互，脱机执行自动化 case 压测，半自动交互测试等

很早写的了，安卓都过了这么多版本，看这个https://testerhome.com/topics/20187
本来是早期，用设备端 shell 脚本 + 数据存 csv + PC 端后处理报告的方式做了很多事；当然现在也在用此方式搞了些脱机方案，或预处理数据传给 PC 再加工的方案，只是一些方案提了专利，不方便分享

to B 可不是，测试做项目，卖测试设备，测试方案，测试服务，是赚钱的。

其实要搞好汇报统计，每轮测试的人效投入统计，针对提高人效的优化，体现在节省人力层面，再有就是数据报告的包装，和自动化收集统计测试结果，先搞好汇报，优化方向一切向 “钱” 看，节省人效，同人效增加更多测试项目，覆盖更多，要能拿出手给甲方汇报用

to B，主要是满足需求，还要有 “亮点”，而且所谓出彩的地方，不一定是实用，实际产生高测试价值的，完全是要包装渲染的，牵扯到甲乙双方，各自目的不同，还真不是为了提高测试效率，提高测试技术水平，更多的是如何在提高报价的同时，让甲方看的舒服，可以接受。实话说不就这点事吗

领导要的"突破"是汇报用的吧，太 “平” 了，汇报没内容，要啥 “绩效”，先得搞好汇报亮点

安卓端适配,8155 的 android 11，车机分 android 和 qnx，监控方案不太一样，按需重新搞了

搜杜比和 dts 的测试 demo，做杜比或 dts 认证的话还有专门的测试文件，都是能找到的：
比如，随便搜下找到：
https://www.zhihu.com/tardis/zm/art/424772851?source_id=1003
https://zhuanlan.zhihu.com/p/297008675

这只能说明招聘的公司：不着急且有的挑，赶上急招和长时间无应聘的情况会相反

测试左移是测试流程中，测试介入向左移，感觉标题把左移概念扩大了

测试卖工具得走供应商路子，赚的是项目的钱，不过得让工具有 “价值”，能解决痛点，还得有软硬件 “包装”

感觉更像是智慧版的 monkey 方向，立个专项，给云测配个执行端的 “大脑”，不过没给 bug 判定，去重提交，版本线的 bug 追踪配 “大脑”，流程上的决策跟踪，离托管还早

其实 app 的响应时间相应 case，大多结果控制在秒级，顶多关注到 100ms 级别的优化，一般刨除和收益相关的广告之类的影响，底线之内，容忍度很高；
流畅度≠帧率；基础帧率满足后，帧率的稳定性决定流畅度，其实流畅度的优化是拉高均值，和拉平波动，卡顿优化主要在这，相关 bug 也出现在这里，平均帧率低或帧率波动，用户明显感知

其实性能优化往往是在功能需求实现的后期，大头是降低 cpu 和内存占用，响应时间和流畅度是看看是否超内部标准（如果有），再有就是 “民不举官不究”，先有抱怨再有专项优化，这是在项目上往往会面临的 “倒挂” 状态

再有真实的性能测试其实服务于提出问题或客观评估，手机做 rom 的客观评估大多用机械臂结果，毕竟卷的厉害，出个客观结果也是用于发版评审或竞品对比；做 app 的其实对响应时间的容忍度大多很高，有个可接受内部底线，控制在底线内即可；往往流畅度、卡顿的抱怨和优化需求反而更高，相对于响应时间，帧率和流畅度评估往往更容易出 bug 要求优化；再有就是 rom 层面平衡资源占用，要求瘦身，更多是用到负载类数据；综上，单搞响应时间工具被应用的场景，频率都不算很高，产生有意义的 bug 的产出完全看各项目的容忍度

并不是，真实硬件的性能测试是从触屏开始，模拟触控操作是事件注入，从操控上就产生时间差，scrcpy 传输屏幕开销也有时间差，这个方案本身就不能等同真机性能测试，所以首先对结果的阐述要说明这点区别；所以基于真机的机械臂 + 触控 + 摄像头的外部硬件性能测试的客观性才有它的市场

对于忽略以上因素和脚本本身资源开销影响，这个方案只是内部取数据评估也有一定意义，尺子相同，可以讨论问题；相对于客观的机械臂，相对准确的响应时间：起始可以从 getevent -lt 拿到，结束可以从目标 Output Layer 的 vsync 拿到（dumpsys SurfaceFlinger --latency “Output Layer 名”），其实相对客观准确的响应时间是这个