Android 4.1开始引入的Uiautomator测试框架非常好用，但由于不够重视还缺失很多功能以及Bug。 本文描述一则Bug，该Bug导致Uiautomator中Configure.setWaitForIdleTimeout()设置的值无效。 由于Uiautomator在所有操作前几乎都会waitForIdle()，对于界面持续变化的App来说总是需要等待10s超时后才能操作一步，解决方法之一是使用Configure.setWaitForIdleTimeout()设置超时时间，然而这个方法并没有起到预期的效果。 Bug之处在于当findAccessibilityNodeInfo中的waitForIdle()时，调用的是无参数waitForIdle()，由此调用到最终的UiAutomatorBridge中的无参数waitForIdle()，这个函数是这样的 public void waitForIdle() { waitForIdle(TOTAL_TIME_TO_WAIT_FOR_IDLE_STATE); } public void waitForIdle(long timeout) { try { mUiAutomation.waitForIdle(QUIET_TIME_TO_BE_CONSIDERD_IDLE_STATE, timeout); } catch (TimeoutException te) { Log.w(LOG_TAG, “Could not detect idle state.”, te); } } 而TOTAL_TIME_TO_WAIT_FOR_IDLE_STATE正等于10s，由此可见这是Google的疏忽导致只有UiDevice.waitForIdle()会读取Configure中的超时值。

最近刚买了ME294，其他都挺好，就是感觉发热比原来还高，装了个温度监控的插件随便玩个游戏就90度以上的实在伤不起。让我想起了睿频的问题，下载了Intel的一个小程序，观察到现在的技术已经成熟到所有核心满载还能睿频到3.3G（原始2.3G）啊……功耗也上升到接近47W的TDP。 一般我也用不到那么高性能，尤其玩玩游戏的话2.3G足够了，在Win下可以通过电源设置禁用睿频，而OS X下使用各大搜索引擎都没有搜到中文的关闭睿频帖子。凭着蹩脚的英语在谷歌搜“OS X TurboBoost” 结果就搜到了几个解决方案，说白了其实就是一个Kext（内核扩展） 这个Kext是开源的，地址： https://github.com/nanoant/DisableTurboBoost.kext 这个是需要自己下载代码编译然后通过终端去使用的，比较麻烦些。 然后又找到一个封装好的，顺带还能看CPU温度及风扇速度的软件，下载地址： http://www.rugarciap.com/turbo-boost-switcher-for-os-x/ 使用效果如下： CPU温度：99℃->70℃ 风扇速度：6000rpm->2500rpm 功耗：47W->22W 性能：100%->75%

之前就有所耳闻校园网使用路由器可能被检测到并被劫持导致无法上网。果然不久之后就出现如下页面，无论如何刷新都是这样。 具体是如何检测到我使用路由的无从得知，不过使用Wireshark抓包分析可以知道整个流程是被铁通（移动）捣蛋了。当已被检测到使用路由器的用户发出网页GET请求时，移动抢先使用对方IP发送他的网页内容，而之后实际网页内容页面是有发送的，但被电脑所丢弃。 详细分析得知这个铁通伪造HTTP响应包在TCP Flags用的保留字段设置了值，那么很简单可以通过这个特征使用iptables过滤掉。 另一件奇葩事是当我下载文件时，发现很多文件最终下载地址都被重定向到一个IP上，而且是移动的IP。 仍然是通过Wireshark抓包分析得知，在用户GET请求下载文件时，铁通同样抢先返回一个302重定向响应，将用户重定向到移动的缓存服务器下载，以节省网间结算费用。这当然没什么不好，下载速度还更快了，但要命的是我下了10个文件就有1个文件损坏，这个不能忍。 通过分析仍然可以抓到特征，这个伪造的302包在TCP的Urgent Pointer字段设置了10，但TCP Flags没有设置Urgent，之后正常数据包仍然会到达电脑，所以还是可以通过iptables屏蔽该包解决。 暂时两大劫持基本解决。

