安卓端适配,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 名”），其实相对客观准确的响应时间是这个

基于视频流并不准确，TP 操作到事件分发被忽略，而且虚拟屏传画面并不等同外部摄像头，也是有本身的开销和传输影响带来的时间差，就看精度要求程度了，还是有偏差的。