【分享】2017-03-15:黑产分享会(百御风控之路)

地点:科技园-K2-F1-卢令

主讲人:李晨百御风控产品负责人

Content:

一、了解黑产:羊毛党、黄牛党

规模化,专业化,组织化:40W-100W,明确上下游分工,组织结构明确(仿真)

短信代接平台、改串码、打码机

二、打击黑产:风控反作弊动态对抗

提升作弊成本

账户、手机号、身份信息、环境、设备、行为

作弊风险

线下追损、法务打击、售卖渠道

 

总体思路:提升作弊成本

战略:全链路分析、挨个击破

战术:数据/情报双监控,动态对抗(潜伏敌营)

 

 

三、百御风控:平台化产品的输出

 

四、案例与合作

 

 

passport账户体系

亮哥:产品化考虑接入、法务和追损

欢哥:黑名单量级(手机号+银行卡)、如何评定黑产作弊成本、手机号和passport打通,所有百度产品得以收益。

【转载】如何做产品运营?

前几天跟老大去拜访了一个做情趣应用的公司,请教了一些关于社区运营的知识,总体来说不是非常满意,特别是他们运营总监,张口闭口全是理论,不愧是阿里出来的。倒是跟个运营妹子学到了点东西,下面是期间的一段对话。

我:“你们论坛里的这些黄图都是用户自己发的嘛?”

妹子:“要是用户发的就好了,80%是我们伴马甲传的!!!”

我:“那用户都在干嘛?”

妹子:“都在评论‘约吗?’”

我:“用户的年龄段大多集中在哪?”

妹子:“大部分是30岁以上的大叔。”

我:“好吧,你们辛苦了~”

没错,运营就是这么苦逼,耐得住寂寞是运营的基本素养,特别是对于没有流量的冷启动产品而言,很长一段时间你都是在做内容填充、兼职客服的角色,但千万不要小看这些基础的工作,里边同样有很多技巧和策略。

首先,我们先从运营的定义说起,连自己做什么都不知道岂不是很悲哀。我见过的很多人都会将运营与产品运营这两个概念混淆,当然,在小公司里很多人都是身兼数职,自然就模糊了其中的界限。

引用知乎中的解释,运营就是一切帮助产品推广、使用、认知的手段,包括以下几部分:新媒体运营、渠道运营、产品运营、商务运营、数据运营等几大类,可以看出产品运营是运营的一部分。百度对产品运营的定义为:产品运营是一项从内容建设,用户维护,活动策划三个层面来管理产品内容和用户的职业。当然,我感觉还应在其中加一个数据分析,即验证的过程。

了解了定义,再来看以下产品运营的方法论:

做任何一件事情都要有逻辑性,典型的有5W2H,SWOT、SMART······

下面是个人理解的产品运营方法:

用户运营

目标:拉新

思考:

  • 用户属性:谁是工具的目标用户?
  • 用户需求:为什么用这个产品?
  • 用户触达:哪里可以找到这些用户?
  • 用户获取:如何吸引他们的注意?
  • 用户活跃:如何提高他们使用产品的频次、时常?

方法:

  • 用户画像分析,年龄、学历、
  • 用户反馈:看用户留言、用户状态、后台反馈
  • 寻找用户:贴吧、QQ兴趣群、论坛、竞品、豆瓣、新浪。
  • 获取用户:朋友、私聊、软文、活动、渠道、换量、CPA
  • 维护用户:用户奖惩机制、权限机制

以他们应用为例,用户大多是30岁以上大叔、学历不高、分布在二三线及以下城市、屌丝居多。有了这个用户画像你就可以去他们聚集的地方寻找用户,比如各游戏论坛、野路子渠道换量、无节操的自媒体大号宣传。他们还有一个比较灵验的方法:申请几个个人微信号,利用附近的人吸引用户,据说每天能增几百个。

问题:第一批用户是专家级还是新手级,如果是专家级该如何去维护?如果是新手级该如何去维护?如何形成闭环?

比如我们拜访的这家情趣应用公司,各位觉得他们前期是更需要女性用户还是男性用户呢?如何才能保证这部分用户不被搔扰呢?这就涉及到权限机制了,比如开辟一些社区版块,只允许女性进入,当然这就会产生新的问题,有些男用户会更改性别啊,这时可能还需要版主的监督。

内容运营

目标:留存

