我的名字叫 Ryan Cooke 我在 Pinterest 的核心體驗(yàn)團(tuán)隊(duì)工作。今天在這里我會(huì)談?wù)摳鞣N Android 庫(kù)：它們各自的優(yōu)點(diǎn)，缺點(diǎn)和其他相關(guān)知識(shí)。目的是高效地概述盡可能多的庫(kù)，這樣，當(dāng)你遇到一個(gè)問(wèn)題的時(shí)候，你知道這是不是個(gè)已經(jīng)解決的問(wèn)題？什么樣的方案更好？同時(shí)也能幫助你避免那些陷阱。

[[204951]]

選擇正確的庫(kù)意味著你可以擁有一個(gè)已經(jīng)成熟的更好的解決方案，而不是花費(fèi)三個(gè)月來(lái)重新構(gòu)建它。了解這些庫(kù)是第一步。

我聽到很多人想要實(shí)現(xiàn)第一個(gè)庫(kù)， 我們難道不能用 Async 任務(wù)或原生的東西來(lái)做嗎？ Google 覺得，如果市面上已經(jīng)有一個(gè)解決方案了，他們就不想建立一個(gè)一模一樣的競(jìng)品。他們?cè)诙鄠€(gè)地方多次表達(dá)過(guò)這個(gè)想法。但是你應(yīng)該知道，你還有一些別的選擇。

一般提示

庫(kù)最有價(jià)值的地方在于 可逆 ：你將庫(kù)添加到你的應(yīng)用程序中，之后也可以將其刪除（沒有任何開銷）。隨時(shí)都能拿出來(lái)。不是所有的東西都可以這樣，但如果它可以的話，請(qǐng)把它做成一個(gè)庫(kù)，而不是和你的應(yīng)用終生綁在一起。

一個(gè)更好的方法是在把你的庫(kù)封裝起來(lái)。如果你自己的類調(diào)用了庫(kù)的方法，那么這樣做就有著許多的好處，可以讓使用者調(diào)用你自己的 API。例如，在某些情況下如果庫(kù)返回異常，你想在 API 里截獲它。你只用修改一個(gè)文件。有一個(gè)封裝器讓你的庫(kù)更易用些。

如果你正在做一個(gè)庫(kù)，你的團(tuán)隊(duì)里面的某些人可能已經(jīng)開始使用它了，他們知道該如何調(diào)用你的庫(kù)，而不用你的封裝。這個(gè)檢查樣式會(huì)在編譯的時(shí)候拋出異常，或者在應(yīng)用中當(dāng)他們?yōu)檫B接類使用 import 語(yǔ)句時(shí)，提示他們“不要使用連接類，使用封裝的 API”。你還會(huì)指出不要在這個(gè)特定文件上這樣做。如果你不這樣做，封裝器用處就不大，因?yàn)槿藗冏罱K會(huì)繞過(guò)它。

另外， 對(duì)第三方庫(kù)做單元測(cè)試 也是一個(gè)好主意。你需要這些測(cè)試，如果你正在使用 Joda-Time 這樣的庫(kù)，你可以使用單元測(cè)試來(lái)了解它奇怪的邊界情況。你甚至可以通過(guò)單元測(cè)試來(lái)了解它的工作原理。你可能會(huì)發(fā)現(xiàn)，如果你不用 add day 方法而是給今天加一的話，你可能會(huì)出現(xiàn)二月三十日的情況。

在 Android 的世界中，我們必須考慮 函數(shù)數(shù)量限制（64,000） 。（ 我在說(shuō)第三方函數(shù)庫(kù)的函數(shù)數(shù)量，它們會(huì)被精簡(jiǎn)掉 ）。有一個(gè)網(wǎng)站[函數(shù)數(shù)量]（http://methodscount.com），你可以上傳你的庫(kù)，Gradle 導(dǎo)入語(yǔ)句，然后它會(huì)告訴你這個(gè)庫(kù)有多少個(gè)方法（這是件很棒的事情，特別是當(dāng)你想使用該庫(kù)的時(shí)候）。使用 ProGuard，許多庫(kù)將會(huì)變得很小。這個(gè)方法使你只會(huì)包含庫(kù)中被引用的部分，但是在使用庫(kù)之前是很難預(yù)測(cè)你將要使用的內(nèi)容的。有些時(shí)候你可以這樣做，“我知道我只使用庫(kù)的這個(gè)方法”，看看它有多小。

Dex函數(shù)計(jì)數(shù) 會(huì)在你的 gradle 里，你也可以在你自己的編譯系統(tǒng)上這么做，跟蹤你應(yīng)用程序中函數(shù)的總個(gè)數(shù)。 Apk-method-count 是一個(gè)很棒的工具。你可以拖動(dòng)你的 APK，看看它有多少個(gè)方法（63,905 個(gè)方法，我喜歡生活在 64,000 的邊緣）。在 MultiDex 限制出現(xiàn)之前，你添加的每個(gè)方法仍將減慢那些舊設(shè)備的啟動(dòng)時(shí)間。雖然你的船已經(jīng)航行，不受 MultiDexing 的限制，十萬(wàn)種方法和十二萬(wàn)種方法之間還是有差別的。更少的方法總是有好處的。 Instagram 就是以 從庫(kù) 中提取所需的東西而不是使用完整的庫(kù)而聞名的。這是一個(gè)很好的實(shí)踐，如果你有精力這樣做的話。

除此之外，我還建議關(guān)注 流行的成熟庫(kù) 。每個(gè)月（特別是如果你訂閱了 Reddit Android 開發(fā)者），你將會(huì)聽到最新，最酷的庫(kù)。庫(kù)越成熟，就會(huì)越受歡迎。與現(xiàn)有的項(xiàng)目一起工作，兼容性問(wèn)題就越少。無(wú)論何時(shí)遇到問(wèn)題，stackoverflow 那里都會(huì)有答案。

另外，請(qǐng)注意特殊的方法。這是不符合 Java 標(biāo)準(zhǔn)的東西。如果你正在構(gòu)建完全不同的布局，那么很可能會(huì)有兼容性問(wèn)題。這時(shí)采用庫(kù)就會(huì)變得更加猶豫。

社交登錄

Facebook 是社交登錄的黃金標(biāo)準(zhǔn)（ 如果你不喜歡 Facebook 的實(shí)現(xiàn)，情況只會(huì)變得更糟 ）。他們提供測(cè)試用戶，你可以使用這些測(cè)試賬戶來(lái)測(cè)試。不再需要假帳戶了，你應(yīng)該使用他們的測(cè)試帳戶 - 它們工作的更好。我看過(guò)有人犯過(guò)這樣的錯(cuò)誤，你不能假設(shè)每個(gè) Facebook 用戶都有電子郵件。大約 10 到 15％ 的 Facebook 用戶沒有電子郵件。如果你期待電子郵件，這可能是 10 到 15％ 的注冊(cè)失敗的神秘原因。他們需要密鑰散列（ 這是一個(gè)隨機(jī)序列，某段代碼打印出的鍵值哈希 ），所以你不必處理它，不用理會(huì)它。如果你想申請(qǐng)些其他的瘋狂權(quán)限，他們現(xiàn)在已經(jīng)鎖定了這些權(quán)限。他們需要先看看你打算如何使用這些權(quán)限，如果你有這個(gè)瘋狂的想法而且應(yīng)用還沒有開發(fā)好，請(qǐng)?zhí)崆案嬷麄儭?/p>

登錄和注冊(cè)時(shí)，請(qǐng)記錄你所得到的錯(cuò)誤。這是我們?nèi)绾伟l(fā)現(xiàn)由于沒有電子郵件，10 到 15％ 的注冊(cè)失敗的方法。有時(shí)候記錄錯(cuò)誤可能是找到你不了解的東西的最有效的方法。

