問題描述
在專案開發中有一個記錄介面，介面邏輯簡單，但處理資料上出了問題，介面效果達到了，但總覺得有點問題，後來收尾清理程式碼，當時頭腦比較清醒，一激動，完善一下；時間軸要求同年顯示月，同年同月顯示日，其它顯示年月日，伺服器返回是list，欄位time是long，介面資料解析用的是Gson。

問題分析
1.從伺服器拿到資料後按要求排序，返回資料中的time轉yyyy-MM-dd;
2.區分資料
3.更新UI

誤區
1.gson物件解析需欄位屬性一一對應；鑑於前款App在後臺修改一些欄位後，App華麗麗的蹦蹦蹦…beng…我對此更加深信不疑，果然太年輕，解決危機後仔細想想，gson不可能沒考慮到這個問題，果然，”gson可以通過使用annotation來靈活配置需要序列化的欄位“,看到這裡，有人意味深長的笑了……
2.在遍歷標記過程中每每將後一個數據與前一個數據對比，效率不高。

誤區結果
model多了一個實體類，資料copy了一份，程式碼產生冗餘，效率不高，簡直是暴擊。

問題解決方案
1.新增一個tag，將年月日均顯示的資料作為父節點（擁有兩種子節點）
2.優化遍歷

程式碼片段

  List<Long> has = new ArrayList<>();
    //排序顯示
    private void filterDate(List<Train> trainList) {
        for (int i = 0; i < trainList.size(); i++) {
            Train train = trainList.get
 
(i);
            if (i == 0) {
                 /*新增第一個父節點*/
                has.add(train.getCreateTime());
            } else {
                /*父節點標記*/
                int tag = -1;
                for (int j = 0; j < has.size(); j++) {
                    if (DateUtils.isSameMonth(has.get(j), train.getCreateTime())) {
                        /*子節點2：同年同月*/
 

                        tag = 2;
                    } else if (DateUtils.isSameYear(has.get(j), train.getCreateTime())) {
                        /*子節點1：同年*/
                        tag = 1;
                    }
                }
                if (tag == -1) {
                    has.add(train.getCreateTime());
                } else {
                    train.setTag(tag);
                }
            }
        }
    }

總結：考慮不夠全面，之前的兩層迴圈，對比之下，如果資料量大且子節點多，效率簡直不止快一倍，回頭想想好慌！