Java轉iOS：第一個專案總結(2)

遇到問題和解決方案

本文是Java轉iOS-第一個專案總結(1)的內容補充，分析遇到的一些問題和解決方案，分享一些收穫。

1.UITableView滑動卡頓的優化

因為 UITableView的cell中有很多圖片，在4/4s上滑動比較卡，最開始覺得是機器太老了，但是對比微信和QQ空間，發現還是我們的問題，所以後期進行了優化，通過xcode的效能監控，記憶體變化不大，但是cpu飆升的倆厲害，通過xcode的Time Profiler工具進行了監控（Product—Profile—Time Profiler），找到了執行比較慢的方法，原因是轉換圖片路徑的時候，呼叫自己的方法進行了log列印，造成滑動卡頓。

網上關於UITableView的效能優化的文章有很多，官方給了一個例子LazyTableImages介紹懶載入UITableview的Image，在滑動的時候，不載入圖片，停止滑動時再載入圖片，並把UIImage放在物件中，判斷物件中圖片不會空則顯示圖片，否則還是佔點陣圖。例子中圖片都是app的icon，都是小圖，所以那樣做也沒問題。但是我們專案中的圖片都是大圖片，如果把圖片放在物件中，顯然不合適，所以當時pass了這個方案。

前幾天在Glow 技術團隊部落格看到了UIScrollView 實踐經驗
這篇部落格，裡面講到了相同的技術，優化了滑動減速過程中也進行圖片載入，另外用到了SDWebImage，裡面判斷SDWebImage是否快取過圖片，如果快取過，從本地載入圖片，否則使用佔點陣圖，應該是比較好的解決方案了

2.右滑手勢返回

iOS7自帶了這個功能，後來設計人員提出了優化建議，但我們的程式卻不能支援這個功能，原因程式返回操作的方法包含其它業務邏輯，比如返回後重新整理上一頁面的資料，返回後是否顯示底部選單。而系統的預設的右滑返回，只是做了頁面返回，並不會觸發自己的返回方法。

所以為了這個功能還是程式碼進行了修改，更新上級頁面的操作放在本頁面資料重新整理的地方。底部選單隻在首頁的幾個頁面顯示隱藏，其它去掉相關業務邏輯。因為改這個地方還和測試起了衝突，因為專案臨近收尾，修改可能會帶來問題，優化的功能可以放在後期。但是作為開發人員還是進行了修改，加班進行了測試。表面上看這是個優化，其實卻是問題暴漏。如果有新需求的可以不做，但是有問題卻應該儘早解決。

另外這個地方做個內容補充，頁面之間的逆向資料傳遞，可以用回撥（block）,委託（delegate）和通知（notifacation），需要熟練掌握這幾個知識點以及實現方法，區分之間的差別。

3.新增頁面統計

友盟統計還是比較強大的，雖然專案沒有要求加相關功能，但是還是加了相關統計，需要在對應ViewController中的viewWillAppear和viewWillDisappear中加入一行程式碼，傳入當前頁面的名字，最開始只加了幾個頁面，所以程式碼是寫死的。全部頁面要加統計,需要對程式碼進行了改進，封裝在自己BaseViewController中

在子頁面中呼叫統計就比較簡單了

Method Swizzling和 AOP實踐裡面提供了更高大上的解決方案，順便可以學習OC的runtime。
在Java領域中，Spring框架以IOC和AOP著稱，所以語言和涉及裡面都是想通的。雖然作為io是新手，但是我是懂AOP的^_。

4.debug版和release版

之前自己對於debug版和release版沒有太多概念，只是知道平時開發的時候是debug版，當要釋出的時候改成release版，看到一些巨集定義，根據不同版本設定不同的巨集，比如debug版的時候，NSLog可以輸出，release的時候不輸出。

前段時間，看到一篇Xcode巨集定義選項以及Release版去NSLog的文章時，就想明白了，在xcode中可以設定巨集，debug下有個預設設定 debug=1，所以

應該就是判斷這個值
在之前的JavaWeb專案中，我們會使用Maven進行專案管理，在Maven的pom.xml可以新增profiles,配置不同的版本，比如開發版，測試版，生產版，不同版本下有不同的配置檔案，比如資料庫連線，log配置等,打包編譯專案時可以通過Maven選擇不同的版本。這樣的好處是切換版本的時候，不用修改相關帶程式碼，避免出現不必要的錯誤。

轉iOS後一直在找相關的解決方案，後來才意識到這個就可以做到，只不過蘋果裡面只有debug版和release版，沒辦法自定義新的版本（或者是我還沒找到，請大神賜教），但是也可以進行相關配置，保證release版的配置都是正確的

另外補充一下，在C/C++中重複引用標頭檔案會出錯，所以標頭檔案引用的時候可以使用下面方法，自定義標頭檔案的引用名，xcode生成標頭檔案的時候也會預設加上這個

所以就會引起一個疑問，自己平時在程式中如果不是這樣引用標頭檔案，是否會引起衝突，網上搜尋給出答案。oc中不推薦#include引用標頭檔案，推薦使用#import就是可以解決這個問題的。

5.關於頁面重新整理

一個頁面，可能包括下拉重新整理，上拉載入更多，翻頁到最後時隱藏重新整理，沒網下從快取中載入資料等多種情況，所以頁面重新整理的功能最好提前考慮到，否則這些功能在後期修改時會變得很麻煩，一不小心就容易出問題。比如翻頁到最後隱藏載入更多，然後下拉重新整理的時候，可能需要把隱藏的控制元件給顯示出來。所以程式碼要考慮好，設計好，封裝好。

6.關於頁面佈局

現在的iOS教程，大部分講得都是故事板，但是在實際專案中，更多的還是用程式碼。
唐巧的部落格StoryBoard–看上去很美
中說明了原因，公司專案多是協同開發，一旦兩個人同時修改了故事板，基本上都會產生衝突，解決起來會非常麻煩，所以作為新手還是應該多學習純程式碼開發。之前專案使用的就是程式碼寫UI，獲得螢幕寬高，在不同控制元件之間算座標，如果程式碼不規範,控制元件的座標和寬高是獨立的，如果一個控制元件發生變化，就會產生雪崩。

這裡推薦Masonry，也是github上非常有名的一個iOS元件，解決了自動佈局寫約束麻煩且繁瑣的缺點，比較容易學習和令人接受。iOS還有個VFL語言，相比還是Masonry感覺更好。

這裡再推薦一個iOS元件，ReactiveCocoa，是一個kvo元件，用來做訊息監聽，效果就是可以像Java寫事件監聽一樣寫OC程式碼 。之前給一個UIButton繫結事件，需要呼叫addTarget繫結，然後再寫一個方法，或者監聽UITextFiled的變化，都要寫很多委託方法。使用ReactiveCocoa後，寫法就大變了，程式碼看起來會整潔很多，而且顯得比較高大上一點。

現在新的專案中，新增使用了上面兩個元件。

7.推薦部落格

唐巧的技術部落格，最早因為不知道唐巧被同事鄙視了下，從他的部落格中可以看到iOS的變化，作者也是從Java轉的iOS，部落格也是通俗易懂，現在博主自己創業雖然不寫部落格了，但是會發週報分享比較好博文和開源專案

Glow 技術團隊部落格，雖然裡面就幾篇博文，但都比較有用，而且是屬於進階提升型的