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中

-(void)beginLogPageView
{
    [MobClick beginLogPageView:NSStringFromClass([self class])];
}

-(void)endLogPageView;
{
    [MobClick endLogPageView:NSStringFromClass([self class])];
}

    在子頁面中調用統計就比較簡單了

-(void)viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    //添加頁面統計
    [self beginLogPageView];
}

-(void)viewWillDisappear:(BOOL)animated{
    [super viewWillDisappear:animated];
    //結束頁面統計
    [self endLogPageView];
}

    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，因此

#if DEBUG    
#warning NSLogs will be shown
#else
#define NSLog(...) {}
#endif

應該就是判斷這個值     在以前的JavaWeb項目中，咱們會使用Maven進行項目管理，在Maven的pom.xml能夠添加profiles,配置不一樣的版本，好比開發版，測試版，生產版，不一樣版本下有不一樣的配置文件，好比數據庫鏈接，log配置等,打包編譯項目時能夠經過Maven選擇不一樣的版本。這樣的好處是切換版本的時候，不用修改相關帶代碼，避免出現沒必要要的錯誤。

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

   另外補充一下，在C/C++中重複引用頭文件會出錯，因此頭文件引用的時候可使用下面方法，自定義頭文件的引用名，xcode生成頭文件的時候也會默認加上這個

#ifndef xxxx
#define xxxx
#endif

因此就會引發一個疑問，本身平時在程序中若是不是這樣引用頭文件，是否會引發衝突，網上搜索給出答案。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 技術團隊博客，雖然裏面就幾篇博文，但都比較有用，並且是屬於進階提高型的