那我就不清楚了。
你试下去搜索 chromedriver ，看它不回应时从哪里能找到一些 log 信息？
或者直接用 chromedriver 来运行你的测试试试？

#13 楼 @sunrise selendroid 是基于 Instrumentation 的，所以获取到的元素列表会和 Appium 有所不同是正常的。

收藏了！

#3 楼 @anikikun 你上 stackoverflow 查一下？
我找到这个http://stackoverflow.com/questions/20961417/android-util-androidexception-instrumentation-failed

#1 楼 @anikikun 我擦，我怎么成姐姐了。。。我也是哥哥啊。。。
你重启一下手机试试？如果确实是由于已经有 selendroid 服务在跑，重启后应该就关掉了。

没实际做过，仅仅抛个砖。。。等待大神们解答

自动掉线、消息无法送达这有可能是弱网络或者是客户端内部数据包没发出。
如果是定位问题的话，可以在网络良好的环境下用抓包工具看看 app 的网络通讯是否正常，会不会出现应该发包的地方实际上没有发包。如果都有发包，那有可能是弱网络下 app 重试发包的次数太少，直接看源码看看重发次数是多少，然后配置弱网络（参考http://testerhome.com/topics/482），修改重发次数来看看效果如何。

#4 楼 @bueaty 能满足你的需要吗？

这标题太简洁了……建议改成更能表达帖子意思的标题。。。
返回键是可以模拟的，就是一个 KeyEvent ，adb 命令就能干这活。不过你需要先确定你一路按返回键能返回主界面。
你的这个功能其实相当于用例失败时自动执行的内容，单元测试框架的话用 tearDown 函数来做（tearDown 是无论用例执行情况如何都会执行的），如果不想每个用例都要加，那就在执行用例的那个语句加个 try catch ，捕捉找不到元素的异常或者点击异常，然后执行你那个一路返回的用例/脚本，再把异常改为用例失败的异常。

不过这么做就变得把用例的内容引入到执行框架了，你要考虑清楚你的框架是否需要保持通用性，不需要的话就加到框架里吧。

#10 楼 @sunrise find_element_by_name 不是匹配 value 的。你的 "北京" 是 value 的值。
参考：http://selendroid.io/native.html#name
而且你的 Log 里面的 xml 有点怪，有些节点名称我也没见过，如 NovaTextView，不知道是不是自定义控件。
不过用 xpath 应该能找到啊。你的 xpath 怎么写的？

从上面的 log 来看，你的元素有找到啊（服务器返回 200 ），只是 tap 那里有问题。可惜最重要的 tap 动作的 log 你没截到。。。

我的治懒方法：搞个 deadline（和别人有合作的事情），或者把自己懒的时间尽可能延长，懒到你觉得无聊为止（我属于同一件事干太长时间就会觉得无聊的人，就算打游戏我也打不了超过 4 个小时，目前只有研究技术/编程能让我连续 4 小时以上保持专注）。

#1 楼 @monkey 你们是真爱啊

#9 楼 @weamylady 我这里没出现过这个问题哦。
你也是 chromedriver 起来后没反应？你试试直接用 chromedriver ，不用 appium 看有没有问题？
正常来说用 chrome 浏览器能看到的 webview chromedriver 应该都能控制。

谢谢分享！不过上面的代码看起来是 object-c 吧？能否把这段代码的详细用法说一下？否则后面想用也不知道怎么用了。
另外，麻烦按照论坛规范，使用代码块和添加头像吧。

#1 楼 @monkey 到现在竟然还坚挺地没被删！？

@doctorq 有个地方我提议详细描述一下：

UIAUTOMATOR STDOUT是系统执行 uiautomator 时显示在 shell 中的信息（在操作系统层面都称为 STDOUT ，即标准输出 (对应地，标准输入为 STDIN，错误输出为 STDERR)。我们编程中使用 print 语句输出的对象就是 STDOUT ），BOOTSTRAP 是 bootstrap.jar 内部的 socket server 与 appium server 通讯的信息（通过 bootstrap port 输出），我觉得意义上这才是 bootstrap 内部操作的 log 。

单纯说 脚本输出 我觉得有些人可能会误解为是 bootstrap 让这些东西输出的，因为实质上是 UIAutomator 的执行过程自动输出的。

#3 楼 @kendydrm 好的，学习了。
@huokedu 你的问题已经得到解答了。你可以尝试后把过程和结论补充到正文中，让其他人也学习一下吧。

大赞，同通过《第一行代码 Android》学习 Android 开发中。
学习到后面你会发现 Fragment 也有生命周期的，而且比 activity 更好玩！

#3 楼 @ivy8_zhang 那就是不能通过 keyevent 来输入了（sendkey 在 UIAutomator 里本质上是发送 keyevent ）。如果真的需要纯自动化输入，只能图像识别了。

认同 @doctorq ，最关键的还是技术能力。做测试还是开发只是分工、着重点不同，本质上还是研发的一部分。你有能力，想做测试还是开发其实都可以的。不过，我认为目前测试转开发确实比开发转测试要难，因为测试工作用到的技术栈都比较浅，要转开发需要补充的东西比较多（在特定领域工作经验的差距）。

我目前选择做测试主要是因为我希望更加全面地了解软件，特别是原理层面，而不仅仅是从某个/些点。引用《 google 测试之道》里面一个测试工程经理 Joel Hynoski 的一句话：测试是开发过程里工程师能涉及的最远的地方。

至于那些觉得手动测试点点点没技术含量的，你看到开发在调试时也是不断点点点吗？点点点本身也许没啥技术含量，但懂得需要点什么、怎么点最容易发现问题就含有技术含量了。如果你发现问题后还能分析出具体哪些代码导致这个问题，甚至 fix 这个问题，那你绝对是一个很受开发欢迎的测试。

#13 楼 @doctorq 回复好快。。。
后面我也要加把劲了！

写得好细啊！
之前的 appium 源码分析大多重点在 bootstrap ，对 appium server 本身关注度都不高。终于有研究 server 本身的了。
我最近都没怎么研究，自愧不如啊。。。

找到这个：
http://stackoverflow.com/questions/16953809/can-one-android-application-control-another-application-via-ui-automator/17561071#17561071
原理就是把 UIAutomator 测试用例打包成 jar ，放到手机里，然后用一个应用调用系统 shell 命令来启动 UIAutomator 测试。

我猜测你看到的应该是把 UIAutomator 的测试用例打包成 jar 后，再用一个可以通过调用 shell 启动测试的 apk 把 jar 包起来。