還有很多其他登錄選項(xiàng)：Twitter，LinkedIn，Google。我的心態(tài)是（特別是 Twitter，LinkedIn），雖然他們很受歡迎，但往往不值得的嘗試。你會(huì)看到不到 2％ 的注冊(cè)率，除非是一個(gè)非常好的場(chǎng)景。 LinkedIn 提供了非常具有挑戰(zhàn)性的 API（ 這不是我原來(lái)的單詞，但是 PR 告訴我，我應(yīng)該改變它 ）。 Twitter，他們不提供很多信息，但你可以 轉(zhuǎn)到此鏈接 ， 并且說(shuō)我需要電子郵件和基本信息，他們會(huì)給大家授予權(quán)限。但總體來(lái)說(shuō)，除非你的架構(gòu)非常好，這些都會(huì)增加你應(yīng)用的復(fù)雜性，。

Google 情況比較復(fù)雜。在 Android 上，很多人都會(huì)擁有 Google 帳戶。如果他們沒有 Google 帳戶，是非常奇怪的。但是你可以從 Google 登錄中獲得很多功能 - 你可以獲取電子郵件提示和其他東西。此外，登錄 UI 是十分丑陋的。還有點(diǎn)慢，所以你必須考慮加載模式的對(duì)話框。

聯(lián)網(wǎng)

如果你使用本地庫(kù)，那么有兩個(gè)大名鼎鼎的庫(kù)：Retrofit，Volley。還有 native HTML URL Connect（通常不推薦）。對(duì)于 Retrofit 和 Volley 來(lái)說(shuō)，你經(jīng)常會(huì)看到些比較，你會(huì)看到 Volley 比 Retrofit 做的更多（例如圖像下載和 neat ）。這具有欺騙性。

Retrofit 是由 Square 建造的，他們有一個(gè)哲學(xué)，他們的庫(kù)會(huì)盡可能少做事情。他們?cè)噲D讓庫(kù)嚴(yán)格地解決具體的問(wèn)題，解決這個(gè)問(wèn)題時(shí)，強(qiáng)制執(zhí)行良好的實(shí)踐。Retrofit 可能是他們最好的例子。這段代碼（ 見幻燈片 ）是我在一個(gè)應(yīng)用程序中使用 Retrofit 的示例，我必須為我的 API 調(diào)用創(chuàng)建一個(gè)非常干凈的接口。

Get more development news like this

Volley 給你足夠的繩子吊死自己。你可以使用 Volley，很容易用錯(cuò)。Retrofit 更好地強(qiáng)化了最佳實(shí)踐，我喜歡這樣的做法。

很多時(shí)候你會(huì)聽到 OkHttp：這是真正的幕后大舉提升網(wǎng)絡(luò)性能的功臣。它已經(jīng)在 Android 4.4 的 native 里面了。

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

考慮到網(wǎng)絡(luò)調(diào)試，你有網(wǎng)絡(luò)調(diào)用正在進(jìn)行，你想了解發(fā)生了些什么。

Stetho

Stetho 是一個(gè)很好的選擇。它是 Facebook 開發(fā)的。它為你的網(wǎng)絡(luò)調(diào)用提供了 Chrome 開發(fā)者工具視圖。它還提供了許多其他的好東西：可以查看你的數(shù)據(jù)庫(kù)，看看那里發(fā)生了什么;可以看到你的布局，如果你不知道屏幕上發(fā)生了什么。其中需要注意的是，你必須在每次運(yùn)行時(shí)啟動(dòng)它，否則它會(huì)自動(dòng)關(guān)閉。雖然時(shí)間是準(zhǔn)確的，但它會(huì)使你網(wǎng)絡(luò)調(diào)用的時(shí)間更長(zhǎng)。

HttpLoggingInterceptor

我個(gè)人傾向于另一個(gè)簡(jiǎn)單的 HttpLoggingInterceptor。你將攔截器添加到你的網(wǎng)絡(luò)請(qǐng)求中，并將其打印在日志文件上。你也可以看到一些 JSON 文件。有一堆類似的東西都命名為 logging 攔截器。使用 Square 的標(biāo)準(zhǔn) HTTP 日志記錄可以讓你更輕松地瀏覽，非常方便。

圖片

作為在 Pinterest 工作的人，圖片很重要。如果你正在做圖片相關(guān)的應(yīng)用，你可能希望使用第三方庫(kù)來(lái)處理圖片緩存，圖片下載和圖片大小調(diào)整。

Picasso,Glide

圖片處理庫(kù)里最有名的兩個(gè)庫(kù)是 Picasso 和 Glide。他們有著非常相似的接口；對(duì)于大多數(shù)標(biāo)準(zhǔn)用戶來(lái)說(shuō)接口基本相同。

Picasso 較小。最新版本從 2,879 行縮小到 849 行。但是，Glide 傾向于提供你想要的每個(gè)功能：它可以加載 GIF，也可以顯示視頻預(yù)覽圖像。

如果你正在加載圖片，Picasso 比較合適。它更受歡迎：它有更多的文檔，更多的支持。兩個(gè)庫(kù)都很好。如果你一直都有些奇怪的場(chǎng)景，你可以冒險(xiǎn)使用 Glide。如果你的使用場(chǎng)景很標(biāo)準(zhǔn)，Picasso 是一個(gè)不錯(cuò)的選擇。

提示

我已經(jīng)提到我在 Pinterest 工作，而且圖像對(duì)我的工作很重要。我必須扔出一堆關(guān)于圖像的提示。

人們都沒有做最簡(jiǎn)單的事情，因?yàn)檫@些庫(kù)沒有這樣做，這件簡(jiǎn)單的事情就是在列表中預(yù)取。每當(dāng)你滾動(dòng)列表時(shí)，你都會(huì)看到圖像在加載。如果你預(yù)取了下一個(gè)或兩個(gè)圖像，那么當(dāng)你滾動(dòng)時(shí)，將會(huì)減少幀丟失。這會(huì)給你帶來(lái)更好的體驗(yàn)，不需要等待加載了。如果你預(yù)取的圖像太多，資源就會(huì)競(jìng)爭(zhēng)，也不好，但預(yù)取下一個(gè)或兩個(gè)圖像一定會(huì)帶來(lái)更好的體驗(yàn)。

除此之外，這些庫(kù)都不能解決你圖像的內(nèi)存問(wèn)題。最簡(jiǎn)單的做法是禁用圖像，然后計(jì)算出應(yīng)用程序中的圖像消耗了多少內(nèi)存。不使用圖像，計(jì)算出省下的內(nèi)存消耗。另外，釋放沒有顯示圖像的圖像，并將圖像的大小調(diào)整為你顯示的尺寸也可以幫助節(jié)省內(nèi)存。 Cloudinary 是一個(gè)很酷的托管服務(wù)，你可以以特定的分辨率請(qǐng)求圖像。他們努力做到這點(diǎn)。但是，當(dāng)你調(diào)整請(qǐng)求的圖像大小時(shí)，你必須確保你沒有通過(guò)請(qǐng)求類似的圖像來(lái)破壞緩存（所以這里有個(gè)平衡）。

我是 bigHeap 的粉絲。我們的一個(gè)的應(yīng)用程序，使用了 bigHeap 后，內(nèi)存崩潰降到原來(lái)的 1/4。 Google 不鼓勵(lì)使用它，因?yàn)樗P(guān)閉了在后臺(tái)的其他應(yīng)用程序，因此應(yīng)用程序之間的切換并不是那么好。但在某些時(shí)候，這不是你的問(wèn)題。垃圾回收也需要更長(zhǎng)時(shí)間，你可以使用它來(lái)屏蔽內(nèi)存問(wèn)題（你不應(yīng)該這么做）。一般來(lái)說(shuō)，bigHeap 是好的。如果你去 Play Store，并且搜索 largeHeap，你可以下載一個(gè)很酷的應(yīng)用程序，它會(huì)顯示你手機(jī)上啟用了 bigHeap 的應(yīng)用程序。你會(huì)注意到現(xiàn)在幾乎每個(gè)人都陷入了困境，并且正在使用 bigHeap。