思考:

  • 不同类型的用户其需求是什么?现阶段我们的主要任务是什么?
  • 如何在让用户第一眼能对你的内容感兴趣?
  • 如何建立自己的产品感知度,即我们说的产品的调性?
  • 如何形成内容生产-消费闭环?
  • 如何引导社区氛围?
  • 如何组织内容模块?

方法:

  • 比较传统的方法为管理员后台审核。比如我们拜访的这家公司,妹子说:“用户产生的内容80%是不合格的,为了维护产品的氛围,后台果断删掉。”这是一个很苦逼的活,当然可以通过关键词筛选来减轻运营人员的负担。
  • PGC模式。通过专家生产内容,奠定前期的内容氛围。当然,内容的生产要结合我们现阶段面向的主要用户,比如我们主要面向的是初学者用户,那我们的PGC内容则倾向于教学类,同时配合给用户及时的答疑解惑。
  • 内容反馈机制。社区的繁荣仅靠运营人员是不够的额,要想持续的产生内容就要建立内容的生产—消费闭环,这其中的核心即为反馈。还是以这家公司为例,如何才能刺激女用户上传比较暴露图片呢?我们就可以建设一个板块叫“身材大比拼”,各位大叔们必然会纷纷去点赞、跪舔,当然不能出现“约炮”这样的字眼,吓跑了女用户怎么办。妹子虚荣心得到满足,下次换个姿势再来一发,岂不是大家各取所需。
  • 从用户需求出发,组织内容模块。这点比较简单,可参考美柚、LOFTER等应用。

活动运营

目标:促活

思考:

  • 我们的用户为什么不活跃了?
  • 这个活动对我们的目标用户有意义吗?
  • 预期的活动ROI是多少?
  • 活动的流程够简单、直接、易传播吗?
  • 活动的参与机制合理吗?

活动

方法:

自己在这方面走过的坑比较多,总结下来就是:不要为了做活动而做活动,要始终明确此次活动的目的。

活动预演。特别是对于公司投资比较大的活动,千万别太自信,事前找5个精准用户试试水,一方面可以观察用户对此活动的发聩,另一方面有利于发现活动流程中的漏洞。

跨界思维。想学好这一点,首推马佳佳。找到各方的利益共同点,而后就看你的公关能力了。

自传播。要做到活动的自传播有几个要点:流程简单、有趣、易传播。这里有个很有意思的问题,假如让你组织一个关于情趣类的活动,如何让它快速传播?我们知道,很少有人会在朋友圈转发此类内容,那我们是否可以通过与大姨妈这类的应用合作来淡化它的情趣属性,强调女性属性呢~

找准用户的真实需求,别花冤枉钱。在知乎看过一个比较典型的例子:有些理财公司为了吸引用户会推出虚拟本金,但使用过后你会成为产品的用户吗?大部分人不会,因为很多人都没有这个需求,只所以会去参加这个活动是因为你白给我利益,这样的便宜不占白不占。活动过后,看留存率简直要吐血。

最后,依然要有数据分析的能力,各种激活率、次日留存、七日留存、PV/UV、RFM方法、复购率,通过数据分析总结经验以便指导下次活动。

 

来自 人人都是产品经理

【转载】知乎客户端产品分析

知乎产品体验报告

知乎产品体验报告

「剑未配妥,出门便已是江湖」

笔者是知乎产品的多年用户且一直深爱着知乎,在知乎上也收获了许多帮助与成长,笔者总结了自身对知乎产品的深度体验并参考了网络上广大用户对知乎产品的讨论,以自己目前对产品设计及互联网行业不成熟的认识撰写这份报告,如有纰漏疏忽之处敬请指正!

1. 文档概述

1.1 体验环境

  • 体验机型:iPhone 6s
  • 系统版本:iOS 10.2.1
  • APP版本:3.30.0
  • 体验时间:2017.3.5
  • 体验人:Darry

1.2 文档目的

  • 了解知乎的产品功能、产品表现、产品战略和商业目标等;
  • 通过分析知乎和同行业竞品的优劣势,总结知识付费行业发展特点,并给出改进建议。

2. 产品简介

知乎官方的宣传语为「与世界分享你的知识、经验和见解」。作为分享专业知识、经验和见解的问答社区,知乎凭借着高质量的内容和友好理性的氛围收获了高质量的用户群体。通过几年的发展,知乎从问答社区出发,将知识分享形式从问答拓展到专栏、Live、付费电子书等多种方式,产品内容愈加丰富,目前的知乎是一个集成了问答、写作、直播、电子书等诸多模块的平台。
核心功能:问答、专栏、值乎、知乎书店、知乎Live、知乎圆桌。

