提綱:
1. 關於xib/storyboard 與 純代碼的對比
2. 一條規範(又提了一點關於命名的)
3. UI工廠類 與 代碼塊
4. 懶加載, View使用strong還是weak
5. 複雜界面要會分區,要會障眼法
6. masonry均布View,及其佈局時約束依賴關係
7. 關於屏幕適配的一點技巧
1. 關於xib/storyboard 與 純代碼的對比
a. xib快,純代碼慢,但是在純代碼熟練的情況下, 並不會慢很多
b. xib不易於修改,怎麼修改,就是今天讓一個View上的元素這麼排布,明天就要換種排布方式,後天又要加些東西。。。
c. xib不靈活,什麼叫靈活,一個View上有10個元素, 其中5個都是不一定出現的,並且它們不是集中的佈局在哪個位置, 亂七八糟的,多一個少一個佈局還都有點影響,這就知道靈活的重要性了
d. xib不利於屏幕適配,怎麼適配,5s上一個View距左10像素,產品說6p上就要距左20才協調,xib上拖線佈局怎麼搞,約束拖出來改變它嗎,複雜View有10個需要這樣處理的地方呢。。。
e. xib寫多了純代碼手生,當然純代碼寫多了,拖線也有點不熟練,這個不作爲純代碼更好的原因。。。
f. 但是!面試的時候如果你說我xib用的多,純代碼佈局有點不熟練, 不好意思, 拜拜(本人經歷過),你說我都是純代碼佈局的, xib會,不熟,大多公司聽到以前都是純代碼,那沒問題,因爲他們公司也不用xib。。。
2. 一條規範(又提了一點關於命名的)
“ .h 和 .m 的類擴展裏面不要隨便加東西,尤其 .h 裏的東西一定要是必須放在這裏,放在別處不行,實在有不太重要還必須放在這的,打好註釋 ”
這個東西無數次在項目中見到過隨意在這加東西的做法, 剛寫完當時還好, 一個月以後再看, 瞬間懵逼。。。
這是什麼鬼。。。
當時爲啥要寫這個量。。。
這怎麼還有個沒用過的量。。。
這個東西要不要傳, 爲啥A類用的時候穿了, B類就不傳了。。。
再提一下另外一個規範, “名字不要隨便起,弄個坑爹名字,自己隔天都不知道啥意思,是跟公司結了仇了還是怕泄露天機”
爲什麼說這些命名不是特別不規範, 因爲這裏面雖然有些vBack啦, lbl啦, tbl啦, 不是那麼容易理解, 但是好歹是lbl,都用lbl了,不過爲啥非得把Label放前面,官方命名的時候比如btn.titleLabel,Label也是放在後面的啊, 也沒縮寫成什麼lbl,我們就簡簡單單的叫nickNameLabel不行嗎。。。
說到命名就再多說一點, 如果一個複雜View內部佈局的時候需要分割成幾部分,在能想出名字的情況下最好不要按位置命名,比如topView,midView之類,明天產品說把位置調一下,最下面的部分比較重要提到最上面,這怎麼辦, 儘量想一想這部分大概負責什麼,要表達個什麼意思
3. UI工廠類 與 代碼塊
UI工廠類: 其實代碼很簡單,就是把對Label, Button等控件的屬性賦值封裝一下, 做到一行代碼就能創建一個VIew, 如下圖, 雖然這一句代碼有點長, 但是習慣之後寫個View是真心快
代碼塊: 代碼塊就是下圖的東西, 應該沒人不知道,不會添加隔壁百度
這個東西不光是UI佈局用, 很多位置都比較方便, 我常用的有這樣幾個
尤其是純代碼masonry佈局, 這樣的代碼塊會讓你佈局的速度直逼甚至超越拖線, 只需要打出make就會出現已經定義好的各種約束, 比如要佈局高度, 打出makeh, 回車, 就直接進入填空模式,tab切換填空即可
4. 懶加載, View使用strong還是weak
爲什麼要用懶加載, 有一種說法是用到的時候在創建,節省內存開銷,這種說法固然沒問題,但是對於大部分UI來說,基本遲早都會被創建。
所以,主要優點不在這裏,本着<自己的事情自己做, 儘量不要影響他人>的做人原則,代碼也該這樣寫,你既然是個View,那你就把自己解決好再來見我, 我要用你的時候只需要self.testView就可以了,下面兩張圖對比一下就會看到區別了,第二張爲剛到公司時上一任的大作,這裏選取了一種比較看的清的貼出來
上圖注意:masonry的block沒有進行copy,即當前對象沒有引用這個block,是局部的引用,不會形成循環引用的,可以不用weakSelf
對比一下即可看出來, 由於上圖使用中的控件均使用懶加載, 所以佈局方法裏連addSubView都不用寫了, 只需逐條佈局即可, 下圖中創建控件, 屬性賦值, 添加到父視圖的代碼都混在一起, 並且還沒有使用masonry, 用上之後只會更亂。。。
View使用strong還是weak: 關於這個問題,其實還是有很多可以說一下的地方
懶加載寫法:
@interface ViewController ()
@property (nonatomic, weak) UIView *weakView;
@property (nonatomic, strong) UIView *strongView;
@end
@implementation ViewController
/**
UI控件使用弱引用創建方法
1. UIView *weakView = [[UIView alloc] init]; 這句必須聲明一個局部變量, 不能用_weakView,
因爲用 _weakView = [[UIView alloc] init], 等號右側創建了一個View之後,給了一個弱引用持有,相當於沒有持有,直接就釋放掉了
而 UIView *weakView = [[UIView alloc] init],等號左側的weakView默認是一個強引用,會暫時持有保住它,但是生命週期就在這個懶加載的大括號內,所有會有其他代碼配合, 使這個View存活下來, 不被釋放
2. _weakView = weakView; 這句代碼爲屬性賦值, 以後在其他位置不管通過self.weakView還是_weakView才能找到這個View,
基本作用可以說等同於強引用的 _strongView = [[UIView alloc] init];
3. [self.view addSubview:weakView], 第一條註釋中說了,UIView *weakView 的生命週期就是在這個{}內,那麼如何保證出了括號依舊存在,就是要給這個View加到一個不會被釋放的View(不一定強引用弱引用)上,即self.view, 這樣就不會被釋放掉了
*/
- (UIView *)weakView {
if (!_weakView) {
UIView *weakView = [[UIView alloc] init];
_weakView = weakView;
weakView.backgroundColor = [UIColor redColor];
[self.view addSubview:weakView];
}
return _weakView;
}
- (UIView *)strongView {
if (!_strongView) {
_strongView = [[UIView alloc] init];
_strongView.backgroundColor = [UIColor greenColor];
}
return _strongView;
}
佈局時區別:
- (void)configView {
WeakSelf(ws);
//弱引用由於懶加載直接加到父視圖上,所以點語法完了直接調用masonry佈局方法即可
[self.weakView mas_makeConstraints:^(MASConstraintMaker *make) {
make.centerX.equalTo(ws.view);
make.top.equalTo(ws.view).offset(100);
make.size.mas_equalTo(CGSizeMake(100, 100));
}];
[self.view addSubview:self.strongView];
[self.strongView mas_makeConstraints:^(MASConstraintMaker *make) {
make.centerX.equalTo(ws.view);
make.bottom.equalTo(ws.view).offset(-100);
make.size.mas_equalTo(CGSizeMake(100, 100));
}];
}
移除之後的區別(重點,涉及到理解強弱指針):執行上述代碼後,屏幕上出現一上一下兩個View, 點擊空白區域, 移除掉兩個View, 1秒後看一下,1秒後看是因爲, 出了這個方法, 也就是運行到結束的括號之後, 纔會把View移除掉, 注意看坐下控制檯兩個View,weakView爲nil, 即已被釋放, strongView還是存在, 因爲即使從父視圖上移除, self本身對其還有一個強引用, 不會釋放掉,那麼如果想把這個View釋放掉需要怎麼辦, 就是在[_strongView
removeFromSuperview]
後面加一句_strongView = nil;
下面圖解一下, 爲什麼不置空, strongView就不被釋放
總結起來的話, 其實如果理解到位,使用強弱都沒有問題,但是一般來說,由於弱引用會被及時的釋放掉,所以需求允許的話,一般建議使用弱引用,那什麼情況不能使用弱引用呢,這個要看具體需求,舉個例子,如果一個View,需要從父View移除掉,但是之後還有可能加回來,還要保持移除之前的樣子,這種情況強引用會更適合。
收集了一些意見:
- 懶加載不一定一定要, 這是完全沒問題的,有人習慣把創建View,屬性賦值,添加到父視圖的代碼寫在一起,認爲這樣便於管理,順着看更清晰,沒問題。
- 如果View層次複雜,用懶加載弱引用View的時候注意層級關係,如果理解不到位,容易產生問題,因爲addSubView寫在懶加載裏,極易造成層次不清晰,這時就要個人理解,用自己認爲最適合的方法了。
- 我爲什麼喜歡將UI寫成懶加載?aView就是aView,bLabel就是bLabel,每個控件做好自己事情,給自己顏色字號都弄好了,等我要用你的時候,比如要往父視圖添加了,拿來直接加就好,所以在添加View這個方法裏都是添加,無關代碼沒有,要修改aView背景色,去找aView(aView的懶加載裏面改)啊
原文鏈接:http://www.jianshu.com/p/bb021d4acc35
著作權歸作者所有,轉載請聯繫作者獲得授權,並標註“簡書作者”。
上篇發出之後收集了一些反饋, 總結起來以下幾點:
- 沒有demo,代碼沒有全部粘上來。
我認爲這篇的內容不需要,不能我寫個弱引用的懶加載怎麼寫,還一定要把聲明weak屬性的代碼放上來吧。 - 關於xib/strotyboard和純代碼
我是兩種用過,實際工作中也基本都達到了熟練的程度,現在使用純代碼也不是公司要求,自己覺得更好,其他的就不說了,這就相當於兩條路都行的通,任意一條走成老司機了另一條也沒問題,但是新人工作中最好純代碼爲主。 - 關於懶加載是否一定要
理解到位想怎麼搞怎麼搞,蘿蔔青菜各有所愛。
提綱:上篇說到第4條
1. 關於xib/storyboard 與 純代碼的對比
2. 一條規範(又提了一點關於命名的)
3. UI工廠類 與 代碼塊
4. 懶加載, View使用strong還是weak
5. 複雜界面要會分區,要會障眼法
6. masonry均布View,及其佈局時約束依賴關係
7. 關於屏幕適配的一點技巧
8. 循環引用(上篇文章有人對循環引用不理解,雖然是基礎,有人不理解還是說一下吧)
5. 複雜界面要會分區,要會用障眼法
分區:什麼叫分區,其實就是封裝,幹啥其實都是一樣,UI網絡邏輯思路有相同的地方,就包括收拾東西,爲啥很多人喜歡把各種東西用各種盒子裝起來,假設現在要寫一個aView,上面是這樣的
這個要怎麼寫, 直接挨個創建直接往aView上加嗎, 這以後維護起來改點東西相信你死的心都會有的,一般這種元素有點多的都要適當的分一下區
這樣分區後,如圖所示,寫UI的時候就先依次單獨解決好上中下三部分,然後需要做的就是對上中下三部分的整體進行佈局,這一級佈局的時候就完全可以忽略他們內部的東西是什麼樣的,全部完成整體微調,該調裏面就裏面, 該調整體就整體
障眼法: 所謂障眼法就是投機取巧,當然可以有各種各樣的方法,把一些複雜功能簡化,不管用了什麼方法,最終看起來像是實現了就可以。
下面舉個例子, 這個例子是項目中的一個界面, 我簡化了一下抽出來, 這是一個消費記錄的界面, 有個tableview,每個cell如下所示,可以展開收起
看到這樣一個界面,首先不要考慮如何展開收起,就看一下展開的要怎麼寫,(演示Demo中的UI因爲沒有使用網絡數據,也爲了演示方便,做了簡化,實際賬單消費下面還有一部分如何消費,可獲得什麼等等的區域),參照上一條,這種一個View裏元素較多的時候可以先分區如下:
先假設展開狀態已經寫好了,下面要考慮如何收起,觀察UI發現收起狀態的信息是展開狀態中的主要信息, 如圖元素其實表達的是同樣信息
那麼難道要打破布局,將這幾個view找到重新佈局,其他的隱藏掉嗎?那再點擊回到展開狀態怎麼辦,在重新佈局?想想就麻煩
所以,這時再搞一個summaryView,負責收起的信息展示,這個View內部的時間桌號等控件,跟展開狀態的時間桌號雖然長的一樣,但是實際是兩個不同的UI對象。
所以完成之後,這個View裏會有如下幾大塊
- summaryView (收起的View)
- expendBgView(展開時的整體View)
- topView (這樣命名不好)
- midView
如此佈局,在點擊了View要展開/收起的時候,只需要轉換summaryView和expendBgView的隱藏狀態,改變一下最外層View的底部約束即可
demo地址:https://github.com/CoderLXWang/LayoutViewDemo
6. masonry均布View,及其佈局時約束依賴關係
均布View: 等間距佈局 - 從0開始說一下masonry的使用
約束依賴關係:這個標題其實比較寬泛,也說不好,如何寫約束本身就是比較靈活的,每個人的寫法可能都不一樣,下面舉兩個例子大概說一下,
示例1:
這個很簡單, 左右間距都是30,第二三四行View的左右約束該怎麼寫,都寫下面的嗎?這樣寫如果要改這個30,就瞎了
make.left.equalTo(父視圖).offset(30);
make.right.equalTo(父視圖).offset(-30);
因爲這裏的設計就是左右都要對其,所以下面都都依靠第一個佈局即可,第二行兩個不是左右都對其
make.left.right.equalTo(父視圖).offset(第一個View);
代碼少了一行是其次,主要是改的話只改一個,也可以透過代碼看到這個地方的設計
注:這個示例很簡單,勿噴,主要說這種做法,複雜佈局也需要考慮到底依靠那個View佈局,具體體況多體會,簡單說就是要選取合適的依賴對象
示例2:
需求:
1.整體居中
2.寬度可變,看文字是否夠一行,最寬左右內邊距10
3.內部兩個View的centerY對其
4.最小高度爲圖片高度,文字高度超度圖片,就以文字高度爲準
直接上代碼,只爲說明約束,不要找別的毛病,具體自己看吧,這裏Label和ImageView一定要作爲一個整體(即放到同一個父視圖中),內部因爲圖片相對固定,左右尺寸都不變,要先佈局圖片纔可以,否則Label沒有可以依賴的東西
@interface ViewController ()
@property (nonatomic, strong) UIView *containerView;
@end
@implementation ViewController
- (UIView *)containerView {
if (!_containerView) {
_containerView = [[UIView alloc] init];
_containerView.backgroundColor = [UIColor orangeColor];
UIImageView *imgView = [[UIImageView alloc] init];
imgView.image = [UIImage imageNamed:@"demo1.jpeg"];
[_containerView addSubview:imgView];
[imgView mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(_containerView).offset(0);
make.size.mas_equalTo(CGSizeMake(100, 100));
make.centerY.equalTo(_containerView);
}];
UILabel *label = [[UILabel alloc] init];
label.numberOfLines = 0;
label.text = @"這是阿三衝擊紅進口付出dsk紅進口付出ds口付出dsk紅進口付出dskjfhks口付kjfhks口付出dskj紅進口付出dskjfhks口付出dskjjfhks口付出dskjfhd付出dsk紅進口付出ds口付出dsk紅進口付出dskjfhks口付kjfhks口付出dskj紅進口付出dskjfhks口付出dskjjfhks口付出dskjfhdjfhdksjhfdk";
[_containerView addSubview:label];
[label mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(imgView.mas_left).offset(-20);
make.left.equalTo(_containerView).offset(0);
make.bottom.top.equalTo(_containerView).offset(0);
make.height.mas_greaterThanOrEqualTo(100);
}];
}
return _containerView;
}
- (void)viewDidLoad {
[super viewDidLoad];
[self.view addSubview:self.containerView];
[self.containerView mas_makeConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(self.view).offset(200);
make.centerX.equalTo(self.view);
make.width.mas_lessThanOrEqualTo([UIScreen mainScreen].bounds.size.width-20);
}];
}
7. 關於屏幕適配的一點技巧
首先說一個屏幕適配到底是什麼, 工作中很多人,甚至產品都搞錯了
所謂屏幕適配,並不是大屏就要將UI變大,而是要顯示更多的內容。
再說一個關於按鈕的寫UI原則
按鈕設計的大沒啥可說,如果設計的按鈕很小,到程序員手裏一定要讓它看起來小,點起來大
KRATE :當然在這一基本原則下,有的時候大屏上的某些元素和小屏保持同樣大小會有一些難看,這時還是要分別對待,如果以5s屏幕尺寸爲基準(也有用6的尺寸做基準的,都一樣,習慣問題),這裏一般會定義這樣一個宏
#define KRATE (SCREEN_WIDTH/320.0)
舉個例子
不做比例的適配,在6p上如圖
其實也沒啥問題,看起來也沒有很不協調的地方,但是注意看一下券左右兩條豎直虛線,會發現大屏上左面券命和右面打印的寬度會比較小,中間區域顯得過大,應該稍微勻一點給左右兩邊,兩邊看起來會不那麼擠,同時右側點擊範圍也會相應放大,做法就是將左右約束的值*KRATE
[self.leftLine mas_makeConstraints:^(MASConstraintMaker *make) {
make.left.equalTo(self.bgView).offset(80*KRATE);
make.top.equalTo(self.bgView).offset(15);
make.bottom.equalTo(self.bgView).offset(-15);
make.width.mas_equalTo(1);
}];
[self.rightLine mas_makeConstraints:^(MASConstraintMaker *make) {
make.right.equalTo(self.bgView).offset(-40*KRATE);
make.top.bottom.equalTo(self.bgView).offset(0);
make.width.mas_equalTo(1);
}];
乘上比例之後,效果如圖
爲什麼會有這種問題產生, 其實也是由於個人的佈局習慣引起的,在佈局這個UI時,我是先將左右兩條虛線定位好,內部的東西根據虛線的位置確定,而虛線的位置就是一塊白色背景左右給定值佈局的,所以換到大屏會左右寬度不變,這種情況乘個KRATE就可以了。
麻煩有些人不要來噴啥你寫就不會有這個問題,按比例分區怎樣的,那是你的方法,你要是按比例分區不也要想到底給0.幾的比例嗎,要是豎直方向在scollView裏也有這個問題呢
KKRATE:因爲KRATE是用不同屏幕的寬度算出的一個係數,假設某個寬度5s上寬度爲10,KRATE後6上則爲10375/320=11.7, 也就是屏幕大1號之後原本爲10的寬度增大了1.7, 那麼這個寬度如果是40呢,40*374/320 = 46.9。
爲了解決小寬度 ×KRATE基本沒效果或者寬度大 ×KRATE 又過分了的問題,又定義了這樣一個宏,給KRATE在乘一個自己制定的係數,感覺沒效果就給KKRATE傳個大於1的係數,感覺過分了就KKRATE(0.95),這裏注意傳入的係數小於0.86就反而大屏UI更小了,這裏不想在裏面繼續寫個三目運算符判斷了,就這樣了
/** 在屏幕比例基礎上再次比例, 大於0.86, 否則反而變小 */
#define KKRATE(rate) (KRATE > 1 ? KRATE*rate : KRATE)
拿一個界面舉個例子,如圖
這裏左右看起來窄窄的間距用的都是6dp,6dp如果直接*KRATE基本沒用,乘完也就加一個dp,效果基本就是如下,屏幕很大,間距很小氣,也許你會說小屏上也小氣,設計說了,你不懂,正好
如果將各處左右間距設置爲
make.left.equalTo(ws.view).offset(6*KKRATE(1.8));
make.right.equalTo(ws.view).offset(-6*KKRATE(1.8));
效果如下
明顯大氣了許多。。。
8. 循環引用(上篇文章有人對循環引用不理解,雖然是基礎,有人不理解還是說一下吧)
這部分是計劃外的,因爲上篇有不少同學問起這個東西,發現不少人對看似簡單的循環引用概念還是比較模糊,所以我就拿出來說一下,我會分別解釋一下常見的循環引用,以及代理,block中的循環引用問題,這裏只做理解解釋,沒有深入研究,大神直接略過吧。
先說一下內存管理,大家都知道內存管理在MRC下要手動寫retain,release等代碼,操作一個對象的引用計數,以此控制對象持有及釋放,ARC下編譯器會自動添加retain/release等代碼,ARC的一個基本規則就是,只要某個對象被任一strong指針指向,那麼它將不會被銷燬。如果對象沒有被任何strong指針指向,那麼就將被銷燬。
所以當前我們的代碼基本都是ARC,當我們研究一個對象是否循環引用時,也就不考去考慮計數到底爲幾,什麼時候retain,什麼時候release,我們只需要按照ARC的基本原則關心指向這個對象的strong指針。
下面就按這個基本原則解釋一下循環引用,觀察是否釋放在控制器打印dealloc方法即可
示例1:簡單粗暴無邏輯演示
有一個控制器SampleRetainCycleController *retainVC
,retainVC.view
上面有個SampleRetainCycleView *testView
,testView
有個強引用指針,指向retainVC
,看起來貌似循環成一個圈了,這就是循環引用嗎?貌似怪怪的,因爲少了一個引用
實際上少了一個引用關係,沒有考慮retainVC是那裏來的,retainVC被創建之後加載nav導航棧裏是被navController強引用的,這是我們就可以按ARC的原則分析了,就是看線,找實線,這裏我們關心的是控制器會不會被正常釋放,那我們就看控制器有幾根實線,這時就會發現有兩根,pop出去的時候,上面的那條nav的線斷了,但是還有一條View的線,所以控制器就不會被釋放
示例2:代理爲什麼用weak聲明
如圖就是代理爲什麼用弱引用,如果用強引用就變成示例1的情況了
示例3:一般使用block爲什麼注意循環引用,使用weakSelf
先說爲什麼block一定要用copy,既然會循環引用,那麼就像代理一樣,使用弱引用的指針不行嗎?
詳細看這篇文章吧 Block爲什麼使用copy修飾,
更詳細可以看這篇談Objective-C block的實現
總結起來就是爲了使其存放在堆中,如果不copy一下,block是存放在棧中的,出了創建它的作用域,就可能被釋放掉,但是用了copy,對這個block就是強引用,所以需要注意循環引用,使用weakSelf。
那什麼是weakSelf,block默認對內部引用的外部變量是強引用,所以如果直接使用了self,則相當於block有一條實線(強指針)指向self,則self又有兩條實線了
示例4:什麼樣的block不會造成循環引用
最常見的就是系統的一些block與masonry,系統的比如:
[UIView animateWithDuration: animations:^{
}];
首先是self(假設是當前的控制器)並沒有copy(強引用)這個block,其次這還是個類方法,類方法裏不能對屬性進行復制,即也不能強引用這個block,所以直接用self(即block對self強引用)也不會形成循環引用
再比如masonry
[self.containerView mas_makeConstraints:^(MASConstraintMaker *make) {
}];
看一下mas_makeConstraints是怎麼寫的
- (NSArray *)mas_makeConstraints:(void(^)(MASConstraintMaker *))block {
self.translatesAutoresizingMaskIntoConstraints = NO;
MASConstraintMaker *constraintMaker = [[MASConstraintMaker alloc] initWithView:self];
block(constraintMaker);
return [constraintMaker install];
}
只有第三行執行了一下這個block,並沒有任何引用的代碼(即類似self.xxblock = block),所以根據上面的幾篇文章,這種block是存放在棧上的,出了作用域(即這個方法)就會被釋放掉,既然block都被釋放掉了,自然不會循環引用。