初識iOS平臺已幾月有余，作為一個從windows平臺轉(zhuǎn)型過來的開發(fā)者,曾經(jīng)有人在微博煞有介事問我轉(zhuǎn)型體驗如何? 我想除了全新的平臺暂题、開發(fā)語言所帶更多的挑戰(zhàn)和新鮮感,如果能夠在不斷磨練技能中日益精進做出更好的產(chǎn)品,這未嘗不可是一件值得嘗試的事情.反言之如果能夠在一個合適時機把自己原來經(jīng)驗適當(dāng)?shù)摹跋窗住敝匦麻_始積累,我更愿意選擇iOS作為新的起點而不是Android,并非詆毀否定Android這個平臺，而是付諸同等成本來做一件事钓试，在我看來Android所能給我?guī)淼恼T惑(或者理解為附加值)遠比iOS帶來的要小的多.所以當(dāng)初在轉(zhuǎn)平臺之初,在這個問題上我并沒有做過過多的搖擺甚至可以說基本沒有考慮Android平臺裂垦，目標(biāo)很明確.?

當(dāng)然更沒有所謂“轉(zhuǎn)型陣通”這么一說.整個過程一切都是順其自然，所謂的不適應(yīng)也在比我預(yù)想更短時間很快被克服了.如果不去嘗試怎么能知道自己其實已經(jīng)手握通往另外一個世界鑰匙呢...

The Gate Via By Davide Bianchi [From 500px]

在windows平臺下強大的IDE-Visual Studio臃腫的身軀下姻乓，除了把開發(fā)人員變得更”懶"和不明就里之外,其實也不乏極具效率生產(chǎn)力工具的封裝.比如調(diào)試用如果用VS和Xcode對比那真的欺負小朋友嵌溢，至于Auto-Complete(自動完成)和Call Tip(聯(lián)想提示)那就更甩開幾條街了.VS可以從設(shè)計，開發(fā)蹋岩，到測試赖草，部署和維護的管理項目的整個生命周期。如果從這個角度來理解所謂的“集成開發(fā)環(huán)境 （IDE）”的話剪个，VS顯然比XCode先進太多了.問題是在Mac平臺上蘋果一直嘗試從編譯器層面上把控一切.換言之Xcode在這個諾大平臺上是沒有對手的.到了"獨孤求敗"的地步.反觀VS,在不同時期則完全不同.不知道是否有人記得很久之前VS有一個強勁的競爭對手-Borland出品的IDE環(huán)境秧骑，包括Delphi, Borland C++等等。這個對手促使Windows平臺的IDE理念不斷進化以便從競爭中勝出.才回有今天各位看到不斷進化的VS版本陸續(xù)發(fā)布.

Visual Studio Vs Xcode [via Binary Wasteland]

當(dāng)然在開發(fā)學(xué)習(xí)過程中其實并不妨礙用使用其他平臺積累的開發(fā)經(jīng)驗來做對比.從生產(chǎn)力角度來說扣囊，那些還停留在語言之爭而非如何更好使用好語言本身其實大多是徒勞無益的.工具意義在于從繁復(fù)和支系龐雜邏輯中解放出來乎折，能夠?qū)で笠粋€最快或者最直接解決問題的路徑，有人老是在爭論工具好壞與否侵歇，其實你可以理解每個工具都在嘗試用自己角度達到所謂“最優(yōu)解”笆檀，而人和使用成本以及生產(chǎn)力效率因素都可以使用者身上尋求變通得到一個平衡,比如善用Xcode中優(yōu)質(zhì)第三方插件和工具就是當(dāng)下面對所謂Xcode不完美是一個很好的嘗試.

1.Linguan

最近負責(zé)客戶端整個國際化模塊,對于整個應(yīng)用程序國際化它在技術(shù)實現(xiàn)其實并沒有難度，問題在于整個項目開發(fā)工作就像你在客廳羊絨地毯上吃面包盒至，而國際化就是你站在羊毛毯中間不斷掉落的面包屑-繁雜而瑣碎.

主要工作量在于Resource目錄下Localizable文件多語言文件支持的整理.而Localizable文件是純文本格式來存在國際化語言的數(shù)據(jù).如下:

Localizable文件

文本格式雖然簡單直接酗洒，但不利于再直接編輯后對錯誤標(biāo)示進行提示，而尋求比對缺失key上難度較大.最關(guān)鍵的問題是當(dāng)需要全新支持一門新的語言時,不得不生成一個新的String文件枷遂，給產(chǎn)品去翻譯,但這種做法無法保證在合并翻譯后的內(nèi)容一次性無錯情況下通過編譯.經(jīng)常出現(xiàn)的問題是翻譯回來因為一個字符因為產(chǎn)品翻譯采用編輯器不同導(dǎo)致編碼不一致或者在修改因為人工失誤導(dǎo)致缺失,這給翻譯后找錯過程增加了難度樱衷，而其實這個問題可以操作過程中就可以避免的,Xcode在項目資源協(xié)作較弱的問題相對于VS就凸顯出來了.而恰恰因為這點給了Linguan用武之地.

Linguan

Linguan的GUI確實非常接近VS中針對多語言支持Key-Value(鍵值對)編輯界面,而Linguan為Xcode項目中所有strings文件提供了智能化的編輯器。在你復(fù)制重復(fù)Key或者丟失翻譯的時候酒唉，Linguan會提示警告例如如下:當(dāng)兩個相同的Key采用不同的值就很明確給出警告:

重復(fù)Key提示

同時矩桂，你可以輸出針對某種語言丟失的Key發(fā)給你的產(chǎn)品去翻譯，產(chǎn)品當(dāng)然也可以同樣使用Linguan完成翻譯,這樣大大簡化國際化翻譯后糾錯編輯工作量.可謂一舉兩得.