产品画像:高质量多方式的知识社交平台。

3. 需求分析

目标用户:知乎的用户主要划分为知识输出者和知识获取者两部分。目标人群一方面包括分享知识与经验的各行业从业人员、分享经历的阅历丰富人群以及对特定问题发表见解的广大用户;另一方面包括寻求高质量专业性解答的学习型用户。
需求分析:

依照马斯洛需求理论,知乎主要满足了用户的两个高级需求:尊重需求和自我实现需求。

  • 各行业的精英通过平台完成自我实现,通过多种方式(回答、写作、Live)发表见解和分享经验在专业领域里传播思想,收获关注与实际收益。一方面,优质答案会通过知乎的算法得到更多的曝光。包括推荐到知乎日报,发现页面等。增强回答的曝光率是很强大的激励,是马洛斯需求理论最顶端的一层,对于很多优质内容输出者来说,这比金钱利益激励更重要。另一方面,一些用户在知乎上通过输出内容打造个人IP,引流到自己的公众号/个人微博/淘宝店铺/求职招聘/软广告等,可以产生更多利益。
  • 学习型用户通过平台寻求高质量专业解答,满足高质量阅读需求与小众内容获取需求,满足求知欲与归属感,在实质上获取知识并提升自我能力,同时获得将碎片时间都利用起来的充实感(相较于其他泛娱乐性媒体)。

4. 产品分析

4.1 产品功能结构

知乎从最初只有问答功能,到如今集成了「值乎」、「知乎书店」、「知乎Live」等多个子产品的知识社交平台,一直保持着清晰的界面结构。笔者从知乎的五个标签页总览知乎的功能结构:

  • 首页:用户在打开知乎客户端时,随着启动推广页面消失,首先进入视线的便是首页界面。首页界面集成了知乎的最核心功能,即获取知识(时间线、搜索、Live、提问)及输出知识(回答、分享、Live)的入口。在首页的时间线上,会推荐用户所关注的话题、用户的最新动态。当然,频率很少的广告以及自家产品推广也包含在每个用户的时间线中。搜索作为用户使用频率非常高的功能,被合理地放置在 Navigation Bar 上。搜索栏右侧新增的Live入口既不喧宾夺主,又能够加强Live的推广。提问与分享都是编辑器的入口,点击进入回答会有问题的分类以及回答草稿的入口。
  • 发现:发现页的核心功能是推广。Banner 是广告和专题推荐,紧接着的五个彩色icon(专栏、Live、书店、收藏夹与圆桌)在知乎经典蓝白的简约淡雅的风格下显得格外显眼,推广多样化的知识分享平台。热门话题和热门内容结合实时热点和用户数据,丰富用户的阅读内容以及引导用户关注点。
  • 通知:通知页在软件内推送给用户新消息,分为「赞与感谢」和「通知」两个模块,我理解为积极性反馈通知和其他通知。
  • 私信:私信功能十分简约,包括常规的聊天功能与编辑对话功能。知乎在对话界面有一个特别的设计:隐藏用户自己的头像,拓宽对话显示区域,可以在单屏展示更多信息。
  • 更多:更多界面中涵盖了个人资料、设置以及个人功能入口。在这里,用户可以查看或编辑自己的个人资料。个人资料入口下面的个人功能部分提供了用户的关注、收藏、草稿、浏览记录、Live 与书架的入口。软件设置部分将反馈帮助中心和夜间模式放置到第一层级,可见知乎非常注重用户的声音,致力于提升自身产品的用户体验。其余设置都被统一放置在设置入口中。

4.2 问答

问答是知乎的最核心功能。从问题入口进入到问题界面,直观上可以获得问题的基本信息、话题归类,回答的渠道(邀请回答与添加回答)与答案列表。用户可以选择答案的排序方式,每个答案cell提供答案正文缩略、答主基本信息、赞同数、评论数与时间信息。点击进入答案界面,用户可以获得答案正文以及对答案的反馈功能。评论界面展示了不同用户对答案的见解,知乎提供给用户正反两种评论排序方式以及按赞数排序的精选评论。无论是问题界面、答案界面还是评论界面,知乎都提供了每位答主个人资料的入口且提供方便的关注方式,这对于以高质量用户与内容积累大量用户留存的平台,是十分关键的。

4.3 专栏

