文檔教程移動(dòng)開(kāi)發(fā)【免費(fèi)下載鏈接】android-best-practicesDos and Donts for Android development, by Futurice developers項(xiàng)目地址https://gitcode.com/gh_mirrors/an/android-best-practices點(diǎn)擊查看免費(fèi)下載本指南以 Futurice 團(tuán)隊(duì)多年 Android 實(shí)戰(zhàn)沉淀的《android-best-practices》為骨架對(duì)應(yīng)倉(cāng)庫(kù)根目錄 README.md 及其多語(yǔ)言譯本如 西語(yǔ)版系統(tǒng)梳理從構(gòu)建系統(tǒng)、依賴管理、代碼與資源組織到測(cè)試、調(diào)試、內(nèi)存泄漏檢測(cè)與發(fā)布加固的完整最佳實(shí)踐鏈路。讀完本文你將掌握一套可直接落地的 Android 工程規(guī)范如何用 Gradle 安全管理簽名密鑰、如何用規(guī)范的 XML 資源組織避免布局與樣式的失控、如何規(guī)避 65k 方法數(shù)限制、如何正確配置 ProGuard 并排查混淆引發(fā)的崩潰以及如何用 Stetho 與 LeakCanary 提升調(diào)試與內(nèi)存治理效率。一、總覽這些建議從何而來(lái)這些實(shí)踐并非紙上談兵而是來(lái)自 Futurice 公司一線 Android 開(kāi)發(fā)者的真實(shí)經(jīng)驗(yàn)教訓(xùn)其目的在于避免重復(fù)發(fā)明輪子Avoid reinventing the wheel。文檔同時(shí)面向開(kāi)發(fā)流程的各個(gè)環(huán)節(jié)其核心主張可以歸納為構(gòu)建默認(rèn)使用 Gradle 及其推薦的項(xiàng)目結(jié)構(gòu)構(gòu)建過(guò)程由 Gradle 文件定義而非 IDE 配置。安全密碼與敏感數(shù)據(jù)一律放入不納入版本控制的gradle.properties。依賴優(yōu)先使用成熟庫(kù)Jackson/OkHttp/Retrofit/Picasso/Glide不自己造 HTTP 客戶端輪子同時(shí)警惕 65k 方法數(shù)限制謹(jǐn)慎控制庫(kù)的數(shù)量。代碼組織精心規(guī)劃 Activities 與 Fragments 的職責(zé)邊界、Java 包結(jié)構(gòu)與資源文件layouts、styles、colors、dimens、strings。質(zhì)量用合適的測(cè)試框架、模擬器、ProGuard、Stetho、LeakCanary 保證發(fā)布質(zhì)量與可維護(hù)性。倉(cāng)庫(kù)以單一 Markdown 文檔承載全部?jī)?nèi)容README.md并提供了包含 中文、法語(yǔ)、日語(yǔ)、韓語(yǔ)、葡萄牙語(yǔ)、俄語(yǔ)、西語(yǔ)、土耳其語(yǔ)、越南語(yǔ) 在內(nèi)的多語(yǔ)言版本且全文基于 Creative Commons Attribution 4.0 International (CC BY 4.0) 協(xié)議開(kāi)放見(jiàn) LICENSE方便團(tuán)隊(duì)將其內(nèi)化為自己的工程規(guī)范。二、開(kāi)發(fā)環(huán)境Android SDK 的安放位置核心建議把 Android SDK 放在home目錄或其他與應(yīng)用程序無(wú)關(guān)的獨(dú)立位置。有些 IDE 發(fā)行版在安裝時(shí)會(huì)順帶把 SDK 放到 IDE 自身目錄之下這會(huì)在你升級(jí)或重裝 IDE 時(shí)帶來(lái)隱患——很可能連 SDK 一起被覆蓋或刪除迫使你重新經(jīng)歷漫長(zhǎng)而繁瑣的下載過(guò)程。同時(shí)要避免把 SDK 放到需要sudo權(quán)限的系統(tǒng)級(jí)目錄如果你的 IDE 以普通用戶身份運(yùn)行而非 root后續(xù) SDK 組件的安裝與更新會(huì)頻繁遭遇權(quán)限問(wèn)題。三、構(gòu)建系統(tǒng)Gradle 與推薦的項(xiàng)目結(jié)構(gòu)3.1 為什么默認(rèn)選擇 Gradle文檔明確建議將 Gradle 作為默認(rèn)構(gòu)建系統(tǒng)理由是它讓以下工作變得簡(jiǎn)單創(chuàng)建應(yīng)用的不同flavor變體用腳本完成簡(jiǎn)單任務(wù)管理與下載依賴自定義 keystore以及更多……Ant 作為舊構(gòu)建系統(tǒng)已于 2015 年廢棄Android 的 Gradle 插件改由 Google 親自開(kāi)發(fā)與維護(hù)。關(guān)鍵原則應(yīng)用的構(gòu)建過(guò)程必須由 Gradle 文件定義而不是依賴 IDE 特定的配置。這樣才能保證在不同工具鏈之間構(gòu)建結(jié)果一致并為持續(xù)集成CI系統(tǒng)提供良好支持。3.2 采用 Gradle 的默認(rèn)項(xiàng)目結(jié)構(gòu)盡管 Gradle 在項(xiàng)目結(jié)構(gòu)上提供了很大靈活性除非你有令人信服的理由否則應(yīng)當(dāng)采用它的默認(rèn)結(jié)構(gòu)基于 source set 的main、androidTest等目錄劃分這會(huì)大幅簡(jiǎn)化構(gòu)建腳本。倉(cāng)庫(kù)中 中文譯本 對(duì)這種新舊結(jié)構(gòu)的差異做了更直觀的對(duì)照舊式 Ant Eclipse ADT 結(jié)構(gòu)把a(bǔ)ssets、libs、res、src、AndroidManifest.xml平鋪在根目錄而新式 Gradle 結(jié)構(gòu)則引入頂層app模塊內(nèi)部再分src/main、src/androidTest并將第三方庫(kù)項(xiàng)目如library-foobar獨(dú)立為同級(jí)模塊通過(guò)根目錄的settings.gradle引用。3.3 Gradle 配置細(xì)節(jié)通用結(jié)構(gòu)遵循 Google 官方的 Gradle for Android 指南。小任務(wù)與其寫(xiě) shell、Python、Perl 等外部腳本不如直接在 Gradle 中定義任務(wù)Task遵循 Gradle 官方文檔即可。密碼與敏感數(shù)據(jù)重點(diǎn)在應(yīng)用模塊的build.gradle中為release構(gòu)建定義signingConfigs時(shí)切勿把密碼硬編碼進(jìn)構(gòu)建文件signingConfigs { release { storeFile file(myapp.keystore) storePassword password123 keyAlias thekey keyPassword password789 } }這樣做會(huì)把密鑰信息泄露進(jìn)版本控制系統(tǒng)。正確做法是創(chuàng)建一個(gè)不加入版本控制的gradle.properties文件KEYSTORE_PASSWORDpassword123 KEY_PASSWORDpassword789該文件會(huì)被 Gradle 自動(dòng)導(dǎo)入因此在build.gradle中可以直接引用并配合try/catch在缺失時(shí)給出清晰提示signingConfigs { release { try { storeFile file(myapp.keystore) storePassword KEYSTORE_PASSWORD keyAlias thekey keyPassword KEY_PASSWORD } catch (ex) { throw new InvalidUserDataException(Deberías definir tu KEYSTORE_PASSWORD y KEY_PASSWORD en gradle.properties.) } } }提示gradle.properties位于項(xiàng)目根目錄時(shí)對(duì)模塊級(jí)build.gradle全局可見(jiàn)務(wù)必把該文件加入.gitignore并可為團(tuán)隊(duì)成員提供一份不含真實(shí)密碼的模板。優(yōu)先使用 Maven 依賴解析而非導(dǎo)入 jar 文件顯式將 jar 放進(jìn)項(xiàng)目意味著版本被凍結(jié)在特定版本上下載與管理更新非常繁瑣而 Maven 依賴解析恰好解決了這個(gè)問(wèn)題這也是 Gradle 推薦的做法。例如dependencies { implementation com.squareup.okhttp:okhttp:2.2.0 implementation com.squareup.okhttp:okhttp-urlconnection:2.2.0 }避免動(dòng)態(tài)依賴版本不要使用2.1.這類動(dòng)態(tài)解析它會(huì)導(dǎo)致構(gòu)建不穩(wěn)定、不同構(gòu)建之間出現(xiàn)難以追蹤的行為差異使用2.1.1這樣的靜態(tài)版本有助于打造更穩(wěn)定、可預(yù)測(cè)、可復(fù)現(xiàn)的開(kāi)發(fā)環(huán)境。為非 release 構(gòu)建使用不同的包名借助applicationIdSuffix讓debug與release兩個(gè) APK 可以同時(shí)安裝在同一臺(tái)設(shè)備上自定義構(gòu)建類型若有需要也可照做這在應(yīng)用上架后尤其有價(jià)值android { buildTypes { debug { applicationIdSuffix .debug versionNameSuffix -DEBUG } release { // ... } } }配套實(shí)踐用不同圖標(biāo)區(qū)分設(shè)備上的構(gòu)建版本例如不同顏色或疊加 debug 字樣。借助默認(rèn)項(xiàng)目結(jié)構(gòu)只需把 debug 圖標(biāo)放進(jìn)app/src/debug/res、release 圖標(biāo)放進(jìn)app/src/release/resGradle 會(huì)自動(dòng)按構(gòu)建類型選擇資源。此外還可以按構(gòu)建類型修改應(yīng)用名與versionName。3.4 IDE 與文本編輯器原則編輯器是個(gè)人選擇但必須讓它適配項(xiàng)目結(jié)構(gòu)與構(gòu)建系統(tǒng)。推薦 Android Studio由 Google 開(kāi)發(fā)并高頻更新對(duì) Gradle 支持良好內(nèi)置大量實(shí)用的監(jiān)測(cè)與分析工具專為 Android 開(kāi)發(fā)定制。也可以使用 Vim、Sublime Text、Emacs 等純文本編輯器但此時(shí)必須自己用命令行 Gradle 與adb完成構(gòu)建與調(diào)試。Eclipse ADT 已不再是好的選擇Google 于 2015 年停止對(duì) ADT 的支持并建議用戶盡快遷移到 Android Studio。無(wú)論選擇哪種工具都不要把編輯器專屬配置文件如 Android Studio 的.iml文件提交到版本控制——它們通常包含你本機(jī)特有的配置無(wú)法在同事的機(jī)器上正常工作。最后請(qǐng)善待團(tuán)隊(duì)其他開(kāi)發(fā)者不要強(qiáng)迫他們更換自己更順手的工具。四、依賴選型庫(kù)的取舍與 65k 方法數(shù)限制4.1 JSON 解析Jackson 為主Gson 為備Jackson 是 Java 領(lǐng)域的 JSON 序列化/反序列化庫(kù)支持三種 JSON 處理方式流式streaming、內(nèi)存樹(shù)模型in-memory tree model與傳統(tǒng)的JSON-POJO 數(shù)據(jù)綁定API 覆蓋面廣且靈活。Gson 同樣是熱門(mén)選擇但它比 Jackson 更小——在需要規(guī)避 65k 方法數(shù)限制的場(chǎng)景下可以考慮以 Gson 替代。其他備選還有 Json-smart 與 Boon JSON。4.2 網(wǎng)絡(luò)、緩存與圖片不要自己寫(xiě) HTTP 客戶端請(qǐng)求后端服務(wù)器有幾套久經(jīng)實(shí)戰(zhàn)考驗(yàn)的方案應(yīng)直接采用而非自行實(shí)現(xiàn)客戶端Volley 或 Retrofit發(fā)起網(wǎng)絡(luò)請(qǐng)求。Volley 還附帶圖片加載與緩存能力。若選 Retrofit建議配 Picasso 做圖片加載與緩存、OkHttp 做更高效的 HTTP 請(qǐng)求。Retrofit、Picasso、OkHttp 出自同一家公司Square彼此配合良好、兼容性問(wèn)題少見(jiàn)OkHttp 也可以與 Volley 配合使用。Glide 是另一款圖片加載/緩存方案支持 GIF 動(dòng)圖與圓形圖片宣稱性能優(yōu)于 Picasso但方法數(shù)也更多。4.3 RxJava強(qiáng)大的異步范式謹(jǐn)慎落地RxJava 是響應(yīng)式編程庫(kù)用于處理異步事件。它是一個(gè)強(qiáng)大且前景廣闊的范式但也與傳統(tǒng)思維方式差異巨大、容易讓人困惑文檔明確建議在使用它架構(gòu)整個(gè)應(yīng)用之前保持謹(jǐn)慎。漸進(jìn)式采用路徑如果對(duì) Rx 沒(méi)有經(jīng)驗(yàn)先只把它用于后端 API 響應(yīng)的處理隨后再逐步應(yīng)用到 UI 事件處理如點(diǎn)擊事件、搜索框輸入事件若確信自己的 Rx 水平并想將其用于整個(gè)架構(gòu)務(wù)必為所有棘手部分編寫(xiě) Javadocs——其他不熟悉 RxJava 的開(kāi)發(fā)者可能很難維護(hù)這樣的項(xiàng)目請(qǐng)盡力幫助他們理解你的代碼與 Rx。補(bǔ)充倉(cāng)庫(kù)英文版 README.md 還提到用 RxAndroid 提供 Android 線程支持、用 RxBinding 從既有 Android 組件輕松創(chuàng)建 Observable并指出從 Android Studio 3.0 起 Java 8 lambda 支持已內(nèi)建、不再需要 Retrolambda。4.4 Retrolambda在舊平臺(tái)使用 Lambda 語(yǔ)法Retrolambda 允許在 Android 及其他 JDK8 之前的平臺(tái)上使用 Lambda 表達(dá)式語(yǔ)法能讓代碼更緊湊易讀尤其適合函數(shù)式風(fēng)格如與 RxJava 搭配。Android Studio 對(duì) Java 8 lambda 提供代碼輔助新手可以這樣入手任何只有一個(gè)方法的接口都是lambda 友好的可以折疊成更緊湊的語(yǔ)法對(duì)參數(shù)等細(xì)節(jié)拿不準(zhǔn)時(shí)先寫(xiě)普通匿名內(nèi)部類再讓 Android Studio 幫你折疊成 lambda。4.5 警惕 dex 方法數(shù)限制慎用庫(kù)Android 應(yīng)用打包為 dex 文件后存在65536 個(gè)引用方法的硬性上限一旦超過(guò)就會(huì)編譯失敗。因此盡量使用最少數(shù)量的庫(kù)用 dex-method-counts 工具統(tǒng)計(jì)各庫(kù)的方法數(shù)確定哪些庫(kù)組合能讓你保持在上限之下尤其避免使用 Guava它包含約 13k 個(gè)方法是方法數(shù)大戶。說(shuō)明英文版補(bǔ)充提到從 API 21 起 multidex 支持庫(kù)不再是必需README.md 的 Gradle 配置一節(jié)但 65k 單 dex 限制的告誡依舊適用于老設(shè)備與舊 API 場(chǎng)景。五、Activities 與 Fragments謹(jǐn)慎駛過(guò)架構(gòu)選擇的暗礁社區(qū)與 Futurice 內(nèi)部對(duì)如何用 Fragments/Activities 組織架構(gòu)并無(wú)統(tǒng)一共識(shí)。Square 甚至推出過(guò)主要基于 View 構(gòu)建架構(gòu)的 mortar 庫(kù)來(lái)繞開(kāi) Fragments但這并未被社區(qū)廣泛認(rèn)可為推薦實(shí)踐。受 Android API 歷史影響可以粗略地把Fragments 視為屏幕上的 UI 片段通常與界面相關(guān)把Activities 視為控制器尤其對(duì)生命周期與狀態(tài)管理重要。不過(guò)實(shí)際中角色常有交叉Activities 可能承擔(dān) UI 職責(zé)如屏幕間轉(zhuǎn)場(chǎng)Fragments 也可能只作為控制器使用。文檔的建議是小心駛得萬(wàn)年船在充分了解信息的前提下做決策因?yàn)榧?Fragments、純 Activities 或純 Views 的架構(gòu)各有弊端。需要警惕的要點(diǎn)盡量避免嵌套 Fragments嵌套容易引發(fā)套娃式matryoshkabug僅在有明確理由時(shí)使用例如橫向滑動(dòng)的 ViewPager 內(nèi)的 Fragment位于類似屏幕的 Fragment 內(nèi)部或確屬深思熟慮的決策。避免在 Activities 中堆砌過(guò)多代碼盡量讓 Activity 保持輕量容器角色主要用于生命周期與 Android 系統(tǒng) API 交互。優(yōu)先使用單 Fragment 的 Activity而非裸 Activity——把 UI 代碼放進(jìn) Activity 對(duì)應(yīng)的 Fragment這樣將來(lái)要改為標(biāo)簽頁(yè)布局或多 Fragment 平板界面時(shí)可以直接復(fù)用除非有充分的決策理由避免出現(xiàn)沒(méi)有對(duì)應(yīng) Fragment 的 Activity。不要濫用 Android API level如果應(yīng)用內(nèi)部大量依賴 Intent 進(jìn)行通信可能影響 Android 系統(tǒng)或其他應(yīng)用造成錯(cuò)誤或延遲。例如已知的問(wèn)題是若應(yīng)用包間用 Intent 做內(nèi)部通信恰在系統(tǒng)剛啟動(dòng)后打開(kāi)應(yīng)用時(shí)可能帶來(lái)數(shù)秒的用戶體驗(yàn)延遲。六、Java 包結(jié)構(gòu)面向功能的組織方式文檔給出的思路是把 Android 的 Java 架構(gòu)放到 MVC 框架下審視Fragments/Activities 既算控制器、又因顯式參與 UI 而算視圖因此難以嚴(yán)格歸類。建議的做法是Fragments 放進(jìn)獨(dú)立的fragments包Activities 數(shù)量不超過(guò) 23 個(gè)時(shí)留在頂層包更多時(shí)則建activities包。models包存放供 JSON 解析器與 API 響應(yīng)使用的 POJO。views包存放所有 Views、通知、Action Bar Views、widgets 等adapters作為數(shù)據(jù)與視圖的中介結(jié)構(gòu)通常需要通過(guò)getView()導(dǎo)出 View因此可放在views之下。managers包全局性的、貼近 Android 系統(tǒng)的控制器類。utils包數(shù)據(jù)處理類如 DateUtils。network包負(fù)責(zé)與后端交互的類。整體上按從離后端最近到離用戶最近排列com.futurice.project ├─ network ├─ models ├─ managers ├─ utils ├─ fragments └─ views ├─ adapters ├─ actionbar ├─ widgets └─ notifications說(shuō)明這是該文檔西語(yǔ)版所呈現(xiàn)的按層分包方案?jìng)}庫(kù)英文版 README.md 已演進(jìn)為更推薦的面向功能feature based分包并列舉了依賴邊界清晰、利于封裝、便于按功能移除代碼、易于過(guò)渡到模塊化構(gòu)建等收益。團(tuán)隊(duì)可根據(jù)項(xiàng)目階段選擇適合的方案。七、資源組織布局、樣式、顏色、尺寸與字符串7.1 資源命名規(guī)范遵循type_foo_bar.xml的命名模式類型前綴 功能 具體對(duì)象例如fragment_contact_details.xmlview_primary_button.xmlactivity_main.xml7.2 布局 XML 的編排規(guī)范如果不確定布局文件如何排版可遵循以下約定每行一個(gè)屬性縮進(jìn) 4 個(gè)空格始終把a(bǔ)ndroid:id放在第一個(gè)屬性android:layout_****類屬性置于頂部style屬性放在最后自閉合標(biāo)簽/獨(dú)占一行便于排序與追加屬性不要硬編碼android:text考慮使用 Android Studio 提供的 Designtime 屬性設(shè)計(jì)期預(yù)覽專用。示例?xml version1.0 encodingutf-8? LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:toolshttp://schemas.android.com/tools android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical TextView android:idid/name android:layout_widthmatch_parent android:layout_heightwrap_content android:layout_alignParentRighttrue android:textstring/name stylestyle/FancyText / include layoutlayout/reusable_part / /LinearLayout黃金法則android:layout_****屬性定位、外邊距、尺寸等布局屬性應(yīng)留在布局 XML 中而其余android:****外觀屬性顏色、內(nèi)邊距、字體等應(yīng)放進(jìn)樣式文件。存在以下例外android:id顯然應(yīng)留在布局文件LinearLayout的android:orientation通常放在布局文件中更合理android:text定義內(nèi)容應(yīng)放在布局文件有時(shí)把通用的android:layout_width/android:layout_height抽成樣式是合理的但默認(rèn)仍應(yīng)寫(xiě)在布局文件里。7.3 使用樣式styles消除重復(fù)屬性幾乎所有項(xiàng)目都需要恰當(dāng)使用樣式因?yàn)?View 的外觀復(fù)用極為常見(jiàn)。至少應(yīng)為應(yīng)用中的大部分文本定義一個(gè)通用樣式例如style nameContentText item nameandroid:textSizedimen/font_normal/item item nameandroid:textColorcolor/basic_black/item /style并應(yīng)用到 TextViewTextView android:layout_widthwrap_content android:layout_heightwrap_content android:textstring/price stylestyle/ContentText /按鈕通常也需要同樣的處理但不要止步于此把一組重復(fù)且相關(guān)的android:****屬性遷移到公共樣式。7.4 拆分大樣式文件沒(méi)有必要只用一個(gè)styles.xml。Android SDK 原生支持任意文件名styles這個(gè)名字并無(wú)特殊魔法真正起作用的是文件內(nèi)部的styleXML 標(biāo)簽。因此你可以擁有styles.xml、styles_home.xml、styles_item_details.xml、styles_forms.xml等多個(gè)文件。與資源目錄名對(duì)構(gòu)建系統(tǒng)有意義不同res/values下的文件名可以是任意的。7.5colors.xml只做一件事定義調(diào)色板colors.xml中除了顏色名 → RGBA 值的映射外不應(yīng)再有任何別的內(nèi)容。這樣既能避免 RGBA 值被反復(fù)書(shū)寫(xiě)也讓?xiě)?yīng)用到底用了多少種顏色一目了然方便日后變更與重構(gòu)對(duì)美觀的 UI 而言收斂顏色種類本身就很重要。不要這樣定義把業(yè)務(wù)語(yǔ)義揉進(jìn)顏色名resources color namebutton_foreground#FFFFFF/color color namebutton_background#2A91BD/color color namecomment_background_inactive#5F5F5F/color color namecomment_background_active#939393/color color namecomment_foreground#FFFFFF/color color namecomment_foreground_important#FF9D2F/color ... color namecomment_shadow#323232/color這樣極易重復(fù) RGBA 值而且buttoncomment這類帶上下文的定義本應(yīng)放進(jìn)按鈕/注釋的樣式文件而不是colors.xml。應(yīng)該這樣定義純調(diào)色板resources !-- Escala de grises灰度 -- color namewhite #FFFFFF/color color namegray_light#DBDBDB/color color namegray #939393/color color namegray_dark #5F5F5F/color color nameblack #323232/color !-- Colores básicos基礎(chǔ)色 -- color namegreen#27D34D/color color nameblue#2A91BD/color color nameorange#FF9D2F/color color namered#FF432F/color /resources可以請(qǐng)應(yīng)用的設(shè)計(jì)師來(lái)定這套調(diào)色板命名不必是greenblue這類直白顏色名color_primario主色、color_secundario次色之類的語(yǔ)義名同樣很好。英文版 README.md 還進(jìn)一步示范了三層職責(zé)劃分colors.xml只定義調(diào)色板styles.xml中通過(guò)引用調(diào)色板來(lái)表達(dá)顏色用途如按鈕前景為白色activity_main.xml引用樣式給按鈕上色若需要更徹底的解耦還可以再建一個(gè)引用調(diào)色板的中間顏色資源文件color namebutton_foregroundcolor/white/color color namebutton_backgroundcolor/blue/colorstyle nameAcceptButton item nameandroid:foregroundcolor/button_foreground/item item nameandroid:backgroundcolor/button_background/item /style這種做法的收益是更強(qiáng)的顏色重構(gòu)能力與更穩(wěn)定的樣式定義代價(jià)是需要額外維護(hù)一組顏色映射。7.6dimens.xml同樣做成尺寸調(diào)色板與colors.xml同理應(yīng)對(duì)典型字號(hào)與間距定義一套調(diào)色板。一份好的 dimens 文件示例resources !-- Tama?o de letra字號(hào) -- dimen namefont_larger22sp/dimen dimen namefont_large18sp/dimen dimen namefont_normal15sp/dimen dimen namefont_small12sp/dimen !-- Espacio entre dos Views視圖間典型間距 -- dimen namespacing_huge40dp/dimen dimen namespacing_large24dp/dimen dimen namespacing_normal14dp/dimen dimen namespacing_small10dp/dimen dimen namespacing_tiny4dp/dimen !-- Tama?o de una View視圖典型尺寸 -- dimen namebutton_height_tall60dp/dimen dimen namebutton_height_normal40dp/dimen dimen namebutton_height_short32dp/dimen /resources布局中的 margin 與 padding 應(yīng)盡量使用spacing_****尺寸而非硬編碼數(shù)值——就像字符串通常的處理方式一樣。這能讓?xiě)?yīng)用獲得一致的視覺(jué)體驗(yàn)也讓樣式與布局的調(diào)整更加容易。7.7strings.xml命名與大小寫(xiě)字符串的 key 應(yīng)體現(xiàn)上下文namespace不必害怕兩個(gè)或多個(gè) key 共用同一個(gè)值語(yǔ)言是復(fù)雜的命名空間式的 key 能帶來(lái)語(yǔ)境、消解歧義。不好key 語(yǔ)義模糊string namenetwork_errorNetwork error/string string namecall_failedCall failed/string string namemap_failedMap loading failed/string好key 攜帶上下文前綴string nameerror_message_networkNetwork error/string string nameerror_message_callCall failed/string string nameerror_message_mapMap loading failed/string不要用全大寫(xiě)書(shū)寫(xiě)字符串值遵循常規(guī)文本習(xí)慣例如僅首字母大寫(xiě)。如果確實(shí)需要全大寫(xiě)展示請(qǐng)?jiān)?TextView 上使用textAllCaps屬性來(lái)實(shí)現(xiàn)不好string nameerror_message_callCALL FAILED/string好string nameerror_message_callCall failed/string八、避免過(guò)深的 ViewGroup 層級(jí)為了完成某種視圖排布你可能忍不住再套一層 LinearLayout于是出現(xiàn)類似下面這種逐層嵌套LinearLayout android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical RelativeLayout ... LinearLayout ... LinearLayout ... LinearLayout ... /LinearLayout /LinearLayout /LinearLayout /RelativeLayout /LinearLayout即便單個(gè)布局文件中沒(méi)有顯式出現(xiàn)這種結(jié)構(gòu)通過(guò) Java 代碼向其他 View 中 inflate 視圖也可能在運(yùn)行時(shí)形成同樣的深樹(shù)。深層級(jí)會(huì)帶來(lái)兩類問(wèn)題一是性能問(wèn)題——處理器需要維護(hù)一棵復(fù)雜 UI 樹(shù)二是更嚴(yán)重的隱患——視圖過(guò)多時(shí)可能觸發(fā)StackOverflowError。因此應(yīng)盡量讓視圖層級(jí)保持扁平學(xué)習(xí)使用 RelativeLayout、學(xué)會(huì)優(yōu)化布局、善用merge標(biāo)簽。英文版 README.md 在此基礎(chǔ)上進(jìn)一步推薦了 ConstraintLayout它是構(gòu)建扁平層級(jí)的有力工具。九、WebViews 的注意事項(xiàng)需要展示網(wǎng)頁(yè)例如新聞?wù)臅r(shí)避免在客戶端做 HTML 清洗處理——應(yīng)要求后端返回純凈的 HTML。WebView 還有一個(gè)典型的內(nèi)存泄漏點(diǎn)當(dāng)它持有 Activity 的引用、而不是綁定到 ApplicationContext 時(shí)就會(huì)泄漏內(nèi)存。此外簡(jiǎn)單文本或按鈕不要用 WebView優(yōu)先使用平臺(tái)自帶的 TextView 或 Button。十、測(cè)試框架、模擬器與調(diào)試工具10.1 測(cè)試框架該文檔寫(xiě)作時(shí)的觀點(diǎn)西語(yǔ)版如下Android SDK 自帶的測(cè)試工具尚顯稚嫩尤其 UI 測(cè)試方面。Android Gradle 提供了connectedAndroidTest任務(wù)借助 JUnit 的 Android 擴(kuò)展運(yùn)行單元測(cè)試這意味著需要連接真機(jī)或模擬器才能執(zhí)行測(cè)試。Robolectric 只適合做單元測(cè)試不適合測(cè)視圖它以無(wú)需連接設(shè)備換取開(kāi)發(fā)速度適合 Models 與 View Models 的單元測(cè)試但它對(duì) Android 平臺(tái)的模擬實(shí)現(xiàn)并不精確也不完整動(dòng)畫(huà)、對(duì)話框等 UI 元素難以測(cè)試且測(cè)試是在盲測(cè)狀態(tài)下進(jìn)行的。Robotium 讓 UI 測(cè)試編寫(xiě)更簡(jiǎn)單雖然不強(qiáng)制需要但它提供的視圖查找/分析輔助與屏幕控制能力很有價(jià)值。測(cè)試用例可以簡(jiǎn)潔到這種程度solo.sendKey(Solo.MENU); solo.clickOnText(More); // 找到第一處 More 并點(diǎn)擊 solo.clickOnText(Preferences); solo.clickOnText(Edit File Extensions); Assert.assertTrue(solo.searchText(rtf));版本演進(jìn)提示倉(cāng)庫(kù)英文版 README.md 的測(cè)試主張已更新為——用 JUnit 做純 JVM 上的無(wú) Android 依賴單元測(cè)試、避免 Robolectric因其平臺(tái)模擬不保證正確性建議改為 JVM 單元測(cè)試 真機(jī)集成測(cè)試的組合、用 Espresso 編寫(xiě) UI 測(cè)試、用 AssertJ-Android 簡(jiǎn)化 Android 組件Support、Google Play Services、AppCompat 等的斷言。斷言示例// 使用 AssertJ-Android 的斷言示例 assertThat(layout).isVisible() .isVertical() .hasChildCount(5);10.2 模擬器該文檔當(dāng)時(shí)的建議西語(yǔ)版是若以 Android 開(kāi)發(fā)為職業(yè)購(gòu)買 Genymotion 模擬器許可證——其幀率遠(yuǎn)高于典型 AVD 模擬器提供演示、網(wǎng)絡(luò)質(zhì)量模擬、GPS 定位等工具非常適合測(cè)試覆蓋眾多但非全部設(shè)備比購(gòu)買多臺(tái)真機(jī)劃算得多。注意事項(xiàng)Genymotion 不含全部 Google 服務(wù)如 Google Play Store、Google Maps且三星特定 API 仍需真機(jī)驗(yàn)證。版本演進(jìn)提示英文版 README.md 指出Android SDK 模擬器尤其 x86 變體性能近年已大幅改善、足以應(yīng)付日常開(kāi)發(fā)同時(shí)強(qiáng)調(diào)真機(jī)驗(yàn)證的價(jià)值并建議把測(cè)試精力聚焦于市場(chǎng)份額大、與產(chǎn)品最相關(guān)的設(shè)備。10.3 Stetho把 Chrome DevTools 變成 Android 調(diào)試臺(tái)Stetho 是 Facebook 出品的 Android 調(diào)試橋與 Chrome 桌面瀏覽器的 Developer Tools 深度集成。通過(guò)它你可以輕松檢查應(yīng)用尤其是網(wǎng)絡(luò)流量還能直接查看與編輯 SQLite 數(shù)據(jù)庫(kù)和 SharedPreferences。務(wù)必確保 Stetho只在 debug 構(gòu)建中啟用絕不能進(jìn)入 release 構(gòu)建。英文版還提到備選方案 Chuck功能更簡(jiǎn)化但日志直接顯示在設(shè)備上便于測(cè)試人員使用無(wú)需連接 Chrome。10.4 LeakCanary把內(nèi)存泄漏檢測(cè)變成日常LeakCanary 讓內(nèi)存泄漏的運(yùn)行時(shí)檢測(cè)與定位成為開(kāi)發(fā)流程的常規(guī)一環(huán)。配置與用法詳見(jiàn)其官方 wiki。關(guān)鍵提醒release 構(gòu)建中只配置 no-op 依賴即空實(shí)現(xiàn)避免把檢測(cè)邏輯帶進(jìn)生產(chǎn)包。十一、ProGuard 配置與混淆問(wèn)題排查ProGuard 常用于 Android 項(xiàng)目對(duì)打包代碼進(jìn)行縮減shrink與混淆obfuscate。是否啟用取決于項(xiàng)目配置常見(jiàn)做法是讓 Gradle 只在構(gòu)建 release APK 時(shí)啟用buildTypes { debug { minifyEnabled false } release { signingConfig signingConfigs.release minifyEnabled true proguardFiles getDefaultProguardFile(proguard-android.txt), proguard-rules.pro } }要判斷哪些代碼必須保留、哪些可以丟棄或混淆需要為代碼指定一個(gè)或多個(gè)入口點(diǎn)——通常是帶有 main 方法的類、applet、midlet、Activity 等。Android 框架自帶一份默認(rèn)配置位于SDK_HOME/tools/proguard/proguard-android.txt上述配置中項(xiàng)目自定義的規(guī)則文件my-project/app/proguard-rules.pro會(huì)被追加到默認(rèn)配置之后。11.1 經(jīng)典問(wèn)題構(gòu)建成功卻啟動(dòng)崩潰常見(jiàn)現(xiàn)象assembleRelease等構(gòu)建命令無(wú)警告地成功了但應(yīng)用啟動(dòng)即崩拋出ClassNotFoundException、NoSuchFieldException等異常。原因不外乎兩種ProGuard 判定某類、枚舉、方法、字段或注解不再需要將其移除ProGuard 對(duì)類、枚舉或字段名做了混淆重命名但代碼仍通過(guò)原名間接使用它例如 Java 反射。排查步驟檢查app/build/outputs/proguard/release/usage.txt確認(rèn)目標(biāo)對(duì)象是否被移除檢查app/build/outputs/proguard/release/mapping.txt確認(rèn)目標(biāo)對(duì)象是否被混淆。11.2 用 keep / keepnames 保護(hù)代碼防止 ProGuard 移除所需類或成員在 ProGuard 配置中加入keep-keep class com.futurice.project.MyClass { *; }防止 ProGuard 混淆類或成員使用keepnames-keepnames class com.futurice.project.MyClass { *; }更多示例可參考 ProGuard 官方手冊(cè)的 examples 章節(jié)。11.3 實(shí)戰(zhàn)紀(jì)律項(xiàng)目早期就做 release 構(gòu)建驗(yàn)證 ProGuard 規(guī)則是否正確保留了依賴。每引入新庫(kù)或更新依賴后再做一次 release 構(gòu)建并在真機(jī)上測(cè)試 APK。不要等到應(yīng)用做到 1.0 版才首次做 release 構(gòu)建——屆時(shí)可能遭遇一堆意外與極短的修復(fù)時(shí)間。保留每次發(fā)布的mapping.txt這樣當(dāng)用戶遇到 bug 并提交混淆后的堆棧軌跡時(shí)你才能據(jù)其定位與反解問(wèn)題。DexGuard若需要更硬核的優(yōu)化尤其是混淆能力可考慮 DexGuard——由開(kāi)發(fā) ProGuard 的同一團(tuán)隊(duì)出品的商業(yè)軟件它還能輕松拆分 dex 文件以解決 65k 方法數(shù)限制。十二、數(shù)據(jù)存儲(chǔ)SharedPreferences、ContentProviders 與 ORM12.1 SharedPreferences如果只需要持久化簡(jiǎn)單值、且應(yīng)用運(yùn)行在單一進(jìn)程中SharedPreferences 是很好的默認(rèn)選擇。以下場(chǎng)景它并不適用性能數(shù)據(jù)復(fù)雜或數(shù)據(jù)量很大多進(jìn)程訪問(wèn)有 widget 或遠(yuǎn)程服務(wù)運(yùn)行在各自進(jìn)程中、需要同步數(shù)據(jù)。英文版 README.md 還補(bǔ)充了第三種場(chǎng)景——關(guān)系型數(shù)據(jù)數(shù)據(jù)各部分之間存在關(guān)聯(lián)、需要強(qiáng)制維護(hù)這些關(guān)系。也可以把復(fù)雜對(duì)象序列化為 JSON 存儲(chǔ)、讀取時(shí)再反序列化但要注意這種做法的性能與可維護(hù)性權(quán)衡。12.2 ContentProviders當(dāng) SharedPreferences 不夠用時(shí)應(yīng)使用平臺(tái)標(biāo)準(zhǔn)的 ContentProviders——更快且進(jìn)程安全。它唯一的缺點(diǎn)是搭建所需樣板代碼較多、且高質(zhì)量教程稀缺。不過(guò)可以通過(guò) Schematic 之類的庫(kù)自動(dòng)生成 ContentProvider顯著降低工作量。之后仍需自己編寫(xiě)少量解析代碼來(lái)讀寫(xiě) SQLite 列與數(shù)據(jù)對(duì)象之間的映射。也可以借助 Gson 等把數(shù)據(jù)對(duì)象序列化只持久化結(jié)果字符串——代價(jià)是性能損失好處是不必為類的每個(gè)字段聲明一列。12.3 關(guān)于 ORM除非數(shù)據(jù)極端復(fù)雜且有迫切需求一般不推薦使用對(duì)象關(guān)系映射ORM庫(kù)它們往往復(fù)雜、學(xué)習(xí)成本高。如果決定使用 ORM務(wù)必確認(rèn)其是否進(jìn)程安全如果應(yīng)用有此需求的話——很多現(xiàn)有 ORM 方案在這方面出人意料地并不可靠。十三、持續(xù)集成CI英文版 README.md 進(jìn)一步補(bǔ)充了持續(xù)集成主張CI 系統(tǒng)能在每次向版本控制推送更新時(shí)自動(dòng)構(gòu)建與測(cè)試項(xiàng)目還能運(yùn)行靜態(tài)代碼分析、生成并分發(fā) APK。Lint 與 Checkstyle 保障代碼質(zhì)量FindBugs 則在代碼中尋找 bug。CI 軟件種類繁多、特性各異開(kāi)源項(xiàng)目通?？擅赓M(fèi)使用Jenkins 適合自建本地服務(wù)器Travis CI 則是云托管 CI 的推薦選擇。這與本文開(kāi)頭構(gòu)建過(guò)程由 Gradle 文件定義、而非 IDE 配置的原則一脈相承——只有可腳本化、可復(fù)現(xiàn)的構(gòu)建才能被 CI 順利接管。十四、結(jié)語(yǔ)與許可本文所依據(jù)的規(guī)范文檔源自 Futurice 的實(shí)踐沉淀倉(cāng)庫(kù)內(nèi)提供 README.md 及各語(yǔ)言譯本中文、西語(yǔ)、法語(yǔ)、日語(yǔ)、韓語(yǔ)、葡萄牙語(yǔ)、俄語(yǔ)、土耳其語(yǔ)、越南語(yǔ)全文遵循 Creative Commons Attribution 4.0 International (CC BY 4.0) 協(xié)議LICENSE可在注明出處的前提下自由使用與演繹。文中大部分代碼示例、目錄結(jié)構(gòu)與命令均可直接對(duì)照倉(cāng)庫(kù)原文復(fù)現(xiàn)建議團(tuán)隊(duì)將其裁剪為本項(xiàng)目的工程規(guī)范并納入代碼評(píng)審清單。贊分享文檔教程移動(dòng)開(kāi)發(fā)【免費(fèi)下載鏈接】android-best-practicesDos and Donts for Android development, by Futurice developers項(xiàng)目地址https://gitcode.com/gh_mirrors/an/android-best-practices點(diǎn)擊查看免費(fèi)下載相關(guān)推薦oh-my-hermes技能體檢omh-skill-health如何守護(hù)124個(gè)技能的質(zhì)量oh my hermes技能體檢omh skill health如何守護(hù)124個(gè)技能的質(zhì)量 oh my hermesohm 是 Hermes Agent文檔教程移動(dòng)開(kāi)發(fā)iOS開(kāi)發(fā)最佳實(shí)踐指南Futurice的完整入門(mén)指南iOS開(kāi)發(fā)最佳實(shí)踐指南Futurice的完整入門(mén)指南 本文詳細(xì)介紹了iOS開(kāi)發(fā)環(huán)境的搭建與配置、項(xiàng)目初始化與架構(gòu)選擇策略、依賴管理工具對(duì)比以及Git版本控制的文檔教程RedwoodJS最佳實(shí)踐指南如何構(gòu)建可擴(kuò)展的全棧項(xiàng)目結(jié)構(gòu)RedwoodJS最佳實(shí)踐指南如何構(gòu)建可擴(kuò)展的全棧項(xiàng)目結(jié)構(gòu) RedwoodJS是一個(gè)強(qiáng)大的全棧Web框架專為幫助開(kāi)發(fā)者從 原型項(xiàng)目快速成長(zhǎng)到創(chuàng)業(yè)級(jí)應(yīng)用 而設(shè)后端前端Web框架開(kāi)發(fā)工具上一篇Home Assistant IMAP 集成 imap.fetch_part 動(dòng)作詳解提取郵件附件與 MIME 部件下一篇DataHub Prefect 集成實(shí)戰(zhàn)指南用 prefect-datahub Block 捕獲 Flow/Task 血緣與運(yùn)行元數(shù)據(jù)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考