为了开发出更好的iOS App,我们经常会去破解(我更喜欢叫Hack)优秀的App的实现方式,一般我们做的无非就是拆了ipa包浏览一下App所用到的图片资源,找个抓包工具看看都访问了那些网络资源,更虎点的就是去反编译,当然最基础的就是把玩一下各个功能,凭经验看出实现方法。

今天就介绍一个比较另类的Hack方式——VoiceOver,估计大部分人都没在自己的iOS设备上打开过这个功能,我就简单说一下效果吧,更细节的东西还是要各位亲身体验一下。

VoiceOver需要在:通用 >> 辅助功能 >> VoiceOver 页面里开启,打开后会进入一个相对比较难操作的环境,随着手指在屏幕上移动,会有一个黑框附着在手指附近的UI元素上面,同时随着黑框的移动,iOS设备会自动朗读UI元素的内容,不难发现VoiceOver这个黑框具有以下几个特性:

  1. 黑框所在位置就是当前UI元素的真实边框
  2. 对于一些元素比如UIButton,当黑框附着在起上面时,系统就会朗读“xxxxx按钮”,对于UITableView更是可以朗读出当前所在行号,以及一共有多少行。朗读的内容通常包含了这些UI元素的独有特性。
  3. 由于大部分的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,真的挺有爱的。

–以上—

Tagged with:  

发表评论

电子邮件地址不会被公开。 必填项已用*标注