重複的代碼一直都是可維護性的大敵，重構的重要任務之一也就是要去除掉重複的代碼，有效的減少重複代碼，可以大大提高軟件的擴展性。
在Android開發中，很容易產生重複的代碼。因爲Android是組件，模板式開發，每個頁面都是獨立用Activity或Fragment實現，佈局文件都是用XML方式去寫，所以很容易造成代碼的重複，雖然二個頁長的差不多，但畢竟是二個Activity，於是就拷一份出來，改吧改吧就成了。
那麼我們如何做才能去掉重複的代碼呢？
爲你的項目定義一個基Activity或Fragment
無論你的項目大或小，定義一個基Activity或Fragment總是有好處的。隨着項目的發展，會有大量的公共代碼可以抽出來放到基類裏去。或者在基類裏面做一些項目特色的事情。再或者添加一些統計，崩潰反饋等等。在一個基類裏面改動總比把每個Activity或Fragment裏面都改一遍要好的多。
代碼的去重複技巧
從代碼上去除重複的代碼就是用通用的重構技巧，比如提煉方法，抽象基類，提煉常量等。但是光是代碼還不夠，因爲Android的頁面代碼跟佈局文件的關聯非常大，通常Activity或者Fragment都是爲了操作佈局頁寫的，所以要想徹底的減少代碼的重複，還必須先減少佈局的重複。
用include減少局部佈局的重複
標籤是減少佈局重複的利器，它的作用是把另外一個佈局文件全部無修改式的嵌入到標籤所在的位置。這與C/C++語言的預處理指令#include是一樣的。在WEB框架式開發中，也非常常用HTML模板，其中也有類似的include。目的也是減少代碼的重複。
要想把include用的恰到好處，首先要做的就是把整體佈局模塊化，從整體的佈局出發，找出可複用的局部佈局或佈局組合，把它們放入單獨一個佈局文件中，然後在其他的地方就可以include了。
用ViewStub減少整體的佈局的重複
前面是找出佈局中的可複用佈局組合，include以減少重複。但有些時候是反過來的，也就是說有幾個頁面，它們整體的一樣的，但是某個局部是不同的，這個時候include就不行了。這個時候就可以使用一樣的整體佈局+ViewStub來做佈局。
ViewStub是一個輕量級別的，不可見的View，當ViewStub被設爲visible時，或者顯示調用layout()時，纔會去把它所指向的佈局渲染出來，所以它非常適合處理整體相同，局部不同的情況。 具體的策略是：
規劃整體佈局，抽象出共同的佈局，把可變的佈局識別出來
寫整體佈局，對於可變的局部佈局用ViewStub替代
用一個基Fragment來操作整體佈局。
創建基Fragment的子類，每個子類，用真正的佈局來替換ViewStub。
多用引用而不是寫死
這點是非常重要的，Android的強大之處在於，所有的資源的指定都可以用引用，而非直接寫死，直接寫死就會出現重複代碼，比如顏色，背影，字串，佈局，ID，度量(dimen)，風格等等。那麼，我們在使用的時候，也儘可能的使用引用，這樣非常易於複用，修改和定製，從而也就更方便複用。
分析，分離變與不變
其實代碼的去重複的關鍵都在於要分析出可變與不可變，共性和特性，這是抽象與封裝的基礎。這個沒有直接可操作性的建議，只能靠自己平時多多積累，以及遇到問題時多多思考。
另外，就是對於重複的定義是達到三次及三次以上。如果僅出現二次，並且，無可能出現別一次，這個時候其時，要不要去重複有在商榷，寫第二次時，花時間重構，與拷貝或重新實現，其實代碼差不多。當發現第三次實現某個東西時，就要考慮好好的重構一下，減少重複。
還有，就是，在項目開始不要考慮的太多，不要過度設計。孤認爲，不過過度設計，更不要過早優化，就根據需求和進度和發展狀況綜合來看。當出現了重複，需要重構時就立馬去做，這樣就不會出問題。但如果沒能及時去做重構，欠了債，那麼由於涉及代碼，功能和模塊都比較多時，再去重構，難度大，風險也大。就好比房屋的維護保養，當出現灰塵時就去打掃，很容易，個把小時就搞定了，但如果一直拖着，一年纔打掃一次，可能要十天半個月才能完事。