在家中和之前学校接触的都是主流网络运营商——电信和联通，所以在网络互联互通的问题上没碰到过太大问题，而现在的学校提供更廉价的移动宽带，但是一些现象让我好奇的想去彻彻底底的研究一番。 刚使用上移动宽带时对带宽比较满意，实测有10M下行和5M上行。但是访问一些国内论坛、游戏时会提示一个与自己PPPoE获得的IP完全不一致的IP，IP WHOIS信息也显示是外省市，电信或联通运营商的IP，而访问我自己位于国外的VPS时则显示IP与本机PPPoE获得的IP一致，至少证明获取的IP是一个合法公网IP并不是一个非法IP。 但是，为什么访问国内那些网站显示的IP与我本机不一致呢？ 经过不停的搜索，注意到了这样一条新闻 尽管如此，弱势运营商依然找到了一线生机：一些公司在中国电信购买带宽后，并不自己使用，而是转手卖给铁通、广电等弱势运营商赚取差价。尽管如此，弱势运营商获得接入带宽的价格仍远低于中国电信的结算标准，往往能低至30万元/G/月甚至更多。 在业内，这条路径被称为“流量穿透”，正是中国电信此次铁腕斩断的“清洗目标”。 对于“流量穿透”，中国电信一直高度抵制。在此前一份内部材料中，中国电信认为，“竞争对手千方百计各地询价，以多种方式低价接入电信骨干网，目的是降低成本使其在宽带市场有降价空间”，并估算当时“流量穿透”使竞争对手单个用户平均成本可下降25元/月。” 流量穿透？我们先要了解一个概念，不同运营商之间需要互联互通时正常方式应通过第三方运营商路由或直连并互相告诉对方自己拥有某一段IP地址。此后不同运营商之间才可以正常互相访问，但在中国特殊国情下，大部分网站和网络资源均在中国电信网络中，如果某一个运营商不接入中国电信则注定无法发展用户（大部分国内网站都无法访问的世界你懂的），而对于中国电信来说多一个小运营商不多，少一个不少。当存在这一地位和资源差距后，自然是小运营商向大运营商购买接入带宽，以便自己的用户能够正常访问大运营商网络中的资源，大运营商中的用户也能访问小运营商网络中的其它用户。如果拿移动宽带和电信宽带来举例，如果采用这种方式即如下图（注意：路由方式传输数据不会改变源IP地址） 而根据新闻所述，上述这种方式电信会根据运营商等级来区分价格，并且远远高于企业等非运营商租用带宽的价格。而小运营商本身就以廉价为主打，自然不可能去负担高昂的互联互通费用。结合自身主打用户而非IDC的定位，这些运营商想到了什么？没错，伪装成非运营商去向大运营商购买带宽然后做NAT。以企业名义向电信购买带宽或直接向企业购买已有电信带宽，然后与自有线路对接，明显这种方式不可能再以正规方式广播给大运营商自己的IP段，让电信将这些流量路由到自己这里来（一般企业使用静态路由方式，分配固定IP地址），于是只能在自己和大运营商之间做NAT，将自己用户向大运营商访问的流量全部路由到此处作NAT处理，这样即可共享同一个IP地址。如下图： 这样做的副作用自然是大运营商的用户无法主动发起访问小运营商用户（想想家里的路由器NAT后的情况？）。而小运营商的用户自然就被“漫游”到外省市的某一个IP上，大运营商网络中的服务器获取的IP自然也是企业的IP，而不是用户真正的IP。 小运营商为了省钱，让用户明明获得了公网IP，但仍然要经过NAT去访问非本运营商的网络。这种大规模NAT不仅影响了网络稳定性，更是让用户无法享受连上互联网就该享受的被连接权利） So，便宜没好货。

魅族MX2虽然官方已经开放了root权限，但adb下显然还是需要在shell下执行su才能获取root权限的。由于adb pull push这类操作无法先执行su，这对调试程序很不方便，于是搜索到了这款程序——adbd Insecure。 adbd Insecure是通过patch方式让adbd工作在非安全模式，adb连接上后即拥有root权限，剩下能做什么相信不用我说也知道了。当然运行它也是需要root权限的 下载地址：http://www.coolapk.com/apk/eu.chainfire.adbd