2.SimPholders

iOS本地文件IO存儲上其實和WP平臺都是采用同樣沙盒機制-既應(yīng)用只能自己在存儲空間讀寫痪伦，且應(yīng)用與應(yīng)用之間彼此不可見的.如果在Debug時需要看本地存儲數(shù)據(jù)文件如何來做?常規(guī)方法是:

找到Finder前往文件夾輸入:

~/library/Developer/CoreSimulator/Devices/3CB828D3-9F35-4B23-B8D4-AC3B2CDC6F06/data/

這樣導(dǎo)致每次Type流程容易出錯且非常耗時.SimPholders可以讓你快速直接地訪問iPhone模擬器應(yīng)用的app文件所在目錄. 可以通過SimPholders找到數(shù)據(jù)庫文件侄榴、永久存儲以及緩存數(shù)據(jù)：

SimPholders

在應(yīng)用Debug調(diào)試時非常實用,同時還可以離線使用.但問題是這就足夠了嗎?

我曾在Windows phone應(yīng)用開發(fā)[15]-輔助工具一文提到了WP平臺關(guān)于沙箱本地查看工具-IsostoreSpy

IsostoreSpy

IsostoreSpy能夠做到：

A:直接遍歷所有文件存儲子路徑.

B:直接查看文本、圖片网沾、語音等文件內(nèi)容不需要額外打開.

C:直接調(diào)試真機上傳癞蚕、下載、刪除沙箱中任何文件資源.

D:直接卸載&安裝應(yīng)用程序.

雖然SimPholders這個小工具很好解決了入口路徑過深打開不便的問題.但相比IsostoreSpy差距在與如果如上功能內(nèi)聚進來辉哥，不需要開發(fā)者直接訪問本地文件方式去操作沙箱文件.而是全部聚合到SimPholders工具本身不要兩邊來切則更方便了.

3.Unused

最近我們一直討論包大小太大的問題.包太大不利于分發(fā).其中就提到關(guān)于整個Project 廢棄的圖片資源剔除到應(yīng)用程序外做法.現(xiàn)在做法是檢索整個Project看圖片是否存在引用桦山，如果沒有則直接干掉,但如果整個Project圖片資源過多，這個方法顯得極為笨拙且效率底下.針對這個問題在github上花了點時間找到找到Unused這個小工具.Unused可以查找整個Project中對應(yīng)文件格式中未使用的圖片資源,最關(guān)鍵它是可視化的形式展現(xiàn)出來.支持查找格式也較為全面.如下是我run我們客戶端發(fā)現(xiàn)廢棄圖片資源的結(jié)果（不一定對僅供參考）:

Unused運行廢棄圖片資源結(jié)果

其中涉及到廢棄資源內(nèi)容多達幾百項.留意一下注意到很多是因為版本迭代需求更改后對應(yīng)圖片資源也跟這廢棄了醋旦，但因為對應(yīng)廢棄代碼沒有刪除恒水，所以引用圖片資源一直存在導(dǎo)致的，還發(fā)現(xiàn)一種情況是整個project中出現(xiàn)重復(fù)圖片資源的情況.建議采用Unused針對指定對整個Project圖片重新梳理.特別提示一下很多首頁天氣動畫圖片引用是在Xml文件中.注意Unuserd目前還未支持xml格式.當(dāng)然有源碼饲齐，可以基于源代碼做一次擴展即可.

4.ImageOptim

上文提到關(guān)于Project中廢棄圖片資源剔除的問題.順便找到了一個關(guān)于圖片壓縮比率最高的圖片壓縮工具[ImageOptim].我一直以為png已經(jīng)是無損格式所以無法被壓縮.但沒想到壓縮比例依然很高,類似如下我放了三個png和一個jpeg文件壓縮比例對比:

壓縮比例對比結(jié)果

可見Png格式下可被壓縮比例還是很高的,基本都接近了50%左右.注意目前ImageOptim工具只支持壓縮JPEG和PNG兩種圖片格式. JPEG 與 PNG 的壓縮時間不等钉凌，JPEG 很快，差不多3- 7 秒;但 PNG 很慢捂人，差不多 30 秒御雕。只有左邊提示綠色對勾才表示壓縮成功.

這里有有幾個小技巧.為了提高 JPEG 的壓縮率其實可以將ImageOptim偏好設(shè)定中「JPEGOptim」最佳質(zhì)量從默認的 100% 調(diào)降為 80%:

JPEGOptim設(shè)置

原本設(shè)定質(zhì)量 100% 的情況下矢沿，JPEG文件差不多只能壓到 90%;調(diào)成 80% 之后文件可以壓到只有 40%.提高一倍左右.當(dāng)然如果PNG格式文件較大,壓縮PNG時間會很長.將ImageOptim偏好設(shè)定中「PNGOUT」的優(yōu)化類型，從默認的「極端」調(diào)降為「簡易」：

PNGOut設(shè)置

如此一來壓縮率不變饮笛，但壓縮時間卻可以減少二分之一.可以保證壓縮比最高的情況咨察，極大節(jié)約了壓縮時間.

關(guān)于這個工具有一個需要注意地方是當(dāng)把圖片拖入工具中就會立即開始壓縮.壓縮后的圖片會覆蓋原來的圖片.如果你要保留壓縮前的圖片最好在拖入壓縮前復(fù)制一份.

后面還有陸續(xù)有4個左右的工具還未介紹,本篇篇幅已經(jīng)很長.考慮到閱讀效率將剩下小工作放在下一個篇幅來介紹.當(dāng)然如果有你有更多關(guān)于IOS開發(fā)小工具和使用的奇淫技巧.不妨在評論提到.最后拓展閱讀有對應(yīng)工具下載地址和使用论熙，各取所需.