移动App设计常见功能点

本篇文章本想着写技术实现来着,写着写着写成了产品。产品就产品吧,之后我再按这个大纲写技术实现。这是一个不小的工程,每个点每个平台都是一篇文章。目前未完待续,先发一下大纲再持续更新。
这是一篇枯燥无味的文章,连个图都没有···

程序中常见且通用的几个点

登录

如果程序涉及到会员注册用户,那么登录是必不可少的。用户模块会在很多的程序中见到。
应用程序做会员有诸多好处
一、成为注册会员方便了对于用户的管理与分析,包括活跃用户与留存用户等。
二、通过对用户的奖励机制,能够提高用户粘度,提高用户留存
三、通过账号的关联关系,用户可以实现多端数据同步
还有其他等等
当然也有一些坏处,如
一、用户反感登录采集个人隐私数据
二、注册登录流程麻烦,使用户失去兴致
常见登录方式罗列了一下,也是各有有缺点

账号登录

账号登录是互联网初期最常见的一种登录方式,也是在程序员学习时最常用到的方式。这种方式实现起来也简单,而且也不需要采集过多的数据。对于一个用户来讲,只需要有个账号和密码就可以。对于个人信息,可以说是采集度最低。
但是对于这种登录,弊端也是很大的。
首先账号的随意性大,没有什么规律。如果是数据库后台没有做字符限制的话,那也会有一些风险,比如特殊字符SQL注入之类的。
其次,对于用户来讲,账号可能是随意起的,如果不记住账号的话,很容易就忘掉了。本来密码就已经难记了,账号也想不起来是啥,会让用户放弃使用,或者直接注册一个新的账号。这也导致了留存很多僵尸账号。
还有,如果仅仅是账号密码,那么用户忘记密码找回也会变得非常的麻烦,因为没有一种其他方式来校验用户是否是当初的注册用户。
移动端建议减少使用账号密码的方式去登录,当然也有例外。比如说某个管理软件的管理员,工具类软件,企业内部软件。这些软件往往使用范围有限,面向群体有限,账号可能还是统一分配的,这个时候还是采用了账号密码的方式去进行登录。局域软件或者单机软件登录,也只能使用账号密码的方式进行验证。
还有一个案例是QQ,QQ账号是互联网早期的登录方式,但是由于人们的广泛使用和高频率使用,QQ账号已经不仅仅是账号了,而成为了一种身份标志。账号登录做到这种程度,也是非常厉害了

邮箱登录

邮箱登录也是非常常见的一种登录方式,仅次于账号登录。但这种方式也是多用于pc端网站的一个登陆,移动端用邮箱登录的比较少。因为邮箱在移动端的验证方式并不是特别的方便。需要接受邮件,打开邮箱软件或者浏览器,然后再填入邮件收到的验证码。这种方式就比较冗余。pc网页一般是邮箱收到一个URL,点击跳转验证。这种方式适用于pc的网页端,作为移动端来讲,就不是那么合适。

手机号登录

手机号登录是作为移动端最常用的登录方式,手机号登录也是有着非常大的优势。
一、手机号格式固定,校验简单
二、短信接收验证,手机比较方便快捷
三、手机号用户容易记住 ,不易忘记
四、找回密码比较方便
五、对于推送给用户一些信息可以采用短信电话的方式,渠道更宽
不过手机号也有一些问题,需要注意
一、当用户手机号丢失,将面临盗号风险
二、当用户手机号丢失或注销,找回密码会比较麻烦
三、用户对于手机号隐私,不愿意注册使用手机号
四、对于短信电话消息,会引起用户反感

软件设计来讲,手机号的劣势往往是被忽略的,因为劣势也仅仅是少部分,带来的优势是非常巨大的。但作为成熟的软件,最好是要多多考虑

混合登录

混合登录是把账号登录,邮箱登录,手机号登录三者混合在一起,都可以作为账号进行登录。对于后台人员来讲,就需要判断验证是那种账号,然后去查询哪个字段。(先验证再查询可以减少数据查询交互,提高效率。当然也可以使用遍历的方式,一项一项的查询,直到查询到匹配账号为止)
混合登录给了用户更多的一个选择,也可以实现多账号统一。目前也有多家采用这种混合登录的方式,弥补了各项登录的不足

第三方登录

