文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

进度汇总

先大致说一下这两周完成的内容:

• 登录界面
• 注册界面
• 新闻详情界面
• 用户偏好算法（初版）的设计与实现
• 通知系统
• 私信系统
• 部分实现了数据操作辅助类族
• 部分实现了推送系统
• 部分UI的优化

细节还有非常非常多，当然不是说要拘泥于细节而失去了整体意识，而是在细节的把控中了解整个项目的脉络。虽然功能远没有实现完，但是现在的项目结构已经略显臃肿了，所以下一周准备梳理一下整个项目，开始尝试自上而下地审视并重新设计一下整个结构。

本周做的工作值得细说的还是用户偏好算法的设计。用户偏好算法是我们项目的核心算法，目的是为推测出用户近期对于新闻类型的偏好，并记录在系统内，从而在之后可以让用户选择自己感兴趣的信息，并且每当发布了用户感兴趣的信息之后可以推送给用户。除此之外，最重要的一点是，系统可以根据用户的喜好向用户提供兴趣相投的好友，从而提升用户黏性，并可以隐形中推广应用。

作为一个用户偏好推测算法，可以划分到人工智能的领域，在这里我想谈一下对于算法起点的考虑。说到机器学习，普通水平的实现只要看了Coursera上吴恩达的Machine Learning就够用了（当然我是说非常简单的应用），再不然Github上一堆数千star的项目，甚至都不需要知道基本概念。但是在初版算法设计中我们并没有采用机器学习算法，这是由于以下几点考虑：

• 我们采集的数据特征值非常少
• 我们采集的数据量非常少
• 手机计算资源的限制
• 在对机器学习没有深入的研究的情况下，设计出的算法有时还不如最普通的迭代

在初版算法设计中，我们只是使用了简单的权值计算，目前先实现这版测试一下效果如何，具体设计如下：

算法目的

为推测出用户近期对于新闻类型的偏好，并记录在系统内，从而在之后可以让用户选择自己感兴趣的信息，并且每当发布了用户感兴趣的信息之后可以推送给用户。除此之外，最重要的一点是，系统可以根据用户的喜好向用户提供兴趣相投的好友，从而提升用户黏性，并可以隐形中推广应用。

算法原理

算法计算结果是用户对于某种类型的新闻的偏好程度，目的在于两部分，第一部分是推测近期趋势，第二部分是推测用户喜好。

为了体现这两部分，我们使用两个衡量指标:时间因子 $tf$ (time factor)和认真程度 $cd$ (conscientious degree)来表示。为了突出两方面的因素，我们使用高阶运算来提升权值，计算出的值为 $tpw$ (temporary preference weight)。
除此之外，由于偏好值的计算是不断迭代的，所以每次计算新的偏好值时应该考虑之前的计算结果，给定一个权值因子 $wf$ (weight factor)，并设旧的用户偏好值为opw(old preference weight)，则新的用户偏好值为 $npw = opw \times wf + (1 – wf) \times tpw$, 目前取 $wf$ 为0.3，并取 $opw$ 初值为0。

算法过程

把用户访问一篇新闻的时间以及在这篇新闻上的停留时间分别设为 $visitTime$ （单位:毫秒）和 $stayTime$ (单位:毫秒)，考虑通过这两个因素来计算 $tf$ 和 $cd$。

1. 对于 $tf$ 的计算，主要是体现用户的偏好有多“新”，考虑取看这篇新闻距离现在的时间间隔，即 $currentTime – visitTime$, 换算成天数设为 $dayInterval$, 那么可以取 $tf = \frac{30}{dayInterval + 1}$ (取30为了使 $tf$ 和 $cd$ 处于同一个数量级)
2. 对于 $cd$ 的计算，取平均阅读每个字所用的时间，设新闻正文字数为 $newsLength$ ,则 $cd = \frac{stayTime}{newsLength}$
3. 对于 $tpw$ 的计算，为了使越新、阅读越认真的新闻重要性越大且增长速度越来越快，可以取 $tf$ 和 $cd$ 和的平方，即 $tpw = (tf + cd) ^ 2$。而用户在某一种类的新闻浏览记录有 $n$ 条，设每条记录计算的 $tpw$ 值为 $tpwi$，综上所述可得 $tpwi = (\frac{30 \times 24 \times 3600 \times 1000}{currentTime – visitTime + 86400000} + \frac{stayTime}{newsLength}) ^ 2$
4. 则 $tpw$ 最终计算结果为。最终计算所得的 $npw = wf \times opw + (1 – wf) \times tpw$。（注意：还可以考虑的一点是，如果我是信息学院计算机系的，你也是信息学院计算机系的，那么我们很可能就有共同语言，也就是同一学院、同一学系或者同一年级的用户也可能有共同的喜好，即使这一点没有体现在算法计算结果上，考虑把这一点也加在偏好算法计算中）