當(dāng)你想到內(nèi)存和圖像時(shí)，這里有一個(gè)簡(jiǎn)單的公式。有些人會(huì)問(wèn)，“這是個(gè)兩千字節(jié)的 JPEG，為什么我的實(shí)際使用的內(nèi)存會(huì)這么大呢？” 使用的內(nèi)存是像素寬度乘以像素高度的四倍。這就是你期望的大小。它們的標(biāo)準(zhǔn)格式是 ARGB_8888 - 它用四個(gè)字節(jié)存儲(chǔ)顏色空間。如果你使用 RGB_565，你可以將其減少到兩倍。但是顏色彼此會(huì)非常相似，你會(huì)看到更少的色彩空間，它也不能做 alpha，但它會(huì)減少一半的內(nèi)存使用量。你可以考慮在低端設(shè)備或低版本 API 上進(jìn)行此操作。這是節(jié)省內(nèi)存不足問(wèn)題的好方法。

Fresco

Facebook 發(fā)布了一個(gè)神奇的庫(kù)，解決了 API 21 之前的所有版本的內(nèi)存不足問(wèn)題。在 API 21 之前，Android 系統(tǒng)中出現(xiàn)了一個(gè)錯(cuò)誤，你可以在應(yīng)用程序內(nèi)存之外使用其他的內(nèi)存。但是會(huì)帶來(lái)些奇怪的情況：你的程序在舊設(shè)備上沒有問(wèn)題，但在新設(shè)備上會(huì)表現(xiàn)更糟。因?yàn)樗虞d的方式與其他庫(kù)非常不同，所以它可以實(shí)現(xiàn)漸進(jìn)式 JPEG 這樣的圖像，圖像在圖層中逐漸加載。但是，它們會(huì)更深入地耦合在你的應(yīng)用程序中。借助 Glide 和 Picasso，你可以將其與你的應(yīng)用隔離的很好。而不使用 imageViews，你必須使用它們的類型 Drawees，并且還會(huì)產(chǎn)生更多的孤島代碼。

如果你定位較低端的設(shè)備，你在舊設(shè)備上有更多的內(nèi)存需求，我建議你使用 Fresco。除此之外，我會(huì)堅(jiān)持 Picasso 和 Glide。

內(nèi)存 - 泄漏

LeakCanary

LeakCanary 是當(dāng)今內(nèi)存泄露的神器，它可以幫助你找到內(nèi)存泄露的地方。泄漏不是所有的內(nèi)存問(wèn)題，但是值得留意。當(dāng)你將 LeakCanary 添加到應(yīng)用程序中時(shí)，它會(huì)自動(dòng)開始觀察你的 activity 的內(nèi)存泄漏。有一個(gè)我親眼所見的誤用是，他們將 LeakCanary 添加到應(yīng)用程序中。修復(fù)一個(gè)或兩個(gè)泄漏，然后就認(rèn)為再?zèng)]有更多的內(nèi)存泄漏了。它只監(jiān)視了 activity。如果你在這里使用這個(gè)代碼（ 看幻燈片 ），你可以讓它監(jiān)視 fragment。這并不意味著你不會(huì)在別處泄漏內(nèi)存。activity 和 fragment 是監(jiān)測(cè)的好地方，但如果你沒有將觀察者設(shè)置為對(duì)象，你是不知道所有的泄露的。

簡(jiǎn)單來(lái)說(shuō)，它的工作原理很酷。作為你引用的任何對(duì)象的弱引用：將其附加到你不再被引用的內(nèi)容中。你把它放在 destroy 代碼段。然后它做垃圾回收。如果對(duì)象仍然存在，這就是內(nèi)存泄漏，所以它知道什么對(duì)象依舊存在。它給你那個(gè) home fragment 現(xiàn)場(chǎng)的相關(guān)引用。我覺得這很難理解（*有些人認(rèn)為這很簡(jiǎn)單，有人認(rèn)為這很難。）

這里有個(gè) view 的例子來(lái)做點(diǎn)簡(jiǎn)單說(shuō)明（ 見幻燈片 ）。你從底部開始（這就是泄露的東西）。我有 home fragment。 它被 pin grid fragment 引用 - pin grid fragment 是這個(gè)對(duì)象的父親。然后我們有這個(gè)奇怪的$ 0 - 它解釋說(shuō)，這是一個(gè)可運(yùn)行的對(duì)象。對(duì)象內(nèi)有一個(gè)處理程序包含一個(gè) runnable。這段代碼（這不是我的），它是 Android 操作系統(tǒng)的，是處理程序的代碼。處理程序有個(gè) runnalbe 正在運(yùn)行。我需要確保處理程序不再保留 runnable。在這種情況下，我可以在視圖的 destroy 中清除所有的 runnable 和處理程序，這將修復(fù)這個(gè)內(nèi)存泄漏。

WeakHandler

你還可以使用這個(gè)隨機(jī)工具 WeakHandler，這使得處理程序引用都是弱引用。如果你觸發(fā)一個(gè)垃圾回收，就可以回收它們。它的缺點(diǎn)是可以被垃圾回收 - 如果你不希望它們被垃圾回收，那可能會(huì)出現(xiàn)意想不到的事情。值得注意的是，我遇到的大多數(shù)內(nèi)存泄漏都是無(wú)效的，它通常是一個(gè)正在運(yùn)行的 non-missed 的類持有外部類 （這是最常見的地方） 。對(duì)于你的內(nèi)存泄漏，還需要一個(gè) bug 分類的方法。沒有什么比你手機(jī)上有 70 個(gè)內(nèi)存泄漏， 而你不知道下一步該做什么更糟糕了。作為一個(gè)團(tuán)隊(duì)，弄清楚當(dāng)我們發(fā)現(xiàn)內(nèi)存泄漏時(shí)要做什么，總是一個(gè)好主意。

UI

我們都知道我們一直深陷泥潭。Activity 是舊標(biāo)準(zhǔn)。因?yàn)槟阆胫赜?，所以有?fragment。但是最后我們用 fragment 把 UI 顯示做的異常復(fù)雜。試試另一種方法，基于視圖的架構(gòu)，它更流行。在基于視圖的架構(gòu)里，你有一個(gè)框架布局，而不用處理任何原生的 Android navigation 的東西，你可以用你想要的視圖替換內(nèi)部的框架布局里的任何東西。希望這能夠解決 fragment 的復(fù)雜性。

fragment 已經(jīng)被簡(jiǎn)化了，而且更新了版本，它們現(xiàn)在更加穩(wěn)定，但是人們依舊爭(zhēng)論著需要有基于視圖的架構(gòu)。如果我們遵循這個(gè)論點(diǎn)，我們應(yīng)該看看一些庫(kù)（圖形的底部， 看幻燈片 ）。

基于視圖的架構(gòu)

這個(gè)架構(gòu)是由 Mortar 和 Flow 引入的。我相信他們是第一批普及基于視圖的架構(gòu)的庫(kù)。 Flow 真正地遵循了基于視圖的架構(gòu)，但是它們往往是一起的，而 Mortar 主要是 MVP 模式。當(dāng)你開始實(shí)現(xiàn)基于視圖的架構(gòu)時(shí)，請(qǐng)注意這個(gè)奇怪的地方。

你還可以找到些更奇怪的地方，那就是如果你的應(yīng)用是基于 View 的話，你會(huì)遇到些隨機(jī)的問(wèn)題，因?yàn)檫@個(gè)庫(kù)不是基于 View 的。它是基于 activity 的， 如果你的應(yīng)用是基于 view 的話，你得自己去解決那些問(wèn)題。比如基于 View 的標(biāo)準(zhǔn)問(wèn)題，例如 on-activity 的行為，許可等等。即使是后退按鈕和導(dǎo)航，你都不得不自己去解決，只要你是基于 View 的。

