iOS生產力之小工具合集

發表於2015-03-11
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開發小工具和使用的奇淫技巧。不妨在評論提到。最後擴充閱讀有對應工具下載地址和使用，各取所需。

擴充套件閱讀

相關文章