|
本文是Java轉iOS-第一個項目總結(1)的內容補充，分析遇到的一些問題和解決方案，分享一些收獲。 1.UITableView滑動卡頓的優(yōu)化 因為 `UITableView`的cell中有很多圖片，在4/4s上滑動比較卡，最開始覺得是機器太老了，但是對比微信和QQ空間，發(fā)現(xiàn)還是我們的問題，所以后期進行了優(yōu)化，通過xcode的性能監(jiān)控，內存變化不大，但是cpu飆升的倆厲害，通過xcode的Time Profiler工具進行了監(jiān)控（Product—Profile—Time Profiler），找到了執(zhí)行比較慢的方法，原因是轉換圖片路徑的時候，調用自己的方法進行了log打印，造成滑動卡頓。 網上關于UITableView的性能優(yōu)化的文章有很多，官方給了一個例子LazyTableImages介紹懶加載UITableview的Image，在滑動的時候，不加載圖片，停止滑動時再加載圖片，并把UIImage放在對象中，判斷對象中圖片不會空則顯示圖片，否則還是占位圖。例子中圖片都是app的icon，都是小圖，所以那樣做也沒問題。但是我們項目中的圖片都是大圖片，如果把圖片放在對象中，顯然不合適，所以當時pass了這個方案。 前幾天在Glow 技術團隊博客看到了UIScrollView 實踐經驗 這篇博客，里面講到了相同的技術，優(yōu)化了滑動減速過程中也進行圖片加載，另外用到了SDWebImage，里面判斷SDWebImage是否緩存過圖片，如果緩存過，從本地加載圖片，否則使用占位圖，應該是比較好的解決方案了 2.右滑手勢返回 iOS7自帶了這個功能，后來設計人員提出了優(yōu)化建議，但我們的程序卻不能支持這個功能，原因程序返回操作的方法包含其它業(yè)務邏輯，比如返回后刷新上一頁面的數(shù)據，返回后是否顯示底部菜單。而系統(tǒng)的默認的右滑返回，只是做了頁面返回，并不會觸發(fā)自己的返回方法。 所以為了這個功能還是代碼進行了修改，更新上級頁面的操作放在本頁面數(shù)據刷新的地方。底部菜單只在首頁的幾個頁面顯示隱藏，其它去掉相關業(yè)務邏輯。因為改這個地方還和測試起了沖突，因為項目臨近收尾，修改可能會帶來問題，優(yōu)化的功能可以放在后期。但是作為開發(fā)人員還是進行了修改，加班進行了測試。表面上看這是個優(yōu)化，其實卻是問題暴漏。如果有新需求的可以不做，但是有問題卻應該盡早解決。 另外這個地方做個內容補充，頁面之間的逆向數(shù)據傳遞，可以用回調（block）、委托（delegate）和通知（notifacation），需要熟練掌握這幾個知識點以及實現(xiàn)方法，區(qū)分之間的差別。 3.添加頁面統(tǒng)計 友盟統(tǒng)計還是比較強大的，雖然項目沒有要求加相關功能，但是還是加了相關統(tǒng)計，需要在對應ViewController中的viewWillAppear和viewWillDisappear中加入一行代碼，傳入當前頁面的名字，最開始只加了幾個頁面，所以代碼是寫死的。全部頁面要加統(tǒng)計,需要對代碼進行了改進，封裝在自己BaseViewController中
在子頁面中調用統(tǒng)計就比較簡單了
Method Swizzling和 AOP實踐里面提供了更高大上的解決方案，順便可以學習OC的runtime。 在Java領域中，Spring框架以IOC和AOP著稱，所以語言和涉及里面都是想通的。雖然作為io是新手，但是我是懂AOP的_。 4.debug版和release版 之前自己對于debug版和release版沒有太多概念，只是知道平時開發(fā)的時候是debug版，當要發(fā)布的時候改成release版，看到一些宏定義，根據不同版本設置不同的宏，比如debug版的時候，NSLog可以輸出，release的時候不輸出。 前段時間，看到一篇Xcode宏定義選項以及Release版去NSLog的文章時，就想明白了，在xcode中可以設置宏，debug下有個默認設置 debug=1，所以
應該就是判斷這個值 在之前的JavaWeb項目中，我們會使用Maven進行項目管理，在Maven的pom.xml可以添加profiles,配置不同的版本，比如開發(fā)版，測試版，生產版，不同版本下有不同的配置文件，比如數(shù)據庫連接，log配置等,打包編譯項目時可以通過Maven選擇不同的版本。這樣的好處是切換版本的時候，不用修改相關帶代碼，避免出現(xiàn)不必要的錯誤。 轉iOS后一直在找相關的解決方案，后來才意識到這個就可以做到，只不過蘋果里面只有debug版和release版，沒辦法自定義新的版本（或者是我還沒找到，請大神賜教），但是也可以進行相關配置，保證release版的配置都是正確的 另外補充一下，在C/C 中重復引用頭文件會出錯，所以頭文件引用的時候可以使用下面方法，自定義頭文件的引用名，xcode生成頭文件的時候也會默認加上這個
所以就會引起一個疑問，自己平時在程序中如果不是這樣引用頭文件，是否會引起沖突，網上搜索給出答案。oc中不推薦#include引用頭文件，推薦使用#import就是可以解決這個問題的。 5.關于頁面刷新 一個頁面，可能包括下拉刷新，上拉加載更多，翻頁到最后時隱藏刷新，沒網下從緩存中加載數(shù)據等多種情況，所以頁面刷新的功能最好提前考慮到，否則這些功能在后期修改時會變得很麻煩，一不小心就容易出問題。比如翻頁到最后隱藏加載更多，然后下拉刷新的時候，可能需要把隱藏的控件給顯示出來。所以代碼要考慮好，設計好，封裝好。 6.關于頁面布局 現(xiàn)在的iOS教程，大部分講得都是故事板，但是在實際項目中，更多的還是用代碼。 唐巧的博客StoryBoard–看上去很美中說明了原因，公司項目多是協(xié)同開發(fā)，一旦兩個人同時修改了故事板，基本上都會產生沖突，解決起來會非常麻煩，所以作為新手還是應該多學習純代碼開發(fā)。之前項目使用的就是代碼寫UI，獲得屏幕寬高，在不同控件之間算坐標，如果代碼不規(guī)范,控件的坐標和寬高是獨立的，如果一個控件發(fā)生變化，就會產生雪崩。 這里推薦Masonry，也是github上非常有名的一個iOS組件，解決了自動布局寫約束麻煩且繁瑣的缺點，比較容易學習和令人接受。iOS還有個VFL語言，相比還是Masonry感覺更好。 這里再推薦一個iOS組件--ReactiveCocoa，是一個kvo組件，用來做消息監(jiān)聽，效果就是可以像Java寫事件監(jiān)聽一樣寫OC代碼 。之前給一個UIButton綁定事件，需要調用addTarget綁定，然后再寫一個方法，或者監(jiān)聽UITextFiled的變化，都要寫很多委托方法。使用ReactiveCocoa后，寫法就大變了，代碼看起來會整潔很多，而且顯得比較高大上一點。 現(xiàn)在新的項目中，添加使用了上面兩個組件。 7.推薦博客 唐巧的技術博客，最早因為不知道唐巧被同事鄙視了下，從他的博客中可以看到iOS的變化，作者也是從Java轉的iOS，博客也是通俗易懂，現(xiàn)在博主自己創(chuàng)業(yè)雖然不寫博客了，但是會發(fā)周報分享比較好博文和開源項目。 Glow 技術團隊博客，雖然里面就幾篇博文，但都比較有用，而且是屬于進階提升型的。 來自：蛙牛的博客 |
|
|
來自： 昵稱20917807 > 《待分類》
