第一個IOS APP總結

一直想做幾個IOS的游戲或者應用，一拖再拖，在IOS APP領域我是新人，所以保持敬畏，從小做起最重要。我特別懶，周圍的人也特別懶，所有東西都想自動化，每天只打幾行命令是最好。

做什么倒是沒考慮多久，我自己都有大把的需求，首先是我喜歡聽有聲書，最近又鬧書荒，喜馬拉雅，懶人聽書，企鵝聽書這些上面的免費精品都聽得差不多了，更新又慢，又不想看文字，干脆做一個直接讀文本的APP好了，主要功能也理了一下，首先是要更新即時，其次是要能連續逐章播放，還要能斷點續播，書簽歷史也不能少，就這么幾個功能，只做核心功能，不搞UI，最終經過兩個多星期的開發調試除錯第一個版本完成了。就算五個星期吧，因為apple開發者年費需要雙幣信用卡，開頭說了我第一次開發IOS APP只有重新申請，坑來了，我有單幣的，全幣的信用卡，就是沒有雙幣的，所以又申請了一張，快遞需要幾天時間，我做項目時間計劃的原則是預估時間乘以2，這個參數救過我好幾次命。

我沒有做什么文檔，直接第一步就是開發核心功能，文本語音合成，俗稱TTS吧，我最先試用了百度的語音合成，其次是訊飛，最后是IOS自帶的，效果是訊飛最好，百度也很好而且免費，最差的是IOS自帶的語音合成，最終經過激烈的思想斗爭，我選擇了IOS自帶的語音合成，主要原因是懶，不想看第三方文檔。隨著語音合成接口的調試正常整個APP的核心功能完成，信心有所提升，剩下的無非就是些服務端爬蟲，數據庫查詢，APP端界面業務邏輯等等等等等等。。。

下來我考慮的是數據源，我只是一個數據的搬運工，爬蟲必不可少，選定了2個小說站，第一個站有三千多本小說，一百七十萬篇正文，服務器是阿里云香港，系統是centos+nginx,居然和我自己做×××的一樣。。。看來我低估了阿里云服務器的實力。第二個站有接近四千本小說，七十幾萬篇正文，剛開始我也不明白為什么一個站小說多，正文卻少這么多，后來發現是新書多，這臺服務器在洛杉磯，系統是windows+iis7.5,居然和我上一臺×××一樣，看來我有必要重新考慮一下×××機房。。。用python scrapy簡單測試了幾個小時阿里云的服務器連續抓取會503或者404，洛杉磯的服務器慢一點但是特別穩定全部200，和我想的完全相反，最后阿里云的服務器居然沒有響應了(過了半天才恢復)；最后我選擇了穩定的洛杉磯，這臺服務器有簡單的防盜鏈，修改一下User-Agent和Referer就可以了，計算了一下速度，每天可以抓七萬到八萬篇正文，差不多要十一，二天才能全部抓完，好在APP開發只需要測試數據就可以，讓爬蟲繼續抓吧。這里有個插曲，最終我沒用scrapy，自己用asyncio+aiohttp+BeautifulSoup(lxml)寫了一個專用爬蟲，因為只需要小說基本信息，章節列表和正文，沒費多少時間。

數據庫用的mongodb，由于asyncio并發很快直接在協程里面執行阻塞調用整個系統幾乎僵死，這里犯了錯誤，解決方案是專門開啟一個消費者線程來處理保存數據庫的操作，asyncio抓到數據就扔到線程數據隊列。由于網絡數據獲取時間肯定比本地保存數據到硬盤時間長，所以用消費者模式來處理阻塞操作是合理的，實際上也是如此。

服務器端API我設計了四個：查詢小說分類（比如玄幻，科幻），查詢小說分類列表（比如圣墟，凡人修真傳），查詢單部小說章節列表（比如第一章。。。，第二章。。。）和查詢正文

考慮了最終服務端生產環境，我最想用的是tcp socket，安全性，性能都很好，不好的是對于這個應用沒有明文顯然調試起來不夠方便，django都大了，后來干脆直接aiohttp，增加了一個連接認證API，就是生成一串數字在服務端和客戶端進行對稱加密，比明文好一點，算法自己寫的用了乘法和加減法，懂的自然懂，但是如果來抓我的庫總要費點時間，何必呢？還不如去抓其他沒加密的，安全性剛剛好。

APP端是同步開發的，大部分的坑都是swift不熟悉又沒有oc背景造成的，好在我直接跳過了swift1,2,3，直接用的4，對于不兼容的語法問題我躲過了，最后花了兩個小時做了各種大小的圖標和一個launch界面背景，過程就是這樣。

信用卡沒到，我就不能提交，因為沒有提交的經驗，所以遇坑是必然的，但是我預留了二個星期的時間應該足夠，畢竟是個如此簡單的免費應用，上帝保佑順利通過。

還是上傳幾張模擬器的預覽圖吧，希望有緣再見！