===========分割线===========
20180121更新，升级到了Appium Desktop 1.3.1，详细更新内容见本文末，建议阅读本文前先看最近更新的内容。
===========分割线===========
在上一篇文章中，进了Android的坑，这次，要跳进更大更深的坑——iOS。
百度google了一轮，最大的感触是：好多教程都不适用啊！要么是Appium版本旧，要么是iOS版本旧。想找一篇详细的“从入门到放弃”的教程都没有，之前搭Android环境的时候，能搜到很多十分详实的教程，而iOS的就有点蛋疼了。
然而，坑还是要入的，所以，就从搭环境开始吧。
我们手机在连Wi-Fi的时候，都有一个”代理服务器“的选项，而fiddler就是作为代理服务器，所以就能抓包了。而https呢，fiddler能作为中间人两边骗，所以还能抓https的包。
File => 勾选capture traffic
Tools => fiddler options => https => capture https traffic => decrypt https traffic => Ignore server certificate errors
由于对本机的数据包不感兴趣，所以把”from all processes” 改为 “from remote clients only”
切换到Connections选项卡，勾选allow remote computers to connect，注意端口号是8888
默认的证书在Android和iOS下可能无效，所以，需要下载certmaker插件，双击安装后，重启fiddler。我用默认的证书，HTTPS确实解密不出来。
主机为电脑IP，端口号为8888
在手机的浏览器进入http://电脑IP:8888，下载页面最下面的FiddlerRoot certificate，完成证书安装。
相关参考：
1. fiddler 手机 https 抓包, http://blog.csdn.net/wangjun5159/article/details/52202059
背景：有一台可以tcpdump的OpenWrt路由器，用它来抓下面的客户端的数据包。以前我一直都是把tcpdump的结果保存成.cap文件再传到PC上用Wireshark打开，直到今天，才学会了更方便快捷的办法。网上给出的命令是这样的：
plink -ssh USER@HOST -pw PASS "tcpdump -s 0 -U -n -i br-lan -w - not port 22" | wireshark -k -i -
其中plink是一个Windows下的命令行SSH客户端程序（Linux系统下改成ssh的相应命令）。试了一下，确实可以！
为什么可以？
由“|”可见它是通过管道来传输的，难道数据还能直接从输入输出传输？因此去看看文档，并找到了答案：
在tcpdump的manpage中得知，最重要的参数是”-w -“，当文件名是”-“时，输出原数据包到stdout；-U参数是让数据包打印时直接输出到stdout而不是在输出缓存满后再输出；”-s 0″表示设置最大数据包长度为默认值(262144 Bytes)。
而从Wireshark的帮助中可知，当抓包接口为”-“时，就从stdin读取数据，所以就ok了。
本文简单记录了我的Appium入门学习历程。系统环境为Win7 x64，Appium client选择Python，Python版本为2.7。那就开始吧。
到Oracle官网下载，我安装的是8u121 x64版本。
安装完，添加环境变量：JAVA_HOME，值：JDK安装的路径，如C:\Program Files\Java\jdk1.8.0_121
修改环境变量Path，发现好像不用改了，因为安装JDK的时候已经加上了C:\ProgramData\Oracle\Java\javapath，所以没有按网上的教程做（在原来的末尾加上分号”;”，再加上%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin）
再添加环境变量：CLASSPATH，变量值：%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
由于用的是Windows系统，Appium给Windows用户做了一个“一键安装包”——AppiumForWindows，到官网http://appium.io/下载即可。里面带了Appium和node.js。安装之后在环境变量Path中再加上Appium（也是node）所在的路径。
阅读更多…
例如我们需要提取
<div id="a"><span id="b">content</span></div>
中的content，以Python为例：
第1个办法：使用text属性：先 elem=find_element_by_id(‘b’)，再用 elem.text 属性；
第2个办法：使用get_attribute / get_property方法，先 elem=find_element_by_id(‘b’)，然后用 elem.get_attribute(‘innerHTML’)；
另外，如果 elem=find_element_by_id(‘a’)，elem.get_attribute(‘innerHTML’) 获取到的会是<span id=”b”>content</span>
用Python处理中文，肯定是每个人都曾经烦过的问题。
生产环境是Python2，任务是把unicode字符串如 u’\uxxxx\uxxxx\uxxxx’ 转换为gbk保存，用的是str.encode(‘gbk’)方法。
然而，经常会出现类似这样的异常：
UnicodeEncodeError: ‘gbk’ codec can’t encode character u’\uxxxx’ in position 0: illegal multibyte sequence
原因是遇到了某些非法字符，而蛋疼的是，一大串字符串里面只要遇到一个非法字符，就会报错，这可不是我们希望的。
解决办法：从帮助文档可知，函数原型是 encode([encoding], [errors=‘strict‘])，decode函数也是一样，默认用的是严格的策略，一遇到问题就抛出异常，我们可以把它改为’ignore’或者’replace’等值，就可以避免异常了。
在挂载U盘时失败，dmesg提示找不到某些codepage，才知道这还和Native Language Support有关。
要记得装上 kmod-nls-cp437、kmod-nls-iso8859-1、kmod-nls-utf8 这3个包。
另外还有 kmod-usb-core kmod-usb-ohci kmod-usb-uhci kmod-usb2 kmod-usb-storage kmod-usb-storage-extras block-mount kmod-fs-vfat kmod-fs-ntfs 等包。
如果想让一个P2P程序不能穿透，比较好的办法就是把NAT类型改为对称型的，即Symmetric.
之前以为NAT类型对于一个路由器是固定的，后来google到了使用iptables模拟的方法，当然Symmetric NAT也有很多不同的具体实现形式，这里模拟的是其中的一种。
系统为OpenWrt，执行命令
WAN_IF = “eth0” # 你的WAN接口 iptables -t nat -A POSTROUTING -o $WAN_IF -j MASQUERADE --random
即可。
测试的结果是，对于同一个LAN IP:Port，对不同的Dst IP，映射到的WAN Port会差异比较大；而如果只改Dst Port，端口增量不大，可能为1。
相关参考：
http://albert-oma.blogspot.bg/2013/12/nat-router.html
先说重点：槽点最大在于国外的资源和UDP被限制。
平时找各种资料，难免要访问位于境外的网站。记得一开始速度还有100kB 200kB，但是最近完全没法用了，http连接基本不能建立，浏览器就一直在在转。
不要以为是地球另一端的网站才这样，香港的服务器一样是这样。
经过一点点分析，当访问一些境外（还是说不在长宽自家资源白名单）IP时，会被NAT到一个东莞的IP，然后就很慢很慢很慢很慢很慢。又测试了一下直接发送UDP报文，直接震惊了我：发送100次另一端可能都接收不了几次，我总算是有点理解UDP的“不可靠”了。
不仅是国外的UDP，就算是国内的UDP，也照丢不误：NTP时间同步，我向正确的服务器IP发了请求，但是根本收不到服务器的回复，换个网络环境，瞬间ok，呵呵了。
另外，就算是国内的网站，也会时不时遇到死活加载不出来的情况，例如某网站的图片是放到另外一个域名下，然后那域名有点问题，于是整个网站的图片都看不到了。另外，DNS也会随机抽风（我改用第三方DNS也如此）。
还有蛋疼的是，国内的出口经常不固定，微博经常给我发邮件，说我在哪个哪个省登录了，次数多了就冻结我的账户，都冻结过几次了。
再反过来说说长宽自家的资源，例如一些视频网站直播网站一些大网站，都有比较好的优化，例如下载某些资源的时候，会直接302重定向到长宽自己的ip下，例如http://123.45.67.89/foo.com/path/file.ext，然后下载速度就飞快了。所谓的100M，是指这些优化过的资源有100M吧，呵呵。至于境外的网站？视乎网站的优化吧，例如github还行，打开成功率比较高；完全没有优化的，大部分情况下打不开，就算能打开，0.1M的速度可能都没有，呵呵。
然而，这个“优化”有时候会有反作用：这相当于劫持了真正的资源，到它自己的资源库中，隐私问题就不说了，它自己的资源有时候是错的！！！！例如更新linux系统时，如果用http的源，经常就被劫持到了它的服务器上，然后hash验证就过不了，导致更新失败。
另外一个是P2P简直没法用，BT下载我是从来没见过有速度，测了一下NAT的类型，就是对称型的Symmetric NAT，P2P看来是不用多奢望了。
之前还不懂别人为什么喷，自己用过了才知道。
总结：国外垃圾、网游呵呵、P2P更不用想。只用来看看优酷土豆爱奇艺乐视的电视剧，估计会比较满意，可惜这不是我的需求。