簡(jiǎn)介這是一份面向Android開發(fā)初學(xué)者與課程設(shè)計(jì)者的二手圖書交易平臺(tái)安卓端完整項(xiàng)目源碼聚焦移動(dòng)端二手書交易場(chǎng)景涵蓋用戶注冊(cè)、登錄、圖書瀏覽與發(fā)布等核心功能模塊。資源包共286個(gè)文件含109個(gè)Java業(yè)務(wù)邏輯文件、94個(gè)XML界面布局文件、60個(gè)PNG圖標(biāo)資源及7個(gè)JPG圖片素材輔以Gradle構(gòu)建腳本3個(gè).gradle、配置文件2個(gè).properties和版本控制相關(guān)文件2個(gè).gitignore整體壓縮后僅4.52MB結(jié)構(gòu)清晰、輕量易上手。已有56人學(xué)習(xí)下載適合用于Android Studio實(shí)戰(zhàn)練習(xí)、畢業(yè)設(shè)計(jì)參考或MVP架構(gòu)入門理解。項(xiàng)目采用全局常量類AppConstants統(tǒng)一管理API地址需替換IP即可對(duì)接服務(wù)端README.md提供基礎(chǔ)使用說(shuō)明引導(dǎo)頁(yè)與實(shí)際運(yùn)行截圖已集成便于快速驗(yàn)證功能完整性與UI交互效果。 接手這個(gè)項(xiàng)目的時(shí)候我最初以為只是一個(gè)普通的課程設(shè)計(jì)級(jí)別應(yīng)用——用戶注冊(cè)登錄、圖書列表、詳情頁(yè)、下單撐死再加個(gè)搜索。但真正把需求梳理清楚、進(jìn)入編碼階段之后才發(fā)現(xiàn)二手圖書交易平臺(tái)這個(gè)選題難點(diǎn)根本不在功能多而在于“交易”兩個(gè)字帶來(lái)的狀態(tài)流轉(zhuǎn)、信任機(jī)制和數(shù)據(jù)一致性。尤其是安卓端作為一個(gè)直接面向C端用戶的入口既要保證體驗(yàn)流暢又要兼顧圖片加載、網(wǎng)絡(luò)容錯(cuò)、離線狀態(tài)、內(nèi)存占用這些移動(dòng)端特有的問(wèn)題。如果你正在準(zhǔn)備做一個(gè)類似的安卓項(xiàng)目或者剛拿到一份“二手圖書交易平臺(tái) 安卓端.zip”的源碼想二次開發(fā)這篇文章應(yīng)該能幫你省下不少?gòu)澛?。我?huì)從項(xiàng)目整體拆解、技術(shù)選型、核心模塊的落地細(xì)節(jié)、實(shí)際開發(fā)中踩過(guò)的坑、性能優(yōu)化一直講到最后打包交付的完整流程。整個(gè)過(guò)程基于真實(shí)開發(fā)經(jīng)驗(yàn)提供可以直接拿走的代碼思路和配置方案。1. 先別急著寫代碼二手圖書交易平臺(tái)的業(yè)務(wù)邊界在哪很多同學(xué)拿到這類項(xiàng)目第一反應(yīng)是打開 Android Studio 直接建工程。我的建議恰恰相反——先花一兩天把業(yè)務(wù)模型想清楚尤其是“二手交易”和“新書商城”的差異。這個(gè)差異決定了你的數(shù)據(jù)庫(kù)表設(shè)計(jì)、界面布局乃至整個(gè)接口約定。1.1 二手交易的核心痛點(diǎn)是“品相”和“信任”新書商城賣的是標(biāo)準(zhǔn)化商品核心字段是書名、作者、出版社、ISBN、庫(kù)存、價(jià)格。但二手圖書不一樣兩個(gè)關(guān)鍵問(wèn)題立刻浮現(xiàn)第一同一本書可以有 N 個(gè)賣家每個(gè)賣家的品相、售價(jià)、可議價(jià)空間都不同。這意味著商品表不能以“書”為唯一維度而是要以“賣家發(fā)布的某本書的某個(gè)副本”為維度。設(shè)計(jì)上我建議拆成圖書基本信息表BookInfo和商品發(fā)布表Product兩張表前者存 ISBN、書名、封面、作者、出版社等靜態(tài)信息后者存賣家ID、售價(jià)、原價(jià)比例、品相描述、實(shí)拍圖URL、是否包郵等動(dòng)態(tài)信息。第二交易信任建立在細(xì)節(jié)描述上。二手書最重要的篩選條件不是價(jià)格而是品相。我在做需求分析時(shí)把品相分成了五檔全新、近全新、輕微使用痕跡、明顯磨損、有筆記劃線。每一檔在 UI 上要有對(duì)應(yīng)的標(biāo)簽色和圖標(biāo)在數(shù)據(jù)庫(kù)里存整數(shù)字段1-5同時(shí)允許用戶填寫自定義描述比如“第37頁(yè)有鉛筆劃線不影響閱讀”。這些細(xì)節(jié)在安卓端看起來(lái)只是幾個(gè)控件但直接影響搜索排序和用戶下單決策。1.2 Android端的功能邊界如何劃分如果做的是純安卓端項(xiàng)目沒(méi)有配套服務(wù)端源碼那大概率是用本地?cái)?shù)據(jù)庫(kù)模擬遠(yuǎn)程數(shù)據(jù)或者接一個(gè)現(xiàn)成的 BaaS 服務(wù)。我在實(shí)際開發(fā)中建議按照 MVC 的職責(zé)把功能分成三層用戶側(cè)注冊(cè)登錄手機(jī)號(hào)驗(yàn)證碼或賬號(hào)密碼、個(gè)人中心、我發(fā)布的商品、我買到的、我賣出的、收貨地址管理。商品側(cè)發(fā)布商品拍照/相冊(cè)選圖、填品相、定價(jià)、商品列表分類篩選、關(guān)鍵詞搜索、價(jià)格/品相排序、商品詳情多圖輪播、賣家信息、評(píng)論區(qū)/留言。交易側(cè)加入購(gòu)物車、立即購(gòu)買、下單確認(rèn)地址運(yùn)費(fèi)、訂單狀態(tài)跟蹤待付款/待發(fā)貨/待收貨/已完成/已取消、訂單留言。這里有個(gè)常見(jiàn)的誤區(qū)第一版就把 IM 聊天、在線支付、推送全做進(jìn)去。我建議把聊天簡(jiǎn)化為“留言板”支付做成“模擬支付”點(diǎn)擊后直接跳轉(zhuǎn)模擬成功頁(yè)推送可以完全不做用下拉刷新代替。把核心交易閉環(huán)跑通才是這個(gè)項(xiàng)目的價(jià)值所在。如果后續(xù)要擴(kuò)展這些模塊再逐步替換。1.3 數(shù)據(jù)模型的實(shí)體關(guān)系直接決定開發(fā)效率我經(jīng)歷過(guò)一次因?yàn)楸碓O(shè)計(jì)不合理導(dǎo)致的大重構(gòu)所以現(xiàn)在做項(xiàng)目第一步永遠(yuǎn)是畫 ER 圖。二手圖書交易平臺(tái)的核心實(shí)體我建議這樣設(shè)計(jì)Useruid主鍵、nickname、avatarUrl、phone、createTime。BookInfobookId主鍵、isbn、title、author、publisher、coverUrl、categoryId。ProductproductId主鍵、bookId、sellerId、price、conditionLevel1-5、conditionDesc、coverImagesJSON數(shù)組存多圖、status0下架 1在售 2已售 3審核中、createTime。OrderorderId主鍵、productId、buyerId、sellerId、addressId、totalPrice、freightPrice、status0待付款 1待發(fā)貨 2待收貨 3已完成 4已取消 5退款中、createTime、payTime、shipTime、finishTime。用 Room 還是直接 SQLite我建議 Room理由后面會(huì)講。但無(wú)論用哪種表關(guān)系必須提前定清楚。Product 和 BookInfo 是多對(duì)一多個(gè)賣家賣同一本書Order 和 Product 是一對(duì)一一個(gè)商品只能屬于一個(gè)訂單Order 和 User 是多對(duì)一。這些關(guān)系定清楚了寫 DAO 的時(shí)候基本是機(jī)械工作。2. 技術(shù)選型的取舍為什么我選 MVVM Retrofit Glide Room安卓開發(fā)的技術(shù)棧選擇很多但對(duì)于“二手圖書交易平臺(tái)”這個(gè)體量的項(xiàng)目我的建議是“主流穩(wěn)定優(yōu)先不做實(shí)驗(yàn)性嘗試”。下面把每項(xiàng)選型的原因和替代方案講清楚。2.1 架構(gòu)模式MVVM 比 MVC 更適合這個(gè)項(xiàng)目MVC 在 Activity 里堆邏輯一旦頁(yè)面復(fù)雜起來(lái)Activity 會(huì)膨脹到上千行。二手圖書的詳情頁(yè)什么都有——圖片輪播、品相標(biāo)簽、賣家信息、留言列表、底部操作欄加上網(wǎng)絡(luò)請(qǐng)求的狀態(tài)管理加載中/成功/失敗/空數(shù)據(jù)如果用 MVC代碼會(huì)非常難維護(hù)。MVVM 的核心是 ViewModel LiveData或 StateFlowActivity 只負(fù)責(zé)渲染和事件分發(fā)業(yè)務(wù)邏輯全部下沉到 ViewModel數(shù)據(jù)變化通過(guò)觀察者模式通知 UI。我用的組合是ViewModel持有頁(yè)面狀態(tài)處理用戶交互事件。LiveDataUI 感知的生命周期組件避免內(nèi)存泄漏。Repository 倉(cāng)庫(kù)層統(tǒng)一管理數(shù)據(jù)來(lái)源網(wǎng)絡(luò) or 本地ViewModel 只面向 Repository 接口。在這個(gè)項(xiàng)目里我寫了 ProductRepository、OrderRepository、UserRepository 三個(gè)倉(cāng)庫(kù)類每個(gè)倉(cāng)庫(kù)負(fù)責(zé)對(duì)應(yīng)模塊的數(shù)據(jù)獲取和緩存策略。例如 ProductRepository 的getProductList(categoryId, page)方法先從網(wǎng)絡(luò)獲取第一頁(yè)數(shù)據(jù)同時(shí)緩存到本地 Room下次打開 App 如果網(wǎng)絡(luò)不通就加載緩存——這個(gè)機(jī)制在弱網(wǎng)環(huán)境下體驗(yàn)提升非常明顯。2.2 網(wǎng)絡(luò)層Retrofit2 OkHttp 的套路化配置Retrofit 是安卓網(wǎng)絡(luò)請(qǐng)求的事實(shí)標(biāo)準(zhǔn)沒(méi)有太多懸念。但有幾個(gè)配置細(xì)節(jié)值得注意第一統(tǒng)一添加公共參數(shù)。比如 userId、deviceId、appVersion用 OkHttp 的 Interceptor 實(shí)現(xiàn)在請(qǐng)求頭里自動(dòng)注入不用每個(gè)接口都手動(dòng)傳。class CommonParamsInterceptor : Interceptor { override fun intercept(chain: Interceptor.Chain): Response { val originalRequest chain.request() val newRequest originalRequest.newBuilder() .header(Content-Type, application/json) .header(deviceId, DeviceUtils.getDeviceId()) .build() return chain.proceed(newRequest) } }第二統(tǒng)一處理錯(cuò)誤碼。后端接口通常會(huì)返回類似{ code: 0, message: success, data: {...} }的結(jié)構(gòu)。我在 ApiResponse 泛型里封裝了 code 和 message在 Repository 層統(tǒng)一判斷 code 是否為 0非 0 直接拋業(yè)務(wù)異常UI 層只需要關(guān)心成功與否不需要每個(gè)頁(yè)面重復(fù)判斷。第三超時(shí)時(shí)間設(shè)長(zhǎng)一點(diǎn)。二手圖書的詳情頁(yè)會(huì)加載多張實(shí)拍圖弱網(wǎng)下 3 秒超時(shí)很容易失敗。我把連接超時(shí)設(shè)為 10 秒讀取超時(shí)設(shè)為 15 秒寫入超時(shí) 15 秒。實(shí)測(cè)穩(wěn)定很多。2.3 圖片加載Glide 4.x 的緩存策略要調(diào)二手書交易平臺(tái)的特殊性在于圖片量大、且很多是用戶手機(jī)里的實(shí)拍圖分辨率參差不齊。Glide 依然是首選但有三點(diǎn)必須配置好第一自定義 OkHttp 網(wǎng)絡(luò)模塊。Glide 默認(rèn)使用 HttpURLConnection但項(xiàng)目的網(wǎng)絡(luò)層是 OkHttp統(tǒng)一用 OkHttp 可以共享連接池和攔截器避免重復(fù)握手。通過(guò)AppGlideModule實(shí)現(xiàn)GlideModule class MyAppGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { registry.replace(GlideUrl::class.java, InputStream::class.java, OkHttpUrlLoader.Factory()) } }第二磁盤緩存策略設(shè)置為 DATA 和 RESOURCE 都緩存。對(duì)于多次展示的商品封面圖緩存原始圖和裁剪圖都能顯著加快二次加載速度。第三縮略圖加載。詳情頁(yè)的輪播圖加載大圖時(shí)先用thumbnail(0.1f)加載低分辨率縮略圖占位再加載高清圖。視覺(jué)上體驗(yàn)會(huì)好很多尤其在高清圖加載慢時(shí)不會(huì)出現(xiàn)空白。2.4 本地存儲(chǔ)Room 解決了 SQLite 的樣板代碼問(wèn)題如果不做本地緩存SQLite 手寫 SQLiteOpenHelper 也能跑通。但項(xiàng)目里需要緩存商品列表、搜索歷史、用戶信息手寫 Cursor 轉(zhuǎn)實(shí)體類實(shí)在痛苦。Room 的編譯期 SQL 校驗(yàn)?zāi)芴崆鞍l(fā)現(xiàn) SQL 錯(cuò)誤配合 Flow 做響應(yīng)式查詢非常舒服。建議建三個(gè) EntityBookInfoEntity、ProductEntity、UserEntity。DAO 層用掛起函數(shù) Flow例如Dao interface ProductDao { Query(SELECT * FROM product WHERE categoryId :categoryId ORDER BY createTime DESC LIMIT :pageSize OFFSET :offset) fun getProductsByCategory(categoryId: Int, pageSize: Int, offset: Int): FlowListProductEntity Insert(onConflict OnConflictStrategy.REPLACE) suspend fun insertProducts(products: ListProductEntity) }使用 Flow 的好處是當(dāng)緩存表更新時(shí)UI 會(huì)自動(dòng)收到新數(shù)據(jù)天然實(shí)現(xiàn)了“網(wǎng)絡(luò)刷新后 UI 同步”。3. 核心功能落地的關(guān)鍵細(xì)節(jié)狀態(tài)機(jī)、圖片上傳、搜索與訂單業(yè)務(wù)模型清楚了技術(shù)棧選好了下面講幾個(gè)最容易寫出 bug 的地方。這些模塊寫好了項(xiàng)目質(zhì)量會(huì)明顯上一個(gè)臺(tái)階。3.1 商品狀態(tài)機(jī)設(shè)計(jì)別再到處寫 if-else 了二手商品在生命周期中會(huì)有多次狀態(tài)變化草稿 - 審核中 - 在售 - 已售或下架/刪除。一開始我是在 Product 實(shí)體里直接加一個(gè) status 字段每個(gè)頁(yè)面判斷 status 的值來(lái)決定顯示什么按鈕。結(jié)果訂單頁(yè)要判斷、詳情頁(yè)要判斷、個(gè)人中心“我發(fā)布的”要判斷邏輯散落各處改一個(gè)狀態(tài)牽扯一大片。后來(lái)我重構(gòu)為狀態(tài)機(jī)模式把狀態(tài)流轉(zhuǎn)集中在一個(gè)類里管理每個(gè)狀態(tài)定義允許的事件和對(duì)應(yīng)的目標(biāo)狀態(tài)。例如enum class ProductStatus(val value: Int) { DRAFT(0), REVIEWING(1), ON_SALE(2), SOLD(3), OFF_SHELF(4); fun canTransitTo(target: ProductStatus): Boolean { return when (this) { DRAFT - target REVIEWING || target OFF_SHELF REVIEWING - target ON_SALE || target OFF_SHELF ON_SALE - target SOLD || target OFF_SHELF SOLD - false OFF_SHELF - target ON_SALE || target REVIEWING } } }在發(fā)布商品時(shí)表單校驗(yàn)通過(guò)后調(diào)用productRepository.changeStatus(productId, ProductStatus.ON_SALE)Repository 內(nèi)部先檢查當(dāng)前狀態(tài)和下一狀態(tài)是否合法不合法直接拋異常。這樣就把“用戶點(diǎn)按鈕 - 狀態(tài)變更”的合法性收斂到了一處不會(huì)出現(xiàn)“已售出的商品還能下架”這種詭異情況。3.2 圖片上傳壓縮、多圖、進(jìn)度一個(gè)都不能少商品發(fā)布的圖片上傳模塊看起來(lái)簡(jiǎn)單實(shí)際上有很多隱藏要求。用戶從相冊(cè)選 9 張圖每張可能 5-10MB直接傳到服務(wù)器不僅慢還容易失敗。我的處理方案是三段式選圖后立即壓縮使用Luban庫(kù)現(xiàn)在可以自己寫或用魯班算法將圖片壓縮到最長(zhǎng)邊不超過(guò) 1280px、質(zhì)量 80%這樣單張通常能壓到 300KB 以內(nèi)。上傳前顯示進(jìn)度用一個(gè)WorkManager或后臺(tái)線程池逐個(gè)上傳每上傳一張更新 UI 的進(jìn)度條。這里建議用 OkHttp 的RequestBody重寫監(jiān)聽上傳字節(jié)數(shù)。上傳完成后返回 URL 列表把返回的 URL 列表按順序保存到 Product 的coverImages字段前端展示時(shí)按此順序渲染輪播圖。多圖上傳的并發(fā)策略也很重要。我建議串行上傳第一張傳完再傳第二張。雖然比并發(fā)慢但失敗重試邏輯簡(jiǎn)單且不會(huì)占滿帶寬導(dǎo)致列表頁(yè)圖片加載變慢。3.3 搜索基于關(guān)鍵詞 分類 排序的聯(lián)合查詢二手圖書的搜索和普通商品搜索不同用戶往往會(huì)帶上“考研”“計(jì)算機(jī)”“小說(shuō)”這種關(guān)鍵詞同時(shí)希望按價(jià)格、品相、發(fā)布時(shí)間排序。數(shù)據(jù)庫(kù)查詢可以這樣設(shè)計(jì)Query( SELECT * FROM product INNER JOIN bookInfo ON product.bookId bookInfo.bookId WHERE (:keyword IS NULL OR bookInfo.title LIKE % || :keyword || % OR bookInfo.author LIKE % || :keyword || % OR bookInfo.isbn LIKE % || :keyword || %) AND (:categoryId IS NULL OR bookInfo.categoryId :categoryId) AND (:minPrice IS NULL OR product.price :minPrice) AND (:maxPrice IS NULL OR product.price :maxPrice) ORDER BY CASE WHEN :sortType 1 THEN product.price END ASC, CASE WHEN :sortType 2 THEN product.price END DESC, CASE WHEN :sortType 3 THEN product.createTime END DESC ) fun searchProducts( keyword: String?, categoryId: Int?, minPrice: Double?, maxPrice: Double?, sortType: Int ): FlowListProductEntity注意 SQL 中用CASE WHEN實(shí)現(xiàn)動(dòng)態(tài)排序避免拼接字符串帶來(lái)的 SQL 注入風(fēng)險(xiǎn)。如果項(xiàng)目接的是服務(wù)端搜索接口那客戶端只需要傳參數(shù)但本地緩存搜索是離線模式的基礎(chǔ)能力。搜索的歷史記錄也建議用 Room 存一張 SearchHistory 表在搜索頁(yè)用瀑布流標(biāo)簽形式展示最近 10 條點(diǎn)擊歷史標(biāo)簽直接搜索體驗(yàn)非常順手。3.4 訂單流程防重復(fù)下單和并發(fā)扣庫(kù)存訂單模塊是交易平臺(tái)最緊張的地方。兩個(gè)高發(fā) bug用戶連點(diǎn)兩次“立即購(gòu)買”創(chuàng)建了兩筆訂單同一個(gè)商品被兩個(gè)用戶同時(shí)下單但庫(kù)存只有一本。防重復(fù)下單的解決方式下單接口設(shè)置一個(gè)訂單防重 Token。用戶在點(diǎn)擊購(gòu)買時(shí)客戶端先生成一個(gè)唯一的 requestIdUUID提交訂單時(shí)帶上這個(gè) requestId服務(wù)端用 Redis 或數(shù)據(jù)庫(kù)唯一索引做冪等。但純安卓本地項(xiàng)目沒(méi)有服務(wù)端怎么辦我當(dāng)時(shí)的方案是在本地訂單表給requestId加唯一約束插入時(shí)用OnConflictStrategy.IGNORE沖突就提示“請(qǐng)勿重復(fù)提交”。并發(fā)搶單的問(wèn)題比較麻煩。如果做的是帶后端的完整項(xiàng)目建議用數(shù)據(jù)庫(kù)樂(lè)觀鎖UPDATE product SET status 2 WHERE productId ? AND status 1如果影響行數(shù)為 1說(shuō)明搶單成功為 0說(shuō)明商品已被別人買走?？蛻舳诉@邊只需要在下單前檢查商品狀態(tài)下單后重新拉取詳情更新 UI。4. 真實(shí)開發(fā)中的踩坑記錄圖片 OOM、Fragment 重建、列表卡頓這一部分是我最想分享的。網(wǎng)上搜源碼往往只能看到功能怎樣實(shí)現(xiàn)但開發(fā)過(guò)程中那些“怎么會(huì)這樣”的問(wèn)題才是真正消耗時(shí)間的地方。我把遇到過(guò)的三個(gè)典型問(wèn)題完整復(fù)盤一遍。4.1 商品列表快速滑動(dòng)導(dǎo)致的內(nèi)存暴增從 80MB 到 200MB第一次用 RecyclerView 加載商品列表時(shí)我直接用 Glide 加載封面圖占位圖用了一個(gè)很大的本地 drawable加載完成后沒(méi)做任何處理?？焖倩瑒?dòng) 100 條數(shù)據(jù)內(nèi)存瞬間從 80MB 飆到 200MB最后直接 OOM 崩潰。排查過(guò)程是這樣的先用 Android Studio 的 Memory Profiler 抓內(nèi)存快照發(fā)現(xiàn)byte[]占據(jù)了大頭進(jìn)一步定位到 Glide 的 BitmapPool 一直在增長(zhǎng)。原因有兩個(gè)一是每張?jiān)瓐D是 4000x3000 像素的實(shí)拍圖而列表 item 只需要 400x400 pxGlide 默認(rèn)加載的是原始尺寸除非顯式指定override()二是占位圖是一張 1MB 的大圖導(dǎo)致每個(gè) item 都持有一個(gè)大 Bitmap。修復(fù)方法很簡(jiǎn)單Glide.with(itemView.context) .load(product.coverImages[0]) .override(480, 480) // 按列表 item 實(shí)際尺寸指定 .format(DecodeFormat.PREFER_RGB_565) // 不透明圖片用 RGB_565 省一半內(nèi)存 .placeholder(R.drawable.ic_book_placeholder) .error(R.drawable.ic_book_error) .into(ivCover)另外把占位圖換成矢量 Drawable 或小尺寸 PNG幾百 KB 級(jí)別就夠。修復(fù)后快速滑動(dòng)內(nèi)存穩(wěn)定在 100MB 內(nèi)。這個(gè)問(wèn)題的本質(zhì)是“移動(dòng)端加載圖片必須按需加載”原圖只應(yīng)該在詳情頁(yè)做大圖展示時(shí)才加載。4.2 Fragment 重建導(dǎo)致的“頁(yè)面狀態(tài)丟失”項(xiàng)目里商品首頁(yè)、分類頁(yè)、我的頁(yè)面都用 Fragment BottomNavigationView 實(shí)現(xiàn)。一開始我直接在 Activity 的onCreate里 add 三個(gè) Fragment沒(méi)有處理配置變更比如屏幕旋轉(zhuǎn)時(shí)的狀態(tài)保存。結(jié)果一轉(zhuǎn)屏Fragment 重建了ViewModel 雖然還在但 RecyclerView 的滾動(dòng)位置、選中的 Tab、搜索頁(yè)輸入框的文字全部丟失。后來(lái)我引入了 Navigation Component 來(lái)管理 Fragment并配合 ViewModel 持有界面狀態(tài)。具體做法每個(gè)頁(yè)面的數(shù)據(jù)加載狀態(tài)和列表數(shù)據(jù)放到 ViewModel 的 LiveData / StateFlow 中。頁(yè)面上的純 UI 狀態(tài)比如滾動(dòng)位置、Tab 選中項(xiàng)在onSaveInstanceState中保存到 Bundle。Fragment 重建后先從 ViewModel 恢復(fù)數(shù)據(jù)再?gòu)?Bundle 恢復(fù) UI 狀態(tài)。這里特別強(qiáng)調(diào)一種容易忽略的場(chǎng)景從詳情頁(yè)返回列表頁(yè)列表頁(yè)的 Fragment 被系統(tǒng)回收后重建如果列表數(shù)據(jù)沒(méi)有緩存用戶看到的是空白頁(yè)。我當(dāng)時(shí)的解決方案是在 Repository 層加了內(nèi)存緩存ConcurrentHashMap列表數(shù)據(jù)加載一次后緩存重建頁(yè)面時(shí)直接從緩存恢復(fù)同時(shí)后臺(tái)刷新。4.3 評(píng)論/留言列表的嵌套滾動(dòng)卡頓商品詳情的留言區(qū)是嵌套在 ScrollView 里的 RecyclerView。這樣做有幾個(gè)天然問(wèn)題嵌套滾動(dòng)事件沖突、滑動(dòng)卡頓、RecyclerView 復(fù)用作廢。一開始怎么調(diào)都卡后來(lái)干脆放棄嵌套改用單一 RecyclerView 多類型 Item的方案。詳情頁(yè)頂部信息圖片輪播、標(biāo)題、價(jià)格、品相描述作為 Header Item下面是留言列表 Item。這樣整個(gè)頁(yè)面只有一個(gè)滾動(dòng)容器滑動(dòng)流暢且復(fù)用正常。如果你只是臨時(shí)展示少量留言可以用NestedScrollView包 RecyclerView 并且設(shè)置android:nestedScrollingEnabledfalse讓 RecyclerView 不攔截滑動(dòng)事件。但數(shù)據(jù)量超過(guò) 20 條后建議還是用多類型 Item 方案我實(shí)測(cè)差距非常明顯。5. 性能優(yōu)化與交付從“能跑”到“好用”的差距項(xiàng)目功能做完只是第一步。真正讓人感覺(jué)“這個(gè) App 質(zhì)量不錯(cuò)”的往往是那些看不見(jiàn)的優(yōu)化。這一節(jié)我不講大道理只講在這個(gè)項(xiàng)目里親自落地過(guò)的優(yōu)化項(xiàng)。5.1 啟動(dòng)速度優(yōu)化冷啟動(dòng)從 2.3 秒壓到 1.2 秒冷啟動(dòng)時(shí)間受 Application 初始化影響很大。我一開始在 Application 的onCreate里初始化了 Glide、LeakCanary、極光推送、網(wǎng)絡(luò)庫(kù)等一堆東西導(dǎo)致啟動(dòng)時(shí)阻塞嚴(yán)重?，F(xiàn)在的做法是分階段初始化必須在 Application 中同步初始化網(wǎng)絡(luò)庫(kù)、數(shù)據(jù)庫(kù)實(shí)例。因?yàn)檫@些是頁(yè)面啟動(dòng)后立刻要用到的?？梢苑诺绞讉€(gè)頁(yè)面加載之后再初始化圖片加載庫(kù)可以延遲到頁(yè)面真正加載圖片時(shí)初始化、統(tǒng)計(jì) SDK、推送 SDK 用異步線程初始化。具體實(shí)現(xiàn)可以用IdleHandler或WorkManager的initialize異步執(zhí)行。我實(shí)測(cè)將 LeakCanary 和推送 SDK 放到主頁(yè)面onResume之后再初始化冷啟動(dòng)時(shí)間從 2.3 秒降到 1.2 秒效果非常明顯。5.2 APK 體積控制從 45MB 瘦身到 28MB二手圖書項(xiàng)目的 APK 體積主要被三塊占據(jù)圖片資源、第三方庫(kù)、多架構(gòu) so 文件。我做過(guò)的有效瘦身手段開啟資源混淆android.enableResourceOptimizationstrue在 gradle.properties 中配合shrinkResources移除無(wú)用資源。移除多余 ABI如果只發(fā)布國(guó)內(nèi)安卓市場(chǎng)abiFilters只保留arm64-v8a和armeabi-v7a去掉x86和x86_64體積瞬間減少很多。當(dāng)然如果要在模擬器上測(cè)試需要保留 x86。圖片資源 WebP 化將啟動(dòng)圖、默認(rèn)頭像、占位圖全部轉(zhuǎn)換為 WebP 格式通常能比 PNG 再小 30%-50%。動(dòng)態(tài)特性模塊如果項(xiàng)目足夠大可以把留言模塊、客服模塊做成 Dynamic Feature用戶按需下載。但對(duì)這個(gè)體量的項(xiàng)目這一步不是必須的。5.3 內(nèi)存泄漏的排查工具鏈越是這種設(shè)計(jì)到大量圖片和網(wǎng)絡(luò)請(qǐng)求的 App越容易在退出后殘留內(nèi)存泄漏。我每次開發(fā)到中后期都會(huì)用 LeakCanary 做一輪全量檢測(cè)。它檢測(cè)出的典型泄漏點(diǎn)有兩個(gè)Activity 被靜態(tài)變量持有比如單例里保存了 Activity 引用。我遇到過(guò)在 UserManager 里用靜態(tài)變量保存了當(dāng)前用戶信息里面有 Bitmap 頭像間接持有了 Activity Context導(dǎo)致整個(gè)頁(yè)面無(wú)法回收。Handler / 回調(diào)未解綁。頁(yè)面銷毀后異步任務(wù)回調(diào)還在操作 View。修復(fù)方式所有跨頁(yè)面共享的 Context 一律使用getApplicationContext()Activity 相關(guān)的引用隨用隨取、用完即置空所有訂閱在onDestroy中取消。另外我做了一輪Memory Profiler 的 Heap Dump 分析發(fā)現(xiàn)商品列表頁(yè)退出后Glide 的緩存仍然占著 30MB 內(nèi)存。這是正常的因?yàn)?Glide 有 LRU 緩存策略。但如果擔(dān)心緩存壓力可以在低內(nèi)存時(shí)onTrimMemory回調(diào)中調(diào)用glide.clearMemory()和glide.clearDiskCache()。6. 打包與交付Zip 里應(yīng)該有什么才能算一個(gè)完整的安卓項(xiàng)目到了項(xiàng)目交付和二次開發(fā)階段很多只發(fā)一個(gè) .zip 壓縮包的朋友可能忽略了打包結(jié)構(gòu)的完整性。一個(gè)合格的“二手圖書交易平臺(tái) 安卓端.zip”除了源碼應(yīng)該包含讓接手者能立刻跑起來(lái)的一切。6.1 Gradle 配置里的坑如果你拿到手的 zip 里帶 local.properties里面寫著本機(jī)的 SDK 路徑那是無(wú)用的甚至可能導(dǎo)致別人打開工程時(shí)報(bào)錯(cuò)。正確的做法是不提交 local.properties讓 Android Studio 自動(dòng)生成。build.gradle里的compileSdk、targetSdk、minSdk要寫清楚。我用的是compileSdk 34,targetSdk 34,minSdk 24。注意targetSdk 34或更高版本會(huì)默認(rèn)啟用分區(qū)存儲(chǔ)所以涉及圖片上傳的時(shí)候需要處理READ_MEDIA_IMAGES權(quán)限和ActivityResultContracts.PickVisualMedia這類新 API不能用老的READ_EXTERNAL_STORAGE。依賴庫(kù)的版本統(tǒng)一放到versions.gradle或ext中管理避免不同模塊依賴沖突。6.2 二次開發(fā)最需要看的三個(gè)文件如果這份 zip 是你要學(xué)習(xí)的源碼拿到手建議按這個(gè)順序閱讀文件/目錄作用app/src/main/java/.../di/或AppContainer.kt依賴注入入口看清單例和對(duì)象創(chuàng)建順序理解數(shù)據(jù)流。app/src/main/java/.../repository/Repository 層所有數(shù)據(jù)獲取邏輯在這里能看出數(shù)據(jù)來(lái)自網(wǎng)絡(luò)還是本地緩存。app/src/main/java/.../ui/按模塊劃分的包頁(yè)面和 ViewModel重點(diǎn)看商品列表和訂單流程的狀態(tài)管理。有了這三個(gè)文件的結(jié)構(gòu)認(rèn)知即使沒(méi)有完整文檔也能快速定位改動(dòng)位置。6.3 多渠道打包和上架的注意事項(xiàng)如果你打算把這套代碼上架到應(yīng)用市場(chǎng)有幾點(diǎn)得提前處理簽名文件.jks 簽名文件一定不能提交到 zip 里但要在 README 里說(shuō)明需要自己生成。上架后簽名丟失是無(wú)法找回的所以項(xiàng)目初期就應(yīng)該建立簽名備份機(jī)制。渠道包productFlavors配置不同渠道的applicationId后綴和渠道號(hào)騰訊樂(lè)固、360、應(yīng)用寶等平臺(tái)需要識(shí)別渠道信息。可以用manifestPlaceholders注入渠道號(hào)。隱私合規(guī)如果集成了友盟統(tǒng)計(jì)、極光推送等 SDK在 targetSdk 34 下上架時(shí)隱私政策彈窗必須在其初始化之前展示并征得同意。7. 寫在最后做交易類項(xiàng)目的一點(diǎn)個(gè)人體會(huì)這個(gè)項(xiàng)目做完之后我最大的體會(huì)是交易類 App 的重點(diǎn)不是炫技而是把狀態(tài)管理和異常流程處理干凈。圖片加載、列表流暢度這些都是常規(guī)操作真正體現(xiàn)功底的是用戶在弱網(wǎng)下點(diǎn)下單、連續(xù)點(diǎn)兩次購(gòu)買、商品中途被下架、支付成功但回調(diào)丟失這些場(chǎng)景下App 能不能給出合理的反饋。如果你正在做這份工程的二次開發(fā)我給三個(gè)具體建議第一優(yōu)先打通一條完整的交易鏈路登錄 - 搜索 - 詳情 - 下單 - 支付 - 查看訂單。這條路走通項(xiàng)目的主干就成了其他功能都是枝葉。第二在列表頁(yè)和詳情頁(yè)之間傳遞數(shù)據(jù)時(shí)不要用 Internt 傳大對(duì)象。傳 productId 或 bookId 就夠詳情頁(yè)根據(jù) ID 去倉(cāng)庫(kù)重新讀取最新數(shù)據(jù)。因?yàn)榱斜眄?yè)的數(shù)據(jù)可能已經(jīng)過(guò)期詳情頁(yè)顯示的價(jià)格、庫(kù)存必須是最新狀態(tài)。第三保持簡(jiǎn)單不要過(guò)度設(shè)計(jì)。很多朋友一上來(lái)就用 Dagger Hilt、Paging 3、DataStore 替換所有組件結(jié)果排錯(cuò)成本急劇上升。這些庫(kù)本身沒(méi)錯(cuò)但在一個(gè)以二手圖書交易為核心的項(xiàng)目里ViewModel Repository LiveData Retrofit Glide 這個(gè)組合已經(jīng)足夠穩(wěn)定可靠。先跑通業(yè)務(wù)再考慮架構(gòu)升級(jí)。最后再分享一件小事項(xiàng)目發(fā)布前我做了三輪真機(jī)測(cè)試最值錢的一輪是讓一個(gè)完全不懂 app 的同學(xué)上手操作看她會(huì)不會(huì)在發(fā)布商品的表單頁(yè)卡住、會(huì)不會(huì)困惑按鈕的位置。她反饋“上傳九張圖太麻煩”于是我把必填圖片從九張降到了三張并增加“使用示例圖”的快捷入口。這個(gè)改動(dòng)帶來(lái)的好評(píng)率提升比任何代碼優(yōu)化都明顯。做安卓開發(fā)始終要把自己當(dāng)成最挑剔的用戶。本文還有配套的精品資源點(diǎn)擊獲取