感觉是 C++ 远古时代叫 cfront，compile 成 C 代码，来支持语法糖的 class。.class 文件可以比较完美地反编译成 Java 代码（学术界），除非 kotlin compiler 做了很多诡异的事情。但是因为要 bytecode 层面兼容 Java，所以必然 Kotlin 基本产生的就是标准 java 代码，一个 class 就是一个标准 class 一个 function 就是一个 function。scala 是被 spark 翻牌子翻中的。kotlin 有了所有语言的影子，那个 it 是 Groovy 的东西（又一个恶心的语言）。

我刚才看了 github，项目量少，而且 star 少，说明玩弄的人少，观望的也不多

恩，我们在考虑，如果 Kotlin 复杂度降低到 python 行数，准备拿 kotlin 当脚本语言，python 2.7, 3.5 差异太恶心了。以前写过把 Java 当脚本语言的，但是 Java 写起来还是太罗嗦后来就没怎么弄。

开发框架好多，我们都一直在评估，ReactNative 之前也弄过，应该也可以

恩，我们 Appetizer 其实就是抓 APP 的 crash 和 ANR，就怕一些 DalvikVM 层次的闪退。多谢分享

既然是兼容性测试有考虑过国内生态设备的差异么，比如小米系列手机要弹框手工确认什么的，OPPO 第一次运行有 GPS 权限的也会弹框要手工，很多都不是一把 adb 就能搞定的怎么办

加群来讨论下: 467889502

我们是 mac/linux，nohup emulator xxxx &，启动就会转后台
内存和 cpu 充足的情况下，一下 4-8 台没问题
windows 下命令行我不是很熟，最简单开多个 cmd 一个个开，如果有 cygwin/msys/github commands 可以就 用上面 linux 的方法

@snake 比自带好很多，模拟的面也很广，不过好像最近开始全面收费了，除了那个 fun zone 好像可以其他不行，以前我们也用过

1. 真机少的情况下，模拟器随起随用，全版本覆盖，喝口咖啡的时间就搞定，不用等兼容性报告，开发自己也可以用
2. 真机可以用来开发调试，插上也能增加兼容性机型，即插即用
3. 如果公司设备多，用云管理，那么可以固定一组用来测兼容，总而言之模拟器比较灵活（8.0 来了），真机比较真（废话），搭配使用
4. 是有模拟器打不开的，但是我们遇到的也不是非常多，百度 sdk 我们碰到过几个
5. 对于机型多或者 APP 多比较有用，何乐而不为

看来我短期任务是让你换掉 fiddle

am 这类，需要 adb 权限（也就是 adb shell 默认的用户）。app 默认通过 getRuntime().exec() 什么打开的，是 app 的 uid 的 shell，权限比较低

以前（挺以前的事情了），可以直接在 shell 里面调用 dalvikvm 然后传给他 bootclasspath (framework.jar 那群人) 以及一个 apk/zip/jar（其实都一样）里面有一个编译好的 dex 文件，然后传给它一个包名，main 函数就启动了，dalvikvm 这个 exe 文件，和 jdk 标准的 java 是一样的 class path, main-class-name。命令行的区别在于，这个进程是一个 linux 进程 userid 和权限是 adb，没有/data path，属于杀鸡取卵。。。。另外一点，adb 权限比 app 权限要高，可以用来做坏事

这个 AppCrawler 的功能, 可以参考这里https://testerhome.com/topics/node83

之后版本会接入其他 sdk 的数据，敬请期待

搞起

前面插桩等流程都成功了吗？加群讨论吧

试试最新的 1.1.1 版？后端我们也在持续更新，还有问题的话可以加群详细讨论

这块兼容性适配需要花挺多时间，在慢慢加

@object 重启下客户端，这个 bug 已经修复，1.1.1 发布就好了

感谢专业的评价

Appetizer 1.1.0 发布了，新增了自动质量监控功能，详情请见 https://testerhome.com/topics/8162，欢迎大家试用并反馈建议

重启下客户端用普通账号试试？

github 授权很慢，我们阿里云服务器连 Github 灰常慢，会卡一会，还有问题的话加群发个截图

Github 登录后第一次插桩会有问题，重启一下客户端插桩就可以了，下个版本修复