androidmvpretrofit

『壹』 android開發一般都使用什麼框架

Android開發框架介紹
編輯文檔
學分 +2
開發框架方麵包含基本的應用功能開發、數據存儲、網路訪問這三大塊：
一、應用方面
一般而言一個標準的Android程序由如下4部分組成即Activity、Broadcast Intent Receiver、Service、Content Provider： 1. Activity是最頻繁、最基本的模塊，在Android中，一個Activity就是手機上一屏，相當於一個網頁一樣，所不同的是，每個Activity運行結束了，有個返回值，類似一個函數一樣。Android系統會自動記錄從首頁到其他頁面的所有跳轉記錄並且自動將以前的Activity壓入系統堆棧，用戶可以通過編程的方式刪除歷史堆棧中的Activity Instance。
Activity類中主要是跟界面資源文件關聯起來（res/layout目錄下的xml資源，也可以不含任何界面資源），內部包含控制項的顯示設計、界面交互設計、事件的響應設計以及數據處理設計、導航設計等application設計的方方面面。 2. Broadcast Intent Receiver
Intent提供了各種不同Activity進行跳轉的機制，譬如如果從A activity跳轉到B activity，使用Intent來實現如下： Intent in = new Intent(A.this, B.class); startActivity(in);
BroadcastReceiver提供了各種不同的Android應用程序進行進行進程間通訊的機制，譬如當電話呼叫來臨時，可以通過BroadcastReceiver發布廣播消息。對於用戶而言，BroadcastReceiver是不透明的，用戶無法看到這個事件，BroadcastReceiver通過NotificationManager來通知用戶這些事件發生了，它既可以在資源AndroidManifest.xml中注冊，也可以在代碼中通過Context.registerReceiver()進行注冊，只要是注冊了，當事件來臨的時候，即時程序沒有啟動，系統也在需要的時候會自動啟動此應用程序；另外各應用程序很方便地通過Context.sendBroadcast()將自己的事情廣播給其他應用程序；
3. Service,跟Windows當中的Service完全是一個概念，用戶可以通過startService(Intent service)啟動一個Service，也可通過Context.bindService來綁定一個Service.
4. Content Provider，由於Android應用程序內部的數據都是私有的，Content Provider提供了應用程序之間數據交換的機制，一個程序可以通過實現一個ContentProvider的抽象介面將自己的數據暴露出去，並且隱蔽了具體的數據存儲實現，標準的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的介面，並且實現了許可權機制，保護了數據交互的安全性； 一個標準的Android應用程序的工程文件包含如下幾大部分： -> java源代碼部分(包含Activity)，都在src目錄當中；
-> R.java文件，這個文件是Eclipse自動生成與維護的，開發者不需要修改，提供了Android對的資源全局索引； -> Android Library，這個是應用運行的Android庫；
-> assets目錄，這個目錄裡面主要用與放置多媒體等一些文件；
-> res目錄，放置的是資源文件,跟VC中的資源目錄基本類似，其中的drawable包含的是圖片文件，layout裡麵包含的是布局文件，values目錄裡面主要包含的是字元串(strings.xml)、顏色（colors.xml)以及數組（arrays.xml)資源；
-> AndroidManifest.xml，這個文件異常重要，是整個應用的配置文件，在這個文件中，需要聲明所有用到的Activity、Service、Receiver等。

『貳』 如何構建Android MVVM 應用框架

