iOS生产力之小工具合集
初识iOS平台已几月有余，作为一个从windows平台转型过来的开发者,曾经有人在微博煞有介事问我转型体验如何? 我想除了全新的平台、开发语言所带更多的挑战和新鲜感,如果能够在不断磨练技能中日益精进做出更好的产品,这未尝不可是一件值得尝试的事情.反言之如果能够在一个合适时机把自己原来经验适当的“洗白”重新开始积累,我更愿意选择iOS作为新的起点而不是Android,并非诋毁否定Android这个平台，而是付诸同等成本来做一件事，在我看来Android所能给我带来的诱惑(或者理解为附加值)远比iOS带来的要小的多.所以当初在转平台之初,在这个问题上我并没有做过过多的摇摆甚至可以说基本没有考虑Android平台，目标很明确.
当然更没有所谓“转型阵通”这么一说.整个过程一切都是顺其自然，所谓的不适应也在比我预想更短时间很快被克服了.如果不去尝试怎么能知道自己其实已经手握通往另外一个世界钥匙呢...
The Gate Via By Davide Bianchi [From 500px]
在windows平台下强大的IDE-Visual Studio臃肿的身躯下，除了把开发人员变得更”懒"和不明就里之外,其实也不乏极具效率生产力工具的封装.比如调试用如果用VS和Xcode对比那真的欺负小朋友，至于Auto-Complete(自动完成)和Call Tip(联想提示)那就更甩开几条街了.VS可以从设计，开发，到测试，部署和维护的管理项目的整个生命周期。如果从这个角度来理解所谓的“集成开发环境 （IDE）”的话，VS显然比XCode先进太多了.问题是在Mac平台上苹果一直尝试从编译器层面上把控一切.换言之Xcode在这个诺大平台上是没有对手的.到了"独孤求败"的地步.反观VS,在不同时期则完全不同.不知道是否有人记得很久之前VS有一个强劲的竞争对手-Borland出品的IDE环境，包括Delphi, Borland C++等等。这个对手促使Windows平台的IDE理念不断进化以便从竞争中胜出.才回有今天各位看到不断进化的VS版本陆续发布.
Visual Studio Vs Xcode [via Binary Wasteland]
当然在开发学习过程中其实并不妨碍用使用其他平台积累的开发经验来做对比.从生产力角度来说，那些还停留在语言之争而非如何更好使用好语言本身其实大多是徒劳无益的.工具意义在于从繁复和支系庞杂逻辑中解放出来，能够寻求一个最快或者最直接解决问题的路径，有人老是在争论工具好坏与否，其实你可以理解每个工具都在尝试用自己角度达到所谓“最优解”，而人和使用成本以及生产力效率因素都可以使用者身上寻求变通得到一个平衡,比如善用Xcode中优质第三方插件和工具就是当下面对所谓Xcode不完美是一个很好的尝试.
1.Linguan
最近负责客户端整个国际化模块,对于整个应用程序国际化它在技术实现其实并没有难度，问题在于整个项目开发工作就像你在客厅羊绒地毯上吃面包，而国际化就是你站在羊毛毯中间不断掉落的面包屑-繁杂而琐碎.
主要工作量在于Resource目录下Localizable文件多语言文件支持的整理.而Localizable文件是纯文本格式来存在国际化语言的数据.如下:
Localizable文件
文本格式虽然简单直接，但不利于再直接编辑后对错误标示进行提示，而寻求比对缺失key上难度较大.最关键的问题是当需要全新支持一门新的语言时,不得不生成一个新的String文件，给产品去翻译,但这种做法无法保证在合并翻译后的内容一次性无错情况下通过编译.经常出现的问题是翻译回来因为一个字符因为产品翻译采用编辑器不同导致编码不一致或者在修改因为人工失误导致缺失,这给翻译后找错过程增加了难度，而其实这个问题可以操作过程中就可以避免的,Xcode在项目资源协作较弱的问题相对于VS就凸显出来了.而恰恰因为这点给了Linguan用武之地.
Linguan
Linguan的GUI确实非常接近VS中针对多语言支持Key-Value(键值对)编辑界面,而Linguan为Xcode项目中所有strings文件提供了智能化的编辑器。在你复制重复Key或者丢失翻译的时候，Linguan会提示警告例如如下:当两个相同的Key采用不同的值就很明确给出警告:
重复Key提示
同时，你可以输出针对某种语言丢失的Key发给你的产品去翻译，产品当然也可以同样使用Linguan完成翻译,这样大大简化国际化翻译后纠错编辑工作量.可谓一举两得.
2.SimPholders
iOS本地文件IO存储上其实和WP平台都是采用同样沙盒机制-既应用只能自己在存储空间读写，且应用与应用之间彼此不可见的.如果在Debug时需要看本地存储数据文件如何来做?常规方法是:
找到Finder前往文件夹输入:
~/library/Developer/CoreSimulator/Devices/3CB828D3-9F35-4B23-B8D4-AC3B2CDC6F06/data/
这样导致每次Type流程容易出错且非常耗时.SimPholders可以让你快速直接地访问iPhone模拟器应用的app文件所在目录. 可以通过SimPholders找到数据库文件、永久存储以及缓存数据：
SimPholders
在应用Debug调试时非常实用,同时还可以离线使用.但问题是这就足够了吗?
我曾在Windows phone应用开发[15]-辅助工具一文提到了WP平台关于沙箱本地查看工具-IsostoreSpy
IsostoreSpy
IsostoreSpy能够做到：
A:直接遍历所有文件存储子路径.
B:直接查看文本、图片、语音等文件内容不需要额外打开.
C:直接调试真机上传、下载、删除沙箱中任何文件资源.
D:直接卸载&安装应用程序.
虽然SimPholders这个小工具很好解决了入口路径过深打开不便的问题.但相比IsostoreSpy差距在与如果如上功能内聚进来，不需要开发者直接访问本地文件方式去操作沙箱文件.而是全部聚合到SimPholders工具本身不要两边来切则更方便了.
3.Unused
最近我们一直讨论包大小太大的问题.包太大不利于分发.其中就提到关于整个Project 废弃的图片资源剔除到应用程序外做法.现在做法是检索整个Project看图片是否存在引用，如果没有则直接干掉,但如果整个Project图片资源过多，这个方法显得极为笨拙且效率底下.针对这个问题在github上花了点时间找到找到Unused这个小工具.Unused可以查找整个Project中对应文件格式中未使用的图片资源,最关键它是可视化的形式展现出来.支持查找格式也较为全面.如下是我run我们客户端发现废弃图片资源的结果（不一定对仅供参考）:
Unused运行废弃图片资源结果
其中涉及到废弃资源内容多达几百项.留意一下注意到很多是因为版本迭代需求更改后对应图片资源也跟这废弃了，但因为对应废弃代码没有删除，所以引用图片资源一直存在导致的，还发现一种情况是整个project中出现重复图片资源的情况.建议采用Unused针对指定对整个Project图片重新梳理.特别提示一下很多首页天气动画图片引用是在Xml文件中.注意Unuserd目前还未支持xml格式.当然有源码，可以基于源代码做一次扩展即可.
4.ImageOptim
上文提到关于Project中废弃图片资源剔除的问题.顺便找到了一个关于图片压缩比率最高的图片压缩工具[ImageOptim].我一直以为png已经是无损格式所以无法被压缩.但没想到压缩比例依然很高,类似如下我放了三个png和一个jpeg文件压缩比例对比:
压缩比例对比结果
可见Png格式下可被压缩比例还是很高的,基本都接近了50%左右.注意目前ImageOptim工具只支持压缩JPEG和PNG两种图片格式. JPEG 与 PNG 的压缩时间不等，JPEG 很快，差不多3- 7 秒;但 PNG 很慢，差不多 30 秒。只有左边提示绿色对勾才表示压缩成功.
这里有有几个小技巧.为了提高 JPEG 的压缩率其实可以将ImageOptim偏好设定中「JPEGOptim」最佳质量从默认的 100% 调降为 80%:
JPEGOptim设置
原本设定质量 100% 的情况下，JPEG文件差不多只能压到 90%;调成 80% 之后文件可以压到只有 40%.提高一倍左右.当然如果PNG格式文件较大,压缩PNG时间会很长.将ImageOptim偏好设定中「PNGOUT」的优化类型，从默认的「极端」调降为「简易」：
PNGOut设置
如此一来压缩率不变，但压缩时间却可以减少二分之一.可以保证压缩比最高的情况，极大节约了压缩时间.
关于这个工具有一个需要注意地方是当把图片拖入工具中就会立即开始压缩.压缩后的图片会覆盖原来的图片.如果你要保留压缩前的图片最好在拖入压缩前复制一份.
后面还有陆续有4个左右的工具还未介绍,本篇篇幅已经很长.考虑到阅读效率将剩下小工作放在下一个篇幅来介绍.当然如果有你有更多关于IOS开发小工具和使用的奇淫技巧.不妨在评论提到.最后拓展阅读有对应工具下载地址和使用，各取所需.