专栏在总体而言,与问答系统是十分相似的。知乎专栏给予用户撰写笔记、发表见解和分享经验(营造个人品牌)的机会。内容输出者可以简便快捷地发布文章,得到读者的赞赏(实际收益)与反馈。而对于内容获取者而言,系统自动推送的优质内容降低了搜索成本,读者可以在感兴趣的话题中寻找高质量的文章。

4.4 值乎

用户可以从开通值乎的答主的个人资料界面入口进入值乎。用户可以选择向答主进行公开提问或私密咨询(收费标准由答主决定),也可以付1元收听历史回答。值乎是知乎在免费问答社区之后尝试的「付费问答」功能模块。答主可以通过回答问题实现知识变现,提问者也可以通过花费一定金钱咨询一些个体性极强的问题。

4.5 知乎书店

知乎书店上线后,为优秀内容输出者提供了变现渠道。知乎书店将知识价值整合,用户可直接通过知乎书店购买、下载和阅读知乎电子书,实现购买、阅读、传播和延伸讨论这一独有的阅读讨论闭环。知乎书店目前集成在知乎内,在知乎内有许多入口可以进入知乎书店,目前的知乎书店功能设计大致如下:
读者找到感兴趣的电子书,可以做标记和分享。点入具体的书籍页面,用户可以获取书籍与作者的基本信息并进行相关操作,在购买并阅读后,书籍将会出现在用户的阅读list里。知乎书店里集成的电子书阅读器具有简单易用的功能,大繁至简,关注用户最需要的阅读体验。

4.6 知乎 Live

知乎 Live 是知乎推出的实时问答互动产品。用户可以申请成为主讲人、创建 Live。用户的 Live 会出现在关注者的信息流中和用户的个人界面中。知乎 Live 与知乎书店类似,都是集成在知乎中。在新版知乎中,知乎在移动端应用中的显眼位置放置了诸多 Live 入口,引导用户尝试新业务,其推广意图十分明显。通过入口进入后,用户可以获得更为丰富的 Live 内容,可依照时间线、热门、分类以及其他多种推荐方式选择 Live 。用户点击并支付票价(由答主设定)后,就能进入到沟通群内,可通过语音分享专业有趣的信息,通过即时互动提高信息交流效率。
借助实时问答方式的知乎 Live 更像是「线上课程」,良性的讨论范围让用户对话题有进一步的思考,而讲者通过分享自己的知识经验,也为用户开拓了视野。更重要的是,知乎Live的推出也是知乎平台化的关键策略,“知识变现”正以多种方式在知乎的平台上发展起来。用户也通过Live的多专业领域视角,集中时间学习,丰富个人知识库。在有需要的情况下,未来的产品形态可以增加PPT配合语音的形式,丰富 Live 实现方式。

4.7 知乎圆桌

类似于线下活动的嘉宾讨论会议,知乎圆桌的主要形式为线上邀请行业精英作为嘉宾对话题共同发表见解,在话题之下分享行业知识以及自身的探索与洞察。用户可以对主题提问,邀请参与活动的各位嘉宾回答。

知乎圆桌为用户和各专业领域的优质嘉宾提供了交流接触的途径,用户能与受邀嘉宾及其他用户展开高效有序的讨论和交流,满足用户的社交需求和品牌(主办方)的推广传播需求。

5. 竞品分析

5.1 市场分析

据易观数据 2016 年 12 月 2 日发布的《中国知识付费行业发展白皮书 2016 》,近年来我国居民人均可支配收入快速增长,消费结构发生变化,人们对于“内容”和“知识”的付费意愿和消费逐渐发生改变,从不愿付费变得对于显著高质量、服务更好的类似产品愿意付费;同时随着移动互联网和移动支付的普及,人们的消费方式也发生了根本性的变化;人们获取信息的方式也从漫无目的地接受变为主动获取知识,信息的选择行为更为成熟。这些基础条件日渐成熟,推动知识付费行业成为新风口。

知识付费不同于生活服务(交通、饮食等)「高频 + 刚需」的应用场景,知识交易的频率相对低且个性化程度高。但基于知识分享的供给需求、用户对专业型高质量优质内容的认知渴求,对高效利用碎片化时间充实自我的提升渴求,知识付费行业仍存在巨大的潜在市场。这也成为了知乎潜在的市场机遇和发展空间。

2017 年 3 月 5 日,ALEXA 排名显示,zhihu.com 综合排名居中国第 29 位。在移动端,根据 appannie 知乎 iOS 版本中国区排名显示,其在社交类 app 中国区下载量排名最近一年基本稳定在 10 到 15 位之间。知乎创始人兼 CEO 周源在 2016 年 10 月 28 日广州“知乎品牌开放日”上提到,截止至 2016 年 9 月,知乎已经拥有 6000 万注册用户,平均日活跃用户达 1600 万,人均访问时长达 40 分钟。目前,知乎已成为国内知识型社交的代表型产品。