我們先來看看什麼是MVVM，然後再一步一步來設計整個MVVM框架。
MVC、MVP、MVVM
首先，我們先大致了解下Android開發中常見的模式。
MVC
View：XML布局文件。
Model：實體模型（數據的獲取、存儲、數據狀態變化）。
Controllor：對應於Activity，處理數據、業務和UI。
從上面這個結構來看，Android本身的設計還是符合MVC架構的，但是Android中純粹作為View的XML視圖功能太弱，我們大量處理View的邏輯只能寫在Activity中，這樣Activity就充當了View和Controller兩個角色，直接導致Activity中的代碼大爆炸。相信大多數Android開發者都遇到過一個Acitivty數以千行的代碼情況吧！所以，更貼切的說法是，這個MVC結構最終其實只是一個Model-View（Activity:View&Controller）的結構。
MVP
View:對應於Activity和XML，負責View的繪制以及與用戶的交互。
Model:依然是實體模型。
Presenter:負責完成View與Model間的交互和業務邏輯。
前面我們說，Activity充當了View和Controller兩個角色，MVP就能很好地解決這個問題，其核心理念是通過一個抽象的View介面（不是真正的View層）將Presenter與真正的View層進行解耦。Persenter持有該View介面，對該介面進行操作，而不是直接操作View層。這樣就可以把視圖操作和業務邏輯解耦，從而讓Activity成為真正的View層。
但MVP也存在一些弊端：
Presenter（以下簡稱P）層與View（以下簡稱V）層是通過介面進行交互的，介面粒度不好控制。粒度太小，就會存在大量介面的情況，使代碼太過碎版化；粒度太大，解耦效果不好。同時對於UI的輸入和數據的變化，需要手動調用V層或者P層相關的介面，相對來說缺乏自動性、監聽性。如果數據的變化能自動響應到UI、UI的輸入能自動更新到數據，那該多好！
MVP是以UI為驅動的模型，更新UI都需要保證能獲取到控制項的引用，同時更新UI的時候要考慮當前是否是UI線程，也要考慮Activity的生命周期（是否已經銷毀等）。
MVP是以UI和事件為驅動的傳統模型，數據都是被動地通過UI控制項做展示，但是由於數據的時變性，我們更希望數據能轉被動為主動，希望數據能更有活性，由數據來驅動UI。
V層與P層還是有一定的耦合度。一旦V層某個UI元素更改，那麼對應的介面就必須得改，數據如何映射到UI上、事件監聽介面這些都需要轉變，牽一發而動全身。如果這一層也能解耦就更好了。
復雜的業務同時也可能會導致P層太大，代碼臃腫的問題依然不能解決。
MVVM
View:對應於Activity和XML，負責View的繪制以及與用戶交互。
Model:實體模型。
ViewModel:負責完成View與Model間的交互，負責業務邏輯。
MVVM的目標和思想與MVP類似，利用數據綁定(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一個更加靈活高效的架構。
數據驅動
在常規的開發模式中，數據變化需要更新UI的時候，需要先獲取UI控制項的引用，然後再更新UI。獲取用戶的輸入和操作也需要通過UI控制項的引用。在MVVM中，這些都是通過數據驅動來自動完成的，數據變化後會自動更新UI，UI的改變也能自動反饋到數據層，數據成為主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不需要直接和UI打交道，在業務處理過程中簡單方便很多。
低耦合度
MVVM模式中，數據是獨立於UI的。
數據和業務邏輯處於一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和UI或者控制項打交道。UI想怎麼處理數據都由UI自己決定，ViewModel不涉及任何和UI相關的事，也不持有UI控制項的引用。即便是控制項改變了（比如：TextView換成EditText），ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點。
更新UI
在MVVM中，數據發生變化後，我們在工作線程直接修改（在數據是線程安全的情況下）ViewModel的數據即可，不用再考慮要切到主線程更新UI了，這些事情相關框架都幫我們做了。
團隊協作
MVVM的分工是非常明顯的，由於View和ViewModel之間是鬆散耦合的：一個是處理業務和數據、一個是專門的UI處理。所以，完全由兩個人分工來做，一個做UI（XML和Activity）一個寫ViewModel，效率更高。
可復用性
一個ViewModel可以復用到多個View中。同樣的一份數據，可以提供給不同的UI去做展示。對於版本迭代中頻繁的UI改動，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二選擇。
單元測試
有些同學一看到單元測試，可能腦袋都大。是啊，寫成一團漿糊的代碼怎麼可能做單元測試？如果你們以代碼太爛無法寫單元測試而逃避，那可真是不好的消息了。這時候，你需要MVVM來拯救。
我們前面說過了，ViewModel層做的事是數據處理和業務邏輯，View層中關注的是UI，兩者完全沒有依賴。不管是UI的單元測試還是業務邏輯的單元測試，都是低耦合的。在MVVM中數據是直接綁定到UI控制項上的（部分數據是可以直接反映出UI上的內容），那麼我們就可以直接通過修改綁定的數據源來間接做一些Android UI上的測試。
通過上面的簡述以及模式的對比，我們可以發現MVVM的優勢還是非常明顯的。雖然目前Android開發中可能真正在使用MVVM的很少，但是值得我們去做一些探討和調研。
如何構建MVVM應用框架
如何分工
構建MVVM框架首先要具體了解各個模塊的分工。接下來我們來講解View、ViewModel、Model它們各自的職責所在。
View
View層做的就是和UI相關的工作，我們只在XML、Activity和Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們在Activity不寫業務邏輯和業務數據相關的代碼，更新UI通過數據綁定實現，盡量在ViewModel裡面做（更新綁定的數據源即可），Activity要做的事就是初始化一些控制項（如控制項的顏色，添加RecyclerView的分割線），View層可以提供更新UI的介面（但是我們更傾向所有的UI元素都是通過數據來驅動更改UI），View層可以處理事件（但是我們更希望UI事件通過Command來綁定）。 簡單地說：View層不做任何業務邏輯、不涉及操作數據、不處理數據，UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel只做和業務邏輯和業務數據相關的事，不做任何和UI相關的事情，ViewModel 層不會持有任何控制項的引用，更不會在ViewModel中通過UI控制項的引用去做更新UI的事情。ViewModel就是專注於業務的邏輯處理，做的事情也都只是對數據的操作（這些數據綁定在相應的控制項上會自動去更改UI）。同時DataBinding框架已經支持雙向綁定，讓我們可以通過雙向綁定獲取View層反饋給ViewModel層的數據，並對這些數據上進行操作。關於對UI控制項事件的處理，我們也希望能把這些事件處理綁定到控制項上，並把這些事件的處理統一化，為此我們通過BindingAdapter對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對於每個事件我們用一個ReplyCommand 去處理就行了，ReplyCommand 會把你可能需要的數據帶給你，這使得我們在Vie，具體見 MVVM Light Toolkit 使用指南的 Command 部分 。再強調一遍：ViewModel 不做和UI相關的事。
Model
Model層最大的特點是被賦予了數據獲取的職責，與我們平常Model層只定義實體對象的行為截然不同。實例中，數據的獲取、存儲、數據狀態變化都是Model層的任務。Model包括實體模型（Bean）、Retrofit的Service ，獲取網路數據介面，本地存儲（增刪改查）介面，數據變化監聽等。Model提供數據獲取介面供ViewModel調用，經數據轉換和操作並最終映射綁定到View層某個UI元素的屬性上。
如何協作
關於協作，我們先來看下面的一張圖：

上圖反應了MVVM框架中各個模塊的聯系和數據流的走向，我們從每個模塊一一拆分來看。那麼我們重點就是下面的三個協作。
ViewModel與View的協作 。
ViewModel與Model的協作 。
ViewModel與ViewModel的協作 。
ViewModel與View的協作

圖2中ViewModel和View是通過綁定的方式連接在一起的，綁定分成兩種：一種是數據綁定，一種是命令綁定。數據的綁定DataBinding已經提供好了，簡單地定義一些ObservableField就能把數據和控制項綁定在一起了（如TextView的text屬性），但是DataBinding框架提供的不夠全面，比如說如何讓一個URL綁定到一個ImageView，讓這個ImageView能自動去載入url指定的圖片，如何把數據源和布局模板綁定到一個ListView，讓ListView可以不需要去寫Adapter和ViewHolder相關的東西？這些就需要我們做一些工作和簡單的封裝。MVVM Light Toolkit 已經幫我們做了一部分的工作,關於事件綁定也是一樣，MVVM Light Toolkit 做了簡單的封裝，對於每個事件我們用一個ReplyCommand去處理就行了，ReplyCommand 會把可能需要的數據帶給你，這樣我們處理事件的時候也只關心處理數據就行了.
由 圖 1 中ViewModel的模塊中我們可以看出ViewModel類下面一般包含下面5個部分：
Context （上下文）
Model (數據源 Java Bean)
Data Field （數據綁定）
Command （命令綁定）
Child ViewModel （子ViewModel）
我們先來看下示例代碼，然後再一一講解5個部分是幹嘛用的：
//context
private Activity context;
//model（數據源 Java Bean）
private NewsService.News news;
private TopNewsService.News topNews;
//數據綁定，綁定到UI的欄位（data field）
public final ObservableField<String> imageUrl = new ObservableField<>();
public final ObservableField<String> html = new ObservableField<>();
public final ObservableField<String> title = new ObservableField<>();
// 一個變數包含了所有關於View Style 相關的欄位
public final ViewStyle viewStyle = new ViewStyle();
//命令綁定（command）
public final ReplyCommand onRefreshCommand = new ReplyCommand<>(() -> {

})
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {

});

