自從iOS退出依賴，png就被用來制作圖標。這已經是如此簡單了，那為什麼還會有人會要考慮其他的解決方案呢？ 一般的制作圖標的工作流程是這樣的：“我想要新添加一個按鈕，這個action需要一個圖標，設計師把圖標發email給我，我們就完工了.” 如此設計師把這項工作安排到了他的工作流之中，然後按部就班完成了這項工作，之後你就會受到一封Email，裡面有2個png文件(retina 和 非 retina 屏幕)
等等... 這個圖標需在改改顏色，以滿足我們想要按鈕呈現高亮狀態的需求. 因此你重復了上述流程，並獲得了另外2個png。實際上，我們還會繼續需要讓這個按鈕在某些特定的情況下呈現禁用狀態，因此我們又會需要禁用狀態的圖標. 好吧，iOS現在又支持@3x分辨率的了, 因此我會需要再輸出這些圖標及其各種狀態的文件… 而設計師現在很忙，短時間內不能為我完成這項工作了?! 如今不能獲得這些資源文件的我如何讓我的應用適配新的屏幕尺寸呢?
任何曾今為那些以開發移動應用為目標的團隊工作過的人，好像大都遇到過上述其中一個或者全部的狀況. 它可能會是非常令人沮喪的，也會讓你的團隊白白浪費許多時間. 在Craftsy這裡，我們向後退一步，看看我們嘗試真正要去完成的是什麼，還要看看我們是否錯失了另外一種可能的更好的方法. 而當我說後退一步的時候，我的意思是做一次大的退步.
目標：在屏幕上繪制一個圖標，使其像素完美的適配那個屏幕的分辨率.
在最基本的層面上，這個目標就是我們現在正在做的. 然後問題就會是，我們是否使用了最有效率和更加務實的方式完成了這個目標? 讓我們來看看我們的選擇。我們可以繼續去構建並維護一個相當簡單的圖像庫，並讓從開發和設計兩頭都承擔保持圖像庫更新的工作量. 或者我們還可以采用一種動態的方式，只去踏踏實實的處理絕對必要的變化和工作，並將時間專注的花在其它問題的解決上.
進入PaintCode, 它是一個 OSX 應用程序，其名字正如你所預想的其功能. 它能解析從PhotoShop創建或導入的矢量圖片資源，然後將其”繪制“成一個編碼庫. 我不會花太多時間向你推銷 PaintCode, 我會建議你上網試試他們的在線解決方案. 不過未來在完成移除我們對於圖像的依賴這項任務方面，會證明使用它是必要的。看待PaintCode及其價格的一個好的方式就是，就好像它是為你的團隊雇傭的一個開發者. 你要問你自己的是 “你會需要雇傭一個開發者，它可以編寫完美的可控代碼，卻只需要開發應用成本負擔一次性的花費?” 好了，那就是我所想的.
設計師們其實擁有的大量的誘人數據，這些數據都隱藏域他們的photoshop文件之中。這些數據被稱作矢量圖形. 為什麼矢量圖形很重要呢 ? 簡單來講， iOS的世界裡現在正面臨的，與分辨率和不同狀態效果有關問題，在設計界早就都解決了. 當設計團隊創建一個圖標的時候，他們很可能會采用一種基於矢量圖形的，使用了線條和貝賽爾曲線的方法. 這就能很好的解決創建“分辨率獨立 ”的問題. 那樣如果我們需要適配屏幕尺寸為1000dpi的圖標，或者只是20dpi的縮略圖，它都可輸出來，而且看上去都是像素完美的!
那麼我們就要問了，如果開發者可以簡單的勝任這種現有的技術，會怎麼樣呢? 那就會使得我們不用再去過多考慮像素問題了. 雖然這常常成為一種可行的方式, 但和只是持續的繪制和輸出圖形比起來，使用編程的方式用代碼繪制矢量圖形需要花費更多的時間，直到 PaintCode 出現才讓收益大過支出. 並且，大多數的程序員們都沒有進行細節設計的好眼力，所以最終的成果大有可能不會符合預期. 因此，設計團隊的存在其實可以促進 PaintCode Objective-C 文件的輸出.
而通過管理起開發者和設計師間的所有這些代碼，PaintCode一舉消除了所有這些問題 ! 設計師只要將他的矢量圖形從Photoshop導入PaintCode中，做一些小維護以方便同開發者的對接, 瞧, 開發人員現在可以繪制符合任何分辨率需求的圖形資源了.
這一功能開始改變了設計師和開發者之間的溝通方式. 標准一旦建立起來，交談的內容立刻從 “你能把資源發Email給我嗎 ?” 變成了 “讓我知道你什麼時候把那個圖標遷入了git ”. 有時候甚至都不要交流；設計師調整完圖標之後，應用程序就會幫他把新的版本繪制出來.
更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2014-10/108429p2.htm