一個前端程序員的一個月原生 Android 開發體驗。自從我寫了 Android 應用后，上知乎的時間變得更長了。

自從我寫了 Android 應用后，上知乎的時間變得更長了。哦，不對，你理解錯了，我的意思是：編譯代碼、打包 APK、運行在設備上需要時間。可不像前端，一保存代碼，就自動刷新頁面。

是的，從上上周一開始，因為項目缺人的原因，作為一個有 Java 開發經驗的大前端，我又又雙叕進入了原生 Android 開發的世界。

這一個月下來，也算是有一些寫 XML 的心得吧——不對，寫 Java 代碼，看 Kotlin 代碼的心得。總的來說，Android 與前端的差異并不是非常大，在某些東西上，他們還是蠻相似的。怪不得像我這樣的程序員，會將 Android 開發也歸類到大前端上去。

如果你是一個前端程序員，想學習移動開發；又或者是一個移動開發，想接觸前端開發；那么，本文可能就很適合你去了解兩者間的差異。

本文包含了以下的內容：

• 編碼效率 vs 可維護度
• MVP vs MV ：后天的 MV
• 靜態語言 vs 動態語言
• View 與 DOM
• 代碼調試
• 兼容性

（PS：受限于我只有短暫的經驗，所以有些用詞可能沒有那么準確。）

注 ：這里的 前端應用特指單頁面應用 。

編碼效率 vs 可維護度

因為從運行效率上來說，原生應用必須遠遠大于 WebView——畢竟 WebView 的背后還是原生應用，直接等于中間多了一個層級。所以，在這里直接討論編碼效率。

從編碼效率上來說，還是前端快，快得不止一點點。

• 更快的預覽速度。
• 成熟的生態系統。
• 大量可用的 UI 框架及組件。
• 參考別家的實現。Web 前端是開放的世界，在今天來看，要實現的效果基本上已經被實現過了，所以我們可以直接參考
• 富文本支持好

而考慮到 Android 和 iOS 是各自實現的，那么一個混合應用的開發效率可能是遠遠大于 2 倍，而跨平臺應用（如 React Native、Weex、NativeScript） 的開發效率會接近他們的 2 倍（原因是：集成某些功能時，需要原生代碼來實現，這時工作量直接翻倍等同）。

從目前的維護程度上來說，還是 Java 的代碼相對維護。主要是前端領域的變化太快了，并且在軟件工程上的實踐不像 Java 是必需要求的，因此容易出現大量的遺留代碼。只是考慮到，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 來做相似的事。

與沒有對象校驗的前端相比，一旦出錯，根本不容易察覺。這一點，或者也是一個優勢所在——當你上架了新版本的 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.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 來切圖，這并不是一件容易的事。不像 CSS 可以通過 “繼承” 和 “覆寫” 的形式來實現樣式復用。Android 中也有類似于 JavaScript 生成 HTML 的方式，自定義模板。

當我們使用 React 編寫組件的時候，可以傳遞對應的屬性到組件中，這個屬性可以是函數、值、組件等等。

MyComponent.propTypes = { 
  optionalArray: PropTypes.array, 
  optionalBool: PropTypes.bool, 
  optionalFunc: PropTypes.func, 
  optionalElement: PropTypes.element 
} 

而在 Android 的布局上，這就不是一樣容易的事。為了復用樣式，需要抽取成 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 上的代碼調試也是很容易的。

而以我有限的 Objective-C 編程經驗來說，XCode 也是可以做到的。

網絡調試

在 Chrome 瀏覽器里，自帶的 NetWorks 幾乎是***的。Android 方面也可以借助于 Stetho 來使用：

但是依賴上比較大，需要在頁面上注入，并且調試不了插件化的應用。要調試網絡吧，還是 Charles 好用一些。

可是，萬一開發環境 HTTPS 了呢，不就更麻煩了。

兼容性

前端面臨的是調試不同的瀏覽器，又或者是兼容 IE。總的來說，問題都不大——不會面臨閃退的問題。即使出了點小問題，用戶可以先換個瀏覽器試試。而當你的 Androdi 應用在用戶的手機上閃退了，那么用戶只能換個 APP 了。

除此，Android 則是面臨碎片化的系統，不同的版本，及不同的屏幕大小，總的來說，要對前端復雜得多。

結論

Android 在軟件工程上做得相當優秀，而前端則是在開發效率上占優勢。

Web 開發大法好。