//Child ViewModel
public final ObservableList<NewItemViewModel> itemViewModel = new ObservableArrayList<>();

/** * ViewStyle 關於控制項的一些屬性和業務數據無關的Style 可以做一個包裹，這樣代碼比較美觀，
ViewModel 頁面也不會有太多太雜的欄位。 **/
public static class ViewStyle {
public final ObservableBoolean isRefreshing = new ObservableBoolean(true);
public final ObservableBoolean progressRefreshing = new ObservableBoolean(true);
}

Context
Context是幹嘛用的呢，為什麼每個ViewModel都最好需要持了一個Context的引用呢？ViewModel不處理和UI相關的事也不操作控制項，更不更新UI，那為什麼要有Context呢？原因
Model是什麼呢？其實就是數據源，可以簡單理解是我們用JSON轉過來的Bean。ViewModel要把數據映射到UI中可能需要大量對Model的數據拷貝和操作，拿Model的欄位去生成對應的ObservableField然後綁定到UI（我們不會直接拿Model的數據去做綁定展示），這里是有必要在一個ViewModel保留原始的Model引用，這對於我們是非常有用的，因為可能用戶的某些操作和輸入需要我們去改變數據源，可能我們需要把一個Bean在列表頁點擊後傳給詳情頁，可能我們需要把這個Model當做表單提交到伺服器。這些都需要我們的ViewModel持有相應的Model（數據源）。
Data Field（數據綁定）
Data Field就是需要綁定到控制項上的ObservableField欄位，這是ViewModel的必需品，這個沒有什麼好說。但是這邊有一個建議：
這些欄位是可以稍微做一下分類和包裹的。比如說可能一些欄位是綁定到控制項的一些Style屬性上（如長度、顏色、大小），對於這類針對View Style的的欄位可以聲明一個ViewStyle類包裹起來，這樣整個代碼邏輯會更清晰一些，不然ViewModel裡面可能欄位泛濫，不易管理和閱讀性較差。而對於其他一些欄位，比如說title、imageUrl、name這些屬於數據源類型的欄位，這些欄位也叫數據欄位，是和業務數據和邏輯息息相關的，這些欄位可以放在一塊。
Command（命令綁定）
Command（命令綁定）簡言之就是對事件的處理（下拉刷新、載入更多、點擊、滑動等事件處理）。我們之前處理事件是拿到UI控制項的引用，然後設置Listener，這些Listener其實就是Command。但是考慮到在一個ViewModel寫各種Listener並不美觀，可能實現一個Listener就需要實現多個方法，但是我們可能只想要其中一個有用的方法實現就好了。更重要一點是實現一個Listener可能需要寫一些UI邏輯才能最終獲取我們想要的。簡單舉個例子，比如你想要監聽ListView滑到最底部然後觸發載入更多的事件，這時候就要在ViewModel裡面寫一個OnScrollListener，然後在裡面的onScroll方法中做計算，計算什麼時候ListView滑動底部了。其實ViewModel的工作並不想去處理這些事件，它專注做的應該是業務邏輯和數據處理，如果有一個東西不需要你自己去計算是否滑到底部，而是在滑動底部自動觸發一個Command，同時把當前列表的總共的item數量返回給你，方便你通過 page=itemCount/LIMIT+1去計算出應該請求伺服器哪一頁的數據那該多好啊。MVVM Light Toolkit 幫你實現了這一點：
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {
int page=itemCount/LIMIT+1;
loadData(page.LIMIT)
});

