建站
咨詢
售后
建站咨詢
新聞中心
一個(gè)前端程序員的一個(gè)月原生 Android 開(kāi)發(fā)體驗(yàn)。自從我寫(xiě)了 Android 應(yīng)用后，上知乎的時(shí)間變得更長(zhǎng)了。
自從我寫(xiě)了 Android 應(yīng)用后，上知乎的時(shí)間變得更長(zhǎng)了。哦，不對(duì)，你理解錯(cuò)了，我的意思是：編譯代碼、打包 APK、運(yùn)行在設(shè)備上需要時(shí)間?？刹幌袂岸?，一保存代碼，就自動(dòng)刷新頁(yè)面。
是的，從上上周一開(kāi)始，因?yàn)轫?xiàng)目缺人的原因，作為一個(gè)有 Java 開(kāi)發(fā)經(jīng)驗(yàn)的大前端，我又又雙叕進(jìn)入了原生 Android 開(kāi)發(fā)的世界。
這一個(gè)月下來(lái)，也算是有一些寫(xiě) XML 的心得吧——不對(duì)，寫(xiě) Java 代碼，看 Kotlin 代碼的心得。總的來(lái)說(shuō)，Android 與前端的差異并不是非常大，在某些東西上，他們還是蠻相似的。怪不得像我這樣的程序員，會(huì)將 Android 開(kāi)發(fā)也歸類(lèi)到大前端上去。
如果你是一個(gè)前端程序員，想學(xué)習(xí)移動(dòng)開(kāi)發(fā)；又或者是一個(gè)移動(dòng)開(kāi)發(fā)，想接觸前端開(kāi)發(fā)；那么，本文可能就很適合你去了解兩者間的差異。
本文包含了以下的內(nèi)容：
- 編碼效率 vs 可維護(hù)度
- MVP vs MV ：后天的 MV
- 靜態(tài)語(yǔ)言 vs 動(dòng)態(tài)語(yǔ)言
- View 與 DOM
- 代碼調(diào)試
- 兼容性
（PS：受限于我只有短暫的經(jīng)驗(yàn)，所以有些用詞可能沒(méi)有那么準(zhǔn)確。）
注 ：這里的 前端應(yīng)用特指單頁(yè)面應(yīng)用 。
編碼效率 vs 可維護(hù)度
因?yàn)閺倪\(yùn)行效率上來(lái)說(shuō)，原生應(yīng)用必須遠(yuǎn)遠(yuǎn)大于 WebView——畢竟 WebView 的背后還是原生應(yīng)用，直接等于中間多了一個(gè)層級(jí)。所以，在這里直接討論編碼效率。
從編碼效率上來(lái)說(shuō)，還是前端快，快得不止一點(diǎn)點(diǎn)。
- 更快的預(yù)覽速度。
- 成熟的生態(tài)系統(tǒng)。
- 大量可用的 UI 框架及組件。
- 參考別家的實(shí)現(xiàn)。Web 前端是開(kāi)放的世界，在今天來(lái)看，要實(shí)現(xiàn)的效果基本上已經(jīng)被實(shí)現(xiàn)過(guò)了，所以我們可以直接參考
- 富文本支持好
而考慮到 Android 和 iOS 是各自實(shí)現(xiàn)的，那么一個(gè)混合應(yīng)用的開(kāi)發(fā)效率可能是遠(yuǎn)遠(yuǎn)大于 2 倍，而跨平臺(tái)應(yīng)用（如 React Native、Weex、NativeScript） 的開(kāi)發(fā)效率會(huì)接近他們的 2 倍（原因是：集成某些功能時(shí)，需要原生代碼來(lái)實(shí)現(xiàn)，這時(shí)工作量直接翻倍等同）。
從目前的維護(hù)程度上來(lái)說(shuō)，還是 Java 的代碼相對(duì)維護(hù)。主要是前端領(lǐng)域的變化太快了，并且在軟件工程上的實(shí)踐不像 Java 是必需要求的，因此容易出現(xiàn)大量的遺留代碼。只是考慮到，Java 代碼的臃腫，還是改用 Kotlin 吧。
只需要按下： Command + Alt + Shift + K ，輕松當(dāng)爸爸。
MVP vs MV ：后天的 MV
MVP，即 Model-View-Presenter，對(duì)應(yīng)于視圖層-數(shù)據(jù)層-展示層。
在 MVP 上來(lái)看，前端應(yīng)用與 Android 都并非天生的 MVP 架構(gòu)的。不過(guò)，兩者在對(duì)業(yè)務(wù)邏輯上的處理，但是沒(méi)有多少差異。***能體驗(yàn)差異的，可能就是 JavaScript 的異步，以及 Java 的同步帶來(lái)的一些差別。
V*
采用了框架的前端應(yīng)用，則會(huì)因此而帶上 MV* 的加成。一旦選用上了某個(gè)框架，那么你只能按照其特有的模式，如 Vue 提供的核心是 MVVM 中的 VM，React 則只是 MVC 中的 View 層，則 Angular 則可能是 MVW（Model-View-Whatever）。在這種情況下，要在框架的基本之上變更，那么靈活性上可能沒(méi)有那么大。
而 Android 方面則是 MVP 架構(gòu)，其主要依賴于 約定俗成 ，其中一個(gè)參考的規(guī)范就是 Google 官方的 android-architecture ，又或者是社區(qū)上推薦的 Clean Architecture。而無(wú)論是 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 來(lái)處理。簡(jiǎn)單來(lái)說(shuō)，就是你需要手動(dòng)地創(chuàng)建四五個(gè)類(lèi)，才能完成一個(gè) Activity 的 Hello, world。
Model
與此同時(shí)，Android 默認(rèn)是要對(duì) Model 進(jìn)行校驗(yàn)和轉(zhuǎn)換的。因?yàn)槿〕?JSON 中的某個(gè)值，需要將 JSON 轉(zhuǎn)換為對(duì)象——可以直接使用 Retrofit 庫(kù)來(lái)轉(zhuǎn)換數(shù)據(jù)，又或者用 GJSON 轉(zhuǎn)換成某種對(duì)象。算是與前端的一個(gè)大的區(qū)別，在前端世界里，這種事情是輕而易舉的，有***的 JSON.parse 。
在使用 JavaScript 編寫(xiě)的時(shí)候，可以不對(duì) Model 進(jìn)行校驗(yàn)。不過(guò)，在 React 里會(huì)有 proptypes ，在 Angular 里可以用 TypeScript 來(lái)做相似的事。
與沒(méi)有對(duì)象校驗(yàn)的前端相比，一旦出錯(cuò)，根本不容易察覺(jué)。這一點(diǎn)，或者也是一個(gè)優(yōu)勢(shì)所在——當(dāng)你上架了新版本的 API 時(shí)，舊的應(yīng)用不會(huì) NullPointerException。與此同時(shí)，在開(kāi)發(fā)的時(shí)候，后臺(tái) API 發(fā)生變化的時(shí)候，也會(huì)導(dǎo)致后續(xù)的一系列 bug。
靜態(tài)語(yǔ)言 vs 動(dòng)態(tài)語(yǔ)言
自從我寫(xiě)了 Android 應(yīng)用后，上知乎的時(shí)間變得更長(zhǎng)了。
編譯與動(dòng)態(tài)運(yùn)行
當(dāng)我們編寫(xiě) Web 應(yīng)用的時(shí)候，只要一保存代碼，網(wǎng)頁(yè)就可以由 LiveReload 這樣的工具來(lái)幫我們自動(dòng)刷新。于是，在諸如 React Native 這樣的跨平臺(tái)框架里，也有 Live Reload 這樣的特性。
而當(dāng)我開(kāi)發(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ù)代碼中的問(wèn)題，加個(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
- }
可由于沒(méi)有經(jīng)驗(yàn)，我經(jīng)常把 val 寫(xiě)成了 var 。這就和那些習(xí)慣寫(xiě) alloc init 的 iOS 程序員，一夜間突然喜歡上了寫(xiě) ES6 一樣：
- let className = NSStringFromClass(MyClass)
- let classType = NSClassFromString(className) as? MyClass.Type
- if let type = classType {
- let my = type.init()
- }
哦，不對(duì)他們寫(xiě)的是 Swift。
并且作為一個(gè)面向?qū)ο蟮恼Z(yǔ)言，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 上對(duì)語(yǔ)言的支持，要比 JavaScript 的 第三方庫(kù) 支持友好得多：
要知道 WebStorm 或者 Intellj IDEA 專業(yè)版，它們?cè)?JavaScript 第三方類(lèi)的支持上就是坑。
View 與 DOM
過(guò)去，前端在 DOM 操作上存在天然的問(wèn)題，即在我們使用 $("*") 的時(shí)候，全局。當(dāng)然現(xiàn)今的框架，在這個(gè)問(wèn)題上比較少，但是考慮到仍然可能會(huì)被誤用，或者注入。而 Android 則是局部頁(yè)面的。
樣式復(fù)用
前端使用 HTML + CSS 來(lái)編寫(xiě)樣式，而安裝則只使用 XML 來(lái)切圖，這并不是一件容易的事。不像 CSS 可以通過(guò) “繼承” 和 “覆寫(xiě)” 的形式來(lái)實(shí)現(xiàn)樣式復(fù)用。Android 中也有類(lèi)似于 JavaScript 生成 HTML 的方式，自定義模板。
當(dāng)我們使用 React 編寫(xiě)組件的時(shí)候，可以傳遞對(duì)應(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 在編寫(xiě) UI 的時(shí)候，有各種奇技淫巧，比如說(shuō)樣式的優(yōu)先級(jí)，或者 important 。
雙向綁定
從原生的角度來(lái)看，前端的 document.getElementById() 與 Android 的 findViewById 并沒(méi)有多大的區(qū)別。而當(dāng)前端有了前端框架之后，就不一樣了。好在 Android 有 ButterKnife 這樣的 View 注入框架。
與此同時(shí)，Android 還自帶了雙向的 DataBinding，而原生的前端是沒(méi)有的。
只是前端有前端框架，在這一點(diǎn)也完全問(wèn)題也不多。
布局調(diào)試
還好，已經(jīng)有寫(xiě) React Native 布局的一些經(jīng)驗(yàn)，在寫(xiě)起 Android 的布局，倒也還好——沒(méi)有那么坑。
在布局調(diào)試上，還是前端用瀏覽器調(diào)式方便——還可以在瀏覽器實(shí)時(shí)修改 DOM 結(jié)構(gòu)。Android 也有這樣的工具，叫 Layout Inspector ：
除此，還可以通過(guò) Facebook 家的 stetho 做與 Web 相關(guān)的調(diào)試工作：
總的來(lái)說(shuō)，還算是不錯(cuò)的。就是這個(gè)結(jié)構(gòu)，看上去和 React Native 怎么那么樣呢？
代碼調(diào)試
在代碼調(diào)試上來(lái)說(shuō)，Java 底子厚，總的來(lái)說(shuō)會(huì)比 JavaScript 好一些。
除此，記得我們?cè)?Chrome 瀏覽器里可以打斷點(diǎn)，隨后在 Console 中做出一些計(jì)算。而得益于 Android Studio 背后的 JetBrain 的 Evaluating Expressions，可以實(shí)時(shí)計(jì)算表達(dá)式的值，Android 上的代碼調(diào)試也是很容易的。
而以我有限的 Objective-C 編程經(jīng)驗(yàn)來(lái)說(shuō)，XCode 也是可以做到的。
網(wǎng)絡(luò)調(diào)試
在 Chrome 瀏覽器里，自帶的 NetWorks 幾乎是***的。Android 方面也可以借助于 Stetho 來(lái)使用：
但是依賴上比較大，需要在頁(yè)面上注入，并且調(diào)試不了插件化的應(yīng)用。要調(diào)試網(wǎng)絡(luò)吧，還是 Charles 好用一些。
可是，萬(wàn)一開(kāi)發(fā)環(huán)境 HTTPS 了呢，不就更麻煩了。
兼容性
前端面臨的是調(diào)試不同的瀏覽器，又或者是兼容 IE?？偟膩?lái)說(shuō)，問(wèn)題都不大——不會(huì)面臨閃退的問(wèn)題。即使出了點(diǎn)小問(wèn)題，用戶可以先換個(gè)瀏覽器試試。而當(dāng)你的 Androdi 應(yīng)用在用戶的手機(jī)上閃退了，那么用戶只能換個(gè) APP 了。
除此，Android 則是面臨碎片化的系統(tǒng)，不同的版本，及不同的屏幕大小，總的來(lái)說(shuō)，要對(duì)前端復(fù)雜得多。
結(jié)論
Android 在軟件工程上做得相當(dāng)優(yōu)秀，而前端則是在開(kāi)發(fā)效率上占優(yōu)勢(shì)。
Web 開(kāi)發(fā)大法好。
名稱欄目：一個(gè)前端程序員的一個(gè)月原生Android開(kāi)發(fā)體驗(yàn)
文章位置：http://www.dlmjj.cn/article/dhjhceo.html
