android應用框架設計

① 如何構建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的框架開發

android應用開發框架是 Application Framework. 其系統架構由5部分組成，分別是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分將詳細介紹這5個部分。下面自底向上分析各層。 Android架構 1、Linux Kernel Android基於Linux 2.6提供核心系統服務，例如：安全、內存管理、進程管理、網路堆棧、驅動模型。Linux Kernel也作為硬體和軟體之間的抽象層，它隱藏具體硬體細節而為上層提供統一的服務。 如果你學過計算機網路知道OSI/RM，就會知道分層的好處就是使用下層提供的服務而為上層提供統一的服務，屏蔽本層及以下層的差異，當本層及以下層發生了變化不會影響到上層。也就是說各層各盡其職，各層提供固定的SAP（Service Access Point），專業點可以說是高內聚、低耦合。 如果你只是做應用開發，就不需要深入了解Linux Kernel層。 2、Android Runtime Android包含一個核心庫的集合，提供大部分在Java編程語言核心類庫中可用的功能。每一個Android應用程序是Dalvik虛擬機中的實例，運行在他們自己的進程中。Dalvik虛擬機設計成，在一個設備可以高效地運行多個虛擬機。Dalvik虛擬機可執行文件格式是.dex，dex格式是專為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。 大多數虛擬機包括JVM都是基於棧的，而Dalvik虛擬機則是基於寄存器的。兩種架構各有優劣，一般而言，基於棧的機器需要更多指令，而基於寄存器的機器指令更大。dx 是一套工具，可以將 Java .class 轉換成 .dex 格式。一個dex文件通常會有多個.class。由於dex有時必須進行最佳化，會使文件大小增加1-4倍，以ODEX結尾。 Dalvik虛擬機依賴於Linux 內核提供基本功能，如線程和底層內存管理。 3、Libraries Android包含一個C/C++庫的集合，供Android系統的各個組件使用。這些功能通過Android的應用程序框架（application framework）暴露給開發者。下面列出一些核心庫： 系統C庫--標准C系統庫（libc）的BSD衍生，調整為基於嵌入式Linux設備 媒體庫--基於PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式，以及靜態圖像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理訪問顯示子系統和無縫組合多個應用程序的二維和三維圖形層 LibWebCore--新式的Web瀏覽器引擎,驅動Android 瀏覽器和內嵌的web視圖 SGL--基本的2D圖形引擎 3D庫--基於OpenGL ES 1.0 APIs的實現。庫使用硬體3D加速或包含高度優化的3D軟體光柵 FreeType --點陣圖和矢量字體渲染 SQLite --所有應用程序都可以使用的強大而輕量級的關系資料庫引擎 4、Application Framework 通過提供開放的開發平台，Android使開發者能夠編制極其豐富和新穎的應用程序。開發者可以自由地利用設備硬體優勢、訪問位置信息、運行後台服務、設置鬧鍾、向狀態欄添加通知等等，很多很多。 開發者可以完全使用核心應用程序所使用的框架APIs。應用程序的體系結構旨在簡化組件的重用，任何應用程序都能發布他的功能且任何其他應用程序可以使用這些功能（需要服從框架執行的安全限制）。這一機制允許用戶替換組件。 所有的應用程序其實是一組服務和系統，包括： 視圖（View）--豐富的、可擴展的視圖集合，可用於構建一個應用程序。包括包括列表、網格、文本框、按鈕，甚至是內嵌的網頁瀏覽器 內容提供者（Content Providers）--使應用程序能訪問其他應用程序（如通訊錄）的數據，或共享自己的數據 資源管理器（Resource Manager）--提供訪問非代碼資源，如本地化字元串、圖形和布局文件 通知管理器（Notification Manager）--使所有的應用程序能夠在狀態欄顯示自定義警告 活動管理器（Activity Manager）--管理應用程序生命周期,提供通用的導航回退功能 5、Applications Android裝配一個核心應用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯系人和其他設置。所有應用程序都是用Java編程語言寫的。更加豐富的應用程序有待我們去開發！ 從上面我們知道Android的架構是分層的，非常清晰，分工很明確。Android本身是一套軟體堆迭(Software Stack)，或稱為「軟體迭層架構」，迭層主要分成三層：操作系統、中間件、應用程序。從上面我們也看到了開源的力量，一個個熟悉的開源軟體在這里貢獻了自己的一份力量。

