1.項目基類
毫不夸張的說葛假，項目基類封裝的質(zhì)量決定你的開發(fā)速度，后期維護難易度藐不。不過估計很多萌新并沒有理解其中原因匀哄，那么我今天就來分析下，項目基類封裝的質(zhì)量有多重要雏蛮。
??首先通常來講涎嚼，入了門的安卓萌新們應(yīng)該都知道，項目中的activity和fragment必須要有統(tǒng)一的基類挑秉，也就是我們常說的BaseActivity和BaseFragment（連這個都沒有概念的同學法梯，恭喜你，連萌新都不算╮(╯▽╰)╭），那么為什么我們需要這兩個基類立哑？
??簡單來說BaseActivity和BaseFragment有利于我們對整個項目中所有activity和fragment的統(tǒng)一管理夜惭，舉個例子，界面跳轉(zhuǎn)铛绰，應(yīng)該沒人不會寫吧诈茧？通常我們會這么寫（看過我另一篇文章的同學都知道，我是主用mvp模式進行開發(fā)的捂掰，不過這里的講解敢会，我盡量以mvc為例）：
傳送門：我的mvp框架
??為了減少敘述，下面同一以BaseActivity為例
Intent intent = new Intent(this,LoginActivity.class);
startActivity(intent);
有的同學可能就不懂了这嚣，這個和基類有什么關(guān)系鸥昏？我相信做過幾個項目的同學應(yīng)該都挺煩這個代碼的，為什么呢姐帚，因為這兩行代碼毫無營養(yǎng)吏垮，但是你每次跳轉(zhuǎn)界面卻又不得不寫，因為標準寫法就是這樣啊罐旗，有一定封裝經(jīng)驗的同學可能會想膳汪，這還不簡單，封裝個utils類唄尤莺，比如下面這樣：
ActivityUtils.goActivity(this,LoginActivity.class);
//======================================================
public static <S extends Activity> void goActivity(Activity activity, Class<S> cls ){
Intent intent = new Intent(activity,cls);
activity.startActivity(intent);
}
這樣寫相比每次都要自己去new Intent來說旅敷，確實好很多，但是在我看來還是不夠簡潔颤霎，如果我們在基類中添加一個方法媳谁，然后就可以簡單只傳入我們所必須的參數(shù)也就是我們所需要跳轉(zhuǎn)的類名，如下：
goActivity(LoginActivity.class);
//======================================================
public <S extends Activity> void goActivity( Class<S> cls ){
Intent intent = new Intent(this,cls);
startActivity(intent);
}
這樣友酱，你會發(fā)現(xiàn)晴音，我們傳的參數(shù)真正做到了，只傳我們覺得需要傳的缔杉，不再需要重復的傳入this了锤躁，也許你會覺得僅僅一個this而已，但是首先或详，跳轉(zhuǎn)界面這個代碼在項目里少說也會出現(xiàn)幾十次系羞，多傳一個this，也就意味著你要多寫幾十次霸琴，其次椒振，這里只是以跳轉(zhuǎn)為例而已，還有更多復雜的場景梧乘。
??如果說上面這個簡單的例子還不能讓你直觀的明白基類的意義澎迎，那么我們再來一個例子庐杨，這次就不貼代碼了，我們以實際場景中的業(yè)務(wù)為例夹供，話說你寫好了一個項目灵份，現(xiàn)在突然需要在每個activity的onCreate初始化時額外加載一個第三方sdk的初始化方法，這個需求是很常見的哮洽，如果沒有基類也就意味著填渠，你需要每個activiy都去復制粘貼，然而有了統(tǒng)一基類時袁铐，你只需要去BaseActivity中的onCreate中加上這行代碼即可揭蜒，這也就是開始說的，方便對activity進行統(tǒng)一管理了剔桨。明白這點之后，為什么基類會影響開發(fā)速度和后期維護難易度徙融，相信你就應(yīng)該能想到了洒缀。
??說了基類的重要性，再來簡單說說該如何封裝欺冀，當然树绩，這里只介紹一些技巧，并不會為大家提供具體基類（如果確實需要例子的隐轩，請參考本人的mvp庫）饺饭，因為大家的項目千變?nèi)f化，而且開發(fā)習慣各異职车，想要都使用一個統(tǒng)一封裝基類是不太現(xiàn)實的瘫俊，這也是為什么幾乎沒有人開源關(guān)于BaseActivity的封裝框架，我們先來看一張圖：
毫無疑問悴灵，BaseActivity就是我們項目的頂層封裝基類扛芽，RefreshActivity和ListActivity從名字上就可以知道了，是基于頂層基類對特定功能的二次封裝积瞒，而RefreshWebActivity則是基于RefreshActivity的二次封裝川尖，真正的界面是下面那幾個。
??明顯的茫孔，DetailActivity是一個帶有刷新web功能的界面叮喳，MainActivity則是可以刷新的主頁面，GoodsListActivity是一個帶有列表的商品清單界面缰贝，LoginActivity是一個普通的界面馍悟，功能單一，直接繼承自BaseActivity揩瞪。這么設(shè)計的好處在哪里呢赋朦？像帶有列表的界面，對于一般的項目而言，通常少則出現(xiàn)幾次宠哄，多則十幾次幾十次壹将，這時如果我們直接繼承自BaseActivity就會造成，列表的邏輯重復寫很多次毛嫉。
??有人可能會提問诽俯，那直接把列表邏輯寫在BaseActivity不就好了，何必再弄一個ListActivity承粤？明確的說暴区，這么設(shè)計并不好，如果遇到一點通用功能就往BaseActivity里寫辛臊，可能等你的項目寫完仙粱，你的基類也就幾千行了，后面其他人來看彻舰，絕對想把你按在地上摩擦伐割。這也是為什么你會發(fā)現(xiàn)哪怕官方的Activity都有什么FramgmentActivity，AppCompatActivity等之類的區(qū)分了刃唤，合理的分散功能比強行寫在一起更容易讓其他人使用隔心。
封裝技巧：
- 不要過度依賴繼承
??雖然上面已經(jīng)建議了分散功能進行封裝，但是尚胞，實踐中并不建議基類層次超過三層的設(shè)計硬霍，結(jié)構(gòu)過于復雜也會造成難于理解，不易維護笼裳。像上面的RefreshWebActivity已經(jīng)是處于第三層封裝了唯卖，所以不建議再繼承他進行基類封裝。不是過于復雜的功能侍咱，建議使用組合的方式來實現(xiàn)而不是僅僅通過繼承耐床，上面是以list功能為例，但是其實list的邏輯相對并不復雜楔脯，我們完全可以采用組合方式進行實現(xiàn)撩轰，這樣，如果我們的DetailActivity如果也需要list昧廷，只需要進行組合就好堪嫂。 - 控制基類層級
??上面也說過了，盡量不要超出3層的基類封裝木柬，方便其他人協(xié)同開發(fā)和自己的日后維護皆串。通常也不可能超過3層結(jié)構(gòu)，如果你超出了眉枕，請確認下自己的架構(gòu)設(shè)計恶复。 - 封裝高頻代碼
??例如toast代碼怜森，本身很簡單，也就一行的事谤牡，但是相對來說副硅，它的使用頻率算是比較高的，而且需要傳的參數(shù)還是比較煩的翅萤，建議在基類封裝出方法恐疲，這樣以后想使用第三方toast庫，也會很容易修改套么。 - 封裝復雜代碼
??比如彈窗的代碼培己，代碼行數(shù)其實還是偏多的，并且通常來說胚泌，一個應(yīng)用的彈窗樣式還是比較統(tǒng)一的省咨，沒必要到處實例化，直接在基類進行诸迟，可以更方便修改茸炒。 - 不添加冗余代碼
??這里包括兩點，一是阵苇，廢棄的方法功能模塊，及時清理掉感论，避免其他人使用時無意中引用到绅项，造成以后清理時大面積報錯，二是比肄，不要添加某些小眾功能邏輯到基類快耿，比如某個特殊的業(yè)務(wù)邏輯功能，可能出現(xiàn)了3,5次的樣子你就往基類里寫芳绩，這樣違背了面向?qū)ο蟮脑瓌t掀亥，并且以后你想直接復制這個基類到其他項目用又要刪除這部分邏輯。
備注：上面主要是以activity為例妥色，但是只要你擁有了基類的思想搪花，不管是framgment還是adapter之類的，你都應(yīng)該能舉一反三了嘹害。
2.第三方庫抉擇
許多同學在使用第三方庫的時候總是很糾結(jié)撮竿，不知道該用哪個，這里我簡單介紹下我自己選擇第三方庫的一點點心得笔呀。
- star數(shù)
??這點相信是大部分人都知道的一點幢踏，我們盡量避免使用github上只有個位數(shù)star的庫，不是說個位數(shù)star的庫都不好许师，而是對于萌新來說房蝉，別人的庫怎么樣僚匆，可能很難一眼看出來，這時候看star數(shù)就是最直觀的了搭幻，至于那些優(yōu)秀的個位數(shù)的star的庫咧擂，還是交給老司機去發(fā)掘吧，大家就不要作死了粗卜。 - 查看issues詳情
??包括作者的解決效率屋确，大家反饋的一些問題和bug - 更新頻率
??留意下作者的更新頻率，如果是一兩年沒有更新的庫续扔，自己用之前最好能看下源碼攻臀，是否出了bug有把握能修復，當然建議還是使用更新頻率較高的庫（說明作者持續(xù)在關(guān)注） - 文檔
??使用別人的庫纱昧，文檔真的很重要（遇到好多萌新都是不看文檔刨啸，喜歡直接加群，去問別人识脆，這種習慣真的要盡快改掉）设联，不然遇到問題的話你可能只能聯(lián)系作者或者自己默默去看源碼了 - 使用難易度
??有些庫可能是針對一些老鳥進行封裝的，所以使用起來會讓萌新們感覺不適應(yīng)灼捂，所以如果有替換的离例，可以考慮先放棄這個庫，等以后水平上升了再換悉稠。
總結(jié)：不要只看star數(shù)宫蛆，star數(shù)不代表一切，要知道某寶已經(jīng)可以代刷star數(shù)了的猛，遇到很多個star數(shù)差不多的庫時耀盗，還是要綜合上面幾點多看看，自己評估一下用哪個
這次的分享就到此為止了卦尊，大家對我分享的東西有任何異議和問題的都歡迎提出叛拷。下次的分享暫內(nèi)容還沒想好，如果大家有什么想了解的岂却，也可以在評論中提出忿薇，我會考慮下次分享一下，持續(xù)更新淌友，歡迎大家關(guān)注
