2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

##遇到問題和解決方案

? ? 本文是Java轉(zhuǎn)iOS-第一個(gè)項(xiàng)目總結(jié)(1)的內(nèi)容補(bǔ)充，分析遇到的一些問題和解決方案，分享一些收獲。

###1.UITableView滑動(dòng)卡頓的優(yōu)化

? ?因?yàn)?UITableView的cell中有很多圖片，在4/4s上滑動(dòng)比較卡，最開始覺得是機(jī)器太老了，但是對(duì)比微信和QQ空間，發(fā)現(xiàn)還是我們的問題，所以后期進(jìn)行了優(yōu)化，通過xcode的性能監(jiān)控，內(nèi)存變化不大，但是cpu飆升的倆厲害，通過xcode的Time Profiler工具進(jìn)行了監(jiān)控（Product—Profile—Time Profiler），找到了執(zhí)行比較慢的方法，原因是轉(zhuǎn)換圖片路徑的時(shí)候，調(diào)用自己的方法進(jìn)行了log打印，造成滑動(dòng)卡頓。

? ? 網(wǎng)上關(guān)于UITableView的性能優(yōu)化的文章有很多，官方給了一個(gè)例子LazyTableImages介紹懶加載UITableview的Image，在滑動(dòng)的時(shí)候，不加載圖片，停止滑動(dòng)時(shí)再加載圖片，并把UIImage放在對(duì)象中，判斷對(duì)象中圖片不會(huì)空則顯示圖片，否則還是占位圖。例子中圖片都是app的icon，都是小圖，所以那樣做也沒問題。但是我們項(xiàng)目中的圖片都是大圖片，如果把圖片放在對(duì)象中，顯然不合適，所以當(dāng)時(shí)pass了這個(gè)方案。

? ? 前幾天在Glow 技術(shù)團(tuán)隊(duì)博客看到了UIScrollView 實(shí)踐經(jīng)驗(yàn) 這篇博客，里面講到了相同的技術(shù)，優(yōu)化了滑動(dòng)減速過程中也進(jìn)行圖片加載，另外用到了SDWebImage，里面判斷SDWebImage是否緩存過圖片，如果緩存過，從本地加載圖片，否則使用占位圖，應(yīng)該是比較好的解決方案了

###2.右滑手勢(shì)返回 ? ? iOS7自帶了這個(gè)功能，后來設(shè)計(jì)人員提出了優(yōu)化建議，但我們的程序卻不能支持這個(gè)功能，原因程序返回操作的方法包含其它業(yè)務(wù)邏輯，比如返回后刷新上一頁面的數(shù)據(jù)，返回后是否顯示底部菜單。而系統(tǒng)的默認(rèn)的右滑返回，只是做了頁面返回，并不會(huì)觸發(fā)自己的返回方法。

? ? 所以為了這個(gè)功能還是代碼進(jìn)行了修改，更新上級(jí)頁面的操作放在本頁面數(shù)據(jù)刷新的地方。底部菜單只在首頁的幾個(gè)頁面顯示隱藏，其它去掉相關(guān)業(yè)務(wù)邏輯。因?yàn)楦倪@個(gè)地方還和測(cè)試起了沖突，因?yàn)轫?xiàng)目臨近收尾，修改可能會(huì)帶來問題，優(yōu)化的功能可以放在后期。但是作為開發(fā)人員還是進(jìn)行了修改，加班進(jìn)行了測(cè)試。表面上看這是個(gè)優(yōu)化，其實(shí)卻是問題暴漏。如果有新需求的可以不做，但是有問題卻應(yīng)該盡早解決。

? ? 另外這個(gè)地方做個(gè)內(nèi)容補(bǔ)充，頁面之間的逆向數(shù)據(jù)傳遞，可以用回調(diào)（block）,委托（delegate）和通知（notifacation），需要熟練掌握這幾個(gè)知識(shí)點(diǎn)以及實(shí)現(xiàn)方法，區(qū)分之間的差別。

###3.添加頁面統(tǒng)計(jì) ? ? 友盟統(tǒng)計(jì)還是比較強(qiáng)大的，雖然項(xiàng)目沒有要求加相關(guān)功能，但是還是加了相關(guān)統(tǒng)計(jì)，需要在對(duì)應(yīng)ViewController中的viewWillAppear和viewWillDisappear中加入一行代碼，傳入當(dāng)前頁面的名字，最開始只加了幾個(gè)頁面，所以代碼是寫死的。全部頁面要加統(tǒng)計(jì),需要對(duì)代碼進(jìn)行了改進(jìn)，封裝在自己BaseViewController中

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

? ? 在子頁面中調(diào)用統(tǒng)計(jì)就比較簡(jiǎn)單了