5.2 竞品分析

笔者将百度知道、果壳、简书、分答作为知乎的竞品分析对象,从多角度进行对比分析。

5.2.1 问答(百度知道)

  • 主要功能对比:相对于知乎,百度知道将「提问」置于最高优先级,其「提问」入口被置于一级菜单,用户只需简短的流程即可提交问题。知乎与百度知道都支持图片和匿名,百度知道采用悬赏的方式来激励用户回答问题,反馈效果更加显著。由此可见,可见百度知道在提问便捷度和反馈速度方面略胜一筹,更加注重用户迅速得到问题的解决。但百度知道的信息同步还不及时,问题得到解答时应同步更新提问记录的状态。由于百度知道将「问答」入口放在首页的顶部二级菜单中,因此知乎需要点击两次才到达的页面在百度知道一步即达。进入「问答」页后,用户会看到默认有「推荐」「最新」「高悬赏」三个二级菜单。从答案呈现方面看,尽管百度知道也允许用户点赞,但并没有像知乎一样采用点赞筛选机制,也不会对没有帮助的答案进行折叠。用户通过知乎搜问题只会得到高质量的解答,而百度知道默认呈现所有答案,对用户来说,后者的选择更多但耗时也多,因此知乎会显得更高效和专业。在回答撰写页面上,百度知道直接罗列所有支持功能,不提供「禁止转载」也不能自动保存,但会默认呈现题目,解决用户不想放弃作答又想看回题目的需求。
  • 核心策略对比:目前的百度知道只停留在问答社区的层面上,并主要作为百度搜索引擎的一部分加以维护。作为百度搜索的子模块的好处便是引流,用户无法直接搜索到的信息有时可以通过百度知道获取。但相比知乎的强社区性,百度知道用户粘性不强,大部分用户只有在使用百度搜索时才会从百度知道上获取信息。百度知道通过悬赏激励方式促进知识流通,盈利模式不明朗。此外,个人认为百度知道上的用户质量与内容质量明显不如知乎,知乎在其专业领域的高质量用户和优质内容,比百度知道不知道高到哪里去了。

5.2.2 社区(果壳)

  • 产品对比:知乎专注于问答社区的搭建,带有浓厚的知识属性,是一个多领域经验交汇并且可以实行互动的优质平台。果壳网专注于科学领域,发展方向是兴趣社区,相比媒体性质之下的社区属性要薄弱许多。
  • 模式对比:知乎在拥有了一大批高质量用户后,能够保证优质内容的输出。在沉淀了高质量用户和优质内容后,用户粘性提高,盈利模式的可操控性更大。果壳的媒体性决定了其信息流动快,能够第一时间掌控热点,且其内容的真实性与权威性更具保证。但其用户的存在感较低,社区性质薄弱,很容易降低用户粘性。
  • 发展机会:知乎在积累用户量的同时,正在推广优质问答的衍生产品,包括目前已经推出的值乎、知乎书店和知乎 Live ,逐步在寻求最合适的盈利方式。果壳网利用丰富的线下活动,既可以做到对自己产品的推广,同时还能够建立起有群众基础的兴趣社区推广,丰富自己的产品线(包括2016年推出的分答)从而达到盈利的目的。

5.2.3 写文章(简书)

  • 主要功能对比:知乎与简书的界面都保持着简洁的风格。简书主打写作与阅读服务,其「写文章」的入口在一级菜单中,相比于知乎更加注重「写作」这一功能。简书提供比知乎更加强大的编辑器,排版功能更加丰富。相比而言,简书在「写文章」的用户体验上略胜一筹。相比于知乎专栏以「分享」为核心的思想,简书更类似于个人博客的升级版,记录技术与专业知识,同时提供社区化的阅读体验。
  • 核心策略对比:简书是一个将写作与阅读整合在一起的产品。旨在为写作者打造最优秀的写作软件,为阅读者打造最优雅的阅读社区。相较于平台化、产品线丰富的知乎,简书的定位较为单一。也希望知乎能够下功夫提升内容输出者的写作体验。

5.2.4 付费语音问答(分答)