③ 在Android開發過程中搭建一個自己的應用框架有幾個步驟

Android應用開發的框架步驟：

1. 項目工程搭建

在搭建工程結構的時候可以盡量抽取一些共用的東西，例如，資料庫操作、base、task、事件觀察者、通用的工具類、UI公共組件等等，這些東西應該表現在代碼結構中。

5.資料庫的處理

在處理資料庫的時候採用ContentProvider的方式。

6.圖片的處理

對圖片處理的軟體很多，只要把基本的一些開源框架原理搞清楚就可以了。

注意：在android開發項目中，首先要考慮的是這個項目或者說這個產品的核心功能。比如，圖片處理和展示類app，更多考慮對大量圖片的處理，防止OOM等等。

④ android開發框架有哪些

Android開發框架主要包括以下幾個：

一、Android官方SDK框架

Android官方SDK框架是Android開發的基礎，提供了Android系統的基礎組件和開發API。它包括視圖系統、資源系統、內容提供者、位置服務等模塊，使開發者能夠利用Android系統提供的各種功能進行應用開發。

二、MVC框架（Model-View-Controller）

MVC是一種常用的軟體設計模式，在Android開發中也有著廣泛的應用。MVC框架將應用程序分為三個基本組成部分：模型（Model）、視圖（View）和控制器（Controller）。這種分離的方式有助於代碼的模塊化，提高代碼的可維護性和可重用性。

三、MVVM框架（Model-View-ViewModel）

MVVM框架是MVC框架的一種改進，它引入了ViewModel層，使得視圖與業務邏輯之間通過ViewModel進行交互。這提高了代碼的清晰性和可測試性。在Android開發中，常見的MVVM框架實現有Data Binding和LiveData等。

四、Clean Architecture框架

Clean Architecture框架強調代碼的層次性和模塊化。它將應用分為多個層次，如數據層、領域層、UI層等，每層之間通過明確的介面進行交互。這種設計使得代碼更加清晰，易於維護和擴展。

五、Kotlin Android Extensions框架

Kotlin Android Extensions是Kotlin語言在Android開發中的一項特性，它簡化了視圖與代碼之間的交互。通過Kotlin的擴展屬性，開發者可以直接訪問UI組件，減少了大量繁瑣的代碼。此外，Kotlin的null安全特性也減少了空指針異常的風險。

⑤ android ui妗嗘灦鏈夊摢浜

Android UI妗嗘灦涓昏佸寘鎷浠ヤ笅鍑犱釜閮ㄥ垎錛

1. Android鍘熺敓UI妗嗘灦

Android緋葷粺鑷甯︾殑UI妗嗘灦鏄寮鍙戠殑鍩虹錛屽畠鍖呮嫭浜嗕竴緋誨垪鐨刄I緇勪歡錛屽侫ctivity銆丗ragment銆乂iew銆乂iewGroup絳夈傝繖浜涚粍浠朵負寮鍙戣呮彁渚涗簡鏋勫緩鐢ㄦ埛鐣岄潰鐨勫熀紜宸ュ叿錛屼緥濡傚竷灞銆佹帶浠躲佽彍鍗曞拰瀵硅瘽妗嗙瓑銆

2. Material Design妗嗘灦

Material Design鏄疓oogle鎺ㄥ嚭鐨勮捐¤璦妗嗘灦錛屽畠鍩轟簬綰歌川瑙︽劅鐨刄I璁捐°傚湪Android寮鍙戜腑錛孧aterial Design鎻愪緵浜嗕竴緋誨垪鐨刄I緇勪歡鍜岃捐¤勮寖錛屾棬鍦ㄥ府鍔╁紑鍙戣呭壋寤虹編瑙傘佺幇浠ｅ寲鐨勭敤鎴風晫闈銆傝繖涓妗嗘灦寮鴻皟鍔ㄧ敾鍜岃繃娓℃晥鏋滐紝鎻愬崌鍙嬫棭紲ョ敤鎴蜂綋楠屻

3. 絎涓夋柟UI妗嗘灦鍜屽簱

