github 提个 issue 然后把报错带上吧，这样也看不出什么

https://github.com/williamfzc/stagesepx#%E5%BD%BB%E5%BA%95%E8%A7%A3%E8%80%A6--%E5%8F%AF%E7%BC%96%E7%A8%8B

https://docs.docker.com/engine/reference/builder/#user

说下你的目的

666，不过你们考虑把 RN 跟其他客户端整合成一套平台吗，像阿里今年那个实时染色一样？

建议从 PATH 入手让所有软件都只能感知到一个 adb，多 adb 并存都是邪教，adbd 是独占的。
https://stackoverflow.com/a/27256599/10641498

现在连反向的反馈都没有了，没有观念冲突、没有缺陷暴露，导致了我们也很难看到不足并做改进。
不过现实是大多数人是为了赚钱才留在这个圈子，也不可能强求每个人都带着兴趣与使命感工作，我倒是看得比较开，只是觉得有点可惜。

用 ffmpeg 处理过？
没有的话视频私发下我吧

用 pip list package 看一下 stagesepx 与 opencv 分别是什么版本

埋点跟这个完全没冲突啊

很多同学问到了落地细节相关的事项，实际上我们也做了一套将它与各类终端绑定到一起的方案，能够让他直接与诸如 uiautomator2 之类的框架一同运作，快速落地。

可以看看这个项目：https://github.com/williamfzc/sepmachine
与这个例子：https://github.com/williamfzc/sepmachine/blob/master/example/android/custom.py

对于文档的话实在是没时间细写，有空会单独发文介绍。这个例子在 100 行内，包含了对微信整个启动过程的全自动测试方法，可以试跑看看。几个前提先提醒免得直接跳坑：

• 需要 ffmpeg 安装好并配置在 $PATH 下
• 需要 scrcpy 安装好并配置在 $PATH 下
• 需要 pip 装一下 uiautomator2，例子里的自动化由他驱动，论坛搜一下好多帖子

既然要跟终端绑定，势必会带来很多环境、稳定性之类的麻烦事情，这也是我一直比较懒得做这个事情的原因。
不过比起这个，我还是希望这个项目能有一种比较漂亮的方式着陆吧。这个仓库应该可以帮到在落地上比较迷茫的同学，毕竟基于这个，需要写的代码量真的非常少了。
有问题与建议欢迎继续留言，或者到 sepmachine 的 issue 区 ：）

• 图片文件夹跑完手动的就会生成，新建同名文件基本是骗自己；
• 你运行了什么脚本？如果是 start_without_report.py ，那本来就不会生成报告；
• 需要报告先参考手动版本改一下；

没，昨天才有人跑通过，发一下报错？

我记得早前跟你沟通那会儿，我还没有想到得用 ffmpeg 去处理软件录制之后的视频，所以那个时候我也误以为软件录制行不通。现在来说，软件录制 +ffmpeg 已经成为了推荐方式，准确度在实验室效果也很不错，可以试试；

不过对于一些特殊场景，例如开关机这种，似乎也没办法用软件录制，确实是比较麻烦。硬件方向我了解到比较多的还是会用外置相机，但是分析这一块还是可以用这套分析工具的；

小米的同学似乎最近也在调研这个方案，不过进展跟结论我就不太清楚了，有相关同学也可以出来冒个泡；

比较怀疑是 numpy 版本问题：

• 你先pip list看看 numpy 版本多少，回复我一下，可能有些依赖没处理好；
• pip install --upgrade numpy 单独升级一下，再试试；

object
 +-- Finder (deprecated)
 |    +-- MetaPathFinder
 |    +-- PathEntryFinder
 +-- Loader
      +-- ResourceLoader --------+
      +-- InspectLoader          |
           +-- ExecutionLoader --+
                                 +-- FileLoader
                                 +-- SourceLoader

谢谢，埋点也是必备思路，我们正式落地时是结合着来的。

可以的，不知道你指哪一个？
https://github.com/williamfzc/work_with_stagesepx

入门机器学习非常推荐微软的课程
https://github.com/microsoft/ai-edu

嗯嗯，看起来是已经落地挺完全的哈。不过这种做法在最初的时候我们就试过了，在 MTSC 上也已经拿出来分析过，弊端也是比较多的。就拿这篇文章里的内容来说的话：

• 对于抖音这类高度动态化的 app 基本是无从下手
• 即时分析这条路会导致高度的延迟，如你文章说到的 200-300ms，对于现代 app 来说是完全不可接受的误差

欢迎出来遛遛

可以，你留我加你吧，我没法仅你可见

游戏跟视频这类完全无迹可寻的动态确实有待改进，应用类型的动态诸如跑马灯、loading 动画这种没有问题。

https://testerhome.com/topics/19978

很不错的样子