分答无疑是2016年度最引人注目的付费语音问答,果壳不仅在产品定位上独具科学气质,同时在战略上积极探索,带着满身锐气推出分答这一「网红经济的语音回答变现」的新颖形式。依靠诸多网红作为种子用户进行推广,分答以高速度实现用户量增长。知乎在知识分享领域深耕,在用户量与内容的沉淀之后,依靠优质专业内容推出「知乎 Live 」。两者有不同的气质与基因,还需要在各自的领域继续深度挖掘,之后的局势走向也取决于两者的具体行动。

分答的主宰是网红偶像,背后是千军万马正在觊觎的网红经济,知乎的主宰是KOL,背后是少数高端人群的知识经济,分答创造不了大规模的知识,知乎孕育不了注意力引爆的网红经济。

6. 改进建议

6.1 精简功能结构

目前的知乎iOS客户端主题分为五个标签栏。在着力于推广「知乎书店」「知乎 Live 」产品时,精简功能结构而将用户的注意力集中在产品的核心功能上尤为重要。按照目前的标签划分,猜测知乎有一颗做社交的心。但依照目前的发展趋势,知乎更应该以问答社区为核心,加大力度推广知识衍生产品。「私信」和「通知」两个较为单薄的功能可集成为「消息」,在发现页着力推广「值乎」「知乎书店」「知乎 Live」等周边产品,并适时推出独立 APP。

原来添加新私信的图标与首页「分享」icon 相似,不能直观反映信息,建议修改。

6.2 调整个人资料界面

在深度体验知乎时发现一个有趣的现象,用户可以同时在五个标签页停留在个人资料界面而不显示应属于本标签栏的内容。「答案」与「个人资料」都属于集中性极强的信息,既然目前「答案」以独立页面形式显示,那么个人资料页也应如此。

笔者调整了个人资料页的布局,增添了搜索入口,可以解决目前知乎不能在用户的主页输关键字搜索内容的问题。同时,知乎应为关注用户提供分组功能,布局重新调整后也可添加编辑用户分组的功能。

6.3 强化搜索功能

知乎的搜索功能,对许多用户而言,不仅是获取关键词回答的入口,更是相对于百度更加专业化的「搜索引擎」,深耕搜索功能对于提升知乎的用户粘性十分重要。

提供「屏蔽0回答的问题」、「按问题回答数排序」等搜索排序可选项。

6.4 改进评论系统

目前的评论推送形式「XX人评论了你」、推送「XX人回复了你的评论」,且答案评论区排序混乱、查看对话功能重复,单页显示信息量有提升空间。建议在评论信息推送时用户可直观收到评论内容反馈,并且在评论区收纳关联评论,提升评论区单页显示的信息量,按照热门 – 最新的排序方式排列评论。

6.5 提升首页用户体验

「首页」对于一款软件无疑是至关重要的,更是知乎用户日常使用中浏览的集中区域。知乎要提升首页推送的用户体验,避免无效信息、重复信息的重复出现污染 TimeLine。并且继续增强反垃圾反作弊手段,将打击水军、恶意评论,过滤劣质问题、回答的力度加大。

6.6 鼓励提问

知乎可以增设对提问者的奖励机制,目前知乎对优质回答的输出者关注度很高,但是发现优质问题的用户却没有得到应有的关注,一定程度上会打击用户的提问积极性。

7. 总结

总之,知乎已经从当初的问答社区逐渐发展成为了面向广泛知识消费者和机构的大型知识平台。知乎正在展开更多产品探索与市场创新,以用知识连接一切为使命,朝着「知识连接的基础设施」不断前进。

在商业模式上,知乎已经开始走上了变现的道路。如今的知乎已成功打造以知识分享为核心的商业闭环,正从内容社区升级为服务平台。当用户寻求一个领域的知识与能力提升或对一个问题产生兴趣,不仅能通过搜索栏查找到相关问题,查看优秀答主的专栏,而且可以在知乎商店读一本电子书,在知乎 Live 上预约一场线上课程。随着国内「知识付费」的氛围逐渐变好,知乎的核心竞争力也会愈加凸显。利用沉淀的优质内容和高质量用户,知乎的发展态势十分明朗。

对知乎未来的憧憬:

  • 以知乎优质内容库为起点,打造高质量专业知识搜索引擎。
  • 以知乎Live为起点,打造一个新型在线教育平台。
  • 以知乎书店为起点,打造网络出版与付费阅读的电子书平台。
  • 以值乎为起点,打造付费问答的知识交易平台。

 

原文地址:https://zhuanlan.zhihu.com/p/25562245

【转载】App组件化和模块拆分那些事儿

前言