Mortar 和 Flow完成基本的導(dǎo)航功能，但它們并不解決所有常見問(wèn)題（例如屏幕上保存的狀態(tài)）。

Conductor正是為這些基于 View 的視圖而生的，它創(chuàng)建了一個(gè)解決方案：比如保存狀態(tài)，轉(zhuǎn)換等等。但是你仍然會(huì)遇到兼容性問(wèn)題。總的來(lái)說(shuō)，他們是非常好的，他們是架構(gòu)不可知的，所以你可以采用你自己的 MV。

Scoop 來(lái)自 Lyft。他們?cè)诋a(chǎn)品中使用它。它是經(jīng)過(guò)產(chǎn)品測(cè)試的基于視圖架構(gòu)的解決方案。它們不保存狀態(tài)，所以 Lyft 無(wú)法保存狀態(tài)。在你將要使用基于視圖的架構(gòu)的主要常見問(wèn)題中，這是最大的問(wèn)題。切換很容易使用，但也很有限，這對(duì)于基于視圖的體系結(jié)構(gòu)來(lái)說(shuō)有點(diǎn)令人失望，因?yàn)樵谶@種架構(gòu)下，你往往可以實(shí)現(xiàn)很好的切換。

總的來(lái)說(shuō)，如果你不需要保存狀態(tài)，Scoop 是可用的，最安全的產(chǎn)品。Conductor 也很好。我會(huì)推薦這兩個(gè)庫(kù)。

模型 視圖 表示（MVP）

有幾個(gè)很好的 MVP 的庫(kù)。MVP 的基本思想是把邏輯代碼分離出來(lái)，這樣視圖部分，Core Android 的東西，會(huì)放在一起，然后 presenter 也是分開的，我們可以單元測(cè)試這個(gè) presenter。理論上，我們可以改變視圖，而不必完全重寫業(yè)務(wù)邏輯。

有很多方法來(lái)做 MVP。我推薦的第一個(gè)庫(kù)是 Mosby 。即使你不使用 Mosby，他們也有很棒的教程和 Android 相關(guān)的文章（ 比如 MVP 應(yīng)該是什么樣的，它如何工作 ）。它主要能提供的功能是給你的 presenter 提供視圖狀態(tài)。

Nucleus也很類似。 Mortar ，作為 Mortar 和 Flow 的一部分，是它們?cè)缙诘陌姹?，它們?cè)缴?jí)問(wèn)題越多。我看到公司常常自己 構(gòu)建 MVP ：在創(chuàng)建時(shí)，你將啟動(dòng)你的 presenter; 銷毀時(shí)，你會(huì)停止你的 presenter 。每個(gè) activity 或任何你的視圖持有的任何東西都會(huì)有一個(gè) presenter。

所有的這些權(quán)衡，雖然聽起來(lái)很簡(jiǎn)單，當(dāng)你實(shí)際操作一個(gè)用例時(shí)，有很多邊緣案例要考慮。你有你的適配器，你的視圖項(xiàng)目。確保每個(gè)人理解的都一樣，并且找到能夠運(yùn)用 MVP 的地方是最難的部分。但是這樣做的最終結(jié)果是你可以獲得更多的可單元測(cè)試代碼。你可以獲得更穩(wěn)定的代碼。

測(cè)試 - 性能

NimbleDroid

我有一堆關(guān)于測(cè)試的內(nèi)容，但我不想讓你們聽三個(gè)小時(shí)測(cè)試的東西，所以我們跳過(guò)使用 JUnit 4 進(jìn)行單元測(cè)試。你有一個(gè) Gradle 構(gòu)建系統(tǒng)，有 Espresso。這些都是標(biāo)配。性能測(cè)試是個(gè)非標(biāo)的工具。

執(zhí)行性能測(cè)試有兩種主要的方法。 Google 傾向于主張使用 Systrace 類似的方法來(lái)查看丟幀率，他們有一個(gè)代碼庫(kù)，可以為你提供幾乎能直接工作的代碼（但不是很有效）。這允許你進(jìn)行自動(dòng)化性能測(cè)試，以查看丟幀率是否變化。

NimbleDroid 有一個(gè)免費(fèi)的試用選項(xiàng)，你可以在其中上傳 APK，它將自動(dòng)測(cè)試?yán)鋯?dòng)，你也可以增加些應(yīng)用程序中的關(guān)鍵流程。他們提供一個(gè)函數(shù)發(fā)生的時(shí)間序列圖和詳細(xì)信息。它可以免費(fèi)進(jìn)行試用（例如上傳你的 APK 并獲得冷啟動(dòng)時(shí)間，看是否有明顯問(wèn)題）。如果你想使用它來(lái)進(jìn)行回歸測(cè)試，那么它是很貴的，但它會(huì)幫助你意識(shí)到，有人做了一個(gè)改動(dòng)，我們的啟動(dòng)時(shí)間變慢了，或者我們的關(guān)鍵流程慢了。如果性能是一個(gè)高優(yōu)先級(jí)的目標(biāo)，那么使用它是很有效的。

JSON

人們?cè)诳紤]性能時(shí)往往都會(huì)想到 JSON。有很多的 JSON 庫(kù)。我的第一個(gè)警告是：人們喜歡純粹通過(guò)性能來(lái)看待 JSON 庫(kù)。這是一個(gè)錯(cuò)誤。我收到了我最大的請(qǐng)求（150千字節(jié)，30,000行，巨大的 JSON 文件）。我分別用 GSON 和 Jackson 解析了它們。它們相差大約 20 毫秒，對(duì)于那個(gè)巨大的文件來(lái)說(shuō)，這并不瘋狂。

我的第一個(gè)建議是：更多地關(guān)注易于使用的東西，有很好的文檔的庫(kù)。你希望得到支持。你不用花幾個(gè)星期讓開發(fā)人員嘗試找出原因，就因?yàn)?stackoverflow 沒有答案。除非你對(duì)性能有超高的要求，GSON 和 Jackson 是使用最多的，最受歡迎的，特別是在 Android 上，GSON 更受歡迎。

Moshi 是 Square 采用的庫(kù)。它跟 GSON 非常相似。我試圖就如何使用好 GSON 給出了一些意見。你可以同意或不同意這些觀點(diǎn)，但都不會(huì)錯(cuò)。

如果你關(guān)心 JSON 解析性能，并希望它更快，LoganSquare 是一個(gè)很好的選擇。它們?cè)诰幾g的時(shí)候完成了其他庫(kù)需要在運(yùn)行時(shí)完成的工作。與其他的庫(kù)相比，這將使你節(jié)約大約 1/4 的時(shí)間，或四倍的性能提升。如果你真的關(guān)心 JSON 性能，你不應(yīng)該使用 JSON。

相反，你可以使用 Flatbuffer。 JSON 人類可讀，F(xiàn)latbuffer 不是，但是因?yàn)檫@樣，它丟掉了其他的不需要的負(fù)擔(dān)。但是 Flatbuffer 與 JSON 相比，F(xiàn)albuffer 解析幾乎不花時(shí)間。Facebook 做了這個(gè)轉(zhuǎn)換。他們發(fā)現(xiàn)啟動(dòng)時(shí)間增加了 10％ 到 15％，啟動(dòng)時(shí)間有所改善。他們也觀察到內(nèi)存使用效率更高。但是使用起來(lái)比 JSON 更難，所以謹(jǐn)慎使用。

數(shù)據(jù)庫(kù) - SQL

對(duì)于數(shù)據(jù)庫(kù)，我們知道常見的是 SQLite - 標(biāo)準(zhǔn) Android 庫(kù)。

SQLBrite 是 SQLite 上一個(gè)常見的簡(jiǎn)單庫(kù);它為你提供了數(shù)據(jù)庫(kù)的 reactive 接口。你可以監(jiān)聽你的用戶。如果你的用戶有任何更改，你會(huì)收到通知，你可以隨即更新用戶界面。這是一個(gè)非常小的庫(kù)。和 SQL 兼容的很干凈。