算法实施

我们在数据库中设置了一张用户偏好表用于记录用户偏好信息，表项有用户 $id$、新闻类型、偏好旧值和详细信息，在详细信息中记录了一个数组，数组中每一个元素都包含 $visitTime$ 和 $stayTime$ 两部分。

每当用户访问一篇新闻时，都会更新相应的表项。同时在用户表中添加一个喜好标签表项，记录用户最近最感兴趣的新闻类型，最多记录三个，太多的话匹配结果会过多，使得匹配系统没有了意义，而且用户也没有精力去关注那么多的新闻类型。当分别计算完一个用户对于各个新闻类型的喜好权值之后，将其排序，得到的前三名新闻类型放入喜好标签中。

当推送新闻时，直接根据标签过滤即可。推荐好友时，比对两人的喜好标签即可，只要有共同的标签就推荐，并且如果当前用户没有喜好标签，那么就随机从所有用户中抽取；如果当前用户有喜好标签，那么对于其他待匹配的没有喜好标签的用户而言，也采用随机抽取的办法。

关于用户喜好的计算时机，因为计算不是在服务器上完成的（用云引擎有点麻烦而且也没必要占用服务器资源），所以考虑只要用户登录了，就在后台计算用户偏好，每个登录周期偏好只计算一次。

目前为止只做了简单的试验，算法可以得到较为合理的偏好值，但是在真实的应用场景中效果如何还有待进一步的测试。

因为软件工程大作业要用网站作为手动添加内容的后台，所以向学校申请了一台服务器(WindowsServer 2008 64-bit)。因为不常用Windows的服务器，拿到手之后遇到了一系列问题，写在这里以备下次需要。

安装应用程序（WampServer2）提示系统缺失MSVCR110.dll
解决方案: 见百度经验。不吹不黑，百度就这点好，大众性的问题还是靠得住的。

WampServer图标一直是黄色，无法正常启动

测试了80端口和3306端口，都没有被占用，修改之后还是没有起作用。
解决方案: 想到wamp的安装是在MSVCR110.dll之前进行的，是不是有什么地方出了错误，所以重新装了一遍WampServer，问题解决。

服务器本地Locathost可以访问，但是在我电脑上通过公网IP无法访问网站，也不能ping通

不能 ping 通问题的解决方案:打开服务器管理器->Windows防火墙->入站规则->文件和打印机共享(回显请求 – ICMPv4-In)，启用。

不能通过公网IP访问网站问题

解决方案:打开服务器管理器->Windows防火墙->入站规则，新建一个端口规则，把80端口加上，随便命名，之后公网IP可以正常访问。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

终于开始了正式的开发工作。鉴于团队之前多少有点开发经验，很多界面写起来并没有什么阻滞，但由于我们都没有深入系统学习过Android架构和API，所以在有些细节上总是会有不到位的地方。

就拿笔者来说，虽然能照葫芦画瓢实现指定的界面和效果，但是总会在一些细微的地方卡住。如通过ViewPager实现SwipeView的解决方案中，ViewPager会时刻保留两个Fragment的View（此处存疑，只是实际操作的情况，并没有查阅过源码），其他的Fragment的view会被destroy掉。被destroyView的Fragment所有的控件都被“下架”，但是实例会被保留，那么对于EditText和RadioButton之类的控件而言，其内容是不会被保存的，除非单独设置变量保存或者放在savedInstanceState中。笔者在这里就卡了很久，又复习了一遍Activity和Fragment的生命周期，并且简单查看了一下ViewPager的源码，才解决了相关的问题。

在实现新闻列表的时候，由于需要上拂加载更多的效果，考虑现有开源方案太过庞大，所以笔者就手写了一个实现。因为新API强迫症，使用了RecyclerView而不是ListView。RecyclerView效率更高，功能更强大，操作也更灵活，但是少了诸多限制也就少了一些方便。如RecyclerView没有OnItemClickListener，笔者就往Adapter里扔了个回调，监听每个条目的点击事件。又如RecyclerView没有默认分隔线，这是可以理解的，因为要同时实现ListView、GridView以及瀑布流的效果。关于添加分割线的方案，鸿洋大大给出了一篇非常精彩的博文Android RecyclerView 使用完全解析 体验艺术般的控件 ，但是由于代码还是过多，所以笔者自己用代码模拟.9图片实现了分隔线效果，就过程而言要简洁的多（当然功能不够强大，具体见Android使用RecyclerView分隔线问题 ）。