第三方登录是目前已有用户量的大佬,开放授权给各个新平台使用用户数据的一种方式。比如现在的QQ、微信、微博、GitHub等等。
第三方登录可以实现快速的用户流量转移,不需要自己去维系账号。基于现有平台的用户量,实现自己平台用户积累,简称“抱大腿”。而且作为软件角度来讲,不需要维系账号,就是不许要考虑账号安全,账号丢失找回这些麻烦事。
对于用户来讲,授权登录也是非常的方便,也不需要额外的记录账号密码,只需要授权登录就可以。也不用担心自己账号泄露的问题。
虽然第三方登录非常的方便,优势也很多,但是账号毕竟 是人家第三方的,一个谈不拢不让你用了,损失就大了。用人家 的就得受到人家的管制,遵守人家的规则。
还有,每个企业每个程序都希望自己做大做强,日活千万用户过亿,老指望这第三方平台可是不成,那是必须得做上自己的用户登录

其他登录

其他还有一些登录方式,比如身份证号登录,银行卡号登录,这些还是基于账号登录的一个变种。
也有基于硬件的登录,比如指纹登录,人脸登录这些生物特征登录。不过这些一般不做为账号主体,仅作为账号认证。比如支付宝指纹登录,人脸登录,首先也是有一个账号在那。指纹人脸替代的仅仅是密码部分。
还有基于设备的,每个设备作为唯一识别账户。由于设备的物理特性,持有设备即认为可以使用,设备的认证交由设备管理。举个例子:手机本身有锁屏,那么有能力解锁的人即认为是当前用户。app则直接获取设备的唯一标识,作为用户记录。那么也不许要用户登录和输入密码,就可以使用软件并拥有用户身份。

分享

分享到QQ、微信、微博等社交平台。

一般采用鼓励分享机制,即分享可以带来一定的利益好处,常见于游戏类或积分会员类程序。这样可以迅速扩大程序的影响力,获得大量的用户流量。但是分享功能也需要慎用,分享内容也需要控制。推广类分享会遭到用户反感,特备是朋友圈内这种私密的用户圈。

还可以采用内容分享,即分享的是有一定的内容,常见于新闻视频类程序。这类分享也会常见于朋友圈,用户看到有意思的内容会自发乐意分享。对于购物类而讲,商品一定是需要内容分享的,商品类分享一般常见于分享到个别的用户。

分享的平台是有对程序的审核,也需要遵守相应平台的规则。当然平台也可能会根据利益去封杀你的分享内容。最近抖音短视频就遭到腾讯管制,这不能怪腾讯,毕竟平台是人家的。

统计

统计是作为运营最基本的判断依据,一个好的程序软件必然要进行运营,也必须的对于app进行数据采集分析,然后根据数据反馈提出改进 。
不过统计功能也是常常被忽略的功能,因为也不是每个公司都有运营,都会考虑使用数据。
数据分析一般分为:数据采集,数据清洗,数据分析,数据呈现
在app端做好数据采集,做好打点。打点也是根据想要采集的数据进行打点,也要确保打点的准确和粒度范围。举个例子,想要采集用户按钮的点击事件,但其实按钮是有touchstart,touchmove,touchend,tap,doubletap等等这些事件,都是跟按钮点击相关的,那么在哪个方法上进行打点统计,统计的粒度,也是需要思量的。
数据采集一般是用一种格式会方便解析与展示。采集的数据一般有
行为:用户操作动作,如点击,浏览,触摸,输入等等
数据:行为产生的数据,如点击位置,携带的其他数据等等
时间:产生的时间
来源:统计的来源,如iOS平台,android平台
分类:自定义分类信息,同一类的做统计处理
平台信息:系统版本等等
其他等等

crash分析

当程序崩溃时采集的信息,一般是由定时发送到服务端。分析崩溃原因用以改善程序。常见的可以用腾讯的bugly,友盟crash统计等。其实crash分析也可以看做是一种特殊的统计需求。

消息推送

消息推送也是作为程序中常见的一个功能。对于不同的平台实现原理也不一样,推送效果也是不一样。iOS平台有官方的apns推送处理,而android是需要开发者自行处理推送的。
为了保证推送的实时性,手机是与服务器一直保持着通讯。iOS还好,是统一管理,android则是要一直开启着service去进行交互,这也会有资源的消耗。不过现在android也有平台厂商的官方推送,也是很大程度上去优化了这一部分内容。
不过对于推送我们也可以直接使用现有的一些第三方,比如友盟、极光等,这样也减少了考虑平台的差异性,降低了编码的难度,减少了服务的内容。

