第一个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界面背景，过程就是这样。

信用卡没到，我就不能提交，因为没有提交的经验，所以遇坑是必然的，但是我预留了二个星期的时间应该足够，毕竟是个如此简单的免费应用，上帝保佑顺利通过。

还是上传几张模拟器的预览图吧，希望有缘再见！