类似的问题还有很多，虽然都不算是大坑，但是有些地方还是挺绊脚的。现在尽量克制不去过于关注细节，先把大框架做出来，再进行优化工作。

贴出下一周的任务安排：

爵爷：

• 完善登录界面、注册界面、新闻详情界面
• 添加第一主界面新闻筛选机制（在新闻分类完成基础上）
• 设计用户偏好计算算法（初步测试）

纪神：

• 和小男孩讨论出新闻的种类，并制定从爬虫正式入库的方案
• 完善好友界面，实现效果应与微信好友相似，尤其是右侧的A-Z导航（在https://github.com/Trinea/android-open-project找开源方案）
• 完成好友详情界面，实现效果应与微信好友详情类似，完成好友申请处理界面（微信收到好友申请后好友界面顶端的效果）

小男孩：

• 和纪神讨论出新闻的种类，并制定从爬虫正式入库的方案
• 完善第四主界面
• 完成修改用户信息的功能（修改的信息项根据数据库设计来，界面效果按照微信来。其中地区修改先不用做，我之前做过类似的东西，有完整的地区库）

老板：

• 完成第三主界面
• 继续爬取其他学院的新闻
• 把爬取的信息按照{纪神和小男孩的方案}正式入库

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

本周大概把四个界面的样子做出来了（没有做细节，现在不贴图），并且老板那边的爬虫也可以跑了，虽然只是测试性入库，新闻的类别和学院学系等都还缠在一块没有分开，数据是不能用的，但效率可以满足要求，入库方案也并不难制定。

至此“试水阶段”结束，下边开始第一版最小化原型的开发（在倾物语（二）中已经提到，第一版最小化原型弱化设计，先走一遍流程知道我们在做什么，否则空谈设计很可能没有效果）。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

本周末我们组已经完成了《需求规格说明书》和《可行性分析报告》两份书面材料，具体内容见提交的文档。

这次想聊一下我们团队对于之后开发工作的构想。

就大的方面来说，我们在前端尽量使用现成的解决方案，并配合手写“胶水”，后端使用LeanCloud解决方案。

前端要展开有非常多的东西，因为Android的前端比HTML更加底层一点，要涉及的东西更多，考虑的面也更广，加之运行在移动平台，限制也颇多。

但是在参考现有解决方案（比如这个）以及基于我们之前的开发经验上，前端是可以跌跌撞撞地走的（当然是在不考虑外行的设计、咄咄逼人的PM、永不满足的客户的情况下）。
至于为什么不使用FB的react-native或是MUI等来做跨平台的界面，一是在性能上H5相对原生仍有不足，并且这一点在Android版本和手机性能差异极大的安卓市场上更为明显，二是一个移动端的应用无论干什么顶部都有一个小绿条咕咕咕地动在我们看来非常难受（纯个人观点）。因此我们考虑只在一些不重要的信息展示界面和时间上来不及的扩展功能上使用H5，其他情况仍然使用原生API开发。

还有就是 JetBrains（笔者免费IDE的提供商，因为有教育账号）的亲儿子 Kotlin，笔者没有深入了解，但是简单看了一下，第一感觉就是好玩，还没有感受到特别强大的地方（当然是了解非常不足），基于学习成本的考虑，我们还是使用了 Java 来作为主开发语言。

后端我们使用现成且强大的解决方案 LeanCloud。笔者多次被问到过“用LeanCloud这么简单方便甚至可以说是无脑的东西，还算是程序员吗？”。这种想法笔者之前也有过，但是如果不接受更快更好更方便的东西（并不是说LeanCloud就一定是这样，LeanCloud的适用场景其实限制还是蛮大的，这里不展开。但是相对于我们目前的开发需求，LeanCloud就是这样的），我们现在想用计算机还得在竹简上钻孔呢（笑）。另外笔者琢磨过算法，写过汇编优化的编译器（特别指明：最后什么都没做出来），也裸写过 socket 以及 RESTFUL，所以对于“不方便”的东西笔者多少还是有发表意见的权利的。出于学习目的或者对于要求特别严格的解决方案，唯有从底层慢慢写，但是就目前的场景来看使用 LeanCloud 是非常好的选择。应该针对不同的开发需求使用不同的方案，这就是我们使用 LeanCloud 的原因。