SQLDelight 也來(lái)自 Square。他們寫了很多庫(kù)。它試圖避免成為一個(gè)完整的 ORM，因?yàn)?ORM 會(huì)泄漏太多你的代碼，并且往往迫使你做太多的事情，當(dāng)然它仍然試圖使數(shù)據(jù)庫(kù)的工作更容易些。它使得 API 類型安全，使得 SQL 語(yǔ)句組織的很好（它嘗試使其更容易些，同時(shí)不會(huì)太重）。

如果你愿意去做一個(gè)完整的 ORM，那么有很多很好的庫(kù)：GreenDAO，OrmLite，DBFlow 是一些比較受歡迎的（ 還有許多其他選擇 ）。他們都會(huì)說(shuō)，它們?cè)谛阅芊奖惚憩F(xiàn)最好。每個(gè)庫(kù)都有些圖表，這些圖表顯示它們比其他的方案快 100 倍。我的建議是易用性是第一優(yōu)先事項(xiàng)，然后再考慮是他們?cè)谛阅苌鲜遣皇菚?huì)更好。

數(shù)據(jù)庫(kù) - NoSQL

Realm 是 NoSQL 的方法。它超級(jí)快。與其他可比較的數(shù)據(jù)庫(kù)不同，Realm 支持的文檔非常多。這可以最終節(jié)省你大量的開發(fā)時(shí)間，而且無(wú)所謂數(shù)據(jù)庫(kù)類型。

Google 推薦的另一種 NoSQL 方法是 LevelDB。鍵值對(duì)，但是它可以說(shuō)是 “你能夠弄清楚該怎么做，但你必須自己弄清楚每一步”。 Realm db 可以幫助你避免這種情況。

Realm 數(shù)據(jù)庫(kù)需要特別注意的地方是它的大?。?我認(rèn)為我們最初添加它時(shí)，我們的應(yīng)用程序大小增加了一倍 ）。原因是它是一個(gè)本地庫(kù)。對(duì)于每個(gè)芯片架構(gòu)，它們?cè)谀愕膽?yīng)用程序中都包含了 Realm 數(shù)據(jù)庫(kù)的完整副本。為了避免這種情況，你可以將此代碼放入 Gradle（ 參見幻燈片中的代碼 ），并為每個(gè)架構(gòu)生成一個(gè)單獨(dú)的 APK。你把它分解成多少個(gè)版本，大小就會(huì)減少多少。這也會(huì)使你的內(nèi)存節(jié)省很多。對(duì)于任何本地運(yùn)行的 C++ 代碼，這是正確的做法，所以在 Crashlytics 和其他一些受歡迎的庫(kù)中，你能看到同樣的收益。

還有另外一款很酷的 Google Play 商店的應(yīng)用程序 Native Lib。 - 它在 Play 商店中，它會(huì)顯示些本機(jī)庫(kù)，以便你可以看到你是否為你的 APK 下載了不適用于你手機(jī)的代碼庫(kù)。這樣做會(huì)減少內(nèi)存使用。如果你就是在尋找手機(jī)上保存數(shù)據(jù)的方案，你可能希望在手機(jī)上存儲(chǔ)數(shù)據(jù)。如果你正在構(gòu)建一次性的應(yīng)用程序，請(qǐng)不要保持?jǐn)?shù)據(jù)。如果你正在使用 Realm 在存儲(chǔ)量很小的手機(jī)上構(gòu)建應(yīng)用（為什么在這種情況下你的應(yīng)用需要占用大量的存儲(chǔ)）？但總的來(lái)說(shuō)，這是一個(gè)非常好的數(shù)據(jù)庫(kù)解決方案。

數(shù)據(jù)庫(kù) - 移動(dòng)平臺(tái)

另一個(gè)方面是移動(dòng)平臺(tái)：移動(dòng)開發(fā)人員的夢(mèng)想，我們不再需要這些服務(wù)器指南。我們也可以自己構(gòu)建應(yīng)用程序。以前的 Parse 是最好的例子（可能會(huì)安息）。

現(xiàn)在移動(dòng)平臺(tái)中最有名的就是 Firebase 和 Realm。它們都是 NoSQL 模型，它們有一些查詢方面的挑戰(zhàn)，但是構(gòu)建速度非常非?？?。非常適合進(jìn)行同步更新。聊天是最常見的解決方案，你發(fā)送聊天消息，突然所有的手機(jī)都能獲取更新。不必構(gòu)建數(shù)據(jù)庫(kù)，不必?fù)碛蟹?wù)器，你可以使用其中一個(gè)解決方案。它使得構(gòu)建過(guò)程非常迅速，馬上完成應(yīng)用并推向市場(chǎng)。而且性能也特別好。

Realm 與 Firebase 的區(qū)別是它有離線優(yōu)先的優(yōu)點(diǎn)。它們都可以脫機(jī)，但是 Firebase 是事后補(bǔ)救，而 Realm 是事先就設(shè)計(jì)好了，Realm 在許多方面都支持離線。許多應(yīng)用程序幾乎不需要在線行為。如果你正在考慮運(yùn)行應(yīng)用跟蹤程序，我們希望同步我們的運(yùn)行狀態(tài)，而且我們希望所有功能都能完全脫機(jī)運(yùn)行，之后在線工作也正常。Realm 就會(huì)脫穎而出。

Analytics

我喜歡分析。精益創(chuàng)業(yè)的說(shuō)法是。如果你可以測(cè)量它，你就可以優(yōu)化它。如果你沒有數(shù)字的東西，一切都是隨機(jī)的，你只能猜想如何使它更好。我喜歡有詳細(xì)的分析，來(lái)了解這個(gè)改變是否使事情變得更好？人們是否使用此功能？如何改善它？

Analytics 是封裝第三方庫(kù)的理想選擇。如果你封裝好了 Analytics，那么你應(yīng)該能夠在不修改任何功能代碼的前提下，完全替代你的分析服務(wù)。你應(yīng)該能夠很容易地添加一個(gè)新的 Analytics 服務(wù)，以便它們能同時(shí)工作。封裝 Analytics 代碼是一個(gè)很好的實(shí)踐。

如果你正在添加分析數(shù)據(jù)，最簡(jiǎn)單的方法是記錄你的屏幕，記錄人們?yōu)g覽過(guò)的屏幕，將其放在抽象的 activity 中。這樣會(huì)很快地獲得很多的價(jià)值。

我看到人們使用 Analytics 技術(shù)的常見錯(cuò)誤是增加了太多的 Analytics 。他們會(huì)在任何地方添加一千個(gè)事件，然后沒有人知道這個(gè)分析意味著什么。他們沒有進(jìn)行充分的測(cè)試，所以你真實(shí)的注冊(cè)只有注冊(cè)的 2/3。在添加分析時(shí)需要非常小心。嘗試使用簡(jiǎn)單的命名和標(biāo)準(zhǔn)。不要使用分析來(lái)延遲輕松的決定。如果有一個(gè)容易的決定，那么請(qǐng)開始。如果你的分析結(jié)果告訴你“人們不喜歡釋放內(nèi)存”，那先假設(shè)你的分析是錯(cuò)誤的。得出一個(gè)錯(cuò)誤的結(jié)論是很容易的。如果你有一個(gè)很重要的結(jié)論，首先要做的是確認(rèn)你的分析代碼方面沒有什么瘋狂的事情。

Firebase

