專案已經開發超過一年半，累積的檔案數量已將近2500個（可見文章：專案檔案數遞增），想必日後編譯速度將會越來越慢，會深刻地影響我們開發的效率，尤其是在要了解前人所寫的程式碼，我們總是會稍微修改一下變數/參數來嘗試是否為增修的關鍵目標，所編譯頻率相當大，三不五時就要按Command+R。
我嘗試過許多改善開發效率的方法，其中有三個可以嘗試：
1和3在我們的專案早已設定完畢，只剩下2可以嘗試，沒想到效果超好，提升幾乎10倍快的編譯速度！
已經好久（約三年）沒使用Window OS來做事情，都快忘記Windows工作管理員 (Windows Process management)這玩意兒，其實在Mac OS也有類似的軟體活動監視器 (Activity Monitor)，最近我第一次開啟它ＸＤ～因為看到網路上有人分享Macbook Air換電池心得，結果只要注意有沒有耗能的軟體一直在執行，將它從記憶體中移除就能舒緩耗能的現象。
平常我工作多是使用Xcode來寫iOS App，照理說最會使用到CPU的角色就是它！
iOS已經寫好的方法，通常我們只要會使用就好，至於實作內容我們就姑且當作沒看到⋯⋯不過在一些情況下，我們很注重效能、效果、效率，原本微不足道的差異或錯誤，將造成「失之毫釐差以千里」的結果。我們就來試驗一下載入來源不同的影像吧～
拿它來作實驗！
很多時候在APP顯示的影像是來自網路，這時候我們會想到，若沒有網路時還想顯示影像該怎麼辦？解決方法當然就是在有網路的時候，把目標影像給儲存到手機端，下次顯示時直接取用。
然而此時出現另一個問題，就是從手機端顯示影像，居然會讓體驗變得頓頓的卡卡的，感覺十分不舒服⋯⋯解決辦法就是把影像快取起來，下次顯示時直接拿來用。
之所以頓頓卡卡是因為讀取自「硬碟」，網路下載會先儲存在「記憶體」，前者是在主程序讀取影像，因來源是硬碟，所以不僅耗時較久，連帶又會卡UI；後者在非主程序下載，當下載完才會切換到主程序顯示，來源又是在記憶體，讀取速度較快，因此就不會卡卡頓頓的。
於是我們就發展出三層級顯示影像 (Three-Level Display Image)，也就是從網路（伺服器）下載影像到手機端（硬碟），再將影像快取（記憶體）起來顯示！
上一篇影像快取 (Image Cache)我的用法是，從網路下載影像，接著快取起來顯示，跳過儲存到手機端這個步驟，在此我用簡單的if-else說明如何實作！
時常需要從網路上抓取影像載入APP裡頭，尤其是在TableView的cell頻繁消失又出現的狀況，會不停地重複同樣（下載與顯示）的動作，這樣子做不是不行，然而使用者體驗會有點差，儘管已經用多執行緒去抓圖和載圖，操作上還算相當順暢，然而使用者還是會看到影像怎麼這時候消失變出現，接著又滾回去又從消失變出現，使用者體驗實在相當糟糕⋯⋯
於是想當然爾，我們會想要把已經載入的圖給暫存起來，下次要顯示時直接抓暫存在記憶體中的影像快取 (Image Cache)即可！
（繼續閱讀…）
相片的應用真的非常之廣，使用WSAssetPicker來多選相片，除了要注意記憶體不能爆掉之外，存取速度也是我們所在意的因素，Asset所提供的特性可以讓我們輕易取得四種不同的影像解析度，就看用途為何來決定。
一般而言，寫程式的時候想要debug，通常會「把訊息印出」，在iOS上會用NSLog這個方法，或是在Xcode上「設定中斷點」。在開發的時候會不斷地用NSLog，一旦要釋出時就要把NSLog給刪掉，這是資深工程師的經驗建議，因為太多的印出資料不但會影響效能，還有很大的機率會讓程式當掉。
我用搜尋功能，一下子就找出非常多個NSLog～
對演算法感興趣的我，一直想知道自己寫的程式的效能如何，所以這一次特別來瞭解演算法執行時間 (Algorithm Time of Execution)。同一流程可以由不同的演算法來達到同一效果，可是在效能方面或多或少就有差別了～
12/14-16遠從台灣到香港的迪士尼，早上逛完整個園區，晚上就坐下來欣賞美麗的煙火～來到這如幻似夢的卡通世界，伴隨著魂牽夢縈的旋律，整顆心在晚上亮了起來！
HappyMan・迴響