另外在开发上，我们目前的想法是先下手开始写代码，而不是先做细致的设计。因为目前团队整体的项目开发经验是不太够的，没有足够经验的支撑，一上来就做细致的设计很有可能会忽略了重要的东西而把精力放在了其实无足轻重的地方，而且做出的设计并不一定效果有多好（编者个人认为可以参考 Java 第一代 UI 库的设计）。当然先写代码并不是说“先写了代码再提取设计以完成任务”，而是先用粗糙的代码把流程简单走一遍，探探路上都有什么坑，然后再回头做设计，这样心里会踏实很多，设计结果也会更加可靠。这也是我们这个月的主要任务：做第一版最小化原型。

目前编者已经搭好了基于 Viewpager 的 Swipe View 以及 4 个 Fragment 作为主界面，下周先分工把这四个主界面按照原型设计做出来。然后依次跟进其他代码任务。下面是应用效果以及项目规模统计（是的我知道很丑，请不要再吐槽→_→）。

最近教大一的小孩理解多线程，想到了一个还算贴切的例子。

假设你要在12306上买两张票，假设票是连号发放的，那么当你一个人买的时候，买到的票一定是连号。而有时并不是连号的，这说明在你买票时也有另外的人在买，把本该属于你的连号票抢走了。

这就相当于多线程，每个买票的人都是一个线程，而总的火车票就是这些线程共享的资源。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

本周六我们进行了一整个下午的详尽讨论，围绕以下几点进行了细致的分析，并且有了比较明晰的结论。

APP的名字

这是最早被提出的问题，但也可能是（不只是一个笨手笨脚的大作业，对于所有的项目都是）最难的一个问题之一。这几乎不涉及技术问题，而是需要外对于整体产品和用户市场、内对于项目定位的一个精准的把控。

由于条件的限制，我们并不能在这一点上花费太多的时间，我们认为基于我们实际情况的最佳的名字应该能够同时反映信息收集 + （基于共同关注点的）社交这两点，在头脑风暴中，我们想了很多正儿八经以及奇奇怪怪的名字。

• 信息人大
• 校园风
• 三人行
• 校园通
• 圈里信息
• 校园知事

最终我们比较中意的是“校园知事”，它满足了我们提出的两点基本要求，并且发音同“芝士”也让人多少有些亲切感（→_→ Fate第十职阶Eater）。暂定这个名字，只有有更好的想法再进行修改。

关于《需求规格说明书》以及《可行性分析报告》

在定下了基本的思路与设计之后我们开始着手书面材料。第一步要做的就是《需求规格说明书》以及《可行性分析报告》。在《需求规格说明书》中我们将按照课件上的标准进行编写，并且对成员进行了分工，具体分工如下：

• 第一部分：系统规格说明：小男孩。内容包括系统概貌、功能要求、性能要求、运行要求、可能增加的要求、DFD、IPO
• 第二部分：数据要求：纪神。内容包括DD、Hierarchy或Warnier Diaggram
• 第三部分：用户系统描述：爵爷。内容包括初步用户手册：从用户的观点考虑系统，系统功能、性能 、使用与步骤
• 第四部分：修正的开发计划：老板。 内容包括成本估计 ，资源使用计划 ，进度计划等。

在《可行性分析报告》上，如果按照业界正式工程的格式来做的话会非常繁冗，并且其中涉及的市场背景、政策背景、法律背景以及资金链等对于我们目前来说有些不切实际，所以我们对于《可行性分析报告的规格》的格式进行了适应性调整。主要分为六个部分：

1. 背景了解以及基于问卷调查的需求分析
2. 对市场现有的产品进行分析对比
3. 我们满足这个需求的思路想法
4. 技术层面上实现我们的思路想法
5. 产品的测试和维护
6. 产品的推广和运营

《可行性分析报告》将于《需求规格说明书》之后完成，届时将根据情况进行调整。预计最晚于下周末完成《需求规格说明书》和《可行性分析报告》这两份书面材料。

关于微人大权限以及各院API接口

因为涉及人大身份（目前APP只覆盖人大范围）验证问题，我们需要微人大的开发者权限，并且在信息收集这方面如果能直接拿到各个学院的新闻API岂不美哉[王司徒脸]。

