一個(gè)前端程序員的一個(gè)月原生 Android 開發(fā)體驗(yàn)。自從我寫了 Android 應(yīng)用后，上知乎的時(shí)間變得更長了。

自從我寫了 Android 應(yīng)用后，上知乎的時(shí)間變得更長了。哦，不對，你理解錯(cuò)了，我的意思是：編譯代碼、打包 APK、運(yùn)行在設(shè)備上需要時(shí)間?？刹幌袂岸耍槐４娲a，就自動(dòng)刷新頁面。

是的，從上上周一開始，因?yàn)轫?xiàng)目缺人的原因，作為一個(gè)有 Java 開發(fā)經(jīng)驗(yàn)的大前端，我又又雙叕進(jìn)入了原生 Android 開發(fā)的世界。

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

如果你是一個(gè)前端程序員，想學(xué)習(xí)移動(dòng)開發(fā)；又或者是一個(gè)移動(dòng)開發(fā)，想接觸前端開發(fā)；那么，本文可能就很適合你去了解兩者間的差異。

本文包含了以下的內(nèi)容：

• 編碼效率 vs 可維護(hù)度
• MVP vs MV ：后天的 MV
• 靜態(tài)語言 vs 動(dòng)態(tài)語言
• View 與 DOM
• 代碼調(diào)試
• 兼容性

（PS：受限于我只有短暫的經(jīng)驗(yàn)，所以有些用詞可能沒有那么準(zhǔn)確。）

注 ：這里的 前端應(yīng)用特指單頁面應(yīng)用 。

編碼效率 vs 可維護(hù)度

因?yàn)閺倪\(yùn)行效率上來說，原生應(yīng)用必須遠(yuǎn)遠(yuǎn)大于 WebView——畢竟 WebView 的背后還是原生應(yīng)用，直接等于中間多了一個(gè)層級。所以，在這里直接討論編碼效率。

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

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

而考慮到 Android 和 iOS 是各自實(shí)現(xiàn)的，那么一個(gè)混合應(yīng)用的開發(fā)效率可能是遠(yuǎn)遠(yuǎn)大于 2 倍，而跨平臺(tái)應(yīng)用（如 React Native、Weex、NativeScript） 的開發(fā)效率會(huì)接近他們的 2 倍（原因是：集成某些功能時(shí)，需要原生代碼來實(shí)現(xiàn)，這時(shí)工作量直接翻倍等同）。

從目前的維護(hù)程度上來說，還是 Java 的代碼相對維護(hù)。主要是前端領(lǐng)域的變化太快了，并且在軟件工程上的實(shí)踐不像 Java 是必需要求的，因此容易出現(xiàn)大量的遺留代碼。只是考慮到，Java 代碼的臃腫，還是改用 Kotlin 吧。

只需要按下： Command + Alt + Shift + K ，輕松當(dāng)爸爸。

MVP vs MV ：后天的 MV

MVP，即 Model-View-Presenter，對應(yīng)于視圖層-數(shù)據(jù)層-展示層。

在 MVP 上來看，前端應(yīng)用與 Android 都并非天生的 MVP 架構(gòu)的。不過，兩者在對業(yè)務(wù)邏輯上的處理，但是沒有多少差異。***能體驗(yàn)差異的，可能就是 JavaScript 的異步，以及 Java 的同步帶來的一些差別。

V*

采用了框架的前端應(yīng)用，則會(huì)因此而帶上 MV* 的加成。一旦選用上了某個(gè)框架，那么你只能按照其特有的模式，如 Vue 提供的核心是 MVVM 中的 VM，React 則只是 MVC 中的 View 層，則 Angular 則可能是 MVW（Model-View-Whatever）。在這種情況下，要在框架的基本之上變更，那么靈活性上可能沒有那么大。

而 Android 方面則是 MVP 架構(gòu)，其主要依賴于 約定俗成 ，其中一個(gè)參考的規(guī)范就是 Google 官方的 android-architecture ，又或者是社區(qū)上推薦的 Clean Architecture。而無論是 Clean Architecture，還是 MVP，其都依賴于 約定 。一旦我們談及參考的時(shí)候，便意味著靈活性——可遵循，可不遵循。