最近事情比较多,2个月没写文章了。看笔者圣诞节还在写技术文章,就知道程序猿的生活有多惨淡。

上几篇单元测试的文章,笔者已经把大部分思路讲给大家听了,如果在开发中有新的思路和技巧,以后给大家分享。

接下来,想给大家讲讲App项目的组件化与业务拆分。

如果上Google搜“App模块化”、“App组件化”,可以出现一堆文章教你“如何组件化”、“组件化用到什么技术”,笔者经常搞不清他们说的“组件”、”模块”、“业务”到底怎么划分,很多作者对这几个概念都有不同的理解。这导致笔者当初在搜集这方面资料,非常尴尬,每看一篇文章都有地方跟之前的文章冲突,也不知道谁对谁错。

本文会从业务的角度,给大家讲讲为什么要拆分App业务,如何拆分,以及优点等等。


为什么要组件化、模块化

项目存在问题

  • 代码量大,耦合严重
  • 编译慢,效率低
  • 业务开发分工不明确,开发人员要关心非业务的代码
  • 改代码时,可能会影响其他业务,牵一发动全身

优点

  • 架构更清晰,解耦
  • 加快编译速度
  • 业务分工明确,开发人员仅专注与自己的业务
  • 提高开发效率
  • 组件、业务独立更新版本,可回滚,持续集成

组件化与模块化

组件、模块,中文字面意思相近,在英文上都可以翻译为“Module”,加上Android Studio上,library被称为”Module”,这就不难解释为什么我们谈到“组件化”、“模块化”,两者之间的区别相当的模糊。

组件

App工程上所说的 组件,应该翻译为“Component”,意思是组件、部件、元件。在电子电路中,电子元件是电子电路中的基本元素。在App工程上,组件是构成业务或者功能模块的基本单位。原则上,组件与组件之间互不依赖。

组件,components

例如,图片上传功能,应该叫“图片上传组件”,而不是“图片上传模块”。因为图片上传从功能、业务上,已经不能往下拆了。图片上传可能使用七牛sdk,或者又拍云sdk。无论图片上传组件用七牛sdk,还是又拍云sdk,都不会影响这个组件的功能,因此组件具有可替换性;同时,图片上传组件可以被多个业务使用,因此组件具有可复用性。由于sdk只是技术细节,它跟业务并没有关系。在业务架构图上,也不会出现“xx sdk”,因此我们说图片上传组件不能拆分了

同理,日志功能,叫“日志组件”,不叫“日志模块”。

模块

模块翻译为“Module”,字面意思。模块由多个组件构成,它可以实现一个独立的功能,甚至业务。

模块,module

例如,大众点评的美食功能,是一个业务,可以叫“美食模块”,习惯上叫“美食业务”。它可以拆分更小的模块:搜索、签到、评论等。

两者关系

从上面的阐述可以得出,一个工程,由多个模块组成,每个模块由多个组件构成。但很多时候,两者界限还是相当模糊。例如“日志组件”称为“日志模块”,也没有违和感。

  • 组件从业务角度上不能继续拆分,可替换,可复用
  • 模块的定义比较笼统,可以是一个Business业务,可以是技术架构中一个业务,也可以是几个组件构成的小功能。

无论是组件化还是模块化,目标都是把臃肿的工程,拆分为更小的部分,解耦各种复杂的逻辑,便于代码管理。


业务划分

一个产品的业务,其实是在规划产品功能,或者做产品原型时,已经定好了(如果连产品或者老板都没这概念的话,我们还是算了);如果后端牛逼的话,他们也会做业务划分,每个业务部署到独立的容器、虚拟机、服务器。所以,我们做业务划分时,可以咨询后端,也可以咨询产品经理。

例如,大众点评,首页已经展示了好多个业务:美食、电影、酒店、休闲娱乐、外卖、机票/火车票….. 这种多业务APP,通常会把业务尽量展示在首页,这种APP大的业务很好划分。美食、电影这类看起来完全不同的业务,笔者称为Business业务

大众点评-首页

但并不是这样划分就OK了,好像大众点评这种超级APP,每个Business业务都能分成很多基础业务。例如,美食业务,可以搜索商铺、预约、使用优惠券、点评、签到等;同时,电影业务也有搜索、优惠券、点评等。所以,搜索商铺、优惠券、点评这种基础业务,可以独立出来,被多个Business业务使用

业务架构

组件与业务

上文提过,多个组件构成一个模块,当模块相当于业务时,就是说该业务由多个组件组合而成。