Firebase 曾經(jīng)是一個(gè)實(shí)時(shí)數(shù)據(jù)庫(kù)，然后 Google（混淆我們）開始使用一大堆叫做 Firebase 的工具。Firebase Analytics 是所有 Firebase 工具的基礎(chǔ)。Google 意識(shí)到 iOS 和 Android 開發(fā)人員正在解決同樣的問(wèn)題。他們正在使用第三方服務(wù)并且通過(guò)付費(fèi)來(lái)解決所有這些問(wèn)題。他們認(rèn)為，我們可以使構(gòu)建應(yīng)用程序更加容易，而且構(gòu)建應(yīng)用程序更容易，賺的錢就更多。他們做了這些工具的競(jìng)品。迫使它們更好用，谷歌試圖使分析工具成為所有的工具的基礎(chǔ)。這樣做的愿景是，如果你收到崩潰報(bào)告，看到你的分析數(shù)據(jù)，你可以按照崩潰的投資回報(bào)率給它們排序。你的通知系統(tǒng)也參與其中，你可以發(fā)送通知給那些碰到最昂貴的崩潰的客戶，并告訴他們一些免費(fèi)的折扣。我們知道你即將購(gòu)買，因?yàn)槟闶且粋€(gè)高價(jià)值的崩潰。

這是個(gè)很酷的愿景。還沒有實(shí)現(xiàn)，實(shí)話實(shí)說(shuō)。有些工作正常，有些還在開發(fā)中，這不是谷歌最高的優(yōu)先級(jí)的任務(wù)。但是很多工具還是很好的（不如競(jìng)爭(zhēng)對(duì)手的工具）。 Analytics 雖然是免費(fèi)的。但是事件不受限制。沒有太多的理由不使用它。

另一個(gè)流行的是 Google Analytics（分析）。它很容易地獲得許多關(guān)于用戶的基本信息。這是我看到的唯一一個(gè)提供很酷的行為流程圖的工具，在那里你可以看到人們?cè)谀愕氖录g切換。它還是有點(diǎn)過(guò)時(shí)了，其記錄事件的風(fēng)格比所有其他分析工具更舊。它也是免費(fèi)的，F(xiàn)irebase 意在替換它。

A / B 測(cè)試

我個(gè)人認(rèn)為 A / B 測(cè)試被過(guò)度宣傳。通常它被用于慢速學(xué)習(xí)，以便你了解的更清楚，如果是簡(jiǎn)單的命名規(guī)則就不適用了，當(dāng)然你可以將其投放到用戶手里，你會(huì)發(fā)現(xiàn)，100 個(gè)用戶的樣本中，55％ 偏好了這一選擇。這就是你通常看到的 A / B 測(cè)試。

它很容易產(chǎn)生 Bug?；旧希珹 / B 測(cè)試中應(yīng)用程序版本數(shù)是你應(yīng)用程序中的 A / B 測(cè)試數(shù)加 2。如果你的應(yīng)用程序中有 3 個(gè) A / B 測(cè)試，那么就有 8 個(gè)不同版本應(yīng)用程序一起工作。你可能沒有測(cè)試各種不同版本的應(yīng)用程序。有時(shí)候你可能會(huì)發(fā)現(xiàn)因?yàn)檫@些問(wèn)題，往往會(huì)導(dǎo)致重要的決定不太容易做了。

我的解決方案是用戶分析服務(wù)。 Mixpanel 具有非常好的 A / B 測(cè)試工具，而且和你的分析工具兼容。有許多工具用于 A / B 測(cè)試。我想說(shuō)最有名的是 Optimizely 和 Apptomize。Optimizely 更適合網(wǎng)頁(yè)（ 他們的價(jià)格 都有點(diǎn)神秘）。他們幫助你提供不同的版本，告訴你這是一個(gè)比另一個(gè)有顯著的更好的統(tǒng)計(jì)學(xué)差異的版本。

Firebase Remote Config 在技術(shù)上可以用來(lái)進(jìn)行 A / B 測(cè)試。它不是用于 A / B 測(cè)試的。它是用來(lái)在不需要開發(fā)人員的更新的情況下，從服務(wù)器發(fā)送鍵值對(duì)的，但是這能讓我們做 A / B 測(cè)試。你可以發(fā)送兩個(gè)不同版本的鍵值對(duì)，然后你可以使用代碼來(lái)決定要做什么。之后，你可以將其傳遞到你自己的分析界面，并找出解析它的方法。從某個(gè)角度說(shuō)，如果你使用 Firebase 遠(yuǎn)程配置，你是在創(chuàng)造輪子。

你也可以使用 A / B 測(cè)試商店列表。這是值得嘗試的，特別是你在不同的國(guó)家里測(cè)試。這是比較容易的，你可以在那里獲得一些收獲。

崩潰報(bào)告

像分析一樣，有一千個(gè)解決方案。 我只打算介紹少數(shù)幾個(gè)

人們首先看到，特別是 Android 新手，那就是 Play 商店。每當(dāng)你遇到崩潰時(shí)，你可以選擇發(fā)送報(bào)告。大家都會(huì)直接忽略，大約 1％ 的崩潰出現(xiàn)在 Play 商店中。有時(shí)候，如果你的用戶數(shù)非常大，而且有些非常神秘的崩潰，那可能值得去看看，因?yàn)槿藗儠?huì)對(duì)發(fā)生的事情發(fā)表評(píng)論。也就是說(shuō)，你有 1％ 的崩潰; “99％ 的人說(shuō)應(yīng)用很爛，崩潰”。但是每隔一段時(shí)間，就會(huì)有這樣的評(píng)論 “我在手機(jī)上旋轉(zhuǎn)了屏幕，它崩潰了”（ 你好像是，啊，一個(gè)開發(fā)者，我很感激 ）

Crashlytics 趨勢(shì)是最受歡迎的。這是 Twitter 的 Fabric Suite 或者說(shuō)是現(xiàn)在的 Google Fabric Suite 的一部分。它是免費(fèi)的，并為你提供一個(gè)非常好的，高級(jí)的，有組織的崩潰視圖。你仍然需要自行排序和確定優(yōu)先級(jí)。它有一些問(wèn)題，很難搜索和查詢。我看到人們聯(lián)合使用 Bugsnag，這樣查詢和搜索會(huì)更好一點(diǎn)。 Bugsnag 是相當(dāng)不錯(cuò)的，但它不是免費(fèi)的。

Instabug 和 Telescope。Telescope 是個(gè)庫(kù)。你把它放到 bug 里，作為第三方服務(wù)。這些庫(kù)的優(yōu)點(diǎn)不是監(jiān)控 crash，而是讓你在問(wèn)題出現(xiàn)時(shí)，搖晃手機(jī)來(lái)報(bào)告問(wèn)題。這樣，當(dāng)你的團(tuán)隊(duì)中的設(shè)計(jì)師看到錯(cuò)誤時(shí)，他們不用在 JIRA 里提交 Bug，或者和別人說(shuō)明所有的步驟然后讓別人來(lái)報(bào) bug，但是你仍然希望這些不是 crash 的 bug 也能被修復(fù)。有這么一個(gè)工具，所有的測(cè)試用戶，alpha 用戶，你公司的人，看到錯(cuò)誤都能告訴你，這些問(wèn)題需要修復(fù)。

推送通知

作為開發(fā)人員，第一反應(yīng)是使用 GCM 或現(xiàn)在的 Firebase Cloud Messaging，這些庫(kù)正在重組。但是這些工具對(duì)營(yíng)銷人員不友好。最簡(jiǎn)單的情況是，如果你已經(jīng)有了很好的分析服務(wù)，F(xiàn)irebase 和 Mixpanel（以及其他許多庫(kù)）都可以用來(lái)發(fā)送通知。你可以根據(jù)你的 activity 發(fā)送消息?？梢赃@樣設(shè)計(jì)，一個(gè)從來(lái)沒有發(fā)生過(guò)購(gòu)買的人，做了三次搜索，這時(shí)你可以給他們發(fā)送一個(gè)通知，建議他們買些東西。這是最簡(jiǎn)單的情況。

