iOS生產力之小工具合集

jopen 9年前發布 | 34K 次閱讀 IOS iOS開發 移動開發

初 識iOS平臺已幾月有余，作為一個從windows平臺轉型過來的開發者,曾經有人在微博煞有介事問我轉型體驗如何? 我想除了全新的平臺、開發語言所帶更多的挑戰和新鮮感,如果能夠在不斷磨練技能中日益精進做出更好的產品,這未嘗不可是一件值得嘗試的事情.反言之如果能 夠在一個合適時機把自己原來經驗適當的“洗白”重新開始積累,我更愿意選擇iOS作為新的起點而不是Android,并非詆毀否定Android這個平 臺，而是付諸同等成本來做一件事，在我看來Android所能給我帶來的誘惑(或者理解為附加值)遠比iOS帶來的要小的多.所以當初在轉平臺之初,在這 個問題上我并沒有做過過多的搖擺甚至可以說基本沒有考慮Android平臺，目標很明確. 

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


The Gate Via By Davide Bianchi [From 500px]
</div>

在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]
</div>

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

1.Linguan

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

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


Localizable文件
</div>

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


Linguan
</div>

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


重復Key提示
</div>

同時，你可以輸出針對某種語言丟失的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
</div>

在應用Debug調試時非常實用,同時還可以離線使用.但問題是這就足夠了嗎?

我曾在Windows phone應用開發[15]-輔助工具一文提到了WP平臺關于沙箱本地查看工具-IsostoreSpy


IsostoreSpy
</div>

IsostoreSpy能夠做到：

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

B:直接查看文本、圖片、語音等文件內容不需要額外打開.

C:直接調試真機上傳、下載、刪除沙箱中任何文件資源.

D:直接卸載&安裝應用程序.

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

3.Unused

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


Unused運行廢棄圖片資源結果
</div>

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

4.ImageOptim

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


壓縮比例對比結果
</div>

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

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


JPEGOptim設置
</div>

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


PNGOut設置
</div>

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

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

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

</div> 來自：http://www.jianshu.com/p/0d972f45da86

 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

相關經驗

相關資訊

相關文檔