闄や簡Android鍘熷ソ鎼忕敓鍜孧aterial Design錛岃繕鏈夎稿氭祦琛岀殑絎涓夋柟UI妗嗘灦鍜屽簱鍙渚涗嬌鐢ㄣ備緥濡傦紝React Native鍙浠ョ敤浜庢瀯寤洪珮鎬ц兘鐨勫師鐢熺晫闈錛汧lutter鎻愪緵浜嗚法騫沖彴鐨勫紑鍙戣兘鍔涳紝鍙浠ユ瀯寤虹編瑙備笖鍝嶅簲榪呴熺殑鐢ㄦ埛鐣岄潰錛汮etpack Compose鏄疉ndroid Jetpack鐨勪竴鐫佸厗閮ㄥ垎錛屾彁渚涗簡涓縐嶆洿澹版槑寮忕殑UI緙栫▼鏂瑰紡銆傝繖浜涙嗘灦鍜屽簱涓哄紑鍙戣呮彁渚涗簡鏇村氶夋嫨鍜岀伒媧繪с

4. 鑷瀹氫箟UI妗嗘灦

寮鍙戣呬篃鍙浠ユ牴鎹欏圭洰鐨勯渶奼傦紝鑷琛屽壋寤哄畾鍒剁殑UI妗嗘灦銆傝繖閫氬父娑夊強瀵瑰師鐢熺粍浠剁殑鎵╁睍鍜屽畾鍒訛紝鎴栨槸鐩存帴浣跨敤寮婧愮粍浠跺簱鏉ュ疄鐜扮壒瀹氱殑鐢ㄦ埛鐣岄潰闇奼傘傞氳繃鑷瀹氫箟UI妗嗘灦錛屽彲浠ュ疄鐜版洿涓轟釜鎬у寲鍜屽壋鏂扮殑鐢ㄦ埛鐣岄潰璁捐°

Android UI妗嗘灦娑電洊浜嗗師鐢熸嗘灦銆丮aterial Design瑙勮寖銆佺涓夋柟搴撲互鍙婅嚜瀹氫箟妗嗘灦絳夊氫釜灞傞潰銆傚紑鍙戣呭彲浠ユ牴鎹欏圭洰鐨勯渶奼傚拰鍥㈤槦鐨勬妧鑳介夋嫨閫傚悎鐨勬嗘灦鏉ユ瀯寤虹敤鎴風晫闈銆傞殢鐫鎶鏈鐨勪笉鏂鍙戝睍錛孉ndroid UI妗嗘灦涔熷湪涓嶆柇鏇存柊鍜屾紨榪涳紝涓哄紑鍙戣呮彁渚涙洿澶氶夋嫨鍜屽彲鑳芥с

⑥ Android鎵嬫満搴旂敤寮鍙戜竴鑸閲囩敤浠涔堟嗘灦_瀹夊崜妗嗘灦鏄浠涔

android搴旂敤寮鍙戞嗘灦鏄疉pplicationFramework.鍏剁郴緇熸灦鏋勭敱5閮ㄥ垎緇勬垚錛屽垎鍒鏄錛歀inuxKernel銆丄ndroidRuntime銆丩ibraries銆丄pplicationFramework銆併傜浜岄儴鍒嗗皢璇︾粏浠嬬粛榪5涓閮ㄥ垎銆備笅闈㈣嚜搴曞悜涓婂垎鏋愬悇灞傘

Android鏋舵瀯

1銆丩inuxKernelAndroid

鍩轟簬Linux2.6鎻愪緵鏍稿績緋葷粺鏈嶅姟錛屼緥濡傦細瀹夊叏銆佸唴瀛樼＄悊銆佽繘紼嬬＄悊銆佺綉緇滃爢鏍堛侀┍鍔ㄦā鍨嬨侺inux

Kernel涔熶綔涓虹‖浠跺拰杞浠朵箣闂寸殑鎶借薄灞傦紝瀹冮殣鈃忓叿浣撶‖浠剁粏鑺傝屼負涓婂眰鎻愪緵緇熶竴鐨勬湇鍔°

濡傛灉浣犲﹁繃璁＄畻鏈虹綉緇滅煡閬揙SI/RM錛屽氨浼氱煡閬撳垎灞傜殑濂藉勫氨鏄浣跨敤涓嬪眰鎻愪緵鐨勬湇鍔¤屼負涓婂眰鎻愪緵緇熶竴鐨勬湇鍔★紝灞忚斀鏈灞傚強浠ヤ笅灞傜殑宸寮傦紝褰撴湰灞傚強浠ヤ笅灞傚彂鐢