在微人大权限上，我们在微人大上申请了开发者账号，系统说7日之内会给回复，然而两个七日过去了······再等等，再催催好了，另外关于微人大的讨论中又催生出了一个问题：登录模式。是直接采用微人大账号登录还是新注册账号登录，再于APP中进行人大身份验证（就像进入APP后再进行邮箱验证一样）。经过讨论我们认为，如果使用微人大账号登录虽然直接方便，但是给人一种官方死板的气息（不吹不黑），且不利于之后用户群体的扩展（怎么能占领清华北大呢）；使用独立账号注册 + 后期验证的方式虽然多了一步流程，但是让人感觉不受束缚（这种感觉很难描述），并且可以让用户先体验一部分功能，并有利于之后对清华北大的占领工作。

在各院新闻API获取这方面，我们以尽可能诚恳的语气向30多个学院发送了邮件，分析了共赢新性并询问是否能拿到新闻的接口，但截至目前没有任何学院给予回复（其实也难怪，人大黄页上找到的邮箱地址有好几个格式都是错的，还有几个要么没这个主机要么没这个用户）。我们并不准备就以上的经历来分析办事效率问题，因为很可能是我们的方法出了问题。目前看来用爬虫抓新闻是比较可行的选择，现阶段无法预料在爬虫部分将遇到的问题，我们将于下周写一份爬虫的demo，并连接LeanCloud进行测试。

做最小化原型的详细功能设计以及简略的UI

这两部分是结合在一起做的，在简要功能的讨论中画出了主要的UI。我们不在这里贴出讨论过程中的草图，之后我们会用原型设计软件重新把图画一遍再发布。主要的界面就是新闻消息、 好友、发现（与自己关注点相同的人，了解自己最近的关注点或者查看自己的时间轴等等）以及更多（个人信息以及应用设置等）。虽然这是至关重要的一点，但是我们认为于”空想阶段“在这上面花费太多的时间不太合适，应该结合最小化原型设计出一个简略的功能框架，然后在做的过程中踩坑。

进度安排

在这点上我们同样无法做出细致的估计，因为涉及公关处理、策略转型或团队配合等方方面面的问题，我们只是做了一个大阶段的预期。

• 四月份： 第一版开发与测试
• 五月份： 第一版集中测试，第二版开发与测试
• 六月份： 第二版集中测试，产品推广

总体来说我们目前的进度是可以接受的，在第一版的开发过程中一定会遇到非常多的问题，而且这些问题中有些将超出我们的预期与能力（即所谓的”坑“），我们会翔实地把这个过程中的心得体会记录下来，作为之后的一个宝贵的参考。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

上周我们在拿到问卷统计数据之后，就APP的初步设想进行了讨论。得到了以下结果：

最小化原型的功能集

1. 管理用户（用户要么直接接入微人大，要么另开注册通道。实在不行用mechanize等进行模拟）
2. 收集信息（教务信息、实习信息等）
3. 管理信息（教务信息、实习信息等）
4. 记录用户喜好，寻找趣味相投的人
5. 私信（站内通知）

开发的阶段以及模块

APP模块

1. 信息管理模块
2. 喜好推测模块
3. 站内消息模块
4. APP管理模块（应用设置，缓存管理，版本检测与更新等）

后台网站模块

手动添加信息，后台管理等

爬虫模块

信息爬取模块（通过网站送入LeanCloud）是否可以拿到学校后台的API

需要向各学院以及学校发邮件询问（包括各种新闻的API，以及微人大入口）

数据库粗略设计

• 用户表
• 信息表
• 信息类型表
• 用户喜好表
• 关注者表
• 被关注者表
• 私信表
• 映射表（放在爬虫端，不同的来源对信息的划类方式不同，统一映射成我们自己的格式）

除此之外还有其他的一些细节问题。讨论完之后我们又对数据库每张表的内容进行了设计，得到了一个初步的数据库方案，并准备再次进行修改验证。详细的方案会放在之后正式的文档中。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

本周我们设计并回收了一套调查问卷，用以了解在校大学生对于学校各类信息的需求程度、了便利程度以及对于基于关注信息的应用的期待程度。最终回收结果部分摘录如下:

• 在刚刚结束不久的选课的过程中，您或身边的同学是否有询问过选课何时结束之类的问题？

  

• 在刚刚结束不久的选课的过程中，您或身边的同学是否有询问过选课何时结束之类的问题？

  

• 您觉得您获取消息及时吗？

  

• 您获取消息的途径一般以什么为主？

  

