以下就是我13年大二暑假做的项目，第一个独自设计开发的Android应用－－CoY。
想起当年的生活也是挺苦的。那是广州最热的时候，每天待在宿舍里除了敲代码外就是做设计。还记得有一天晚上热得要命，开着风扇也睡不着，12点躺在床上浑身大汗，洗了个澡到了2点还是睡不着，4点再洗了个澡，6点被热醒后又洗了个澡后就起床干活了，那天我真的哭了，因为这生活真的太苦了，关键是自己逼自己。
这个应用的诞生是有一个挺可悲的故事的。曾经在校道上我碰见了一个非常清纯的妹子，每次都是单身一人和我在校道上擦肩而过（肯定没有擦肩orz但想不到其他词了），我一直在心里问这妹子这么漂亮肯定有男朋友吧，如果没有的话我就应该勇敢点搭讪…结果就这样过了一年多…就在我大二生日那天，我突然发现这妹子牵着一个男生的手…而且这男生比她还矮…好吧…这外貌…hehe…当时我就真的懵逼了，莫名的怒火涌上大脑，妈的早知道我就该早点搭讪了，估计也轮不到这兔崽子。就是因为不知道女神有没有男朋友，所以一直没敢向前，呵呵，我一定要解决这个问题。
苦思了一周后，结果我没有想着看看如何搭讪泡妞的书，却决定要做一个应用出来。嗯，之前买了好多关于Android的开发书，这个应用就用Java开发好了，查了下单词，暗恋英文叫Crush on You，缩写coy也有怕羞的意思，这英文铁定是以后APP的名字了。
到了5月份我开始看数据库优化和安卓开发的书籍，大一已经有做网站开发的经验，因此5月末的时候我已经用PHP和MVC架构把后台搭建的差不多了，包括建立了与客户端交互的接口以及如何各种调用数据库的命令。数据库是最重要的，一个产品的核心可以认为就是数据的结构和逻辑。这个应用的核心我认为有两个，连接和问答。
连接：
之前看过一部叫《六度人脉》的书，主要讲只要你通过6个人就能认识全世界的任何一个人；也有一本书叫《大连接》，主要讲美国60%的情侣都是在校园，工作地方等通过熟人介绍认识的，而且你和你未来老婆之间其实只隔了1-2个同学或朋友（意思是你的朋友的朋友或者你朋友的朋友的朋友可能就是你未来老婆）那么如果要知道女神有没有男朋友，肯定不是让她回答（她不好意思我也多不好意思…），而是让她的朋友告诉你，这么一来我的朋友或者我朋友的朋友就能告诉我女神有没有男朋友了，是不是感觉好简单？
那么我怎样才能把这些人聚集进我的APP里呢？我又怎么让这些人加现实中的朋友为应用里的好友呢？从0开始建立关系是非常不明智的，这时候我想到了微博和人人网，大学生基本都会有自己的微博和人人网，自己关注的人除了大号外就是自己的朋友，关注我的人除了朋友外就是对我感兴趣的人或僵尸粉，这么说相互关注的人八九不离十都是认识的朋友。微博的用户量比人人网多很多，而且微博的OAuth2.0技术已经很成熟了，还可以通过微博授权获取用户的相互关注列表，所以当时选择了微博为基础。
使用微博OAuth2.0还有一个好处是如果手机里有微博客户端，可以通过微博的sdk直接调用微博授权，可以免去用户在CoY填写微博账户和密码，减少了用户对此隐私性的烦恼，而且一键登录微博注册CoY节省了用户的输入成本。
通过CoY用户间的微博相互关注列表做交叉对比就可以知道哪些用户间是有关系的，将用户在微博的关系转化成CoY的关系，从而大大降低了用户在CoY增添好友的难度，这样可以起到一个很好的破冰作用。
由于微博的关系是动态的，所以用户登录时每天会拉取三次互相关注列表来动态更新CoY中的好友关系，这样也保障了不断多的用户进来时每位用户都能智能发现老朋友入驻CoY。
一键登录微博授权和智能发现增加好友是CoY的最重要的用户体验和核心所在。
问答：
怎么问这妹子是不是有男朋友？
我不知道她叫什么名字；
用文字我也不知道怎么形容她；
我更不知道她微博微信是多少
我怎么来告诉别人她就是我要找的人呢？
好吧，只能光明正大的拍一张她的照片然后放上CoY问其他人了。这是我最纠结的功能，因为我是一个非常注重隐私的人，但没有它这应用是绝对完成不了的。
我思考了好久，平时我们也是通过眼睛和手指指问朋友这人是谁以及了解她的信息，我们从朋友那获取信息理论上是没有侵犯到她的隐私权，所以理论上通过照片问别人这人叫什么名字和一些简单的信息也不算是侵犯她的隐私的。
在做这功能时也咨询了在校的法律系学生和外面的律师朋友，确保这应用不会因为隐私权的问题影响到我。为了保守起见，我对于用户输入环节做了苛刻的限制，用户不能通过输入文字来问问题（因为输入文字可以产生无穷无尽的问题），用户只能上传照片并通过系统的固定问题去问问题，用户得到的反馈也只有这妹子有没有男朋友的答案yes和no的比例以及回复的用户（这措施也对于CoY的商业模式产生了很大的影响）。很多用户可能会担心身边朋友知道自己喜欢谁，为了让广大用户安心地发照片，我还特意开发了一个匿名模式，就是谁也不知道是谁发的照片。
系统固定的问题只有5个：
你是否知道他她是不是单身（知道，分享出去问问别人）
她他是不是有男女朋友？（是，不是）
你确定吗？（是，不是）
你和她他的关系是什么？（朋友，陌生人）
根据4的回答会产生问题5.你和她他的关系很要好吗？（一般、很要好）
在这里会对回答进行筛选。如果问题3回答了“不是”系统不会录入该数据；由于附近的人也可能看到过这妹子是不是跟一个男的在一起，所以陌生人的答案也不能忽视，如果问题4回答了“陌生人”，系统会根据生成问题和回答问题时的地理坐标进行距离判断，如果超过2公里的也不录入系统中，这样最基础地保障了陌生人数据的良好性。系统也会给陌生人、普通朋友、好朋友不同的权重，用户通过不同的权重的回答从而可以判断这妹子是不是有男朋友，以及可以套一下该妹子的朋友近乎（可能也就是你的朋友），私下问问相关妹子的信息，从而对妹子更多了解，也从陌生人往“这是我介绍的朋友”方向发展，增加成功率。
设计
以上就是CoY的两大核心，接下来我需要围绕这两点进行设计。当时开始流行扁平化设计，刚好我对拟物设计感到非常头疼，决定从0开始学习android4.0设计规范，一定要做出一款最符合Android设计规范的Android应用来。
当时也非常流行汉堡菜单，汉堡菜单可以提供一个很好的沉浸式体验，把大部分功能隐藏在界面之外，所以我也采用了该导航设计，以下为该应用的信息架构和部分视觉图。
我是一个非常重视用户的使用流程的设计师，我会尽量去压缩流程的让用户用最短的路径去完成最多的事情。
未登录时用户可以查看附近两公里内用户发布的图片，当用户选择回答问题时自动定位到登录页面进行登录。
一键登录微博注册相关信息并找到好友。
三步回答问题。
三步发起问题，拍照选择照片－裁图－选择是否匿名发布
一步查看答案。
还有首页展示的图片会根据手机分辨率进行缩放，保证图片不会被拉伸变形。此外还做了一个细节设计，当查看回答问题的小伙伴时，向上滚动时背景会逐渐模糊，类似于Yahoo天气的滚动动效。
开发：
一定要学会用google搜东西，嗯，搜技术帖还是用google吧，学会在Stack Overflow看解决方法，在Github上查找第三方开发者提供的库，例如汉堡菜单这些有现成的安卓库不需要自己开发，只要学会看懂和怎么改代码就好。
当时github上有一个网络连接库比原生的性能要高很多，为了提高网络下载和上传的速度提升用户体验，这个库也被我放在CoY里使用，定位这些使用百度地图提供的SDK，微博登录使用官方提供的demo和API，这样能大大降低开发成本。
设计数据库占用了我大量时间，当时主要在啃一本叫《高性能Mysql》的书，在里面可以学到很多关于数据库优化的方法，例如利用trigger和事务等方法减少连接数据库次数，选择更有效的索引和如何更优地联表查询等等方法减少查询时间。通过后台的优化从而提高整个应用的响应速度，提高用户体验。
最后由于为了省钱选择了百度的BAE作为服务器，结果大部分数据库的优化工作都白做了orz，当时心有点疼。但还好，整个app从上线到下线服务器那边也基本没怎么花钱，降低了开发成本。
13年时普遍网民还停留在2G时代，平均每秒30KB左右，为了让用户最快看到图片和上传图片，我对比了压缩图片的比例和质量，在不影响体验的情况下选择将每张照片的等比例压缩率控制在30%，每张照片大小大约为20kb－30kb，由于一张图片几乎占了一屏，通过lazyload（就是滑屏到某个位置时才去拉取照片）的方法去加载图片，用户基本不会感觉到加载图片的环节，让整个用户体验上升。
滚动模糊的实现方式也困扰了我好久，由于每次通过y轴判断用户滚动距离而去渲染模糊效果会严重影响GPU，导致整个应用卡顿到无法使用。最后我采取了渲染一次图片模糊效果并叠放在清晰图片上面，用户在滑屏时，控制模糊照片和清晰照片的Alpha（透明度）来达到逐渐模糊的效果。
总结一下，设计决定用户体验，产品性能是影响用户体验的关键因素之一。
后话：
上线后有些用户问我几时有iOS版本当时让我小激动了好久，但因为不懂运营，CoY上线几个月后就下线了（下线前被我拿去各种比赛，还好获得了一些还不错的成绩），所以说团队很重要，单枪匹马做产品是很难成功的。这个概念有点超前，但不明白大家包括一些天使投资人为什么都觉得这个就是陌陌，也让我心疼了好久。
独立开发应用也让我对交互设计和用户体验有了更深一步的了解，毕竟体验是要靠技术和设计换来的，两者不可缺一，只有真的懂两者（无论是个人还是团队）才能做出好的用户体验。
独立开发很苦，别人在玩的时候你还在默默地干活；别人睡觉了你还在苦逼地找资料看书，但独立开发给我带来的好处有太多太多，我不用求人家来帮我干活，自己的想法自己做主；一说自己是独立开者也会有点小骄傲；独立开发可以对整个项目会有更全局的理解，每次的解决问题都会考虑到更多因素，由于思考比别人多也会比其他人走得更远。即使现在工作岗位是一名交互设计师，但我也不会放弃独立开发这条路，毕竟这条路也可以走很远很远：）
