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

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

登录

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

账号登录

账号登录是互联网初期最常见的一种登录方式，也是在程序员学习时最常用到的方式。这种方式实现起来也简单，而且也不需要采集过多的数据。对于一个用户来讲，只需要有个账号和密码就可以。对于个人信息，可以说是采集度最低。
但是对于这种登录，弊端也是很大的。
首先账号的随意性大，没有什么规律。如果是数据库后台没有做字符限制的话，那也会有一些风险，比如特殊字符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

请求方式

请求时机

请求内容

内容缓存

数据

本地存储

数据操作

数据操作的一致性

界面

界面设计

界面性能

控制

生命周期

程序设计中注意的地方

功能模块独立（高内聚）

功能间互不影响（低耦合）

稳定性与可靠性

安全方面