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