第一个IOS APP总结

一直想做几个IOS的游戏或者应用,一拖再拖,在IOS APP领域我是新人,所以保持敬畏,从小做起最重要。我特别懒,周围的人也特别懒,所有东西都想自动化,每天只打几行命令是最好。
第一个IOS APP总结

做什么倒是没考虑多久,我自己都有大把的需求,首先是我喜欢听有声书,最近又闹书荒,喜马拉雅,懒人听书,企鹅听书这些上面的免费精品都听得差不多了,更新又慢,又不想看文字,干脆做一个直接读文本的APP好了,主要功能也理了一下,首先是要更新即时,其次是要能连续逐章播放,还要能断点续播,书签历史也不能少,就这么几个功能,只做核心功能,不搞UI,最终经过两个多星期的开发调试除错第一个版本完成了。就算五个星期吧,因为apple开发者年费需要双币信用卡,开头说了我第一次开发IOS APP只有重新申请,坑来了,我有单币的,全币的信用卡,就是没有双币的,所以又申请了一张,快递需要几天时间,我做项目时间计划的原则是预估时间乘以2,这个参数救过我好几次命。

我没有做什么文档,直接第一步就是开发核心功能,文本语音合成,俗称TTS吧,我最先试用了百度的语音合成,其次是讯飞,最后是IOS自带的,效果是讯飞最好,百度也很好而且免费,最差的是IOS自带的语音合成,最终经过激烈的思想斗争,我选择了IOS自带的语音合成,主要原因是懒,不想看第三方文档。随着语音合成接口的调试正常整个APP的核心功能完成,信心有所提升,剩下的无非就是些服务端爬虫,数据库查询,APP端界面业务逻辑等等等等等等。。。

下来我考虑的是数据源,我只是一个数据的搬运工,爬虫必不可少,选定了2个小说站,第一个站有三千多本小说,一百七十万篇正文,服务器是阿里云香港,系统是centos+nginx,居然和我自己做VPN的一样。。。看来我低估了阿里云服务器的实力。第二个站有接近四千本小说,七十几万篇正文,刚开始我也不明白为什么一个站小说多,正文却少这么多,后来发现是新书多,这台服务器在洛杉矶,系统是windows+iis7.5,居然和我上一台VPN一样,看来我有必要重新考虑一下VPN机房。。。用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界面背景,过程就是这样。

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

还是上传几张模拟器的预览图吧,希望有缘再见!
第一个IOS APP总结
第一个IOS APP总结
第一个IOS APP总结
第一个IOS APP总结
第一个IOS APP总结

猜你喜欢

转载自blog.51cto.com/1557154/2110711