androidmvpmvcmvvm
① Android 目前是 mvc，mvp，mvvm 哪種模式比較好
mvc的界面和邏輯關聯緊密，數據直接從資料庫讀取。mvvm的界面與viewmode是松耦合，界面數據從viewmodel中獲取。如果你寫代碼的時候在界面的cs文件里有很多業務邏輯代碼，那麼你使用的就不是mvvm，而是mvc
② Android 開發一般都使用什麼框架
開源框架推薦：
網路
* [okhttp](square/okhttp · GitHub)
* [android-async-http](loopj/android-async-http · GitHub)
事件匯流排
* [otto](square/otto · GitHub)
* [EventBus](greenrobot/EventBus · GitHub)
依賴注入
* [Dagger](square/dagger · GitHub)
* [RoboGuice](roboguice/roboguice · GitHub)
* [ButterKnife](JakeWharton/butterknife · GitHub)
圖片
* [Fresco](facebook/fresco · GitHub)
* [Glide](bumptech/glide · GitHub)
* [picasso](square/picasso · GitHub)
資料庫
* [greenDao](greenrobot/greenDAO · GitHub)
* [ormlite](j256/ormlite-android · GitHub)
* [LitePal](LitePalFramework/LitePal · GitHub)
響應式編程
* [RxJava](ReactiveX/RxJava · GitHub)
* [RxAndroid](ReactiveX/RxAndroid: RxJava bindings for An...)
日誌輸出
* [logger](orhanobut/logger: Simple, pretty and powerf...)
* [android-CLog](liaohuqiu/android-CLog)
* [KLog](ZhaoKaiQiang/KLog · GitHub)
* [LogUtils](pengwei1024/LogUtils · GitHub)
崩潰統計平台
* [騰訊bugly](騰訊Bugly - Android Crash(崩潰)_iOS Crash(崩潰)_ANR_卡頓)
* [Crittercism](Crittercism - Developer Home)
* [Crashlytics](The most powerful, yet lightest weight crash reporting solution for iOS and Android
developers.)
架構設計
這個肯定得了解下MVC，MVP，MVVM還有設計模式這些，這里有幾個開源項目推薦下
philm
Movie collection and information app for Android.
Github地址：chrisbanes/philm: Movie collection and info...
SimpleNews
基於Material Design和MVP的新聞客戶端
Github地址：GitHub - liuling07/SimpleNews: 基於Material Design和MVP的新聞客戶端
GankDaily
A application show technical information every working days, use MVP pattern.
Github地址：maoruibin/GankDaily
SimplifyReader
Github地址：GitHub - SkillCollege/SimplifyReader: 一款基於Google Material Design設計開發的Android客戶端，包括新聞簡讀，圖片瀏覽，視頻爽看 ，音樂輕聽以及二維碼掃描五個子模塊。
NBAPlus
Github地址：SilenceDut/NBAPlus · GitHub
PhotoNoter
Github地址：yydct/PhotoNoter
Mei
Github地址：drakeet/Mei: gank.io unofficial client, RxJava & Retrofit
DebugDrawer
Android Debug Drawer for faster development
Github地址：palaima/DebugDrawer · GitHub
ViewServer
Local server for Android's HierarchyViewer
Github地址：romainguy/ViewServer · GitHub
AndroidWiFiADB
IntelliJ/AndroidStudio plugin which provides a button to connect your Android device over WiFi to install, run and debug your applications without a USB connected.
③ Android 開發有什麼好的架構么
Android 開發架構主要用於去除耦合，方便測試和升級，MVC,MVP,MVVM是現在流行的架構，可以看看下面的文章。
Android設計架構經驗分享
http://www.apkbus.com/thread-307889-1-1.html
④ 開發 Android軟體時，需要為其撰寫文檔，其中有一項為關鍵技術，應該寫些什麼內容
軟體架構MVP MVC MVVM 等等，使用的框架OKHttp EventBus Xutils ButterKnife retroft Picassp等等，使用的加密演算法，排序演算法等等。
⑤ android 怎麼使用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相關的事。
⑥ android開發mvvm模式是不是已經成熟
android開發mvvm模式不是很成熟，現在成熟的開發模式是mvc，mvp模式就是邏輯代碼與界面分離開來處理，更清晰。
⑦ android mvc什麼時候出來的
很久了、
mvc是model、view、controller的縮寫。android 鼓勵弱耦合和組件的重用，android 中mvc的具體體現如下：
模型（model）：是應用程序的主題部分，所有的業務邏輯都應在該層（對資料庫的操作、對網路等的操作都應該在model裡面處理，當然對計算等操作也是必須放在該層的）。
視圖層（view）：是應用程序中負責生成用戶界面的部分。也是整個mvc架構中用戶唯一可以看到的一層，接收用戶的輸入，顯示用戶的處理結果。一般用xml文件進行界面的描述，使用的時候可以非常方便的引入。
控制層（controller）：是根據用戶的輸入，控制用戶界面數據顯示及更i新model對象狀態的部分。android的控制層的重任通常落在了眾多activity的肩上，這句話也就暗含了不要在activity中寫過多代碼，要通過activity交割model業務邏輯處理層處理，這樣做的另外一個原因是android中的activity的響應時間是5秒，如果耗時的操作放在這里，程序很容易被回收掉。
⑧ 怎麼樣能快速搭建一個Android APP的界面和框架
自己從零開始快速搭建Android app架構
簡單的看下這三個架構模式：
MVC：Model-View-Controller，經典模式，很容易理解，主要缺點有兩個：
View對Model的依賴，會導致View也包含了業務邏輯；
Controller會變得很厚很復雜。
MVP：Model-View-Presenter，MVC的一個演變模式，將Controller換成了Presenter，主要為了解決上述第一個缺點，將View和Model解耦，不過第二個缺點依然沒有解決。
MVVM：Model-View-ViewModel，是對MVP的一個優化模式，採用了雙向綁定：View的變動，自動反映在ViewModel，反之亦然。
面對眾多的架構模式你會選擇哪個？
MVC，MVP還是MVVM？
越高級的模式復雜性越高，實現起來也越難。然後搭建項目時也是看項目的需求，別人說好你也有要實用才好，高效的實現項目的功能才是最好的架構模式。
那麼，哪一個才是最好的呢？
個人覺得適合你的才是最好的，不要去盲目的跟風，大家說mvp好那你就使用咯，沒有實踐就沒有話語權，所以說用哪種架構模式本人不發表任何意見：任何模式的動機都是一樣的，那就是如何避免復雜混亂的代碼，讓執行單元測試變得容易，創造高質量應用程序，開發維護更高效。
在實際項目中思考架構時，也不會想著要用哪種模式，我只思考現階段，以現有的人力資源和時間資源，如何才能更快更好地完成需求，適當考慮下如何為後期擴展或重構做准備。
我項目中的架構
這是我上一個項目的包架構：
permission(許可權管理系統)
這功能是絕對項目中需要的，別告訴我你的項目還沒有適配安卓6.0，適配了就肯定會有許可權管理，我這里用的是 安卓6.0許可權處理在項目中的實踐,也還可以吧，反正github上的許可權管理的開源東西比較多，覺得合適就ok。
哈哈，這樣基礎功能都搭建好了，然後就是一些邏輯功能的封裝了。
⑨ android mvp mvvm怎麼選擇 簡書
1.MVC
傳統的Android App其實都是基於MVC的，Activity，Fragment相當於C,布局相當於V,數據邏輯相當於M
隨著業務的增長Controller里的代碼會越來越臃腫，因為它不只要負責業務邏輯，還要控制View的展示。也就是說Activity、Fragment雜糅了Controller和View，耦合變大。並不能算作真正意義上的MVC。
這也是為什麼後面的MVP會引起很多開發者興趣的原因了。
2.MVP
MVP架構其實可以說與MVC的架構還是有很大的差別的，數據邏輯相當於M，Activity（負責View的繪制以及與用戶交互）相當於V ，View於Model間的交互則為P
理論上感覺區別有點抽象，可以通過下面的圖來看一看其中的區別
⑩ android開發一般都使用什麼框架
目前框架使用的主要都是開源框架，都可以在github上找到：
1、volley
2、android-async-http
3、Afinal框架
4、xUtils框架
5、ThinkAndroid
6、LoonAndroid
主要有以下模塊：
(1) 自動注入框架（只需要繼承框架內的application既可）
(2)
圖片載入框架（多重緩存，自動回收，最大限度保證內存的安全性）
(3) 網路請求模塊（繼承了基本上現在所有的http請求）
(4)
eventbus（集成一個開源的框架）
(5) 驗證框架（集成開源框架）
(6) json解析（支持解析成集合或者對象）
(7) 資料庫（不知道是哪位寫的 忘記了）
(8) 多線程斷點下載（自動判斷是否支持多線程，判斷是否是重定向）
(9)
自動更新模塊
(10) 一系列工具類