浜嗗彉鍖栦笉浼氬獎鍝嶅埌涓婂眰銆備篃灝辨槸璇村悇灞傚悇灝藉叾鑱岋紝鍚勫眰鎻愪緵鍥哄畾鐨凷AP錛圫erviceAessPoint錛夛紝涓撲笟鐐瑰彲浠ヨ存槸楂樺唴鑱氥佷綆鑰﹀悎銆

濡傛灉浣犲彧鏄鍋氬簲鐢ㄥ紑鍙戱紝灝變笉闇瑕佹繁鍏ヤ簡瑙LinuxKernel灞傘

2銆丄ndroidRuntimeAndroid

鍖呭惈涓涓鏍稿績搴撶殑闆嗗悎錛屾彁渚涘ぇ閮ㄥ垎鍦↗ava緙栫▼璇璦鏍稿績綾誨簱涓鍙鐢ㄧ殑鍔熻兘銆傛瘡涓涓獮ndroid搴旂敤紼嬪簭鏄疍alvik鉶氭嫙鏈轟腑鐨勫疄渚嬶紝榪愯屽湪浠栦滑鑷宸

鐨勮繘紼嬩腑銆侱alvik鉶氭嫙鏈鴻捐℃垚錛屽湪涓涓璁懼囧彲浠ラ珮鏁堝湴榪愯屽氫釜鉶氭嫙鏈恆侱alvik鉶氭嫙鏈哄彲鎵ц屾枃浠舵牸寮忔槸.dex錛宒ex鏍煎紡鏄涓撲負Dalvik

璁捐＄殑涓縐嶅帇緙╂牸寮忥紝閫傚悎鍐呭瓨鍜屽勭悊鍣ㄩ熷害鏈夐檺鐨勭郴緇熴

澶у氭暟鉶氭嫙鏈哄寘鎷琂VM閮芥槸鍩轟簬鏍堢殑錛岃孌alvik鉶氭嫙鏈哄垯鏄鍩轟簬瀵勫瓨鍣ㄧ殑銆備袱縐嶆灦鏋勫悇鏈変紭鍔ｏ紝涓鑸鑰岃█錛屽熀浜庢爤鐨勬満鍣ㄩ渶瑕佹洿澶氭寚浠わ紝鑰屽熀浜庡瘎瀛樺櫒鐨勬満

鍣ㄦ寚浠ゆ洿澶с俤x鏄涓濂楀伐鍏鳳紝鍙浠ュ皢Java.class杞鎹㈡垚.dex

鏍煎紡銆備竴涓猟ex鏂囦歡閫氬父浼氭湁澶氫釜.class銆傜敱浜巇ex鏈夋椂蹇呴』榪涜屾渶浣沖寲錛屼細浣挎枃浠跺ぇ灝忓炲姞1-4鍊嶏紝浠ODEX緇撳熬銆

Dalvik鉶氭嫙鏈轟緷璧栦簬Linux鍐呮牳鎻愪緵鍩烘湰鍔熻兘錛屽傜嚎紼嬪拰搴曞眰鍐呭瓨綆＄悊銆

3銆丩ibrariesAndroid

鍖呭惈涓涓狢/C搴撶殑闆嗗悎錛屼緵Android緋葷粺鐨勫悇涓緇勪歡浣跨敤銆傝繖浜涘姛鑳介氳繃Android鐨勫簲鐢ㄧ▼搴忔嗘灦錛坅pplication

framework錛夋毚闇茬粰寮鍙戣呫備笅闈㈠垪鍑轟竴浜涙牳蹇冨簱錛氱郴緇烠搴--鏍囧噯C緋葷粺搴擄紙libc錛夌殑BSD琛嶇敓錛岃皟鏁翠負鍩轟簬宓屽叆寮廘inux璁懼

濯掍綋搴--鍩轟簬PacketVideo鐨凮penCORE銆傝繖浜涘簱鏀鎸佹挱鏀懼拰褰曞埗璁稿氭祦琛岀殑闊抽戝拰瑙嗛戞牸寮忥紝浠ュ強闈欐佸浘鍍忔枃浠訛紝鍖呮嫭MPEG4銆