接著在XML布局文件中通過bind:onLoadMoreCommand綁定上去就行了。
<android.support.v7.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
bind:onLoadMoreCommand="@{viewModel.loadMoreCommand}"/>
x

當然Command並不是必須的，你完全可以依照自己的習慣和喜好在ViewModel寫Listener，不過使用Command可以使ViewModel更簡潔易讀。你也可以自己定義更多的、其他功能的Command，那麼ViewModel的事件處理都是託管ReplyCommand 來處理，這樣的代碼看起來會比較美觀和清晰。Command只是對UI事件的一層隔離UI層的封裝，在事件觸發時把ViewModel層可能需要的數據傳給ViewModel層，對事件的處理做了統一化，是否使用的話，還是看你個人喜好了。
Child ViewModel（子ViewModel）
子ViewModel的概念就是在ViewModel裡面嵌套其他的ViewModel，這種場景還是很常見的。比如說你一個Activity裡面有兩個Fragment，ViewModel是以業務劃分的，兩個Fragment做的業務不一樣，自然是由兩個ViewModel來處理，這時候Activity對應的ViewModel裡面可能包含了兩個Fragment各自的ViewModel，這就是嵌套的子ViewModel。還有另外一種就是對於AdapterView，如ListView RecyclerView、ViewPager等。
//Child ViewModelpublic final
ObservableList<ItemViewModel> itemViewModel = new ObservableArrayList<>();

