@override
public void onresume()
public
void refresh()
這樣不合適，在什麼時候重新整理是根據需要來的，並不是每次onresume()的時候都需要重新整理。
假如使用者關閉了螢幕後再開啟螢幕，頁面會重新整理，這樣沒有必要，也許幾秒中前剛重新整理過。
網易新聞客戶端就不是這樣的。
如果乙個activity中有乙個viewpager，viewpager中載入了兩個fragment，這時要特別注意的是，兩個fragment是同事載入的，雖然只顯示了乙個
fragment的介面，但是另外乙個也是載入了的，所以如果當前顯示的fragment沒有彈窗，但是另乙個fragment彈窗了也會顯示到當前activity中。
重用優點：減少布局檔案個數，如果幾個介面的布局問個始終一致，那麼可以使用
重用缺點：如果其中乙個布局檔案有所改動，那麼其他頁面將不能再使用，因為布局檔案中沒法使用 if else 。
copy優點：乙個頁面對應乙個xml檔案，完全解耦
copy缺點：會大量出現重複的**
總結：需求隨時都可能變動，還是把布局解耦比較好
哪段**使用的頻率越高就應該先優化哪段**，這樣會事半功倍！
昨天跟我說某某模組的介面改了，要重新做，我做了。
今天來的時候又跟我說暫時不改了，還是用之前的**。
天啦，幸虧我沒有刪掉之前的**，不然死的心都有了。
so，程式猿們，保護好你自己的**。
模板方法寫好了，比如baseacitivity，然後開始寫它的子類，忽然除錯的時候發現模板的方法有問題，比如說要調整方法呼叫的順序或者改變方法呼叫
的位置，這下好了，你的n個子類都是按照之前的模板方法去寫的，so 你就乙個乙個去修改子類吧。
另外，要千萬注意別人修改了公用的模板方法，要及時pull和push**，不然自己寫的很多**都白費了。
比如你要獲取10-個新聞列表資料，而且你要同一時間去獲取，那就得建立10次http鏈結，這很費時的。最好的方法是讓伺服器把10個新聞列表資料寫
在乙個xml檔案中，這樣會顯著的節約時間。wo
so,當進行遠端呼叫時，從資料提供者反覆呼叫取得資料會嚴重影響效能，比如資料庫呼叫、web服務呼叫或者其他編譯碼呼叫。這種情況下可以使用
facade模式一次獲得所有所需的資料，盡可能減小連線成本和在網路上傳輸資料的成本。
本類的所有成員變數前加"m"，好處是：敲"m"就能提示本類的一些成員變數
別人的部落格和帖子是別人的，要有自己的，不斷補充，不斷完善，以後再檢視的時候才方便。
另外 ，強迫自己寫技術部落格和帖子就是強迫自己總結，加深技術知識的印象。
比如寫乙個瀑布流類（自定義view），幹了很多事情，布局了瀑布流模型，設定了重新整理功能。
這不應該在乙個類中出現，瀑布流就是瀑布流，重新整理是另外一回事，獲取資料又是另外一回事！不要混在一起，寫在乙個類中！
乙個類應該是純粹的，盡量的簡單，就是幹一件事情。完成乙個功能我們可以把多個類組合在一起，或者引用等等方法。
好處在於拆卸方便，當不需要什麼功能的時候能快速明晰的剝離掉。如果什麼**都混在一塊那是灰常難以剝離的。
Android開發過程中需要注意的細節
git 使用 rebase 命令來合併分支，盡量不要直接 merge 導致分支 日誌混亂。開發新功能時，自己在本地建立 feature 分支開發，功能開發完畢之後，參照上面合併流程操作功能的合併，並刪除本地分支，注意不要將本地分支推送到伺服器。平時開發只在 develop 分支和自己的本地分支操作，...
敏捷開發中需要注意的事情
1.團隊中各個隊員的直接面對面相互溝通勝過任何的工具溝通 2.可以工作的軟體勝過詳細的文件，才是最好的文件 3.良好的客戶關係比死板的合同更具有意義 4.及時的響應變化勝過時刻遵循計畫 5.盡早的持續的交付有價值的軟體使客戶滿意 6.任何時候都積極的擁抱需求的變化，哪怕是開發後期也是如此 7.在整個...
介面開發需要注意的
我們在開發 api 應該注意的幾個事項 僅供參考 1 單檔案實現多介面的形式有很多種，例如 if.elseif.或 switch 或 動態方法 也就是tp的這種訪問函式體的形式 2 對於資料的輸出最好用json，json具有相當強大的跨平台性，市場上各大主流程式語言都支援json解析，json正在逐...