在五月份,我花了大概三个星期的时间做了一款简单的iOS应用。现在将整个开发过程分享给大家,希望对在入门开发应用的同学有些帮助。
需求分析
在这里是站着技术人员角度去做需求分析,比专业产品需求分析是要简单很多的。我需要做的是一款日记应用,触发动机是我找不到我想要的日记应用。我用过很多工具来写日记。比如有有道云笔记,印象笔记,QQ邮箱的记事本,Day One等,也体验过其它用户比较多的日记应用,依然满足不了我的需求。
从自身需求出发去做应用,这对于大众产品设计来说,是非常不适合的,不过我要做的就是一款给我这样需求的用户的小众应用,所以首先满足我的需求,也不为过,至少做出来自己用的好呀。
我自身是有写日记的习惯的,我的需求是这样的
1.要快,打开应用可以马上记录发生的事情
2.时间线,我需要记录一天发生的多次事件
3.需要记录图片,图片方便裁剪
4.隐私安全,这点特别重要,我不希望数据保存在别人的服务器上面
5.数据安全,数据可以以通用格式导出,方便打印成册,毕竟对于日记是要存在几十年的,而很多互联网公司熬不过5年,特别是多数的移动互联网公司两年就死掉了。
6.按日历查找数据
对于隐私安全和数据安全,这两个是特别重要的,这不仅是我自己的要求,参考了多个应用的App Store的评论,和知乎上面关于日记的讨论得出来的,所以这两个是最重要的。
另外出于收益考虑,对于一些功能需要购买开通使用,也是重要需求。
技术评估
针对上面的需求,探求实现的可能性和初步的技术方案。大部分的需求的实现都是比较简单,特别需要处理的是隐私安全和数据安全这两个需求。
隐私安全
数据不能保存到应用服务器,防止别人服务器被hack是一个原因,最重要的是防止数据被开发者利用(当然也是在说我自己),毕竟日记数据是非常隐私的。所以多方面考虑下,数据保存到苹果的iCloud是较好的做法。数据放在大厂上面,对短期数据保存是比较放心的,安全度较高,苹果也是一家把用户隐私放在首位不惜和FBI怼上的这么一个公司,数据放在iCloud上面,也避免了应用提供商存储用户数据导致数据被非法利用的问题。
数据安全
数据保存到iCloud是相对安全的了,但是依然不够,数据能够导出交给自己才是最放心的。对于导出的数据格式选择是一个难题,目前包含文本和图片的富文本格式方案不多。如下列表
RTF 也称富文本格式(Rich Text Format, 一般简称为RTF)。虽然表面上说是非常流行的文档格式,但国内就没怎么见人用过,国外情况不知晓,也就不考虑了。
Doc/Docx 这个是微软Word文档格式,是通用的格式,是富文本方案比较好的选择。不过要导出这个格式不容易,Word文档格式极为复杂,iOS下面没有好的库可以用,自己实现比较繁琐,因此方案待定
PDF Portable Document Format的简称,意为“便携式文档格式”。这也是一个比较流行的文档格式,格式也比较复杂,不过苹果内置PDF生成接口,因此比Word文件更为可行
MarkDown 这是一种纯文本格式,不过可以引用外部图片路径,所以也可以作为导出的格式选项。不过MarkDown的排版单一,对于需要打印成册这个需求不友好,也作为待定考虑
综合多个格式,目前优先先去PDF这个格式。
原型设计
将需求落实到原型上面。原型设计是很重要的一步,在这一步需要多花点时间,好的原型可以加快后面所有的步骤。另外按照多年的经验,也不可能设计出周全不需要后续修改的原型,因此后续稍作优化也是必然的事情。原型工具我使用的是MockPlus,它内置了很多基本控件,通过简单拖拉就可以完成了设计,非常方便。如下图是其中一个原型
UI设计
UI设计这个环节是大多程序员的痛,如果资金充足,或者项目比较重要,找一个UI设计师来设计,是强烈推荐的,千万不要干自己吃力不讨好的事情。在大多数领域里面,颜值都是关键的一个环节。由于我的项目,功能简单,第一个版本先自己完成设计。
我使用的设计工具是Sketch,比起PS,这个工具更廉价,并且对于移动UI设计,它更简单,高效。
设计对于程序员来讲,真的是很难的,如果没有一定的研究,那就需要找一些相关书籍来补充一些基本知识,这对于以后和设计进行良好的沟通也打下坚实的基础。我觉得《写给大家看的设计书》的设计书值得看,里面会教会大家基本的配色,对齐,字体等,这些内容非常重要,它会使的之前一团糟(当然如果自身没有基本的美学概念,也不觉得一团糟)的设计,变得基本美观。
在有了基本的设计指导之后,想要设计出像样一点的东西,也是很难的,这时候就要参考大量主流的UI设计案例,它们会增强你对潮流的感知能力,也会给你带来一些灵感。我常去的网站有:
http://dribbble.com 这里有非常多优秀的设计案例
http://collectui.com 这是一个专门收集UI设计的网站,包含了大量移动端设计的案例,而且是每日更新,强烈推荐
http://huaban.com 这是国内著名的花瓣网站,里面也收集很多案例,特别适合国情。虽然很过国外的设计看起来很漂亮,但是不符合国内审美的,国内大众喜欢界面热闹一点,国外的喜欢设计简洁一点。
另外UI设计过程中需要很多设计资源,特别是图标资源。图标资源我找到了一个比较好的网站http://www.iconfont.cn 。这是阿里巴巴的阿里妈妈UED出品的一个图标资源网站,非常好用。
需要特别声明的一点是,国内的版权意识慢慢好了起来,因此使用第三方网站素材的时候,要注意版权问题。
在UI设计的时候碰到一个难点就是数据导出PDF的一个板式的问题。板式设计在平面设计系统中是非常重要的一项。为了习得板式的一些皮毛,立马购买了两本和板式设计有关的数据,分别是
书是挺不错的,但是也不可能一看书就能获得真髓,只是辅助一下不至于设计跑偏那么厉害。
代码实现
来到了自己流程最在行的一个环节了。由于这不是一篇侧重技术的文章,所以不再这里阐述过多的技术问题,主要是把开发的重要环节拿出来分享一下。
建立代码仓库
我使用的是https://coding.net 的Git仓库,觉得还不错,不用Github主要是因为在国内它慢。我是偏向工具流,而不是命令流,我用的Git客户端工具是SourceTree,免费好用。
建立工程
工程文件组织结构贴下
Pod用到的库如下
pod 'Aspects' pod 'AVOSCloud', '~> 3.10' pod 'LeanCloudSocial', '1.0.0-beta3' pod 'AFNetworking', '~> 3.0' pod 'Bugly' pod 'SDWebImage', '~> 4.0' pod 'ReactiveCocoa', '~> 2.5' pod 'DateTools' pod 'NYXImagesKit' pod 'M13OrderedDictionary' pod 'Mantle' pod 'MBProgressHUD' pod 'CocoaLumberjack' pod 'EAIntroView' pod 'Realm' pod 'FSCalendar' pod 'TOCropViewController' pod 'NYTPhotoViewer'
项目的后端是使用LeanCloud的服务,服务接口是运行在LeanCloud的云引擎上面的,我使用的是Node.js版本的云引擎。我觉得云引擎是很好的一个东西,它让我只关注我的业务实现,我只需要写一些业务代码就行了。我本地存储使用的是Realm,为啥选择它?因为对我来讲,它是目前使用最简单的。
技术难点
这个项目虽然功能简单,但也是有些难点的。
iCloud备份
之前的iOS开发中并没有使用过iCloud,所以对iCloud基本不了解。如何快速学习一个新的技能,这本身就是一个非常重要的技能。我是这么办的,首先搜索iCloud相关的教程,有一个基本了解,然后搜索iCloud相关的坑(多年经验告诉我,谁家的技术都是充满了坑的,知道他好,更好知道他的丑),最后查看官方详细文档,全面了解他的细节。
数据备份到iCloud和iCloud数据同步到应用流程还是略微复杂的,面对流程复杂的问题,请记得一定要作图。要知道其实人脑是非常不善于处理这些逻辑复杂的问题的,所以只能借助工具帮助我们完成复杂的问题。我使用的是 https://www.processon.com 的在线作图。在这里我特别提一下,客户端大部分的流程都是和用户操作混在一起的,所以我作图使用的是一种事件驱动方式作图,只包含事件和处理两种元素,非常简单易懂。下面是iCloud备份环节的一小块流程图截图
方框的是处理,箭头代表事件。其中看到的有布尔事件,用户操作事件等。如果有更好的图示方式,请告诉我。
导出PDF
iOS有接口生成PDF,这个是降低了导出PDF的难度。现在面临的问题就是,如何按照板式灵活排版。我采用的一个方法是,建立板块和板式管理器。板块负责他的内容绘制,决定他的字体,颜色,板块内布局,板式管理器负责板块布局,文档分页等。这样将日记数据传入板式管理器,就可以自行生成PDF了。
测试
很多程序员不喜欢测试,但是这个一个极坏的做法。自己的程序必须全面自测,这可以加快整个项目的进度,也可以建立测试部对开发部的信心,和个人威信。把功能做出来没啥了不起的,关键指标是可用性和性能问题。
对于我的应用,一般采用如下测试流程
功能测试
自己使用几天,使用所有的功能,你会发现各种各样的问题,一边修复一边测试。特别有个现象要说明一下,bug最喜欢出现在上线第一天,如果不想经常干紧急修复这样自己都不好意思的事情,请认真对待测试。
性能测试
在用了几天没啥问题后,需要进入性能测试。粗略评估用户每个月产生的数据15M左右,对此我进行了如下测试
测试超过1G的数据,在不同的设备上面测试iCloud的写入和读取性能
单日1000条事件测试,查看UI显示性能
多月多年数据测试,测试数据读取和显示是否正常
小规模内测
发布到fir.im,要求亲朋好友使用,获取反馈。这个很重要,通常有些bug不会在自己这里产生,但是一到别人手里,马上就暴露,这是因为每个人的使用习惯不一样,因此少量用户内测也是比较有必要的。
发布
发布这里问题不大。主要是iTunes Connect的宣传图麻烦一点,不过我找到一个可以制作漂亮宣传图的网站 https://theapplaunchpad.com 。缺点是国外的网站付费都比较贵,算了一下自己制作的成本后,咬咬牙购买了他们的Pro功能。
总结
应用已经在几天前上线。自己开发完整的一个app实属不容易,更不容易的现在app市场趋于饱和了。几年前移动互联网市场还是无限畅想的,现在发现不是这样的,你会发现手机上面的软件就是那么几个,都是大厂垄断了,现在app store上面分类下面的app连新品展示的地方都不给了。那些想去做独立开发者的同学,如果你不能做出令苹果眼前一亮的产品,那么在app store上面是等于扔进了垃圾堆。现在做app要解决的都是啥问题?推广和运营!现在app用户获取成本高的直接让你亏损。为啥?因为现在用户都是别人的,如同人家老婆,要去撩人家老婆,那可是很大代价的哦。