它們的每個Item其實就對應於一個ViewModel，然後在當前的ViewModel通過ObservableList 持有引用（如上述代碼），這也是很常見的嵌套的子ViewModel。我們其實還建議，如果一個頁面業務非常復雜，不要把所有邏輯都寫在一個ViewModel，可以把頁面做業務劃分，把不同的業務放到不同的ViewModel，然後整合到一個總的ViewModel，這樣做起來可以使我們的代碼業務清晰、簡短意賅，也方便後人的維護。
總的來說，ViewModel和View之前僅僅只有綁定的關系，View層需要的屬性和事件處理都是在XML裡面綁定好了，ViewModel層不會去操作UI，只是根據業務要求處理數據，這些數據自動映射到View層控制項的屬性上。關於ViewModel類中包含哪些模塊和欄位，這個需要開發者自己去衡量，我們建議ViewModel不要引入太多的成員變數，成員變數最好只有上面的提到的5種（context、model……），能不引入其他類型的變數就盡量不要引進來，太多的成員變數對於整個代碼結構破壞很大，後面維護的人要時刻關心成員變數什麼時候被初始化、什麼時候被清掉、什麼時候被賦值或者改變，一個細節不小心可能就出現潛在的Bug。太多不清晰定義的成員變數又沒有注釋的代碼是很難維護的。
另外，我們會把UI控制項的屬性和事件都通過XML（如bind：text=@{...}）綁定。如果一個業務邏輯要彈一個Dialog，但是你又不想在ViewModel裡面做彈窗的事（ViewModel不希望做UI相關的事）或者說改變ActionBar上面的圖標的顏色，改變ActionBar按鈕是否可點擊，這些都不是寫在XML裡面（都是用Java代碼初始化的），如何對這些控制項的屬性做綁定呢？我們先來看下代碼：
public class MainViewModel implements ViewModel {
....
//true的時候彈出Dialog，false的時候關掉dialog
public final ObservableBoolean isShowDialog = new ObservableBoolean();
....
.....
}
// 在View層做一個對isShowDialog改變的監聽
public class MainActivity extends RxBasePmsActivity {

private MainViewModel mainViewModel;

@Override
protected void onCreate(Bundle savedInstanceState) {
.....
mainViewModel.isShowDialog.addOnPropertyChangedCallback(new android.databinding.Observable.OnPropertyChangedCallback() {
@Override
public void onPropertyChanged(android.databinding.Observable sender, int propertyId) {
if (mainViewModel.isShowDialog.get()) {
dialog.show();
} else {
dialog.dismiss();
}
}
});
}
...
}

簡單地說你可以對任意的ObservableField做監聽，然後根據數據的變化做相應UI的改變，業務層ViewModel只要根據業務處理數據就行，以數據來驅動UI。

『叄』 Android大廠面試經驗分享（OPPO，位元組，華為，阿里）

