高仿網易評論列表效果之介面分析(一)

Hello大家好我是周杰倫~！@#￥#@￥%￥%……%&*&……**）……*%&￥%#￥！！！！

不好意思，剛忘了吃藥了~~~~扯正事，前幾天有個小哥來面試，因為前些天面試了很多人了實在是有點面試疲勞了，我就乾脆問了點基礎的知識然後給了他一個上機測試題，這個測試題呢其實也是偶然想到的，就是一個網易新聞客戶端的評論列表，見下圖：

我給了這個面試的孩紙一天時間回去做好就發我，最後當然也是意料之中這可憐的娃木有做出來~~~

後來我自己閒暇之餘也做了一下發現其實這個評論列表並沒有想象中的那麼難，只要是掌握了Adapter的用法我相信應該還是比較容易做出來的，其餘的像多重的蓋樓回覆框之類的都不是重點，那麼今天哥就帶大家一起來仿仿這個列表介面~~~

作為一個善於發現生活規律的人，我模仿做別人東西有個習慣，喜歡先分析，那麼我們就先來看看這個介面是怎樣的？

GIF圖可能看不清楚，沒關係，我們用高清無碼的截圖說話！

首先點選了開啟評論列表的按鈕後，映入眼簾的就是這麼一個介面：

介面很單純~~單純到我都不敢相信~~~

頂部是一個標題欄，裡面只有左上方一個返回按鈕，底部呢是一個回覆框，一個帶Icon的EditText和一個傳送按鈕，中間是我們的重點，也就是整個評論列表的主體，這個主體部分包含了三大部分：最上面的Banner廣告，緊隨其後的“熱門跟帖”區域，還有下面的“最新跟帖”區域。Banner廣告就一圖片沒什麼好說的，來看看“熱門跟帖”，點了無數個主題看了看它們的評論列表發現這個“熱門跟帖”的數量都是一致的：10個，也就是說該區域下的評論資料條數是固定的，那麼再看看“最新跟帖”的資料是怎麼展示的呢？雖然“最新跟帖”下的的資料是分頁的，但是它每頁展示的評論資料依然是10條~~~恩，這算是對整個介面一個整體的分析，那麼我們再來看看細節。

如果這個評論列表套用的是ListView之類的控制元件，當然不排除其他的或者說網易自定義的類似控制元件，這裡我姑且認為他就是一個ListView，那麼他的Item應該可以分為兩大種：

一種是隻有一條評論資料的，如下圖：

這種Item的佈局就很簡單了，兩大部分，上方顯示使用者的一些資訊，下方顯示評論，使用者資訊區域又可分為幾個小部分分別顯示頭像、ID、位置、時間和讚的數量，這裡就不一一贅述了。

另一種是評論帶回復的，如下圖：

這種就很奇葩了不是，回覆數是不固定的，有的有一條，有的有兩條三條四條的等等：

但是即便是如此的不規律我們還是能在其中發現規律，我們發現這種評論帶回復的Item也可以大致分為兩部分，上方是該條評論者（也就是常說的擼主）的使用者資訊，下方呢就成了一層又一層的蓋樓了~~~每一層樓只有三部分：地理位置、回覆內容和樓層數，而最後呢是最底層也就是最新的一條回覆。

還有，一旦樓層數超過一定數量（這個我沒刻意去統計，姑且也認為是9層吧）後，樓層會摺疊起來隱藏中間的樓層而只顯示頭兩條後最後兩條資料，其餘的資料就會用“展開隱藏樓層代替”：

再者，我們仔細觀察“熱門跟帖”和“最新跟帖”的第一條Item，如果從分割線來看，“熱門跟帖”和“最新跟帖”的第一條Item是跟其他Item又不一樣的：

同樣，“最新跟帖”的第一項Item也如此：

整個介面大致就是如此，分析完成後我們可以構思一下如何實現這一介面，首先最先讓人想到的莫過於ListView了，資料預先在介面顯示前獲取並封裝成物件列表傳遞給Adapter，然後通過標識不同的物件型別決定在Adapter中生成幾種型別的View，最後傳值顯示介面即可。這種方法是可行的，但是Adapter的邏輯就很複雜了，而且預先對資料進行分類也是個棘手的過程，我們先擱置該方法，想想有沒其它的方法呢？如果我有這麼一個控制元件，只需要把封裝資料的物件傳遞給該控制元件，然後讓該控制元件顯示資料豈不是更好？這樣既可以大幅度地減少Adapter中的邏輯又把繁瑣的問題簡化，看起來是個可行的方案。那麼對於這樣一個控制元件，其佈局必定是相容所有不同Item的資料顯示的，而據我們觀察最複雜的顯示效果莫過於“熱門跟帖”和“最新跟帖”的第一條Item蓋樓顯示，那麼我們就可以以此為藍本進行復合控制元件的構造！

那麼資料呢？我們應該封裝一些什麼資料在我們的物件裡？首先從介面上來看：使用者名稱、頭像地址、地理位置、時間還有右上方的贊資料，還有“熱門跟帖”和“最新跟帖”的第一條Item左上方的型別標識，大概就這些~~

繼續進入到蓋樓的佈局，層疊的效果我們可以通過繪製不同size的背景Drawable+margin來實現，但是對於該模組的資料結構應該如何構造呢？通過我們上面分析的可以知道，一個Item是“評論”—>“回覆”的形式存在，也就是說第一個發表的人說的是評論，而之後的人發表的則是回覆，評論和回覆在資料上的表達應該是一個一對多的關係，這應該正確的吧~~~~~不過仔細觀察介面後你就會否定這種設想！

我們發現，每一個Item下的資料顯示並非是按我們說的一個評論+多條回覆的方式顯示的，而是一個Item+多條評論，評論按時間先後顯示，繼續觀察發現Item右上角的贊圖示只在一個Item中顯示而不是每條評論&回覆都顯示，這倒沒什麼，最讓我們下定決心否定“評論—>回覆”結構的是當我們點選Item中的每條回覆時發現其中的“踩”和“收藏”對應的並非該條評論&回覆而是整個Item的內容：

也就是說資料結構應該是一個Item對應多個評論，或者說是“帖子—>評論”的結構，一個Item是一條帖子，這個帖子只是個容器，裡面包含了我們的評論，這麼一想資料結構就清晰了一個Item所要顯示的資料我們封裝成一個Post物件，而這些評論呢，我們將其封裝成Comment物件，其中Post和Comment是一對多的關係~~

好了，關於介面的分析就先到這裡，我們也有了一個大致的構思，一些小細節我們會在做的過程中不斷完善，下一節將會給大家講一下專案的整體結構和做之前的資料準備，畢竟有資料我們才能測試才能顯示才能做嘛~~~~OK！See you！跟我一起裝個逼~~~