在這種時(shí)候，Android 的 MVP 需要我們自己去創(chuàng)建 MVPView，創(chuàng)建 Presenter。

public class MainActivity extends AppCompatActivity implements MainView { 
    ... 
} 

而整個(gè) MainActivity 只是一個(gè) View 層，真正的業(yè)務(wù)邏輯要交給 Presenter 來處理。簡單來說，就是你需要手動(dòng)地創(chuàng)建四五個(gè)類，才能完成一個(gè) Activity 的 Hello, world。

Model

與此同時(shí)，Android 默認(rèn)是要對 Model 進(jìn)行校驗(yàn)和轉(zhuǎn)換的。因?yàn)槿〕?JSON 中的某個(gè)值，需要將 JSON 轉(zhuǎn)換為對象——可以直接使用 Retrofit 庫來轉(zhuǎn)換數(shù)據(jù)，又或者用 GJSON 轉(zhuǎn)換成某種對象。算是與前端的一個(gè)大的區(qū)別，在前端世界里，這種事情是輕而易舉的，有***的 JSON.parse 。

在使用 JavaScript 編寫的時(shí)候，可以不對 Model 進(jìn)行校驗(yàn)。不過，在 React 里會(huì)有 proptypes ，在 Angular 里可以用 TypeScript 來做相似的事。

與沒有對象校驗(yàn)的前端相比，一旦出錯(cuò)，根本不容易察覺。這一點(diǎn)，或者也是一個(gè)優(yōu)勢所在——當(dāng)你上架了新版本的 API 時(shí)，舊的應(yīng)用不會(huì) NullPointerException。與此同時(shí)，在開發(fā)的時(shí)候，后臺(tái) API 發(fā)生變化的時(shí)候，也會(huì)導(dǎo)致后續(xù)的一系列 bug。

靜態(tài)語言 vs 動(dòng)態(tài)語言

自從我寫了 Android 應(yīng)用后，上知乎的時(shí)間變得更長了。

編譯與動(dòng)態(tài)運(yùn)行

當(dāng)我們編寫 Web 應(yīng)用的時(shí)候，只要一保存代碼，網(wǎng)頁就可以由 LiveReload 這樣的工具來幫我們自動(dòng)刷新。于是，在諸如 React Native 這樣的跨平臺(tái)框架里，也有 Live Reload 這樣的特性。

而當(dāng)我開發(fā) Android 應(yīng)用的時(shí)候，每次我想試著在手機(jī)上查看效果的時(shí)候，得構(gòu)建、編譯代碼、安裝，大概得等上個(gè)兩三鐘才能運(yùn)行在虛擬機(jī)或者真機(jī)上。

可事件往往不會(huì)這么順利，動(dòng)不動(dòng)會(huì)遇上個(gè) NullPointerException ，然后應(yīng)用就 Crash 了。這個(gè)時(shí)候，就要去修復(fù)代碼中的問題，加個(gè) blabla!=null ，然后編譯，繼續(xù) Crash。

怪不得 Android 的程序員喜歡上了 Kotlin，只要一個(gè) 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 
} 

可由于沒有經(jīng)驗(yàn)，我經(jīng)常把 val 寫成了 var 。這就和那些習(xí)慣寫 alloc init 的 iOS 程序員，一夜間突然喜歡上了寫 ES6 一樣：

let className = NSStringFromClass(MyClass) 
 let classType = NSClassFromString(className) as? MyClass.Type 
 if let type = classType { 
   let my = type.init() 
 } 

哦，不對他們寫的是 Swift。

并且作為一個(gè)面向?qū)ο蟮恼Z言，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 ，一定量的重復(fù)代碼，一下子又回到設(shè)計(jì)模式的天下。

IDE 支持

好在，由于 Android Studio 有強(qiáng)大的、良好的 Intellij 支持。在 IDE 上對語言的支持，要比 JavaScript 的 第三方庫 支持友好得多：

