前言
做程序開發(fā)，基礎(chǔ)很重要。同樣是擰螺絲人家擰出來的可以經(jīng)久不壞，你擰出來的遇到點(diǎn)風(fēng)浪就開始顫抖，可見基本功的重要性。此系列，專門收錄一些看似基礎(chǔ)，但是沒那么簡單的小細(xì)節(jié)，同時(shí)提供權(quán)威解決方案。喜歡的同志們點(diǎn)個(gè)贊就是對(duì)我最大的鼓勵(lì)！先行謝過！
網(wǎng)上可能有一些其他文章，提供了解決方案，但是要么就是沒有提供可運(yùn)行demo，要么就是demo不夠純粹，讓人探索起來受到其他代碼因素的影響，無法專注于當(dāng)前這個(gè)知識(shí)點(diǎn)（比如，我只是想了解Activity的生命周期，你把生命周期探究的過程混入到一個(gè)很復(fù)雜的大雜燴Demo中，讓人一眼就沒有了閱讀Demo代碼的欲望），所以我覺得有必要做一個(gè)專題，用最純粹的方式展示一個(gè)坑的解決方案.
先吐個(gè)槽
做開發(fā)的，少不了被UI大佬折磨的經(jīng)歷。之前做
陰影的時(shí)候，都是自己繪制，太麻煩。后來直接讓UI大佬給帶陰影的圖片，大佬又不樂意。直到···發(fā)現(xiàn)谷歌居然提供了CardView，不但帶陰影，還帶圓角? 喜出望外，但是，用過之后才發(fā)現(xiàn)還是有坑。不過好在有辦法解決。CardView是 谷歌大佬按照android 自定義控件的規(guī)則寫的控件，那我們作為高級(jí) 開(碼)發(fā)(農(nóng))，就有辦法找到坑的原因并且，解決它的缺陷。
什么坑？
SDK 21以下SDK21以下.gif
但是在SDK 21（含21）以上：沒有這種問題
SDK21(含)以上.gif.gif
確定是 兼容性問題。
查查剛才坑的原因
為什么加了圓角，在28的模擬器上效果OK，但是19的機(jī)器上有問題？直覺，就是在CardView的源碼內(nèi)部，在圓角的處理上，做了SDK版本的區(qū)分，而且19的處理貌似還沒做好(大概這就是谷歌的實(shí)習(xí)生造的孽吧 囧)
查唄，啥原因，進(jìn)源碼看一眼。 發(fā)現(xiàn)：
image.png
image.png
image.png
image.png
image.png
同樣都是利用拿到的radius屬性值，然后構(gòu)建出一個(gè)Drawable子類。但是 17以上21以下的處理是存在問題的。為何有問題，再進(jìn)去看。
跟蹤這個(gè)radius參數(shù)，
image.png
到了這里，發(fā)現(xiàn)radius被轉(zhuǎn)化成了一個(gè)int值 mCornerRadius，繼續(xù)跟蹤
image.png
驚奇地發(fā)現(xiàn)，radius居然影響到了CardView的背景的padding值？！
當(dāng)addPaddingForCorners為true的時(shí)候，外部傳入的radius圓角值會(huì)參與padding的計(jì)算。那么這個(gè)addPaddingForCorners的值是哪來的？
一頓追蹤之后(作為高級(jí)開(碼)發(fā)(農(nóng))，你一定可以追蹤得到··所以我就省略了過程)，居然發(fā)現(xiàn)，
image.png
居然是CardView的自定義屬性cardPreventCornerOverlap,可見這個(gè)值，在SDK 21以下的機(jī)器上運(yùn)行，圓角角度參與到CardView的背景padding的計(jì)算中去。我們讓它為false，不讓他參與計(jì)算，就正常了。
坑2
居然還有第二個(gè)坑？
image.png
image.png
image.png
原因也是這個(gè)屬性cardUseCompatPadding的影響，可以推測這個(gè)屬性值，在21前后有對(duì)陰影和padding有不同的處理,原因可以按照上面的思路在去找一遍代碼。
總之，要保持不同版本上UI效果一致，使用了陰影，就要寫上cardUseCompatPadding=true
另：給出一個(gè)偏方，據(jù)說也能解決此問題，那就是創(chuàng)建value-v21目錄，寫一個(gè)同名的dimen值，手動(dòng)給cardView加上間距，21以前為0（因?yàn)槟J(rèn)已經(jīng)有間距了），21以后不為0.
總結(jié)
CardView看上去就像是谷歌的實(shí)習(xí)生寫的控件，兼容性做的有問題，雖然官方給出了兩個(gè)屬性解決問題，但是卻沒有對(duì)這兩個(gè)屬性做出貼切的解釋說明。誒···算了，知道就行了，畢竟是大佬寫的。歐了！