• 您是否使用校内新闻消息推送之类的APP？

  

• 如果有人跟您关注相同的新闻，您是否愿意跟他（她）交流看法或互相分享信息？

  

• 如果现在有一款推送校内信息的APP您有多大程度愿意使用？（1很愿意，5很不愿意）

  

从主要的调查结果部分来看，能简要总结出以下几点关键信息：

• 在校学生对于教务信息等学校官方信息需求很大，需求种类也很多
• 有相当一部分在校学生不能及时获得需要的信息
• 在校学生的信息来源较为分散，并且信息的接收比较被动
• 绝大多数在校学生并没有正在使用的校园信息推送应用
• 将近半数的在校学生非常愿意与有着相同关注点的人交流，几乎所有的在校学生都可以接受这种交流
• 41%的在校生对于校内信息推送的APP有着相当的期待，另外有41%的在校生持观望状态

以上是报告的部分内容，详细的分析报告我们会在《可行性分析》中给出。

从报告中可以看出我们目前的设想是基本可行的，下一步是尽快商讨最小化原型并收集用户评价，对现有轨道进行进一步的调整。

文章来源：中国软工亚洲指挥中心

共同作者：纪神，爵爷，老板，小男孩（按首字拼音排序）

责任编辑：爵爷

在组队初期，我们就达成了一致的意见：做一款为学生群体服务的Android平台上的应用。在前两周中，我们查访并使用了市面上很多流行的APP，并且尽力避免在用户和投资人眼中都基本上不再有希望的应用，如O2O类、基于IM的社交类应用等。

最终吸引我们注意力的是两款应用：今日头条和芥末校园。我们注意到这两款应用虽然用户量算不上特别巨大，但是在学生群体中有比较好的使用氛围，并且两者的方向也都非常受我们组成员的喜欢。

• 今日头条: 是一款新闻APP，但不同于传统APP的一点是它会不断学习掌握用户的新闻喜好，并不断修正，进而推送给用户其感兴趣的新闻，这样方便并且带有一定“黑科技”色彩的应用一经推出便好评不断，公司发展目前也是蒸蒸日上。
• 芥末校园: 是一款校园交友APP，据我们了解，基本上90%的社交软件最后都变成了约炮软件（更何况这是一款校园！校园社交软件），虽然这其中有很多都是制作方有意无意的推动造成的，但交友最终变成交肾仍是我们对于社交类应用比较大的顾虑。遗憾的是，我们在这款软件上也看到了一些约炮软件套路的影子，但是这款软件的交友方式让我们很感兴趣。软件是需要注册用户先填写自己的信息以及兴趣点，之后可以在广场查看和自己兴趣相投（而不是**厘米图片）的用户，如果感兴趣就点个赞，当两人互相点赞（用户是看不到谁给自己点了赞的）之后就会成为好友。我们不能保证这一定是个有前途的点子，但这一定是有趣的。

除了查找了大量的APP，我们还注意在身边查找潜在的需求。我们发现学生群体需求比较大的一点是校园中各种信息，如出国信息、保研信息、招聘信息以及其他各种各样的事情。虽然这些信息在校网站、院网站或者班长发来的邮件中都能找到，但是信息来源分散，而且相当一部分同学都没有按时查看校网站、院网站或者邮箱的习惯，所以这是不容忽视的一点需求。

我们经过调查，发现之前有不少人尝试过做类似的软件，比如社团宣讲信息、讲座信息的集成APP等，但都不温不火最终慢慢消失了。我们认为这是由于单纯的信息集成虽然满足了用户需求，但是没有也无法培养用户粘性，致使用户只是单纯的用来查过几次信息，之后就遗忘在了手机的某个角落。

综合以上种种，我们决定制作一款能满足学生群体对于信息集成的需求的软件，同时做需求上的纵向延伸，培养用户粘性，并且增加推荐率（用户向其他用户安利或者其他用户看到了相关的信息进而加入）。当前的打算是借鉴今日头条，通过用户查看的种种信息掌握用户目前阶段的关注点，再借鉴芥末校园通过这个关注点推荐和用户有相同或相似关注点的用户，通过社交来增加用户粘性。

我们也研究了《精益创业》中的很多说法，认为单纯自己去做设想或是“信仰之跃”是没有意义的，所以还是需要了解用户需要什么。因此我们下一步的目标就是尽快制作一份问卷，调查使用过类似软件的用户的看法，以及没有使用过类似软件的用户对于这个想法的意见和建议，进而修正目前的轨道。