-(void)viewWillAppear:(BOOL)animated{[super viewWillAppear:animated];//添加頁面統(tǒng)計(jì)[self beginLogPageView]; }-(void)viewWillDisappear:(BOOL)animated{[super viewWillDisappear:animated];//結(jié)束頁面統(tǒng)計(jì)[self endLogPageView]; }

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

###4.debug版和release版

? ? 之前自己對(duì)于debug版和release版沒有太多概念，只是知道平時(shí)開發(fā)的時(shí)候是debug版，當(dāng)要發(fā)布的時(shí)候改成release版，看到一些宏定義，根據(jù)不同版本設(shè)置不同的宏，比如debug版的時(shí)候，NSLog可以輸出，release的時(shí)候不輸出。

? ? 前段時(shí)間，看到一篇Xcode宏定義選項(xiàng)以及Release版去NSLog的文章時(shí)，就想明白了，在xcode中可以設(shè)置宏，debug下有個(gè)默認(rèn)設(shè)置 debug=1，所以

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

應(yīng)該就是判斷這個(gè)值 ? ? 在之前的JavaWeb項(xiàng)目中，我們會(huì)使用Maven進(jìn)行項(xiàng)目管理，在Maven的pom.xml可以添加profiles,配置不同的版本，比如開發(fā)版，測(cè)試版，生產(chǎn)版，不同版本下有不同的配置文件，比如數(shù)據(jù)庫連接，log配置等,打包編譯項(xiàng)目時(shí)可以通過Maven選擇不同的版本。這樣的好處是切換版本的時(shí)候，不用修改相關(guān)帶代碼，避免出現(xiàn)不必要的錯(cuò)誤。

? ? 轉(zhuǎn)iOS后一直在找相關(guān)的解決方案，后來才意識(shí)到這個(gè)就可以做到，只不過蘋果里面只有debug版和release版，沒辦法自定義新的版本（或者是我還沒找到，請(qǐng)大神賜教），但是也可以進(jìn)行相關(guān)配置，保證release版的配置都是正確的

? ?另外補(bǔ)充一下，在C/C++中重復(fù)引用頭文件會(huì)出錯(cuò)，所以頭文件引用的時(shí)候可以使用下面方法，自定義頭文件的引用名，xcode生成頭文件的時(shí)候也會(huì)默認(rèn)加上這個(gè)

#ifndef xxxx #define xxxx #endif

所以就會(huì)引起一個(gè)疑問，自己平時(shí)在程序中如果不是這樣引用頭文件，是否會(huì)引起沖突，網(wǎng)上搜索給出答案。oc中不推薦#include引用頭文件，推薦使用#import就是可以解決這個(gè)問題的。

###5.關(guān)于頁面刷新 ? ? 一個(gè)頁面，可能包括下拉刷新，上拉加載更多，翻頁到最后時(shí)隱藏刷新，沒網(wǎng)下從緩存中加載數(shù)據(jù)等多種情況，所以頁面刷新的功能最好提前考慮到，否則這些功能在后期修改時(shí)會(huì)變得很麻煩，一不小心就容易出問題。比如翻頁到最后隱藏加載更多，然后下拉刷新的時(shí)候，可能需要把隱藏的控件給顯示出來。所以代碼要考慮好，設(shè)計(jì)好，封裝好。

###6.關(guān)于頁面布局 ? ? 現(xiàn)在的iOS教程，大部分講得都是故事板，但是在實(shí)際項(xiàng)目中，更多的還是用代碼。 唐巧的博客StoryBoard--看上去很美 中說明了原因，公司項(xiàng)目多是協(xié)同開發(fā)，一旦兩個(gè)人同時(shí)修改了故事板，基本上都會(huì)產(chǎn)生沖突，解決起來會(huì)非常麻煩，所以作為新手還是應(yīng)該多學(xué)習(xí)純代碼開發(fā)。之前項(xiàng)目使用的就是代碼寫UI，獲得屏幕寬高，在不同控件之間算坐標(biāo)，如果代碼不規(guī)范,控件的坐標(biāo)和寬高是獨(dú)立的，如果一個(gè)控件發(fā)生變化，就會(huì)產(chǎn)生雪崩。

? ? 這里推薦Masonry，也是github上非常有名的一個(gè)iOS組件，解決了自動(dòng)布局寫約束麻煩且繁瑣的缺點(diǎn)，比較容易學(xué)習(xí)和令人接受。iOS還有個(gè)VFL語言，相比還是Masonry感覺更好。

? ? 這里再推薦一個(gè)iOS組件，ReactiveCocoa，是一個(gè)kvo組件，用來做消息監(jiān)聽，效果就是可以像Java寫事件監(jiān)聽一樣寫OC代碼 。之前給一個(gè)UIButton綁定事件，需要調(diào)用addTarget綁定，然后再寫一個(gè)方法，或者監(jiān)聽UITextFiled的變化，都要寫很多委托方法。使用ReactiveCocoa后，寫法就大變了，代碼看起來會(huì)整潔很多，而且顯得比較高大上一點(diǎn)。

? ? 現(xiàn)在新的項(xiàng)目中，添加使用了上面兩個(gè)組件。

###7.推薦博客 唐巧的技術(shù)博客，最早因?yàn)椴恢捞魄杀煌卤梢暳讼?#xff0c;從他的博客中可以看到iOS的變化，作者也是從Java轉(zhuǎn)的iOS，博客也是通俗易懂，現(xiàn)在博主自己創(chuàng)業(yè)雖然不寫博客了，但是會(huì)發(fā)周報(bào)分享比較好博文和開源項(xiàng)目

Glow 技術(shù)團(tuán)隊(duì)博客，雖然里面就幾篇博文，但都比較有用，而且是屬于進(jìn)階提升型的

轉(zhuǎn)載于:https://my.oschina.net/lujianing/blog/404080

總結(jié)

以上是生活随笔為你收集整理的Java转iOS-第一个项目总结(2)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。