还是拿大众点评做例子,点评基础业务,发布点评需要上传图片、网络提交、记录本地日志等,那么需要调用上传图片组件、网络组件、日志组件等

点评业务-组件

不仅仅点评业务调用,所有业务都会调用这些组件。于是,业务架构如下:

Business业务 -> 基础业务 -> 各种组件

业务-组件架构

业务与业务

情景

场景:在大众点评订了酒店,入住之后,打开该酒店详情页,大众在“推荐列表”给你推荐若干大保健……
(不要问笔者大保健是什么,笔者什么都不知道)

情况1:

前端H(负责酒店业务H):后端D,麻烦给酒店业务单独做个推荐大保健的api。
后端D(负责大保健业务D):大保健业务api D,你调用api D

前端在酒店业务Module,写了调用api D,功能上线。

=============================================================
过了一段时间,大保健业务做了调整,数据变动、改域名等。

后端D:前端H,api调整了,麻烦调用api D改为调用api D1
前端H:现在好忙,我加班搞吧。

于是前端H加班改代码,还要做单元测试等一系列工作。

=============================================================
又过了一段时间,大保健业务再次数据变动。

后端D:前端H,api D1改成api D2
前端H:怎么又改…..

本来前端H是做酒店业务的,为了大保健的推荐列表,不得不因为大保健业务调整,而加班加点。再延伸一下,如果酒店业务H还需要调用电影院列表、美食列表…..每个业务的改动,前端H就呵呵了。

情景2:

当然了,要前端不改动,后端保持原来api D也可以的。只不过,会引发下面对话:

前端H:后端D,不过你一直提供api D给其他业务使用,当数据调整时,api D做好兼容我们就不用改了。
后端D:你傻逼啊,兼容多麻烦,我们很忙的,你们不就改一点代码吗?我们还要#&^@&#$”@*#……

维护兼容/对外开放接口确实是一种解决方法,只不过会加重后端开发、运维的工作量,长期来看并不科学。

情景3:

如果在前端业务与业务在独立的情况下,也可以相互调用,那就简单多了:

前端H:前端D,麻烦写一个接口,让其他前端业务可以请求大保健推荐列表。
前端D(负责大保健业务D),没问题,你调用D类getHealthCare(),就会请求大保健推荐列表,并返回你要的数据了。

=============================================================
过了段时间,大保健数据变动。前端D在前端大保健业务D做了api D->api D1改动,并对D类getHealthCare()做了数据兼容,前端H不需要额外改代码。

从上面3个情景看,情景3是最优的做法,前端H并不需要跟后端D对接,大保健业务D改动,后端D不需要通知前端H,只需要跟前端D对接即可。而前端的兼容工作,比后端兼容工作要简单得多。

业务之间跳转

业务之间跳转,这个话题老生常谈了。无论是Android、iOS,都是URL Scheme跳转这种解决方案。原因是url不需要任何依赖,而且可传递参数。

业务数据交互

无论前端、后端,业务之间数据交互,都是很重要的环节,选用何种合适的方案,就考验架构师的水平了。

未做业务拆分时,直接调用其他业务的代码即可:

数据直接交互,强耦合

但业务拆分后,就不能直接调用代码了。两个业务相互独立,代码互不依赖,必须用某种协议(常用json)用数据。

间接交互,服务中心做数据中转

如果其他业务需要获取大保健数据,首先大保健业务要注册大保健服务到服务中心,其他业务才可以通过协议调用这个服务。

业务相互调用-服务中心

如何注册服务,Android和iOS都有不同的做法,而且方法不止一种。本文仅提供思路,技术细节,会在之后的文章阐述。

其实组件与组件之间,也存在相互调用的情况,可参考这种做法。

P.S.大众点评没有“大保健”业务,只有“足疗按摩”业务。笔者为渲染气氛虚拟一个大保健出来,希望大众的朋友谅解。


小结

组件化、拆分业务后:

  • 单一职责:开发人员专注于自己的业务
  • 依赖倒置:上层业务依赖下层业务,业务依赖组件,业务之间、组件之间不相互依赖
  • 接口隔离:业务之间调用数据,通过统一的协议与服务中心交互,不调用业务实际代码

代码质量与规范程度明显提高,高内聚、低耦合。业务职责分明,单元测试也更好写。如果业务拆分做得好,可以一个业务一个单独工程编译,不仅大幅提高编译速度,而且业务代码还可以回滚、版本发布等。

一切为了更清晰的架构、更干净的代码^_^。