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