一個前端程序猿的一個月原生 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 吧。
僅僅須要按下： 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 應用的時候。每次我想試着在手機上查看效果的時候。得構建、編譯代碼、安裝，大概得等上個兩三鍾才干執行在虛擬機或者真機上。
可事件往往不會這么順利。動不動會遇上個 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.Typeif 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：
除此，還能夠通過 Facebook 家的 stetho 做與 Web 相關的調試工作：
總的來說。還算是不錯的。就是這個結構，看上去和 React Native 怎么那么樣呢？
代碼調試
在代碼調試上來說。Java 底子厚，總的來說會比 JavaScript 好一些。
除此。記得我們在 Chrome 瀏覽器里能夠打斷點，隨后在 Console 中做出一些計算。
而得益於 Android Studio 背后的 JetBrain 的 Evaluating Expressions。能夠實時計算表達式的值。Android 上的代碼調試也是非常easy的。
而以我有限的 Objective-C 編程經驗來說，XCode 也是能夠做到的。
網絡調試
在 Chrome 瀏覽器里，自帶的 NetWorks 差點兒是萬能的。
Android 方面也能夠借助於 Stetho 來使用：
可是依賴上比較大，須要在頁面上注入，而且調試不了插件化的應用。要調試網絡吧。還是 Charles 好用一些。
可是，萬一開發環境 HTTPS 了呢，不就更麻煩了。
兼容性
前端面臨的是調試不同的瀏覽器，又或者是兼容 IE。總的來說，問題都不大——不會面臨閃退的問題。即使出了點小問題。用戶能夠先換個瀏覽器試試。
而當你的 Android 應用在用戶的手機上閃退了。那么用戶僅僅能換個 APP 了。
除此，Android 則是面臨碎片化的系統。不同的版本號，及不同的屏幕大小，總的來說。要對前端復雜得多。
結論
Android 在軟件project上做得相當優秀，而前端則是在開發效率上占優勢。
Web 開發大法好。