H.264銆丮P3銆丄AC銆丄MR銆丣PG銆丳NG鐣岄潰綆＄悊--綆＄悊璁塊棶鏄劇ず瀛愮郴緇熷拰鏃犵紳緇勫悎澶氫釜搴旂敤紼嬪簭鐨勪簩緇村拰涓夌淮鍥懼艦灞

LibWebCore--鏂板紡鐨刉eb嫻忚堝櫒寮曟搸,椹卞姩Android嫻忚堝櫒鍜屽唴宓岀殑web瑙嗗浘SGL--鍩烘湰鐨2D鍥懼艦寮曟搸

3D搴--鍩轟簬OpenGLES1.0APIs鐨勫疄鐜般傚簱浣跨敤紜浠3D鍔犻熸垨鍖呭惈楂樺害浼樺寲鐨3D杞浠跺厜鏍匜reeType

--浣嶅浘鍜岀煝閲忓瓧浣撴覆鏌揝QLite--鎵鏈夊簲鐢ㄧ▼搴忛兘鍙浠ヤ嬌鐢ㄧ殑寮哄ぇ鑰岃交閲忕駭鐨勫叧緋繪暟鎹搴撳紩鎿

4銆丄pplicationFramework

閫氳繃鎻愪緵寮鏀劇殑寮鍙戝鉤鍙幫紝Android浣垮紑鍙戣呰兘澶熺紪鍒舵瀬鍏朵赴瀵屽拰鏂伴栫殑搴旂敤紼嬪簭銆傚紑鍙戣呭彲浠ヨ嚜鐢卞湴鍒╃敤璁懼囩‖浠朵紭鍔褲佽塊棶浣嶇疆淇℃伅銆佽繍琛屽悗鍙版湇鍔°佽劇疆闂歸挓銆佸悜鐘舵佹爮娣誨姞閫氱煡絳夌瓑錛屽緢澶氬緢澶氥傚紑鍙戣呭彲浠ュ畬鍏ㄤ嬌鐢ㄦ牳蹇冨簲鐢ㄧ▼搴忔墍浣跨敤鐨勬嗘灦APIs銆傚簲鐢ㄧ▼搴忕殑浣撶郴緇撴瀯鏃ㄥ湪綆鍖栫粍浠剁殑閲嶇敤錛屼換浣曞簲鐢ㄧ▼搴忛兘鑳藉彂甯冧粬鐨勫姛鑳戒笖浠諱綍鍏朵粬搴旂敤紼嬪簭鍙浠ヤ嬌鐢ㄨ繖浜涘姛鑳斤紙闇瑕佹湇浠庢嗘灦鎵ц岀殑瀹夊叏闄愬埗錛夈傝繖涓鏈哄埗鍏佽哥敤鎴鋒浛鎹㈢粍浠躲傛墍鏈夌殑搴旂敤紼嬪簭鍏跺疄鏄涓緇勬湇鍔″拰緋葷粺錛屽寘鎷錛氳嗗浘錛圴iew錛--涓板瘜鐨勩佸彲鎵╁睍鐨勮嗗浘闆嗗悎錛屽彲鐢ㄤ簬鏋勫緩涓涓搴旂敤紼嬪簭銆傚寘鎷鍖呮嫭鍒楄〃銆佺綉鏍箋佹枃鏈妗嗐佹寜閽錛岀敋鑷蟲槸鍐呭祵鐨勭綉欏墊祻瑙堝櫒鍐呭規彁渚涜咃紙ContentProviders錛--浣垮簲鐢ㄧ▼搴忚兘璁塊棶鍏朵粬搴旂敤紼嬪簭錛堝傞氳褰曪級鐨勬暟鎹錛屾垨鍏變韓鑷宸辯殑鏁版嵁璧勬簮綆＄悊鍣錛圧esourceManager錛--鎻愪緵璁塊棶闈炰唬鐮佽祫婧愶紝濡傛湰鍦板寲瀛楃︿覆銆佸浘褰㈠拰甯冨矓鏂囦歡閫氱煡綆＄悊鍣錛圡anager錛--浣挎墍鏈夌殑搴旂敤紼嬪簭鑳藉熷湪鐘舵佹爮鏄劇ず鑷瀹氫箟璀﹀憡媧誨姩綆＄悊鍣錛圓ctivityManager錛--綆＄悊搴旂敤紼嬪簭鐢熷懡鍛ㄦ湡,鎻愪緵閫氱敤鐨勫艱埅鍥為鍔熻兘