有時(shí)你會(huì)想要一些更深入的東西。Urban Airship 的推送通知特別專業(yè)，這是他們的主要方向。他們發(fā)現(xiàn)，“人們只會(huì)看到通知的前 60 個(gè)字符”，我們都會(huì)收到這樣的通知，你只能看到前面幾個(gè)字。就像，“你不會(huì)相信這個(gè)…”，它被截?cái)嗔?。然后你點(diǎn)擊它，你被帶到一個(gè)隨機(jī)的屏幕里，你甚至不知道推送通知的內(nèi)容是什么。Urban Airship 很好，他們幫助你思考這樣的事情，給你更多的細(xì)微差別提示，思考如何能更好地推出通知服務(wù)。

Kahuna 很受歡迎，有很多人都在使用它，但我會(huì)強(qiáng)烈反對(duì)。他們的想法很棒。通過(guò)借助 AI 來(lái)幫你確定哪種推送方式更合適，是發(fā)送電子郵件，還是發(fā)送短信或者是推送通知。AI 計(jì)算出最好的推送時(shí)間，并建議通知上需不需要添加花朵。這部分他們還沒有實(shí)現(xiàn)。但他們現(xiàn)在會(huì)做些文字上的變化。他們?cè)噲D讓通知受人喜愛，盡可能地推送最合適的通知，想法很酷，希望它能很快實(shí)現(xiàn)。但是現(xiàn)在，現(xiàn)實(shí)實(shí)現(xiàn)中，他們遇到了很多問(wèn)題，用戶的通知被發(fā)送給錯(cuò)誤的用戶。用戶被合并在一起，視為一組。所以使用時(shí)請(qǐng)小心。有些人用的很好。但我被坑了。

更輕松

有很多偉大的工具能使你的開發(fā)更容易些。

一個(gè)工具是 Butter Knife（@indVView）。它使你的代碼更漂亮。你可以使用 @BindView 通過(guò) ID 查找視圖，而不必遍歷所有的視圖。Zelezny，是一個(gè)Android Studio 插件。把它放進(jìn) Layout 中，它會(huì)自動(dòng)生成 BindViews 和 OnClicks。如果你以前一直是手敲代碼，它會(huì)節(jié)省點(diǎn)時(shí)間。最大的限制是 annotation 的處理會(huì)破壞增量編譯。如果你有 Butter Knife，那么你可能會(huì)比沒有 Butter Knife 時(shí)的增量編譯慢些。對(duì)我個(gè)人而言，我喜歡所有的 annotation 處理工具，船已航行。我已經(jīng)接受了 annotation 處理器打破我的增量編譯的現(xiàn)實(shí)。我聽說(shuō)有人建議將它們?nèi)糠旁谕粋€(gè)模塊中可以解決這個(gè)問(wèn)題。這是唯一的缺點(diǎn)，許多 annotation 處理都會(huì)有這個(gè)問(wèn)題。也許有一天這個(gè)問(wèn)題會(huì)被修復(fù)。 JRebel 聲稱一些特定版本的增量編譯已經(jīng)修復(fù)了。除此之外，Butter Knife 是最好的選擇。

Hugo 是個(gè) Jake Wharton 的庫(kù)（* 當(dāng)我說(shuō) Jake Wharton，一半的時(shí)候是指 Square，它們是同一個(gè)意思*）。它是一個(gè)輕量級(jí)的庫(kù)，你可以在方法之上執(zhí)行 @Debug.Log，然后打印出該方法花費(fèi)的時(shí)間，以及參數(shù)。它特別適用于現(xiàn)場(chǎng)性能記錄。 “我需要緩存這個(gè)變量嗎？它被調(diào)用太多了以至于變慢了嗎？”你可以看到，“不，這只花了 10 毫秒，我應(yīng)該把它放在一個(gè)后臺(tái)線程上，或者花了不到一毫秒，我們不用擔(dān)心這個(gè)”。它很容易納入你的代碼，并迅速獲得相關(guān)數(shù)字。

Dart ＆ Henson，你有 intents ;不需要使用鍵值映射，它給你應(yīng)該有的值。它做了點(diǎn) annotation 的映射來(lái)展示 intents 的值是什么。我更喜歡的另外一種理解方法是你正在調(diào)用的 activity 的靜態(tài) intents 。這樣，你可以傳入你想要的參數(shù)，這樣就解決了神秘的鍵值對(duì)的問(wèn)題。它使得代碼更加緊密，這樣可以防止錯(cuò)誤。

如果你喜歡 lambdas，你應(yīng)該使用 Retrolambda。需要注意是它產(chǎn)生四種方法，而不是正常的匿名類。我認(rèn)為使用 Retrolambda 會(huì)使得代碼不易讀，這是你必須做出明智決定的地方。

更困難（初期）

我們來(lái)談一談哪些庫(kù)會(huì)讓開發(fā)變得更加困難，或者說(shuō)開始的時(shí)候更困難。但總的來(lái)說(shuō)，這些都是好工具。

RxJava

RxJava，對(duì)于那些沒有聽說(shuō)過(guò)的人來(lái)說(shuō)，這個(gè)庫(kù)的想法是，過(guò)去的代碼從 A 點(diǎn)開始，到 B 點(diǎn)結(jié)束。但在 Android 世界中，移動(dòng)開發(fā)世界中，這一切就都不一樣了。 *你從 A 點(diǎn)開始。然后人們點(diǎn)擊某些東西，所以你必須做些別的事情來(lái)響應(yīng)。然后一個(gè)通知進(jìn)來(lái)，你必須又做些事情。然后數(shù)據(jù)庫(kù)請(qǐng)求出現(xiàn)了。Reactive 努力使你的代碼能夠?qū)δ愕膽?yīng)用程序中的發(fā)生的事情做出反應(yīng)，幫助你更好的組織它們，而且方便移動(dòng)。

起初很難，因?yàn)樗幸粋€(gè)學(xué)習(xí)曲線。如果你正在看代碼，特別是對(duì)于沒有接觸過(guò) RxJava 的人來(lái)說(shuō)，會(huì)有許多不清楚的地方。最簡(jiǎn)單的就是網(wǎng)絡(luò)。但是，如果你有幾個(gè)標(biāo)準(zhǔn)的例子，你使用這些案例，并確保是最佳的做法，情況就會(huì)不一樣了。當(dāng)你開始擁有這些功能時(shí)，它們非常強(qiáng)大，你可以將其運(yùn)用于應(yīng)用程序中的任何地方，但是當(dāng)你這樣做的時(shí)候，每當(dāng)雇用新的開發(fā)人員，你將不得不教會(huì)他們每個(gè) activity 是怎么工作的，這需要很小心。

此外，它很容易用錯(cuò)。即使是關(guān)于 RxJava 的許多會(huì)議都會(huì)漏掉一些最佳做法。例如，如果你不取消訂閱網(wǎng)絡(luò)呼叫，那么你會(huì)被回調(diào)，這時(shí)可能會(huì)發(fā)生崩潰，因?yàn)槠聊灰呀?jīng)不存在了。謹(jǐn)慎地使用它，總體上來(lái)說(shuō)它還是很好的。

Kotlin

當(dāng)我說(shuō)小心使用非內(nèi)建語(yǔ)言或者說(shuō)新語(yǔ)言不尋常的地方時(shí)，我想說(shuō)的就是那些你能看到的不尋常的地方。 Kotlin 生成了更整潔的代碼。這有好處。使你的代碼更容易閱讀，也會(huì)使沒有意義的東西少一些，這是你需要的核心東西。它也隱藏了指針的概念。

最大的缺點(diǎn)是它會(huì)隨機(jī)地破壞事情，如果有什么事情發(fā)生，你都會(huì)懷疑 Kotlin。這可能是 Kotlin 的錯(cuò)，可能不是，但是都會(huì)花掉開發(fā)人員的許多時(shí)間，來(lái)弄清楚到底是不是 Kotlin 的錯(cuò)。你需要更新 Gradle 的構(gòu)建，然而這依舊不奏效。這可能是 Kotlin 的錯(cuò)，也可能不是 Kotlin 的錯(cuò)，但是你都不得不重新檢查 Kotlin。

