最近對項目代碼做了一些更改，主要的改動是對整個界面框架的改變，因為以前寫代碼的時候，為了完成功能，沒有從上帝視角來思考軟件的界面設計，完全是需要這個功能了，怎么可以做到？好，就就這樣吧，為了完成功能而對界面不停的修修補補，這樣帶來的主要壞處有很多：

一是，后續功能加進來的話，需要考慮的地方會越來越多，因為前面的代碼耦合程度很高，比如onStart回調，有些事情，既可以在Activity的回調里面去做，也可以在Fragment的回調里面去做，既可以在這里做也可以在那里做，新增加一個功能進來的時候，不得不考慮在所有可能的地方都要檢查一遍，然而這樣可能還是無法完全考慮到所有情況，最后出現遺漏導致測試的時候報bug修改。

二是，維護現有的代碼也很困難，比如測試或者產品突然冒出來一個新想法，要把原來的效果改成一種別的效果，看起來似乎不是很難，但是實現的時候發現真的很麻煩。。比如之前支離破碎的fragment，連我自己都不知道這個title到底是屬于fragment還是屬于acticity，整個界面的動畫切入切出也很難做，因為他們根本就不是一個整體的。。

三是，代碼寫起來很丑。比如onbackPressed,需要先判斷(xxxFragnemt != null ，xxxfragent.isvisiable(),xxxPopwindow != null）之類的鬼東西。。實在是太難看了。。

?

?

現在改動主要是考慮到了上面幾點，主要的變化是，

1.界面和數據分離，比如界面A更新的時候，它也不需要考慮，我是不是也要更新B了，這些都抽出來交給上一層數據結構去處理。例如如果activity包含有很多fragment的話， 那么把這個activity單獨抽出來，負責保存數據，在android的設計中，activity和fragment之間的消息通訊有很完整的解決方案，這樣做也把activity從交錯復雜的界面中解放了出來，它只負責保存和同步數據，通知界面更新狀態，而fragment則只負責界面，顯示數據。原來屬于公共部分的界面，比如title,bottom現在分開到各個fragment里面去了，所以也需要一種同步的機制，這種需求的話交給activity去控制，比如觀察者模式之類的，這是完全可以做到的，現在我只是暫時粗略的維護了一個fragment的鏈表，數據更新的時候依次通知各個子頁面就可以了。

2.想辦法提取一些公共的特性，把它們都放到基類里面去做，因為界面之間的耦合度降低了，因此很多交互的需求都可以抽象出來成為接口，讓各個界面自己去響應對應的調用就可以了，比如前面所說的onbackPressed回調，現在activity根本就不用管這么多條件了，直接一次調用子界面的接口就可以了，而不用自己去檢查管理應該調用哪一個界面，怎么響應。當然，因為這個交互的特殊性，只能有一個界面去響應，所以暫時改成了這個樣子：

　　

for(fragment x:fragmentList){ if（x.myBackPressed() ){break ; } }

這樣改之后感覺邏輯處理上確實簡單了很多，具體效果還有待確認。仔細想想，這一套似乎和MFC那一套十分相似。。。這次的改動也讓我覺得，android和windows確實很多相似的地方，比如消息隊列，比如這次的activty和fragment的關系，就和windows里面的各個窗口的關系差不多，只不過android把它抽象出來了而已。日子似乎又回到了我剛開始看PC客戶端代碼的時候，David跟我說，你主要需要弄清楚消息是怎樣流動的。現在想想，一個框架的設計，的確最重要的就是消息怎樣流動，怎樣響應。它的結構清晰嗎？它需要被消耗掉嗎還是要通知到所有的地方？界面之間的消息，需要怎樣相互通知？界面和框架之間，需要怎么通知？界面狀態更新直接和同步，需要怎樣通知？這些都是需要認真考慮的問題。

轉載于:https://www.cnblogs.com/BezierCurve/p/4771943.html

總結

以上是生活随笔為你收集整理的最近对项目代码做的一些更改和感想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。