我是從小公司跳出來的，最終入職OPPO，說實話這段時間的經歷讓我深深地感受到，我們為跳槽做的一些臨時抱佛腳的提升跟那些大佬的沉澱比起來太渺小了。我們都知道找資料學習、刷面試題，但也許只能應付這一次的面試，後面還是會技術發愁，那些短時間背下來的東西遲早會忘掉， 大家還是做好長期提升自己的准備，好好沉澱的東西最後才是屬於自己的。

說說當時的面試過程，我是內推獲得的面試機會，很感謝當時幫我內推的兄弟，總共三輪面試，兩輪技術，一輪HR面，當天面試結束。

我10：10分到的公司，10：30開始面試，第一輪面試將近一個小時，聊的點我基本上都答得上來，自我感覺良好。然後面試官讓我等一下，他去叫他們老大來給我二面，我等了有二十幾分鍾吧，二面有一個多小時，這次問的比較深，有些地方答的有些嗑吧，總體來說我自己是滿意的。HR面約到下午了，整個流程下來每輪面試官都讓人感覺很不錯，我自己做的准備也讓我面試感覺下來很爽。

我把面試遇到過的以及自己學慣用到過相關內容都整理到一起了，方便自己進行復盤和後續的查漏補缺：

一、 Java基礎

1.1 靜態內部類和非靜態內部類的比較

1.2 多態的理解與應用

1.3 java方法的多態性理解

1.4 java中介面和繼承的區別

1.5 線程池的好處，詳解，單例（絕對好記）

1.6 線程池的優點及其原理

1.7 線程池的優點（重點）

1.8 為什麼不推薦通過Executors直接創建線程池

1.9 不怕難之BlockingQueue及其實現

1.10 深入理解ReentrantLock與Condition

1.11 Java多線程：線程間通信之Lock

1.12 Synchronized 關鍵字原理

1.13 ReentrantLock原理

1.14 HashMap中的Hash沖突解決和擴容機制

1.14 Java並發

1.15 Java虛擬機

1.16 JVM常見面試題

1.17 JVM內存結構

1.18 類載入機制/雙親委託

二、 Android基礎

2.1 Activity知識點(必問)

2.2 Fragment知識點

2.3 Service知識點

2.4 Intent知識點

2.5 數據存儲

三、UI控制項篇

3.1 屏幕適配

3.2 主要控制項優化

3.3 事件分發與嵌套滾動

3.4 動態化頁面構建方案

四、網路通信篇

4.1 網路協議

五、架構設計篇

5.1 MVP架構設計

5.2 組件化架構

六、性能優化篇

6.1 啟動優化

6.2 內存優化

6.3 繪制優化

6.4 安裝包優化

七、源碼流程篇

7.1 開源庫源碼分析

7.2 Glide源碼分析

7.3 day 20 面試題：Glide面試題

7.4 聊一聊關於Glide在面試中的那些事

7.5 面試官：簡歷上如果寫Glide，請注意以下幾點…

7.6 Glide OOM問題解決方法匯總

7.7 LeakCanary源碼分析

7.8 OkHttp源碼分析

7.9 okhttp連接池復用機制

7.10 okhttp 流程和優化的實現

7.11 一篇讓你受用的okhttp分析

7.12 OkHttp面試之–OkHttp的整個非同步請求流程

7.13 OkHttp面試之–HttpEngine中的sendRequest方法詳解

7.14 OkHttp解析大總結

7.15 Okhttp任務隊列工作原理

7.16 Android高頻面試專題 - 架構篇（二）okhttp面試必知必會

7.17 Android 網路優化，使用 HTTPDNS 優化 DNS，從原理到 OkHttp 集成

7.18 Retrofit源碼分析

7.19 RxJava源碼分析

7.20 RxJava原理與源碼分析

7.21 RxJava如何進行線程切換的？

7.22 Rxjava內存泄漏防止方案——RxLifecycle，AutoDispose，RxLife框架

7.23 Tinker源碼分析

7.24 ARouter源碼分析

7.25 Android框架層源碼解析

7.26 演算法設計

八、新技術篇

8.1 實戰問題篇

九、面試篇

9.1 開源文檔

9.2 面試文獻

