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