同樣的情況是，你的 Android Studio 也會(huì)隨機(jī)崩潰，或者 ProGuard 不工作了，因?yàn)樗サ袅艘恍?Kotlin 的類。這些事情經(jīng)常發(fā)生，很難扭轉(zhuǎn)。Kotlin 有很多權(quán)衡點(diǎn)。我們?cè)诖a中使用它。確實(shí)有一些問(wèn)題，與此同時(shí)，了解 Kotlin 的人們的代碼審查更快。對(duì)于不知道 Kotlin 的人來(lái)說(shuō)，有一個(gè)學(xué)習(xí)的曲線。這是一個(gè)權(quán)衡。你必須自己決定。

相機(jī)

如果你曾經(jīng)在 Android 中使用過(guò) Camera，而且你采用的是原生的方案，這并不瘋狂，你會(huì)發(fā)現(xiàn)有攝像頭 one API 和攝像頭 two API，而且攝像頭 two API 沒有比攝像頭 one API 更好，如果你同時(shí)支持新舊設(shè)備，你必須使用攝像頭 one API，除非你只打算在非常新的設(shè)備上正常運(yùn)行。我的第一個(gè)建議是，如果你有使用相機(jī)的場(chǎng)景，構(gòu)建一個(gè) intent。讓其他人的相機(jī)應(yīng)用來(lái)解決你的問(wèn)題，如果這不是你的核心場(chǎng)景的話。

如果不是這種情況，有一個(gè)名為 Material Camera 的庫(kù)，我以前 fork 過(guò)。你可以添加自己的外觀。它幫助你創(chuàng)建相機(jī)。解決問(wèn)題。但是當(dāng)你按照本教程進(jìn)行首次設(shè)置后，橫向顯示時(shí)，圖片會(huì)顛倒，你不得不在每個(gè)手機(jī)上都進(jìn)行測(cè)試，因?yàn)樗麄儠?huì)以不同的方式安裝相機(jī)。還有很多邊界案例要考慮。Material Camera 是偉大的，它已經(jīng)把這些情況都解決了。它也支持視頻。這是視頻模式。你可以改變它上面的 UI，效果很好。再說(shuō)一次，如果 Camera 是你非常核心的用例，那么你應(yīng)該重新構(gòu)建它，這只是個(gè)折衷的方案。

我使用的每個(gè)相機(jī)應(yīng)用都有裁剪功能，這個(gè)功能很可怕。我不知道是什么原因。你試圖剪裁，突然間你的視頻被剪掉了中間部分。有一個(gè)很好的庫(kù)叫做 “Android Crop”。它提供了一個(gè)非常簡(jiǎn)單的新的 activity 來(lái)完成剪裁。

全球思考

作為 Android 的開發(fā)人員，我們需要考慮到世界各地的所有開發(fā)者。如果你正在為世界各地的開發(fā)人員做些開發(fā)工作，有些事情你必須考慮，比如網(wǎng)絡(luò)仿真：你希望能夠在低質(zhì)量網(wǎng)絡(luò)上進(jìn)行測(cè)試。Android 上做到這點(diǎn)比 iOS 難。仿真器技術(shù)可以提供本地仿真器 AVD，但通常情況下，我的經(jīng)驗(yàn)是，如果你在模擬器上進(jìn)行任何 3G 操作，沒有應(yīng)用工作正常。我的一些應(yīng)用程序有時(shí)候能在 3G 上正常工作。

我知道的最成功的工具是 Charles 代理。你可以配置經(jīng)過(guò)某個(gè)代理。這很容易設(shè)置。你可以告訴代理，下載速度應(yīng)該是多快。但仍然有一個(gè)挑戰(zhàn)，你需要知道網(wǎng)絡(luò)可能有多快。比如說(shuō)像巴西的 3G 網(wǎng)絡(luò)，幾乎是一個(gè)無(wú)意義的聲明 - 3G 在巴西各處都不一樣，在各地都是非常不同的。某些時(shí)候，你必須嘗試找一些數(shù)字，選擇一些數(shù)字。

外面有些資源，但是選擇參數(shù)是挑選網(wǎng)絡(luò)仿真最困難的部分之一。有一個(gè)名為 Augmented Traffic Control 工具，它來(lái)自 Facebook。它允許你連接到服務(wù)器或設(shè)置路由器，你可以設(shè)置配置文件 - 當(dāng)你連接到路由器時(shí)，你的互聯(lián)網(wǎng)應(yīng)該有多快。如果你有非開發(fā)人員為你測(cè)試，他們?nèi)匀豢梢赃B接到這個(gè) WiFi 網(wǎng)絡(luò)并設(shè)置他們擁有的連接級(jí)別。產(chǎn)品經(jīng)理和測(cè)試人員一般也應(yīng)該考慮質(zhì)量較差的網(wǎng)絡(luò)。 ATC 服務(wù)器很好用。

我相信新的 Android O 暗示他們會(huì)有類似于 AutoFitTextView 的東西，但現(xiàn)在這只是一個(gè)庫(kù)，只要文本對(duì)于文本框來(lái)說(shuō)太大，文本就會(huì)縮小。如果你正在翻譯德語(yǔ)，它的很多字母比英文還是要大一些，那么它會(huì)把它縮小到框中。這不是你的第一個(gè)翻譯解決方案，但最好讓它們縮小到文本框的大小，而不是填滿整個(gè)屏幕并覆蓋所有內(nèi)容。它將調(diào)整你的文本大小（更改你的文本大小來(lái)適應(yīng)），這是一個(gè)很好的安全的翻譯。

YearClass 是 Facebook 的另一個(gè)庫(kù)。它會(huì)告訴你，運(yùn)行你產(chǎn)品的最新的手機(jī)生產(chǎn)年份是多少。如果我們說(shuō) 2015 年是最高的年份，那你就不用關(guān)心 2016 年制作的手機(jī)上的一些特別的事情。從分析角度來(lái)說(shuō)，這是最好的 - 比如這個(gè)崩潰是，發(fā)生在 Android OS Marshmallow 上，所有的手機(jī)都是低功耗的手機(jī)，有時(shí)候會(huì)發(fā)生這種情況。知道一下 crash 在不同年份的手機(jī)上的發(fā)生概率可以幫你對(duì)這個(gè) crash 有更深的了解。

Connection 類是理解用戶連接質(zhì)量的一個(gè)非常好的工具（* 這是我在開始時(shí)推薦的封裝樣本類）。它對(duì)網(wǎng)絡(luò)進(jìn)行分類。不是分成 4G 3G，因?yàn)樗鼈冏兓艽?，它依?jù)的是帶寬，分為優(yōu)秀，好，中度或差，或未知。它通過(guò)采樣下載速度來(lái)分類。然后它會(huì)移動(dòng)平均值。這樣做的價(jià)值是，例如，你是一個(gè)顯示許多圖像的圖像網(wǎng)站，你可能希望在較差的網(wǎng)絡(luò)上降低圖像質(zhì)量，或著執(zhí)行其他操作。預(yù)先知道帶寬可以做許多事情。

最大的警告是它的抽樣可能是不合時(shí)宜的。你能做的事情是讓它們開始采樣和停止采樣。比如，當(dāng)我打開應(yīng)用程序時(shí)，開始采樣，當(dāng)我關(guān)閉應(yīng)用程序時(shí)停止。它們做的事情是查看你下載的數(shù)據(jù)量，每秒刷新一次。如果用戶將你的應(yīng)用程序打開，并且沒有進(jìn)行任何操作，他們會(huì)認(rèn)為你的網(wǎng)絡(luò)慢的可怕。我們所做的是，你可以在網(wǎng)絡(luò)調(diào)用或者圖像調(diào)用的中間啟動(dòng)它，這樣做的效果很好。除此之外，這個(gè)庫(kù)對(duì)你的網(wǎng)絡(luò)帶寬了解的很準(zhǔn)確。

About the content

This content has been published here with the express permission of the author.