以上就是我的學習和面試積累，有自己面試經歷過的，也有整理的一些大廠面試題，篇幅有限，具體內容就不展示了，我已經整理成文檔了。

還是開頭說的，僅靠面試期間臨時抱佛腳和刷題對自身發展不是長久之計，做好長期提升的規劃，好好沉澱每一次的學習和面試經歷，把這些最終都轉化成屬於自己的東西才是實質上對自己最有用的。

『肆』 Android活動命名是怎樣的規則

一．標識符命名方法
1 .小駝峰命名法，除首單詞外，其餘所有單詞的第一個字母大寫。如：allPrice，getAllNames
2.大駝峰命名法，所有單詞的第一個字母大寫。如：GuideActivity，StudentInfoBean
3.下劃線命名法:單詞與單詞間用下劃線做間隔。如：activity_main,select_backGround_color
二．命名規范
（一）包（packages）的命名規范:
採用反域名命名規則，全部使用小寫字母。一級包名為com，二級包名lwz（為個人或公司名稱，可以簡寫），三級包名guidecity（根據應用進行命名），四級包名ui或utils等（模塊名或層級名），根據實際情況也是可以用五級包名，六級包名。
這里的四級包名是要重點理解和分類的，例如：com.lwz.應用.utils ，此包中包含：公共工具方法類
1.utils
此包中包含：公共工具方法類，比如：SPHelperUtil、TimeUitl、FileUtil等
2.adapter
此包中包含：一些適配器的類，比如：ArticleAdapter、FansAdapter，HistorAdaper等
3.base
此包中包含：一些共同類的基類，比如：BaseActivity（所有的Activity類都繼承這個類）、BaseFragment（所有的Fragment都繼承這個類），ListItemAdapter（封裝了Base Adapter的基類）等
4.bean
此包中包含：一些屬性對象類，比如：StudentBean、LonginBean、ArticleBean等
5.config
此包中包含：最頂級的配置類，比如：MyApp（繼承了Application）
6.httpservice
此包中包含：Http數據的請求介面類，好像Retrofit網路框架請求網路數據才要使用。如：ILogin介面，IAddTopic介面，IUpdate等
7.interface
此包中包含：某個頁面或對象的所用操作介面類，這個介面主要是定義這個對象的所有方法。如：IUser介面，IArticle介面，ITopic介面等
8.model
這是MVC或MVP框架設計中的M。此包中包含：某個頁面或對象的所用操作類，這個類繼承了上面定義的interface介面，重寫並實現厘米那的方法。如：UserModel，ArticleMode類，TopicMode類等
9.ui
這個ui表示的頁面的意思，也是MVC或MVP中的V，很多人把這個包名寫成activity，其實是不準確的，因為ui包含了activity和fragment，所以ui是四級包名，而activity和fragment是ui包下的五級包名。
activity此包中包含：Activity對象類。如：MainActivity類，HomeActivity類，FansListActivity類等。如果是使用了MVP框架模式，activity包名下還可以有六級包名，比如：loginMVP（包含ILoginView介面類，LoginPresenter類）、seleteTopicMVP
fragment此包中包含：Fragment對象類。但是Fragment一般都是多個存在的，所以fragment包下一般還有六級包名，表示裡面是哪個頁面的Fragment對象。
10.weight
此包中包含：自定義View或自定義對話框等視圖類。如：CursroDialog類，SpringScrollView類，ScrollListView類等
11.db
此包中包含：資料庫操作類
12.service
此包中包含：Service服務類
13.broadcast
此包中包含：Broadcast廣播接收者類
14.provider
此包中包含：Provider內容提供者類（用得很少）
包名規劃我感覺對程序後期閱讀或修改有很大的幫助，特別是很大的程序，文件太多，不規劃的話自己都不知道這個類是干什麼的！
當然如果程序中沒有這一類的文件，這個包名是可以不寫，但是一些基本的包名，基本每個程序都是需要的比如：ui、utils、adapter、weight、bean等
（二）類（classes）的命名規范：
一般用名詞，採用大駝峰命名法，盡量避免縮寫，除非該縮寫是眾所周知的，比如HTML,URL，如果類名稱中包含單詞縮寫，則單詞縮寫的每個字母均應大寫。
以下是部分示例說明：
1.activity 類，如歡迎頁面類WelcomeActivity.
2.adapter類,如商品詳情適配器ProctDetailAdapter
3.util公共方法類，如：線程池管理類：ThreadPoolManager，日誌工具類：LogUtil
4.db資料庫類，以DBHelper後綴標識。如城市資料庫：CityDBHelper
5.Service類，以Service為後綴標識
6.BroadcastReceive，以Broadcast為後綴標識
7.ContentProvider，以Provider為後綴標識
（三）介面（interface）：
命名規則與類一樣採用大駝峰命名法，多以able或ible結尾或以I開頭，如Runnable、Accessible、IUser。
（四）方法（methods）的命名規則：
一般使用動詞或動名詞，採用小駝峰命名法 例如:onCreate(),run()
>1.initXXX()初始化相關方法,使用init為前綴標識
2.isXXX()、checkXXX() 方法返回值為boolean型的請使用is或check為前綴標識
3.getXXX()返回某個值的方法，使用get為前綴標識
4.processXXX() 對數據進行處理的方法，盡量使用process為前綴標識
5.displayXXX() 彈出提示框和提示信息，使用display為前綴標識
6.saveXXX() 與保存數據相關的，使用sav為e前綴標識
7.resetXXX() 對數據重組的，使用reset前綴標識
8.clearXXX()removeXXX() 清除數據相關的，使用clear或remove為前綴標識
9.drawXXX() 繪制數據或效果相關的，使用draw前綴標識

