为了开发出更好的iOS App，我们经常会去破解（我更喜欢叫Hack）优秀的App的实现方式，一般我们做的无非就是拆了ipa包浏览一下App所用到的图片资源，找个抓包工具看看都访问了那些网络资源，更虎点的就是去反编译，当然最基础的就是把玩一下各个功能，凭经验看出实现方法。
今天就介绍一个比较另类的Hack方式——VoiceOver，估计大部分人都没在自己的iOS设备上打开过这个功能，我就简单说一下效果吧，更细节的东西还是要各位亲身体验一下。
VoiceOver需要在：通用 >> 辅助功能 >> VoiceOver 页面里开启，打开后会进入一个相对比较难操作的环境，随着手指在屏幕上移动，会有一个黑框附着在手指附近的UI元素上面，同时随着黑框的移动，iOS设备会自动朗读UI元素的内容，不难发现VoiceOver这个黑框具有以下几个特性：
- 黑框所在位置就是当前UI元素的真实边框
- 对于一些元素比如UIButton，当黑框附着在起上面时，系统就会朗读“xxxxx按钮”，对于UITableView更是可以朗读出当前所在行号，以及一共有多少行。朗读的内容通常包含了这些UI元素的独有特性。
- 由于大部分的App都不会对“辅助功能”有所支持，有些没有文字的UI元素系统甚至会朗读其变量名，这跟反编译已经比较相似了。
借助第一个特性我们可以破解App的UI布局，借助第二个特性我们可以找出一些UI元素的实现方式，比如有些Gird View就是用UITableView实现的，如果系统朗读了行号等UITableView所具有的特征内容，我们就可以基本确定这个Gird View就是用TableView来实现的，TabBar之类的也是如此。借助第三条特性，我们可以通过其变量名判断其功能和实现方法。此外对于那些开源应用，变量名也可以方便我们更快地研究开源代码。
相对的，如果我们想避免App的关键实现细节被破解，就要在代码中加入防止VoiceOver响应的代码。
综上，虽然VoiceOver属于辅助功能范畴，但其一些特性为我们Hack App提供了方便。在一般的应用中加入Accessibility支持可能会使开发成本有所提高，但对于某些领域的应用，Accessibility支持无疑会成为应用的一大两点，在此也推荐大家看一下 WWDC 2011 Session 127 – Design Patterns to Simplify Mac Accessibility，真的挺有爱的。
–以上—