牢騷

最近回學校, 聽說阿里好多實習生都被拒了, 不過大概都被撿漏了, UC這方面還沒動靜, 不知道是打算把我當臨時工使還是怎麼, 有點煩躁, 還是得加強自己的能力才行.
最近半年一直在做音樂播放器專案, 開發期間遇到了許多奇怪的問題, 有些我單獨寫了文章, 有些只是臨時找到了解決方法, 沒有仔細研究, 這裡先總結一下.

坑

下載進度item無法長按

上面是一個比較常見的下載item, 開發中我們發現經常出現不能對其進行長按操作的情況, 表現就是長按後長按被取消.
追蹤原始碼, 最可疑的地方就是requestLayout.
一個控制元件呼叫requestLayout, 很可能讓他的父控制元件也調這個, 有可能導致最外圍的item把自己的狀態清除掉.
在很多情況下都會導致控制元件呼叫這個方法, 比如setText

, setImage*, 當時釋出比較趕, 沒有仔細看TextView的原始碼具體是個什麼情況, 但是有一點可以確定, TextView在寬度為match_parent並且singleLine為true的情況下給他設定文字是不會呼叫requestLayout的, 這是我當時測試的結果, 我們解決這個問題的方法就是讓圖中的所有文字都只允許單行, 且寬度match_parent, 至於右下角, 那是將gravity設為right了, 兩個TextView在一個FrameLayout裡.

ViewPager無法滑動

大家可以試一試, 讓ViewPager有兩頁就行, 其中一頁放上一個TextView

, 設定singleLine為true, 並且把ellipsize設定成marquee, 然後把文字內容設定成一個非常長的字串, 然後手指在這個TextView上滑動, 你會發現ViewPager根本不動.
追查程式碼, 其實是TextView自身有毛病.
大家知道ViewPager支援巢狀, 而他們之所以能巢狀是因為ViewPager在準備攔截事件滑動之前, 會先通過ViewCompat.canScrollHorizontally詢問當前頁面裡面有沒有能在當前滑動方向上能滑動的控制元件, 當然這裡有碰撞檢測, 只有手指能碰到的View才會被詢問, 而TextView竟然在上面條件滿足時在一定情況下返回true, ViewPager認為內層View可以優先滑動, 就不攔截事件了. 其實這個東西應該是給EditText使用的, 不知道TextView湊什麼熱鬧, 印象裡面TextView根本沒有接受滑動手勢這麼一個功能.
在三星手機上不會出這個問題, 因為三星對marquee的處理統一是end, 這是三星的bug. 解決方案最簡單的就是ellipsize不要用marquee, 用end.
剛才又發現下面這個有可能會出現同樣的問題, 把gravity刪掉就好

<TextView android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:singleLine="true"
    android:gravity="center"
    android:ellipsize="end"/>

UIL圖片錯亂

如果你用UIL載入res/drawable目錄下的圖片, 恰好又把cacheOnDisk設為true了, 那麼下個版本很可能出現圖片錯亂的問題, 根源在於UIL通過R.drawable.id將圖片快取在了磁碟上, 而這個id很可能對應的不是同一張圖片, 關於這個我單獨寫了一篇文章, 詳情請移步為什麼不推薦用UniversalImageLoader載入res/drawable

saveLayer效能問題

最近有個圖示漸變色需求, 不僅要求圖示能隨意更換顏色, 還要能染漸變色, 我重寫了了ImageView.onDraw來實現, 用了一個叫saveLayer的東西, 現在看來好像有優化的餘地, 但針對這個問題, saveLayer好像很吃效能, 搞的介面非常卡, 所以如果你的View用了saveLayer, 務必在初始化的時候把硬體加速開啟, 對應的方法是View.setLayerType

不要主動呼叫on*方法

這個真的是開發的準則了, 凡是on***的方法, 都不應該主動呼叫, 比如activity不應該主動呼叫自己的回撥函式.
我們最近一期做了一個換膚功能, 有個onThemeChanged方法, 會把當前主題傳進來, 是外部回撥的, 我們偷懶, 在初始化的時候也用這個方法初始化, 結果因為這個方法要調super.onThemeChanged, 加上繼承層次上很多類都重寫了這個方法, 也在初始化的時候調了這個方法, 由於多型的存在, 這個方法呼叫鏈會反覆執行好幾次.