（五）變數（variables）採用小駝峰命名法。類中控制項名稱一般與xml布局id保持一致
（六）常量（constants）全部大寫,採用下劃線命名法.例如：MIN_WIDTH
（七）XML文件（布局文件）：全部小寫，採用下劃線命名法，
例如：main_activity.xml， item_activity.xml、homeposter_item_poster.xml
（八）資源文件（圖片）： 全部小寫，採用下劃線命名法，加前綴區分

命名
說明

btn_login_normal 按鈕圖片使用btn_功能_說明
bg_head 背景圖片使用bg_功能_說明
def_search_cell 默認圖片使用def_功能_說明
icon_more_help 圖標圖片使用icon_功能_說明
seg_list_line 具有分隔特徵的圖片使用seg_功能_說明
sel_ok 選擇圖標使用sel_功能_說明
（九）動畫文件（anim包）：全部小寫，採用下劃線命名法，加前綴區分。
動畫命名例子：

規范寫法
備注

click_head_left 點擊背景切換動畫使用click前綴標識
bg_shape_rectangle 背景自定義圖形使用bg前綴標識
show_shopcar_add 小動畫效果使用show前綴標識
（十）資源ID（resources id）：大小寫規范與方法名一致，採用小駝峰命名法。
命名規范為「資源控制項的縮寫名」+「變數名」。例如TextView的id=「tv_userName」。注意：頁面控制項名稱應該和控制項id名一般是一致，例如：TextView tv_userName=(TextView)findViewById(R.id.tv_userName);
三．圖解包名規范示例
本文主要是想對程序包名的命名規劃，這里展示我之前開發的程序的包名圖片，供大家參考：
（一）總顯示

上面example這個包名一般是不用的！
（二）ui包下
fragment展示

activity 展示：

（三）utils和weight包下

（四）res文件夾下的部分文件展示：

drawable包下：

layout包下：

上面就是一個完成程序的主要文件展示，這個程序大概有三百多個文件（包括java文件和資源文件），這里就不一一展示了！
大家可以想像一下，如果這個程序包名和文件名都沒有很好規劃，那麼你要找你想要的幾個文件是一個多麼麻煩的事情！
一般地，我在創建每個java程序文件都會在上面做幾句話的註解，說明一下這個文件的作用，有些布局文件也是有簡單說明。這樣更加有利於後期的程序代碼迭代或版本更新！
命名規范是必須的嗎？有些是！有些不是。比如包名、類的定義，系統沒有硬性規定，但是資源文件res文件夾下的命名，系統要求資源文件名必須小寫，否則，你的程序一直運行不了，你都不知道為啥。
最後說一句：程序開發中命名規范是一個很好的開發習慣！