程序中其他功能性功能

这些移动端会用到,但不是每个App都可能会用到

音视频

一般音视频播放器使用系统提供的就可以满足需求 ,其实音频实现起来并不是很麻烦,麻烦的是多种状态的控制。我之前做的音频播放器就需要考虑与视频的互斥,全局的音频控制播放,锁屏界面的音频控制与播放。这些状态需要维护好。但是单纯的从播放的角度讲,实现其实并不是很麻烦。
视频播放模块是比音频更加复杂一些,因为视频相较于音频操作更加丰富一些。但其实系统提供的也够用。
目前也有很多封装的第三方音视频播放,我没用过也不是很了解,不能判断好坏。

还有是基于流媒体的一个播放,流媒体就设计到网络传输,音视频编码解码。服务器端也需要对视频进行分段切割编码。自己实现起来就比较费劲。不过现在有很多流媒体服务,可以是用他们的服务和SDK进行接入,这样研发成本会大大降低。
其实有个非常好用的音视频处理框架 FFmpeg,相信做过音视频的人就会对这个有所耳闻或者正在用这个。而且有许多基于FFmpeg的第三方音视频框架。FFmpeg是一个强大的音视频处理的程序,但是学习 成本也高,一般非专业音视频处理也可以不使用,有句话是说“杀鸡焉用宰牛刀”,大概是这个意思。

如果是做音视频编辑的话,那还是使用FFmpeg进行操作比较方便也比较专业。

即时通讯

即时通讯越来越多的被许多App使用。第一个把即时通讯做成主业务的也就是腾讯了。即使后来大家都掌握了即时通讯的技术,也很难颠覆腾讯帝国。
即使通讯一般是采用长连接进行通讯,最基础的网络层协议就是TCP。不过TCP虽然提供了通讯链路保障,但是用TCP通讯还是比较底层,虽然能实现,但是对于数据处理,安全性、通讯效率等等还是要有很多事情要做。所以基于TCP协议还有一些上层协议为了解决即时通讯问题,其中广为使用的就是MQTT协议。MQTT的优点是:协议简洁轻巧,数据冗余量低。并且支持的设备从智能硬件到智能手机无所不包。缺点是服务端开发难度大,学习成本高。
即使通讯要是做起来还是有很多需要考虑的事情,并不是一个通讯协议就可以实现搞定。比如移动端要和服务器建立实时的通讯,接收消息 需要进行通知,即时通讯双方的关系对应,好友的维护,消息的解析(文字,语音,图片视频等等)
当然我们可以选择比较成熟的第三方,比如环信,融云等,这样可以大大减少开发的成本,而且开发起来也相对容易。只不过就是用第三方的就要遵循第三方的规则,通信数据也是经过第三方的服务,还有就是收费费用与研发费用的比较。

地图

国内一般都是采用百度地图或者高德地图实现,实现起来也算比较容易。官网都有很详细的文档介绍。之前也写过腾讯地图与高德地图的文章

支付

支付接入支付宝,微信,财付通,百度钱包,银联等等。当然我们可以选择单个的接入,参照各个平台提供的文档。也可以选择使用集成的第三方,如ping++。之前用过ping++觉得也是蛮好用的。

语音识别

语音识别做的不错的我们可以找到讯飞,不过现在各大平台都有OCR服务,比如腾讯、阿里、百度这三大巨头。
如果想要把语音识别做的比较好,那么还得考虑音频的采集处理。一般手机会有多个麦克风进行采集语音数据进行处理,而网页的表现就会差很多。
现在语音成为智能设备控制的一股潮流风,各家的智能音箱争相发展。目前带系统的一般是基于android的进行实现,android的应用市场还是蛮广泛的。

人脸识别

人脸识别face++ 做的还是不错的,就是价格得考虑一下

加密解密

常见MD5、URLEncode、DES

二维码

ZXing ,zBarSDK,iOS原生识别,比较炫酷的EFQRCode

程序设计

分层架构

mvc,mvvm

网络

iOS:AFNetwork、YTKNetwork
Android:OKHttp

请求方式

请求时机

请求内容

内容缓存

数据

本地存储

数据操作

数据操作的一致性

界面

界面设计

界面性能

控制

生命周期

程序设计中注意的地方

功能模块独立(高内聚)

功能间互不影响(低耦合)

稳定性与可靠性

安全方面

版权声明:本文为rqzdh原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/rqzdh/p/14765201.html