5銆丄ndroid瑁呴厤涓涓鏍稿績搴旂敤紼嬪簭闆嗗悎錛屽寘鎷鐢靛瓙閭浠跺㈡埛絝銆丼MS紼嬪簭銆佹棩鍘嗐佸湴鍥俱佹祻瑙堝櫒銆佽仈緋諱漢鍜屽叾浠栬劇疆銆傛墍鏈夊簲鐢ㄧ▼搴忛兘鏄鐢↗ava緙栫▼璇璦鍐欑殑銆傛洿鍔犱赴瀵岀殑搴旂敤紼嬪簭鏈夊緟鎴戜滑鍘誨紑鍙戱紒浠庝笂闈㈡垜浠鐭ラ亾Android鐨勬灦鏋勬槸鍒嗗眰鐨勶紝闈炲父娓呮櫚錛屽垎宸ュ緢鏄庣『銆侫ndroid鏈韜鏄涓濂楄蔣浠跺爢榪(Softwaretack)錛屾垨縐頒負銆岃蔣浠惰凱灞傛灦鏋勩嶏紝榪灞備富瑕佸垎鎴愪笁灞傦細鎿嶄綔緋葷粺銆佷腑闂翠歡銆佸簲鐢ㄧ▼搴忋備粠涓婇潰鎴戜滑涔熺湅鍒頒簡寮婧愮殑鍔涢噺錛屼竴涓涓鐔熸倝鐨勫紑婧愯蔣浠跺湪榪欓噷璐＄尞浜嗚嚜宸辯殑涓浠藉姏閲忋

⑦ 細談在 Android 開發中 MVVM 與 AOP 的框架設計

MVVM可以被視為MVP的升級，其核心是ViewModel，它整合了View的數據模型和Presenter的功能，通過Data Binding實現View與ViewModel之間的交互，增強了數據的雙向綁定，降低了視圖與控制層的耦合性，從而實現更加清晰的職責分離。實際開發中，並不需要糾結是否採用MVC、MVP或MVVM，重要的是實現模型與視圖的解耦，提升代碼的可維護性和可測試性。

MVVM模式從MVP進一步發展而來，解決了MVP模式中Presenter直接操作View介面的問題，通過Data Binding實現數據的直接綁定，避免了重復的showData等操作，使得代碼更加簡潔優雅。MVVM模式強調Model、View和ViewModel之間的分離，而共同的目標是實現用戶交互和數據變更通知的高效處理。

在軟體架構設計中，Controller和Presenter負責邏輯代碼的管理，根據Presenter和View對邏輯代碼的分擔程度，形成了被動View和監督Controller兩種模式。ViewModel則作為Model與View之間的橋梁，將Model和View解耦，使得應用的模塊化更加清晰，避免了不相關的代碼混雜在一起。

在實際開發中，開發者通常會結合多種模式，以滿足不同場景的需求。例如，Model、View和ViewModel之間的數據傳輸可能會採用更靈活的方式，以減少不必要的性能開銷。通過將核心關注點與橫切關注點分離，開發者能夠更加專注於業務邏輯的實現，同時保證代碼的可重用性和可維護性。

AOP（面向切面編程）作為OOP（面向對象編程）的補充和完善，提供了一種靈活的方式來處理橫切關注點，如日誌、安全性、異常處理等。通過將這些通用的代碼封裝為「Aspect」（方面），開發者可以在不修改核心業務邏輯的前提下，增強系統的功能和性能，提高代碼的復用性和可維護性。

在Android開發中，通過採用MVVM架構和AOP技術，開發者可以構建更加模塊化、可擴展和易於維護的應用。通過合理的架構設計，將應用的邏輯和功能分層，能夠有效提高開發效率，同時確保應用在不斷變化的市場需求面前具有良好的適應性。

總結而言，MVVM與AOP的框架設計是現代Android應用開發中的關鍵組成部分，通過將應用邏輯與界面展示分離，以及利用AOP技術處理橫切關注點，開發者能夠構建出更加健壯、可維護且易於擴展的應用。掌握這些技術對於提升開發者的職業技能和應對復雜項目挑戰具有重要意義。