原文：https://www.jianshu.com/p/4ef3d3737661?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

　　作者：故胤道長

　　在 iOS 開發(fā)中，寫一個 App 很容易，但是要寫好一個 App，確是要下另一番功夫。首先，我們來看一個 App 的開發(fā)要求：

　　寫一個 App，顯示出 Spotify 上 Lady Gaga 相關(guān)的所有音樂專輯，相關(guān)信息可以通過以下網(wǎng)址查到：

　　https://api.spotify.com/v1/search?q=lady+gaga&type=album

需求分析

　　首先拿到開發(fā)要求，最重要的是明確開發(fā)細(xì)節(jié)。這里面有很多我們不清楚的地方需要與產(chǎn)品經(jīng)理和設(shè)計師交流：顯示是要用 TableView 還是 CollectionView？每個音樂專輯的哪些信息需要顯示？如果專輯數(shù)量過多，我們優(yōu)先顯示哪些專輯？這個 App 除了顯示信息以外，還需要哪些拓展功能？這個產(chǎn)品的大小是否有要求？需要多少天完成？

　　經(jīng)過討論之后，大家的一致意見是做個如下的 App:

　　LadyGaga

　　于是我們就清楚了，是要做一個 tableView，每個 Cell 對應(yīng)一個專輯信息，左邊是圖片，右邊是專輯名。點(diǎn)擊 Cell，可以看到相應(yīng)的專輯大圖。

　　構(gòu)建架構(gòu)

　　首先這個 App 比較簡單，我們只要用最基本的 MVC就可做好。

Model 部分：

　　只需要一個 Model， 為 Album，對應(yīng)每一個專輯的信息；

View 部分：

　　主體的部分可以在 Storyboard 里面完成；

　　最好單獨(dú)新建一個 UITableViewCell 的子類，用來對應(yīng)設(shè)置專輯的UI；

ViewController 部分：

　　其中一個 ViewController 為 TableViewController，負(fù)責(zé)現(xiàn)實(shí)所有專輯的信息；

　　另一個 ViewController 負(fù)責(zé)展示 detail info，比如專輯的大圖；

Network 部分：

　　負(fù)責(zé)從網(wǎng)絡(luò)上 fetch 專輯信息；以及根據(jù)專輯的圖片網(wǎng)址，fetch 圖片數(shù)據(jù)；

　　基本架構(gòu)

　　細(xì)節(jié)實(shí)現(xiàn)

Network 部分：

　　fetchAlbums 和 downloadImage 都用Apple 自帶的 URLSession 和 JSONserialization 就可以實(shí)現(xiàn)，或者也可以用優(yōu)秀的第三方庫 AlamoFire。因?yàn)檫@個 App 比較簡單，AlamoFire 優(yōu)勢不明顯，且引入第三方庫會增加 App 的體積，故而推薦使用前者?；旧暇褪菍?shí)現(xiàn)下面兩個函數(shù)：

　　funcfetchAlbums(with url: String, completion : @escaping (_ albums: [Album]?, _ error : NSError?) -> Void) funcdownloadImage(_ url: String) -> UIImage?

　　對于第一個函數(shù) fetchAlbums，因?yàn)榫W(wǎng)絡(luò)請求是耗時耗力的工作，我們一般會將它們用后臺線程而非主線程（UI線程）來處理，這樣可以保持UI的流暢運(yùn)行。用閉包則是為了異步多線程完成后可以回調(diào)，同時 error 是為了監(jiān)視網(wǎng)絡(luò)請求是否出錯。

　　對于第二個函數(shù) downloadImage，最簡單的方法是通過 url 拿到對應(yīng)的 data，然后通過相應(yīng)的 data 拿到 image。返回為 optional 的原因是有可能 URL 有問題或者網(wǎng)絡(luò)請求出錯，此時返回 nil。

　　從API設(shè)計的角度來說，以上的downloadImage并不是最佳設(shè)計。最佳的設(shè)計是我們能知道哪里出錯了，比如下面這樣：

　　enumDownloadImageError: Error{ caseInvalidURLcaseInvalidData}funcdownloadImage(_ url: String)throws -> UIImage { guardlet aUrl = URL(string: url) else { throwDownloadImageError.InvalidURL } do { let data = tryData(contentsOf: aUrl) iflet image = UIImage(data: data) { return image } else { throwDownloadImageError.InvalidData } } catch { throwDownloadImageError.InvalidURL } }

ViewController 部分：

　　對于 AlbumsController，我們用到了代理模式(Delegate)，即將 tableView 代理到了 AlbumsController 上。我們只要實(shí)現(xiàn)相應(yīng)的 dataSource 和 delegate 方法即可。其中對于 dataSource 而言，有兩個方法是必須實(shí)現(xiàn)的，它們是：

　　functableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> IntfunctableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell

