版權聲明：本文為部落客原創文章，未經部落客同意不得轉載。 https://blog.csdn.net/j01G58UC80251/article/details/79017706
一個前端程式猿的一個月原生 Android 開發體驗。
自從我寫了 Android 應用後，上知乎的時間變得更長了。
自從我寫了 Android 應用後。上知乎的時間變得更長了。哦。不正确。你了解錯了，我的意思是：編譯代碼、打包 APK、執行在裝置上須要時間。可不像前端，一儲存代碼，就自己主動重新整理頁面。
是的。從上上周一開始，由于項目缺人的原因，作為一個有 Java 開發經驗的大前端。我又又雙叕進入了原生 Android 開發的世界。
這一個月下來，也算是有一些寫 XML 的心得吧——不正确，寫 Java 代碼，看 Kotlin 代碼的心得。
總的來說，Android 與前端的差異并非非常大，在某些東西上，他們還是蠻類似的。怪不得像我這種程式猿，會将 Android 開發也歸類到大前端上去。
假設你是一個前端程式猿。想學習移動開發。又或者是一個移動開發，想接觸前端開發。那麼。本文可能就非常适合你去了解兩者間的差異。
本文包括了下面的内容：
- 編碼效率 vs 可維護度
- MVP vs MV：後天的 MV*
- 靜态語言 vs 動态語言
- View 與 DOM
- 代碼調試
- 相容性
（PS：受限于我僅僅有短暫的經驗，是以有些用詞可能沒有那麼準确。）
注
：這裡的前端應用特指單頁面應用。
編碼效率 vs 可維護度
由于從執行效率上來說，原生應用必須遠遠大于 WebView——畢竟 WebView 的背後還是原生應用。直接等于中間多了一個層級。是以，在這裡直接讨論編碼效率。
Web
從編碼效率上來說，還是前端快。快得不止一點點。
- 更快的預覽速度。
- 成熟的生态系統。
- 大量可用的 UI 架構及元件。
- 參考别家的實作。Web 前端是開放的世界。在今天來看，要實作的效果基本上已經被實作過了。是以我們能夠直接參考
- 富文本支援好
而考慮到 Android 和 iOS 是各自實作的，那麼一個混合應用的開發效率可能是遠遠大于 2 倍。而跨平台應用（如 React Native、Weex、NativeScript） 的開發效率會接近他們的 2 倍（原因是：內建某些功能時，須要原生代碼來實作，這時工作量直接翻倍等同）。
Android
從眼下的維護程度上來說。還是 Java 的代碼相對維護。主要是前端領域的變化太快了。而且在軟體project上的實踐不像 Java 是必須要求的，是以easy出現大量的遺留代碼。僅僅是考慮到，Java 代碼的臃腫，還是改用 Kotlin 吧。
Android Studio 轉 Kotlin
僅僅須要按下： Command + Alt + Shift + K。輕松當爸爸。
MVP vs MV：後天的 MV*
MVP，即 Model-View-Presenter，相應于視圖層-資料層-展示層。
在 MVP 上來看，前端應用與 Android 都并非天生的 MVP 架構的。隻是。兩者在對業務邏輯上的處理，可是沒有多少差異。唯一能體驗差異的，可能就是 JavaScript 的異步。以及 Java 的同步帶來的一些差别。
V*
採用了架構的前端應用，則會是以而帶上 MV* 的加成。
一旦選用上了某個架構，那麼你僅僅能依照其特有的模式，如 Vue 提供的核心是 MVVM 中的 VM，React 則僅僅是 MVC 中的 View 層。則 Angular 則可能是 MVW（Model-View-Whatever）。
在這種情況下，要在架構的基本之上變更。那麼靈活性上可能沒有那麼大。
而 Android 方面則是 MVP 架構。其主要依賴于約定俗成。當中一個參考的規範就是 Google 官方的 android-architecture，又或者是社群上推薦的 Clean Architecture。
而不管是 Clean Architecture。還是 MVP。其都依賴于約定。
一旦我們談及參考的時候，便意味着靈活性——可遵循。可不遵循。
在這種時候。Android 的 MVP 須要我們自己去建立 MVPView。建立 Presenter。
-
public class MainActivity extends AppCompatActivity implements MainView {
-
...
-
}
而整個
MainActivity
僅僅是一個 View 層，真正的業務邏輯要交給 Presenter 來處理。簡單來說，就是你須要手動地建立四五個類，才幹完畢一個 Activity 的 Hello, world。
Model
與此同一時候。Android 預設是要對 Model 進行校驗和轉換的。
由于取出 JSON 中的某個值，須要将 JSON 轉換為對象——能夠直接使用 Retrofit 庫來轉換資料。又或者用 GJSON 轉換成某種對象。算是與前端的一個大的差别，在前端世界裡，這種事情是輕而易舉的。有萬能的
JSON.parse
。
在使用 JavaScript 編寫的時候。能夠不正确 Model 進行校驗。隻是，在 React 裡會有
proptypes
，在 Angular 裡能夠用 TypeScript 來做類似的事。
與沒有對象校驗的前端相比。一旦出錯。根本不easy察覺。這一點，或者也是一個優勢所在——當你上架了新版本号的 API 時，舊的應用不會 NullPointerException。與此同一時候，在開發的時候。背景 API 發生變化的時候，也會導緻興許的一系列 bug。
靜态語言 vs 動态語言
自從我寫了 Android 應用後，上知乎的時間變得更長了。
編譯與動态執行
當我們編寫 Web 應用的時候，僅僅要一儲存代碼，網頁就能夠由
LiveReload
這種工具來幫我們自己主動重新整理。于是。在諸如 React Native 這種跨平台架構裡。也有 Live Reload 這種特性。
而當我開發 Android 應用的時候。每次我想試着在手機上檢視效果的時候。得建構、編譯代碼、安裝，大概得等上個兩三鐘才幹執行在虛拟機或者真機上。
Android Studio Process
可事件往往不會這麼順利。動不動會遇上個
NullPointerException
，然後應用就 Crash 了。
這個時候，就要去修複代碼中的問題，加個
blabla!=null
，然後編譯，繼續 Crash。
怪不得 Android 的程式猿喜歡上了 Kotlin，僅僅要一個
view?
就能推斷是不是有值的事：
-
override fun onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View? {
-
val view = inflater?.inflate(R.layout.fragment_home, container, false)
-
val button: Button = view!!.findViewById(R.id.open_rn_button)
-
button.setOnClickListener(this)
-
return view
-
}
可由于沒有經驗，我常常把
val
寫成了
var
。這就和那些習慣寫 alloc init 的 iOS 程式猿，一夜間突然喜歡上了寫 ES6 一樣：
-
let className = NSStringFromClass(MyClass)
-
let classType = NSClassFromString(className) as? MyClass.Type
-
if let type = classType {
-
let my = type.init()
-
}
哦，不正确他們寫的是 Swift。
而且作為一個面向對象的語言，Java 天生就意味着，大量的臃腫代碼。
-
public int getId() {
-
return id;
-
}
-
public void setId(int id) {
-
this.id = id;
-
}
-
public String getName() {
-
return name;
-
}
-
public void setName(String name) {
-
this.name = name;
-
}
大量的代碼，就意味着大量的
bug
。一定量的反複代碼。一下子又回到設計模式的天下。
IDE 支援
好在。由于 Android Studio 有強大的、良好的 Intellij 支援。
在 IDE 上對語言的支援，要比 JavaScript 的第三方庫支援友好得多：
靜态語言
要知道 WebStorm 或者 Intellj IDEA 專業版，它們在 JavaScript 第三方類的支援上就是坑。
View 與 DOM
過去，前端在 DOM 操作上存在天然的問題，即在我們使用
$("*")
的時候，全局。
當然現今的架構，在這個問題上比較少，可是考慮到仍然可能會被誤用。或者注入。而 Android 則是局部頁面的。
樣式複用
前端使用 HTML + CSS 來編寫樣式，而安裝則僅僅使用 XML 來切圖。這并非一件easy的事。不像 CSS 能夠通過 “繼承” 和 “覆寫” 的形式來實作樣式複用。Android 中也有類似于 JavaScript 生成 HTML 的方式。自己定義模闆。
當我們使用 React 編寫元件的時候，能夠傳遞相應的屬性到元件中，這個屬性能夠是函數、值、元件等等。
-
MyComponent.propTypes = {
-
optionalArray: PropTypes.array,
-
optionalBool: PropTypes.bool,
-
optionalFunc: PropTypes.func,
-
optionalElement: PropTypes.element
-
}
而在 Android 的布局上，這就不是一樣easy的事。為了複用樣式，須要抽取成 UI 元件。還僅僅能是 UI 上的元件。僅僅能實作 HTML + CSS 上的複用。
HTML + CSS 在編寫 UI 的時候，有各種奇技淫巧，比方說樣式的優先級，或者
important
。
雙向綁定
從原生的角度來看，前端的
document.getElementById()
與 Android 的
findViewById
并沒有多大的差别。
而目前端有了前端架構之後，就不一樣了。
好在 Android 有 ButterKnife 這種 View 注入架構。
與此同一時候，Android 還自帶了雙向的 DataBinding，而原生的前端是沒有的。
僅僅是前端有前端架構。在這一點也全然問題也不多。
布局調試
還好，已經有寫 React Native 布局的一些經驗。在寫起 Android 的布局，倒也還好——沒有那麼坑。
在布局調試上。還是前端用浏覽器調式友善——還能夠在浏覽器實時改動 DOM 結構。Android 也有這種工具，叫Layout Inspector：
Layout Inspector
除此，還能夠通過 Facebook 家的 stetho 做與 Web 相關的調試工作：
Stetho 調試示範樣例
總的來說。還算是不錯的。就是這個結構，看上去和 React Native 怎麼那麼樣呢？
代碼調試
在代碼調試上來說。Java 底子厚，總的來說會比 JavaScript 好一些。
Android 調試
除此。記得我們在 Chrome 浏覽器裡能夠打斷點，随後在 Console 中做出一些計算。
而得益于 Android Studio 背後的 JetBrain 的 Evaluating Expressions。能夠實時計算表達式的值。Android 上的代碼調試也是非常easy的。
Evaluating Expressions
而以我有限的 Objective-C 程式設計經驗來說，XCode 也是能夠做到的。
網絡調試
在 Chrome 浏覽器裡，自帶的 NetWorks 差點兒是萬能的。
Android 方面也能夠借助于
Stetho
來使用：
Stetho 網絡調試
可是依賴上比較大，須要在頁面上注入，而且調試不了插件化的應用。要調試網絡吧。還是 Charles 好用一些。
可是，萬一開發環境 HTTPS 了呢，不就更麻煩了。
相容性
前端面臨的是調試不同的浏覽器，又或者是相容 IE。總的來說，問題都不大——不會面臨閃退的問題。即使出了點小問題。使用者能夠先換個浏覽器試試。
而當你的 Android 應用在使用者的手機上閃退了。那麼使用者僅僅能換個 APP 了。
除此，Android 則是面臨碎片化的系統。不同的版本号，及不同的螢幕大小，總的來說。要對前端複雜得多。
結論
Android 在軟體project上做得相當優秀，而前端則是在開發效率上占優勢。
Web 開發大法好。
