移動購物APP設計與實現
所謂電商購物平臺，就是通過網際網路進行商品展示、交易的平臺，這個模式極大的提高了商品的銷售範圍，相比傳統的實體店購物更加便宜，對使用者來說有更多的選擇，對商家來說擁有了更多的客戶。網上購物這是一個當下熱門的詞彙，自從雙十一購物節的記錄不斷地被打破，這和APP購物平臺是密不可分的。自從2007年10月Android智慧作業系統被開源,智慧手機就迅速佔領移動智慧市場，這也為移動購物的發展提供了一個很好的機會。伴隨著資訊科技的不斷進步和因特網各項技術的不斷完善，電子商務逐漸成為了網際網路時代的一種全新的網路商品交易方式，大家也不在陌生。作為領先的新型產業，電子商務在中國的發展速度有目共睹。但是隨著每秒訂單的數量，對後臺伺服器的穩定性、系統可擴充套件性和每秒高併發的下單要求也越來越高。
通過對電子商務平臺的研究，我認為現在的電子商務正在經歷著以下幾點難題：
（1）如何實現高併發，並且保證系統的穩定執行。就此，我們需要叢集以及大資料平臺的支撐，以及出現系統問題時如何保證消費者和商家的權益。
（2）如何有效的監管平臺物品的真實性。對於這個問題我相信在未來將更加完善，隨著虛擬現實技術的出現，平臺能最大限度地展示物品。另外，需要平臺方配合國家物品監管加大防偽，打假的力度，給消費者普及防騙的相關知識和案例，以確保消費者的權益。
（3）支付安全，這個問題是每個消費者和商家關心的問題。目前，在Android平臺上保證支付安全的主要採取的措施有，資料加密，簽名。雖然現在很安全，但是我們也應該加大力度去研究更好、更安全的措施。
（4）如何確保物流不延時，運輸過程不損壞物品。這就需要商家，平臺方，物流公司共同配合。
我相信，電子商務平臺方做好這四點，移動購物將會更加深入人心，使移動購物更上一層樓。另外，這幾點也是麼個消費者所關心的，因此，我們還需努力完善系統，使得客戶，消費者的權益得到保障。
1 緒論
1.1 設計背景
在這個網上購物盛行的今天，作為消費者更應該瞭解系統是怎麼執行的。移動購物APP這個專案，也是致力於研究如何有效的給消費者帶來更好的體驗，致力於研究如何加強支付安全，以確保消費者權益。這個專案開始與2017年3月,在移動購物盛行的時代，本人想通過這個專案更加深入的學習Android和Java相關技術。而且隨著移動智慧裝置在生活中的使用越來越廣，Android作業系統作為搭載最多的手機作業系統。慢慢的在生活中已經隨處可見搭載安卓作業系統的裝置,例如MP3音樂播放器，智慧手機，手持平板，智慧電視機，機頂盒等等。並且隨著時代、科技和網際網路的發展，二十一世紀已經成為了以網路為資訊傳輸紐帶，以網際網路為主導的資訊化社會。移動智慧裝置、雲購物、電子商務、網際網路、大資料也成為了21世紀最熱門的詞彙。隨著計算機軟體技術和網際網路通訊技術的不斷完善、提高，人工智慧也逐漸成為了我們生活中有一道靚麗的風景線。特別是谷歌公司2007年將Android作業系統程式碼公開後，使得移動智慧裝置在科技圈掀起了一次智慧裝置浪潮，讓Android作業系統成為了很多移動電子裝置製造商的不二之選，同時興起了很多智慧手機制造商。正因為移動智慧裝置的盛行，網上購物也很快成為了21世紀一種全新的網路購物模式。2014年雙十一天貓一天創下571億元的交易額； 2015年一天就達到了912億元交易額；再到2016年天貓一天交易額達1300億元的交易額，已經說明電商平臺和網路購物在我們生活中扮演著重要的角色。
1.2 設計目標和意義
瞭解移動購物的執行流程，正確對待電商購物平臺，在使用平臺的同時讓消費者能夠有效的避免損失。通過這個設計，我希望自己能夠對移動平臺的開發和Java後臺的開發技術更上一層樓。另外，就當下購物平臺相關知識的普及給消費者，也讓消費者瞭解他們所使用的系統。
2系統概述
2.1 開發工具
整個專案移動端APP使用當下流行的Android開發工具Android Studio開發。伺服器採用Eclipse Java整合工具開發後臺資料支撐系統，伺服器端程式碼搭建在Tomcat上，使用Oracle資料庫儲存整個專案所涉及的資料。
2.1.1 Eclipse
Eclipse整合環境是由IBM公司開發的軟體開發環境，不同公司自主研發的可擴充套件軟體開發工具集。它是一款具有可擴充套件、跨平臺的軟體開發應用，它本身只是一組軟體開發平臺，由於高擴充套件性和眾多外掛的存在、支援，使得Eclipse擁有其他功能固定的軟體開發環境沒有的靈活性，也是由於眾多的外掛支援，使得它功能更加強大。很多軟體開發公司研發部以Eclipse作為基本環境搭建更適合自己業務的開發工具集，完成所需的軟體開發。Eclipse是一款可擴充套件的Java開發整合環境，是一個開放原始碼的軟體。就Eclipse本身而言，它只是一組軟體開發服務介面和一個普通應用軟體，通過外掛元件構建最終的開發環境。Eclipse自帶了一些固有的外掛，Eclipse軟體是基於Java平臺的可擴充套件開發工具，包括基本的Java軟體開發工具。安裝Java Web外掛後可以用於開發Web網站，安裝Android SDK和ADT後可以開發Android應用，安裝J2EE外掛後可以開發伺服器等等，因此Eclipse也變得更加強大。
2.1.2 Android Studio 2.3
Android Studio是一款全新的Android整合開發工具，有32位和64位兩種版本。在2013年Google在Android I/O大會上正式推出，並大力推廣。它提供了整合的Android用於開發APP應用的開發環境和除錯工具集，它具有強大的功能，例如，Debug，記憶體分析工具，自動導包功能。強大的佈局展示功能，使得Android開發者可以在編寫程式介面佈局檔案的同時就能在軟體的預覽位置看到自己的UI在不同尺寸螢幕中的樣子，它強大的功能、眾多外掛支援深受Android開發者的喜愛。Android Studio整合了Gradle構架工具，更加智慧，更多外掛的支援，自帶命令列工具，使用更加方便快捷。另外，隨著技術的不斷提高，某些已存在的APP都在使用Android Studio進行重構目，Android Studio專案目錄層次結構更加完善、容易管理。Android Studio強大的功能深受開發人員喜愛，特別是導包，螢幕適配及更加智慧的程式碼提示，使得開發更加快速。
Tomcat是由Apache、Sun公司軟體開發團隊共同開發而成。Tomcat伺服器是Apache專案的一個核心之一，是一款免費的開源的Web 應用級伺服器，是輕量級、易安裝的應用伺服器，在中小型企業系統和使用者併發訪問不是很高的公司系統中使用普遍，而且很適合專案前期開發和除錯，因此移動購物平臺我也採用了該輕量級的伺服器作為後臺支撐。另外，Tomcat和Windows系統自帶的IIS等Web伺服器功能一樣，都擁有處理HTML、JSP頁面的功能，可以搭建Web網站，為小企業和個人使用者提供簡單服務[1-3]。Tomcat還有其他強大的功能，比如：釋出網站，搭建公司內部系統。除此之外，Tomcat作為一個能執行Servlet和JSP的容器，它預設的Servlet是獨立的。
Oracle 10g關係型資料庫管理系統(DMS)是由Oracle公司開發的。Oracle 10g資料庫的可移植性好、使用方便、功能強大使得大多數企業內部都在用的關係型資料庫管理系統，主要面向兩種平臺Linux和Windows，適用於各種大型伺服器系統，微型系統，小型系統等。它具有很高的資料管理效率，具有很高的可靠性、安全性，能夠適應各種高併發的環境，具有很高的吞吐率[4-7]。Oracle 10g在實際開發中應用也很廣，特別是大中型企業基本都是Oracle資料庫。
2.2 開發環境
系統採用二十一世紀非常流行的Java程式設計語言開發。Java語言很好的解決了跨平臺。面向物件的思想，語法簡單等特點深受程式設計者的喜愛。系統伺服器主體是基於Java SDK 1.8平臺開發的伺服器。前端是基於Android 5.0開發的APP，後臺搭建在Tomcat8.0伺服器上，APP通過網路進行訪問伺服器獲取和提交資料。
2.3 相關技術
Mybatis是一款伺服器端操作資料庫的框架。Mybatis封裝了JDBC能夠通過配置XML檔案寫SQL，使得開發變得簡單更加面向業務，而無需編寫載入驅動、獲取連線、獲取執行SQL的物件，執行SQL、結果集處理，關閉資料庫連線等繁瑣的程式碼，開發者只需將資料庫連線配置到XML配置檔案中即可連線資料庫，在XML中編寫SQL語句即可將所得結果轉換成實體Bean類，開發者也不需要關閉連線。Mybatis將結果集處理透明化，通過反射執行相應的SQL，不僅效率高而且容易維護。使用Mybatis只需匯入相應資料庫JDBC的jar包，編寫相應的配置檔案即可連線任意資料庫，提高了開發者的開發效率。值得注意的是 Mybatis是通過事務操作資料庫的，但是Mybatis並不會自動提交事務，因此需要開發人員，對資料更新、刪除、插入時要手動提交事務。
Servlet是一種與具體網路求協議無關、與平臺無關的伺服器技術。Servlet是專門在伺服器端執行的元件，負責接收來自客戶端或者Web的網路請求，並把請求交給伺服器進行處理，將伺服器的處理結果響應給APP，Servlet是APP和伺服器進行連線的橋樑，經常作為大型應用與伺服器之間的網路中介軟體[8-9]。
Retrofit2是一款基於RxJava的非同步的Android網路請求框架。Retrofit2預設分裝了Okhttp框架，配合Google的Gson框架能自動將伺服器獲得的Json字串轉成相應的實體物件。非同步的請求使得當使用者點選了某個服務後，還可以進行其他的操作，而不是必須等待伺服器響應結束後才能做其他操作。這樣的好處就是當用戶點選了某個按鈕後，無需等待伺服器，而可以直接使用另一個服務，有效的防止了客戶端卡死。Retrofit2採用註解的方式拼接請求的URL引數，極大地簡化了程式碼，提高了程式碼可讀性，另外使用介面配置網路請求，使得專案容易管理和維護。通過框架請求網路，開發者無需處理流相關的程式碼，也減少了程式碼書寫量。
Gson是一款將Json字串轉實體Bean的框架。Gson封裝了Json字串讀取、解析和給物件賦值。使得開發人員無需解析Json字串，這樣提高了開發效率，如果沒有Gson框架，那麼解析複雜而且比較長的Json字串將有很大難度，並且解析所佔程式碼比例很大，不容易維護。
ButterKnife作為一款Android應用開發的註解框架，能夠進行findViewById，繫結事件等相關操作。ButterKnife能夠通過反射獲得每一個佈局中的控制元件ID並繫結給控制元件物件，另外還能繫結事件，但是由於使用了反射，因此，相對來說，比較浪費資源。在APP中使用ButterKnife註解，在編寫程式碼時將能夠很簡便、快速的為View控制元件繫結事件和findViewById，給開發者也節約了很多時間，讓開發者能把更多時間花在思考邏輯中去，而不是做一些特別繁瑣的事，例如簡化findViewById程式碼。
2.3.6 快取設計
為了提升使用者體驗，客戶端實現了三級快取技術。三級快取有效的為使用者節約了流量，當再次進行載入時能很快的展示資料。三級快取，即就是先從記憶體中讀取資料，其次再從本地SD卡讀取資料，如果本地和記憶體都沒有資料，再去請求網路，反之，當網路請求成功後將獲得資料，寫入記憶體和SD卡。如圖2-1所示：
圖 2-1 三級快取圖
客戶端採用快取技術，將從伺服器獲得的Json資料快取的SharePerference配置檔案中，用請求時間戳作為儲存的Key值,獲得的Json字串作為Value值。當再次進入時載入本地快取資料，另外把時間戳傳送到伺服器，如果伺服器資料變化，伺服器就會把新資料返回給客戶端，並由APP展示給使用者。對於圖片這種比較的大資料，由URL作為檔名，儲存在APP的快取目錄。另外值得注意的是圖片使用三級快取時，必須先處理Bitmap物件的儲存大小，否則採用的三級快取將不明顯，還有可能造成記憶體溢位。怎樣高效的載入Bitmap物件在APP中。其實處理的思想也很簡單，那就是通過系統提供的BitmapFactory類中的Options方法來優化載入所需尺寸的圖片[10]。即就是把圖片按照控制元件大小進行壓縮處理後寫入記憶體或展示。
2.3.7 執行緒池設計
在APP中為什麼要把執行緒池化？在系統中好處有三點：（1）複用執行緒池中已儲存的Thread物件，能夠有效的避免因為建立Thread物件和銷燬Thread物件的所帶來的手機系統的效能開銷[11];（2）使用執行緒池的設計能夠有效控制APP在具體手機上的執行緒最大併發數，避免系統內因為大量執行緒之間互相爭奪，系統資源而導致的軟體執行緒阻塞現象，能防止系統執行緒死鎖[12];（3）APP內使用執行緒池設計能夠對系統內的Thread物件進行基本的管理，能夠提供Thread物件按時執行以及指定Thread物件執行的迴圈間隔等功能，對於Thread物件的控制起了很好的幫助[13]。
為提高軟體的流暢效能和使用者體驗，對於從服務端獲取大資料(如圖片)的情況都需要非同步獲取資料，因此需要新開執行緒的方式和伺服器連接獲取資料。因為APP內執行緒的連線、建立需要耗費較多系統資源，而且Android系統佔用記憶體小，是輕量級的作業系統，為每個APP的可用資源有限。另外，Android系統的編碼說明文件中也提供了Java語言說明文件中的執行緒池技術，因此，實現APP時我使用了執行緒池。專門用於獲取服務端資料和向伺服器提交資料，執行緒池的設計能控制APP內手機所能達到的最大執行緒數，不然容易造成費電，手機發熱，一般以具體使用裝置的最大執行緒的的一半為最大執行緒數[14-16]。
2.3.8 自定義View
在APP編寫程式碼實現功能過程中，由於APP功能需求的多樣性，Android已存在的控制元件已經不能滿足專案需要。因此，我寫了一個ImageView的子類重寫父類的方法實現了圓形的CircleImageView作為展示頭像的控制元件，自定義指示實現了各種炫酷的介面。自定義View有三種，第一就是繼承已有的非容器元件(TextView)，重寫父類非私有的方法，自己定義View的功能,第二，就是繼承容器類元件(ViewGroup) ，重寫父類的方法，按照自己的需求定義控制元件,第三，自定義組合控制元件，即就是將專案中用到很多，而且很相似的佈局定義為控制元件使用[17]。這樣佈局不僅易讀，而且會減少程式碼量，對後期維護和重構也很重要。
2.3.9 螢幕適配
由於Android系統實現程式碼開源，電子裝置生產廠家眾多，而且裝置螢幕大小不一，這就給開發人員帶來了很多麻煩。因此為了匹配每一款手機解析度，我運用了螢幕適配，比如：在程式碼中使用dp不適用畫素，佈局中不適用絕對佈局，不將控制元件尺寸固定，而是通過使用者手機的螢幕解析度自動適配。
3 系統需求分析
3.1 功能性需求分析
移動購物APP主要為使用者提供一個商品搜尋、商品分類、商品按條件排序、商品詳情、軟體升級、首頁、分類、註冊、登陸等功能；使用者註冊登陸後還可以進行物品線上下單、使用購物車、記錄瀏覽記錄、商品收藏、檢視訂單、檢視已分享商品，個人資訊管理等功能，是一個集商品交易管理和互動的商品交易APP。從電子商務的需要出發，以購物、交易、網際網路技術等理論為指導，基於現代網路技術和Android技術，設計實現了移動購物APP。本APP是以網路化的交易、管理技術為支撐，實現了商品購買、購物車、檢視訂單、物品分類等線上購物功能。
（1）商品搜尋
在移動購物APP設計中，使用者需要快速查詢自己想要的商品。使用者將搜尋資訊通過APP提交後，伺服器會根據使用者輸入的搜尋關鍵詞分析做出響應，傳送到UI上展示搜尋商品。使用者還可以按照價格、銷量等進行快速的排序，使得搜尋更加細化和準確。
（2）物品分類
APP對商品進行了分類，使用者可以直接在分類中按照系統分類快速檢索商品，然後進行購買。分類中使用者可以看到商品基本資訊，使用者可以根據需求快速篩選。
（3）檢視訂單
檢視訂單主要記錄的是當前使用者的所有訂單資訊。在訂單功能中使用者可以通過訂單狀態快速的檢視訂單，也可以在訂單頁面對於狀態為待支付的訂單直接進行支付，這樣使用者能夠很清晰的記錄個人購物資訊，方便快捷的進行二次支付。
（4）商品分享
商品分享功能主要記錄使用者分享過的一些商品。在分享頁面能方便使用者檢視自己分享過的喜歡的商品，方便再次快速的查詢、分享物品。
（5）商品收藏
使用者可以瀏覽商品詳細資訊並將喜歡的物品加入收藏，當用戶想再次檢視時，就可以直接在商品收藏頁面找到該物品，商品收藏頁面通過時間進行了排序，方便使用者瀏覽個人收藏資訊。
（6）瀏覽足跡
瀏覽足跡是系統自動記錄使用者檢視詳情的物品，系統會抓取使用者瀏覽商品的關鍵詞進行基本的大資料分析，然後向用戶推送商品。如果使用者希望再次瀏覽該物品，那麼使用者就無需再次查詢，可以直接檢視瀏覽足跡。
（7）個人資訊管理
個人資訊管理主要展示使用者選用的是那個收件人資訊，使用者也可以新增、刪除收件人資訊，該功能選用資訊將會成為後續下單的收件人，就無需每次購買商品都新增收件人資訊。
具體根據功能需求，整理APP用例圖如3-1所示
圖3-1 系統用例圖
3.2非功能性需求分析
整理APP的非功能效能的需求包括以下6個方面:
（1）APP互動性強，介面友好美觀易於使用，資訊查詢方便、快捷、準確、資料儲存安全可靠。
（2）使用者的軟體專業知識普遍偏低，要求APP具有良好的人機互動介面。
（3）全面、分類顯示使用者的所有資訊。
（4）APP易於擴充套件。
（5）APP圖片較多，需要能夠快速的載入圖片資訊。
（6）系統應該易維護，穩定的執行。
3.3 購物流程需求分析
根據需求和技術建模，最終所得購物流程。使用者通過APP搜尋物品，檢視物品詳情，在詳情頁面，使用者可以選擇物品屬性，把喜歡的物品選擇加入購物車或者立即購買進行下單，在這之前系統會判斷使用者是否登入，只有登入後才能使用購物車和下單功能，當用戶進入支付頁面後，APP將自動提交訂單資料到伺服器並作入庫操作，預設狀態為待付款，當用戶點選支付，呼叫第三方支付平臺，支付成功後伺服器更新訂單狀態並將結果反饋到客戶端，另外伺服器還會通知商家訂單資訊，商家根據訂單進行發貨。如果在支付頁面，使用者選擇放棄訂單，資料庫將不會刪除該條訂單，並保持待付款狀態。系統具體流程如圖 3-2所示：
圖 3-2 購物流程圖
3.4 APP時序需求分析
根據使用者操作和APP和伺服器互動過程，整理APP請求和系統響應的時序圖，系統時序圖如3-3所示：
4 系統總體設計
4.1 UML圖設計
根據系統實體模型，經分析設計相關實體類圖如圖4-1所示：
圖 4-1 類圖
4.2 資料庫設計
系統用E-R(實體-關係)圖來描述實體的關係模型，抽象成建立資料庫的關係模型。本系統主要有13個實體，主體模型關係如圖4-2所示：
圖 4-2 主體E-R圖
4.1.1 使用者
使用者實體資訊包括：使用者ID,密碼，使用者名稱，使用者積分，使用者等級，使用者頭像6個屬性，如圖4-3所示：
圖4-3 使用者實體圖
4.1.2 商店
商店實體資訊包括：商店ID,商店名字，關注人數，商店描述，商店地址，商店商品數量，商店促銷資訊，商店型別，共8個屬性，如圖4-4所示：
圖 4-4 商店實體圖
4.1.3 商品
商品實體資訊包括：商品ID，商品名稱，商品價格，商店ID，促銷價格，額外費用，是否新品，是否免費，庫存量，詳情，尺寸，顏色，促銷資訊，銷量，限購數量，圖片，型別共17個屬性，如圖4-5所示：
圖 4-5 商品實體圖
4.1.4 訂單
訂單實體主要包括：訂單ID，使用者ID，支付資訊，電話號，地址，訂單時間，額外費用，訂單總價格，訂單狀態，商店ID共10個屬性，如圖4-6所示：
圖4-6 訂單實體圖
4.1.5 購物車
購物車實體資訊包括：使用者ID，商店ID，物品ID，物品名字，物品圖片，物品屬性，商店名字，物品價格，物品數量，額外費用共10個屬性，如圖4-7 所示：
圖4-7 購物車實體圖
4.1.6 收貨人
收件人實體資訊包括：電話號碼，名字，ID，狀態，地址，使用者ID等6個屬性，如圖4-8所示：
圖 4-8 收件人實體圖
4.1.6 其他相關實體
使用者瀏覽，使用者收藏，使用者分享實體資訊包括：使用者ID，商店ID，商品ID，時間共四個屬性,如圖4-9所示：
圖4-9 足跡、瀏覽實體圖
4.1.7 商店與商品關係
根據現實生活，商店與商品為一對多關係。每個商店有很多商品，但一個商品只能屬於一個商店，因此將物理模型轉化成邏輯模型，如圖4-10所示：
圖4-10 商店與商品關係
4.1.8 使用者與訂單關係
最終整理使用者關係如圖4-11所示：每個使用者只有一個購物車，有很多瀏覽記錄，也可以分享很多物品，另外一個使用者可以線上下多個訂單和新增多個收件人資訊，因此形成了很複雜的關係，經過邏輯轉換，最終將物理模型抽象成邏輯模型，雖然現實中關係複雜，但是在抽象過程中忽略了很多不符合邏輯的關係，最終生成了系統所需要的模型。
圖4-11 使用者關係
4.3 邏輯結構設計
4.3.1 資料庫表及其結構
使用者資訊邏輯儲存如表4-1所示：
表4-1 使用者資訊表
|
欄位 |
中文名 |
型別 |
含義 |
|
user_id |
使用者賬號 |
varchar2(30) |
唯一標識使用者，用於登入 |
|
user_name |
使用者名稱 |
varchar2(50) |
使用者暱稱 |
|
user_score |
使用者積分 |
varchar2(20) |
標識使用者購買比例 |
|
user_grade |
使用者等級 |
varchar2(10) |
等級 |
|
is_vip |
是否vip |
varchar2(10) |
標識使用者型別 |
|
head_image |
使用者頭像 |
varchar2(100) |
使用者頭像url |
使用者收藏、分享、瀏覽足跡邏輯儲存如表4-2所示：
表4-2 收藏分享瀏覽記錄表
|
欄位 |
中文名 |
型別 |
含義 |
|
user_id |
使用者賬號 |
varchar2(30) |
唯一標識使用者，用於登入 |
|
product_id |
商品標識 |
varchar2(30) |
商品唯一標識 |
|
shop_id |
商店標識 |
varchar2(30) |
商店唯一標識 |
|
date |
時間 |
varchar2(50) |
收藏時間 |
|
type |
型別 |
varchar2(10) |
資料型別 |
商店資訊邏輯儲存模型如表4-3所示：
表4-3 商店資訊表
|
欄位 |
中文名 |
型別 |
含義 |
|
shop_id |
商店標識 |
varchar2(30) |
商店唯一標識 |
|
shop_name |
商店名稱 |
varchar2(50) |
商店展示名稱 |
|
shop_desc |
商店描述 |
varchar2(200) |
商店描述 |
|
fav_info |
促銷資訊 |
varchar2(500) |
商店促銷資訊 |
|
pro_num |
物品數量 |
varchar2(10) |
商店物品型別總數 |
|
address |
地址 |
varchar2(100) |
商店地址 |
商品資訊邏輯儲存模型如表4-4所示：
表4-4 商品資訊表
|
欄位 |
中文名 |
型別 |
含義 |
|
product_id |
商品標識 |
varchar2(30) |
物品唯一標識 |
|
shop_id |
商店標識 |
varchar2(30) |
商店唯一標識 |
|
pro_name |
商品名稱 |
varcahr2(50) |
商品展示名稱 |
|
pro_price |
價格 |
varcahr2(10) |
商品價格 |
|
pro_favl |
促銷價格 |
varcahr2(10) |
商品促銷價格 |
|
pro_num |
庫存量 |
varcahr2(10) |
商品剩餘量 |
|
pro_limit |
限購數量 |
varcahr2(10) |
商品限購數量 |
|
type |
分類 |
varcahr2(10) |
商品型別 |
|
pro_sale |
銷量 |
varcahr2(10) |
總銷量 |
|
pro_image1 |
圖片1 |
varchar2(100) |
展示圖片 |
|
pro_image2 |
圖片2 |
varchar2(100) |
展示圖片 |
|
pro_image3 |
圖片3 |
varchar2(100) |
展示圖片 |
|
pro_image4 |
圖片4 |
varchar2(100) |
展示圖片 |
|
pro_image5 |
圖片5 |
varchar2(100) |
展示圖片 |
|
promotion |
促銷 |
varchar2(200) |
商品促銷資訊 |
|
color |
顏色 |
varchar2(100) |
商品顏色 |
|
size |
尺寸 |
varchar2(100) |
商品尺寸 |
|
pro_desc |
商品描述 |
varchar2(100) |
商品描述 |
|
is_new |
是否新品 |
varchar2(10) |
標識物品是否新品 |
|
extra_mon |
運費 |
varchar2(10) |
是否有運費 |
|
detail_url |
詳情 |
varchar2(100) |
詳情url |
|
is_fee |
是否免費 |
varchar2(10) |
標識物品是否免費試用 |
購物車資訊邏輯儲存模型如表4-5所示：
表4-5 商品資訊表
|
欄位 |
中文名 |
型別 |
含義 |
|
user_id |
使用者賬號 |
varchar2(30) |
唯一標識使用者 |
|
product_id |
商品標識 |
varchar2(30) |
物品唯一標識 |
|
shop_name |
商店名稱 |
varchar2(50) |
商店展示名稱 |
|
pro_attr |
屬性 |
varchar2(100) |
已選擇商品屬性 |
|
pro_price |
價格 |
varchar2(10) |
商品促銷價格 |
|
pro_num |
數量 |
varchar2(10) |
購買數量 |
|
pro_name |
商品名稱 |
varchar2(50) |
商品展示名稱 |
|
extra_mon |
運費 |
varchar2(10) |
額外費用 |
|
add_date |
時間 |
varchar2(50) |
新增時間 |
訂單資訊表儲存邏輯模型如表4-6所示：
表4-6 訂單表
|
欄位 |
中文名 |
型別 |
含義 |
|
order_id |
訂單標識 |
varchar2(30) |
唯一標識訂單 |
|
user_id |
使用者賬號 |
varchar2(30) |
唯一標識使用者 |
|
all_mon |
訂單總費用 |
varchar2(20) |
訂單總費用 |
|
date |
訂單時間 |
varchar2(30) |
訂單時間 |
|
phone |
電話號 |
varchar2(20) |
電話號 |
|
user_name |
收件人 |
varchar2(30) |
收件人 |
|
pay_info |
支付資訊 |
varchar2(30) |
支付資訊 |
|
address |
地址 |
varchar2(100) |
地址 |
|
extra |
運費 |
varchar2(20) |
額外費用 |
|
shop_id |
商店標識 |
varchar2(30) |
商店唯一標識 |
|
state |
訂單狀態 |
varchar2(10) |
訂單狀態 |
訂單擴充套件表邏輯儲存模型如表4-7所示：
表4-7 訂單擴充套件表
|
欄位 |
中文名 |
型別 |
含義 |
|
order_id |
訂單標識 |
varchar2(30) |
唯一標識訂單 |
|
product_id |
商品標識 |
varchar2(30) |
物品唯一標識 |
|
shop_id |
商店標識 |
varchar2(30) |
商店唯一標識 |
|
pro_attr |
屬性 |
varchar2(10) |
已選擇商品屬性 |
|
pro_price |
價格 |
varchar2(10) |
商品促銷價格 |
|
pro_num |
數量 |
varchar2(10) |
購買數量 |
|
pro_name |
商品名稱 |
varcahr2(50) |
商品展示名稱 |
|
pro_image |
圖片1 |
varchar2(100) |
展示圖片 |
|
extra_mon |
運費 |
varchar2(10) |
額外費用 |
收件人資訊表邏輯儲存模型如表4-8所示：
表4-8 收件人資訊表
|
欄位 |
中文名 |
型別 |
含義 |
|
user_id |
使用者賬號 |
varchar2(30) |
唯一標識使用者 |
|
phone |
電話號 |
varchar2(20) |
電話號 |
|
user_name |
收件人 |
varchar2(30) |
收件人 |
|
address |
地址 |
varchar2(100) |
地址 |
|
addres_id |
地址編號 |
varchar2(30) |
唯一標識 |
|
state |
地址狀態 |
varchar2(10) |
啟用地址標識 |
分類維表如表4-9所示：
表4-9 分類維表
|
欄位 |
中文名 |
型別 |
含義 |
|
type_id |
分類標識 |
varchar2(10) |
分類的唯一標識 |
|
type |
型別 |
varchar2(50) |
分類 |
訂單狀態維表如表4-10所示：
表4-10 訂單狀態維表
|
欄位 |
中文名 |
型別 |
含義 |
|
state_id |
狀態標識 |
varchar2(10) |
狀態的唯一標識 |
|
state |
狀態 |
varchar2(20) |
狀態 |
物品狀態維表如表4-11所示：
表4-11 商品狀態維表
|
欄位 |
中文名 |
型別 |
含義 |
|
dim_id |
維表id |
varchar2(10) |
唯一標識維表資訊 |
|
is_new |
是否新品 |
varchar2(20) |
標識物品是否新品 |
|
is_fee |
是否免費 |
varchar2(20) |
是否免費標識 |
|
share_foot |
分享或足跡 |
varchar2(20) |
是分享或者足跡 |
4.4 伺服器架構設計
系統伺服器採用三層架構的模式編寫程式碼，將業務處理的邏輯程式碼全部放在Service層，這樣能更好的維護程式碼，也能調高程式碼的可讀性，如圖4-12所示：
圖4-12 系統架構圖
伺服器一般有三種模式BIO、NIO和AIO。而我的伺服器為了支援高併發的訪問，系統採用BIO的設計模式實現系統的併發訪問。 BIO就是單詞Blocking IO的簡寫,即就是採用執行緒阻塞的方式實現多併發的訪問，即就是一個每一個使用者連結使用系統資源時都需要單獨開闢一個執行緒來進行處理使用者請求。NIO就是單詞Nonblocking IO的簡寫,NIO是基於事件驅動的思想為理念的一種新的伺服器端支援高併發的設計模式，該模式主要利用的是Reactor設計模式[18]。相對與BIO的模式,NIO的模式一個明顯好處就是不需要為每一個使用者的連結和請求分配單獨的執行緒，而是可以在伺服器中一個執行緒內處理多個不同使用者的連線和請求資訊等相關任務。AIO是單詞Asynchronous IO的簡寫,就是非同步的IO模式，也是伺服器採用較多的高併發設計模式 [19]。
相對於BIO，現在伺服器端更多使用的是NIO的模式，因為考慮到機器的發熱與處理速度，以及手機穩定執行能夠承受的最大執行緒數。NIO在高併發的方面做得更好，避免了這些瓶頸。BIO是針對每一個使用者開一個執行緒，去分別處理使用者請求，每一個使用者單獨使用每一個處理請求的方法。這樣的方法簡單，不容易造成錯誤資料處理，具體模式圖4-13所示：
圖4-13 中介軟體圖
NIO雖然能較好支援高併發，但是相對於技術要求會很高，要控制資料的真確性，確保響應的真正確性。
伺服器端使用Mybatis作為資料庫操作框架，它是底層利用了JDBC原理來操作關係型的資料庫，利用XML封裝SQL語句的資料庫操作框架。Mybatis封裝了JDBC後，開發人員只需要通過編寫相應的xml配置檔案就你能很快的連線、操作資料庫，通過編寫SQL和Java Bean就能查詢出想要的結果物件，這樣大大的減少了非業務的程式碼，開發者只需面向業務而無需管理具體該怎麼做，很適合快速開發，而且能改善APP程式碼維護性、閱讀性，有利於軟體功能的可擴充套件性和軟體原始碼可讀性，當需求變化時開發者只需修改Bean和XML配置檔案。
服務端還採用DAO,SERVICE的三層架構模式，將處理業務的邏輯程式碼全部都寫在Service層，這樣當業務變化時，無需重構整個專案，只需要修改、重構Service層。這種設計模式很好的將業務、資料庫和前臺UI分離，之間通過模型傳遞資料，只要模型不變，系統維護就能花很少的人力。在開發中，我們提倡儘量將每個模組都分開，因此我也是這麼做的。DAO層因為資料庫連線時執行緒安全的，而資料庫操作上執行緒不安全的，因此我通過單例設計模式獲取資料庫連線，這樣充分利用了伺服器資料庫連線，有效的防止了APP記憶體洩露[20]。
4.5 客戶端設計
客戶端採用Retrofit2+Okhttp+ButterKnife+MVC的模式設計並實現，主要分為三層：網路層，業務層，UI層。
4.7.1 網路層
移動端用Retrofit2+Okhttp網路框架利用GET請求從伺服器獲取Json資料，APP利用POST網路請求給伺服器提交資料。
Retrofit2是基於Rxjava的非同步網路請求框架，預設使用Okhttp網路框架進行網路請求，是Android平臺使用很多的網路請求方式。非同步請求網路有助於改善使用者體驗，減少使用者等待的時間，防止了介面卡死。相對於同步網路請求來說，非同步執行耗時的操作不需要等待伺服器響應，而是等伺服器響應後會通知UI執行緒，即就是說，當用戶請求網路獲取資料時，還可以點選UI上其他功能按鈕。
其次，Retrofit2配合Google的Json轉化物件框架Gson,能很方便的將從伺服器獲得的字串轉換中Java Bean物件，減少了很多繁瑣的程式碼，是開發人員能儘量面向業務開發，提高了開發效率。
4.7.2 業務層
業務層主要負責，生成訂單資料並提交給伺服器。
為了改善使用者體驗，移動端使用了三級快取的設計，很好的為使用者節約了流量、改善了資料的載入速度。
記憶體快取：即就是當網路請求成功後，先把獲得的Json資料寫入記憶體，把圖片資料處理後再寫入記憶體，為了防止記憶體溢位，記憶體快取設定為每個APP分配記憶體的八分之一。記憶體快取使用的是LruCacHe,這個類裡面定義了一個MAP集合，可以通過鍵值對來儲存資料，並且他能夠根據最近最少使用的演算法進行排序，將用到最少的資料移除。這樣既保證了資料能很快的展示到UI上，也防止了記憶體溢位，明顯提升了使用者對APP的使用體驗。
本地快取：本地快取就是當第一次網路請求成功後，將獲得的Json資料利用SharePerference儲存到檔案，將獲得的圖片資源寫入本地SD卡的快取目錄，用URL的MD5值作為檔名儲存成png格式圖片。當第二次進入之後系統會先讀取本地資料，這樣為使用者不僅節約了流量，而且提高了載入速度。如果沒網APP也能顯示快取資料，這樣使用者就不用面對預設圖片，也無需等待伺服器響應。
網路快取：即就是當記憶體和本地都沒有相關資料時，才從伺服器獲取資料，眾所周知，從伺服器獲取資料時比較慢的。所以大多數的APP一般都會用三級快取來改善使用者體驗。
App採用Fragment搭建UI框架，採用工廠模式生成對應的子頁面，從外至內，逐層巢狀。每個頁面都要載入佈局、初始化資料和請求網路，所以我向上抽取BasePager,然後讓每個頁面繼承BasePager並實現父類的方法，這是一款典型利用多型搭建的框架。
工廠設計模式，是一種建立型設計模式，只需定義一個用於建立物件的介面，讓子類決定例項化那個類。在任何一中複雜的物理模型中需要複雜物件，都可以用工廠設計模式進行設計開發。
APP使用自定義View,實現了圓形ImageView,通過自定義對話方塊，實現了不規則更新提醒對話方塊。由於專案多處用到ListView，因此我自己封裝了介面卡，通過封裝旨在減少程式碼書寫，增強了APP程式碼的可閱讀性和後期二次開發、擴充套件的可維護性。通過抽取，只需要載入佈局和繫結資料，其他都交給父類去做。
專案程式碼也做了優化，很少使用內部類巢狀，並且使用了第三方優秀框架，使得程式碼清晰易懂，模組清晰，容易維護。佈局中多處使用<incloud>和<merge>標籤，使得佈局巢狀不超過三層，使應用UI載入速度更快。使用單例模式，執行緒池訪問網路，有效的防止了記憶體洩露，對圖片進行處理，降低了記憶體溢位的風險，使記憶體也更加優化[21-22]。
5系統實現
5.1 開發環境搭建
任何軟體要執行、開發，都要有它的基本環境。Android開發也有它的環境才能夠開發，有了開發環境才能很快很好的開發軟體。因此需要安裝開發工具和支撐平臺。
搭建開發環境需要的軟體：
（1）作業系統：Windows 10
（2）軟體包：Android SDK(Software Development kit Java Development kit) 、AndroidStudio、Eclipse
（3）IDE環境：Androidstudio 2.3 + Android SDK5.0+Eclipse以上
（4）JDK：JavaRuntime Environment 1.8虛擬機器 、(JDK)Java Developmentkit 1.8
5.2 APP模組實現
最終移動購物APP主要實現了註冊，登入，搜尋商品，購物車，線上提交訂單，檢視所有訂單，系統註冊，地址管理，物品分享，檢視瀏覽記錄，檢視分享等功能，下面將詳細介紹。
5.2.1 系統註冊模組
註冊頁面如圖5-1 所示：由三個EditText和一個註冊按鈕(Button)組成。EditText負責獲取使用者要登陸賬號和登陸密碼，當用戶輸完資訊後點擊註冊按鈕後，APP將會獲取EditText輸入的內容，判斷是否為空後，將資料利用post請求將註冊資訊傳送倒伺服器端，伺服器判斷使用者不存在，並且成功插入資料庫後通知客戶端註冊成功。
圖5-1 註冊UI圖
5.2.2 系統登陸模組
登陸介面如圖5-2所示：由二個EditText、一個CheckBox和一個註冊按鈕(Button)組成。EditText用於輸入賬號和密碼，CheckBox用於顯示密碼，預設情況下密碼用星號(*)顯示，當選中後將正常顯示密碼。按鈕點選後將把獲得的密碼採用DES加密後提交到伺服器，伺服器通過賬號獲得對應密碼，將獲得加密後的密碼與客戶端提交資料進行驗證，最後將結果返回給客戶端，如果是成功切換UI，如果密碼錯誤就彈Toast提示使用者密碼錯誤，讓使用者重新輸入密碼。
圖5-2 登陸UI圖
5.2.3 物品搜尋模組
物品搜尋是首頁和分類頁面的一個快速查詢功能，使用者可以通過該功能查詢自己想要的物品。如圖5-3所示，當用戶在輸入框中輸入關鍵詞，點選搜尋按鈕，APP會通過網路將使用者的查詢關鍵詞傳送到伺服器，然後獲得相關物品，使用者可以把獲得的物品按照銷售數量，物品價格進行排序，實現快速查詢物品的作用。該頁面會展示商品的基本資料，包括：商品名字，商品促銷價格和原價等資訊。除此之外，APP會記錄使用者搜尋的關鍵詞，當用戶第二次搜尋時，展示給使用者，幫助使用者快速輸入。該頁面還集成了訊飛語音輸入，可以把使用者語音快速識別成搜尋關鍵字並輸入搜尋框，幫助使用者搜尋。
圖5-3 搜尋UI圖
5.2.4 購物車模組
購物車是儲存使用者想要購買但沒有下單的商品的展示功能，使用者可以把自己喜歡的、想購買的商品加入購物車，當想要購買時直接從購物車下單，不僅速度快，而且省去了搜尋，瀏覽等繁瑣的步驟，使用者可以在商品詳情頁面加入購物車，也可以在購物車介面進行編輯。購物車可以根據物品的商店進行分組展示，從購物車也可以跳轉到詳情頁面。購物車採用了觀察者模式，通過觀察者模式實現了物品選中和選中金額變化。購物車是本專案的核心，也是移動購物平臺中最難的UI，為了實現容器連動，採用了多個觀察者。但是使用者要使用購物車必須先登入，如圖5-4所示：
圖5-4 購物車UI圖
核心觀察者程式碼實現如下：
|
public class
ItemObserver { |