要知道 WebStorm 或者 Intellj IDEA 專業(yè)版，它們在 JavaScript 第三方類的支持上就是坑。

View 與 DOM

過去，前端在 DOM 操作上存在天然的問題，即在我們使用 $("*") 的時(shí)候，全局。當(dāng)然現(xiàn)今的框架，在這個(gè)問題上比較少，但是考慮到仍然可能會(huì)被誤用，或者注入。而 Android 則是局部頁面的。

樣式復(fù)用

前端使用 HTML + CSS 來編寫樣式，而安裝則只使用 XML 來切圖，這并不是一件容易的事。不像 CSS 可以通過 “繼承” 和 “覆寫” 的形式來實(shí)現(xiàn)樣式復(fù)用。Android 中也有類似于 JavaScript 生成 HTML 的方式，自定義模板。

當(dāng)我們使用 React 編寫組件的時(shí)候，可以傳遞對應(yīng)的屬性到組件中，這個(gè)屬性可以是函數(shù)、值、組件等等。

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

而在 Android 的布局上，這就不是一樣容易的事。為了復(fù)用樣式，需要抽取成 UI 組件，還只能是 UI 上的組件。只能實(shí)現(xiàn) HTML + CSS 上的復(fù)用。

HTML + CSS 在編寫 UI 的時(shí)候，有各種奇技淫巧，比如說樣式的優(yōu)先級，或者 important 。

雙向綁定

從原生的角度來看，前端的 document.getElementById() 與 Android 的 findViewById 并沒有多大的區(qū)別。而當(dāng)前端有了前端框架之后，就不一樣了。好在 Android 有 ButterKnife 這樣的 View 注入框架。

與此同時(shí)，Android 還自帶了雙向的 DataBinding，而原生的前端是沒有的。

只是前端有前端框架，在這一點(diǎn)也完全問題也不多。

布局調(diào)試

還好，已經(jīng)有寫 React Native 布局的一些經(jīng)驗(yàn)，在寫起 Android 的布局，倒也還好——沒有那么坑。

在布局調(diào)試上，還是前端用瀏覽器調(diào)式方便——還可以在瀏覽器實(shí)時(shí)修改 DOM 結(jié)構(gòu)。Android 也有這樣的工具，叫 Layout Inspector ：

除此，還可以通過 Facebook 家的 stetho 做與 Web 相關(guān)的調(diào)試工作：

總的來說，還算是不錯(cuò)的。就是這個(gè)結(jié)構(gòu)，看上去和 React Native 怎么那么樣呢？

代碼調(diào)試

在代碼調(diào)試上來說，Java 底子厚，總的來說會(huì)比 JavaScript 好一些。

除此，記得我們在 Chrome 瀏覽器里可以打斷點(diǎn)，隨后在 Console 中做出一些計(jì)算。而得益于 Android Studio 背后的 JetBrain 的 Evaluating Expressions，可以實(shí)時(shí)計(jì)算表達(dá)式的值，Android 上的代碼調(diào)試也是很容易的。

而以我有限的 Objective-C 編程經(jīng)驗(yàn)來說，XCode 也是可以做到的。

網(wǎng)絡(luò)調(diào)試

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

但是依賴上比較大，需要在頁面上注入，并且調(diào)試不了插件化的應(yīng)用。要調(diào)試網(wǎng)絡(luò)吧，還是 Charles 好用一些。

可是，萬一開發(fā)環(huán)境 HTTPS 了呢，不就更麻煩了。

兼容性

前端面臨的是調(diào)試不同的瀏覽器，又或者是兼容 IE。總的來說，問題都不大——不會(huì)面臨閃退的問題。即使出了點(diǎn)小問題，用戶可以先換個(gè)瀏覽器試試。而當(dāng)你的 Androdi 應(yīng)用在用戶的手機(jī)上閃退了，那么用戶只能換個(gè) APP 了。

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

結(jié)論

Android 在軟件工程上做得相當(dāng)優(yōu)秀，而前端則是在開發(fā)效率上占優(yōu)勢。

Web 開發(fā)大法好。