　　同時，AlbumsController 里面，還有兩個數(shù)組，一個用來裝專輯（[Album]），一個用來裝圖片([UIImage?])，這樣我們只需下載數(shù)據(jù)一次，并將其存入相應(yīng)數(shù)組，之后就無需再次進(jìn)行相關(guān)的網(wǎng)絡(luò)請求了。也就是說，這兩個數(shù)組起到了緩存的作用。

　　具體的實(shí)現(xiàn)是：首先在 viewDidLoad() 中請求服務(wù)器取出相應(yīng)的數(shù)據(jù)。之后根據(jù)專輯數(shù)量設(shè)定 TableView 的相應(yīng)行數(shù)。在具體的一行當(dāng)中，我們可以根據(jù) indexPath 確定相應(yīng)的專輯。根據(jù)相應(yīng)專輯的圖片 URL ，我們可以拿到相應(yīng)的圖片，之后緩存進(jìn)圖片數(shù)組。由于我們復(fù)用了 TableView 的 Cell，所以如果不緩存圖片而每次去進(jìn)行網(wǎng)絡(luò)請求，會因?yàn)檠訒r很嚴(yán)重而會造成圖片閃爍的后果。

　　最后兩個 ViewController 之間的跳轉(zhuǎn)可以用 navigationController 來實(shí)現(xiàn)。

View 部分：

　　自定義 AlbumCell 可以保證 App 的擴(kuò)展性很好。同時，為了處理有些專輯名字過長 Label 顯示不了的問題，可以用autoshrink 來處理。

　　App 運(yùn)行流程

　　優(yōu)化拓展

　　上面的設(shè)計和實(shí)現(xiàn)比較理想化，現(xiàn)在我們要考慮一個邊界情況，假如網(wǎng)絡(luò)不穩(wěn)定，怎么辦？

　　一個簡單的解決方法就是，當(dāng)網(wǎng)絡(luò)好的時候把數(shù)據(jù)下載下來，存入 cache 和 storage 中，之后即使網(wǎng)絡(luò)中斷、App 崩潰，我們都能從 storage 中拿到相應(yīng)數(shù)據(jù)。

　　這里引入外觀模式（Facade），創(chuàng)建一個新的 class 名為 LibraryAPI，提供兩個接口：

　　funcgetAlbums(completion : @escaping (_ albums: [Album]?, _ error : NSError?) -> Void)funcgetImage(_ url: String) throws-> UIImage

　　這里的方法跟之前 Network 的不同之處在于：getAlbums 方法會先嘗試從 storage 中取出相應(yīng)數(shù)據(jù)，如果沒有，則去訪問 Network，之后再把從 Network 中拿到的值存入 storage 中。這里面的實(shí)現(xiàn)有點(diǎn)復(fù)雜，牽涉到兩大模塊和多線程操作，但是我們并不必關(guān)心方法內(nèi)部的實(shí)現(xiàn)，而僅僅關(guān)心接口，這就是外觀模式的優(yōu)點(diǎn)。同時，LibraryAPI 這個 class 最好用單例模式(singleton)，因?yàn)樗鼞?yīng)該被當(dāng)做是全局 API 被各個 ViewController 來訪問，同時這樣設(shè)計也節(jié)省資源。

　　優(yōu)化后的 App 流程

　　另外一個優(yōu)化點(diǎn)在于，假如我們一開始拿到很多數(shù)據(jù) —— 例如10000 個專輯，那么我們該怎么操作？

　　正確的做法是分頁。我們可以先只拿20個，顯示在 TableView 上。當(dāng)用戶快滑到底端的時候，我們可以再取下面20個，然后我們總共有40個在內(nèi)存中可以顯示，以此類推。這樣做的好處是，我們無需下載所有的數(shù)據(jù)，以最快、最流暢的方式布局 TableView，同時根據(jù)用戶的需求增加相應(yīng)的專輯數(shù)據(jù)。

　　最后一個優(yōu)化點(diǎn)在于，假如用戶上下滑動很快，我們?nèi)绾文軌蛴米羁焖俣燃虞d圖片？

　　答案是用 operationQueue 來處理，當(dāng)前 cell 是可見的時候，我們就 resume 下載圖片的進(jìn)程，否則就 suspend。這樣保證了我們用有限的內(nèi)存和 CPU 去最高效的下載用戶需要、當(dāng)前要見的圖片。

　　值得一提的是，大家還可以借鑒 ASDK 的思路來進(jìn)一步優(yōu)化程序。

　　總結(jié)

　　本文從一個簡單的 tableView App 說起，談?wù)摿碎_發(fā)一個 App 的4個步驟：需求分析、構(gòu)建架構(gòu)、細(xì)節(jié)實(shí)現(xiàn)、優(yōu)化拓展。簡單介紹了多線程和幾種設(shè)計模式，希望對大家有所幫助。