我是如何从0开始开发一款应用的

在五月份，我花了大概三个星期的时间做了一款简单的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用户获取成本高的直接让你亏损。为啥？因为现在用户都是别人的，如同人家老婆，要去撩人家老婆，那可是很大代价的哦。