没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
app 后端设计
作者:曾健生,博客专栏:http://blog.csdn.net/newjueqi ,qq:190678908
目录
前言 .................................................................................................................................................. 2
app 后端设计(1)—api....................................................................................................................... 3
app 后端设计(2)--xmpp 的使用 ....................................................................................................... 7
app 后端设计(3)--短信,邮件,推送服务 ..................................................................................... 9
app 后端设计(4)--通讯的安全性 ................................................................................................... 10
app 后端设计(5)--表情的处理 ....................................................................................................... 12
app 后端设计(6)--LBS ..................................................................................................................... 13
app 后端设计(7)--项目管理 ........................................................................................................... 16
app 后端设计(8)--数据库分表 ....................................................................................................... 19
app 后端设计(10)--数据增量更新 ................................................................................................. 21
app 后端设计(11)--系统架构 ......................................................................................................... 27
app 后端设计(12)--图片的处理 ..................................................................................................... 28
app 后端设计
作者:曾健生,博客专栏:http://blog.csdn.net/newjueqi ,qq:190678908
前言
曾经,我也是一直从事网站后台的开发,因为一些机缘,踏进了移动 app 后台,之前对
app 后台没什么了解。
曾经,我们连续一个月从早上 9 点工作到晚上 10 点,就为了改进后台的架构,提供性
能,让 LBS 的服务响应时间从十多秒提升到 1 秒内。
曾经,我觉得 app 后台架构上和传统的网站上有很大的区别,现在发现,其实很多思想
都是通用的。
曾经,我在后台架构犯过很多问题。有一天,忽然想:如果把遇到的问题的解决方案都
记录下来,不就能让别人少走弯路吗?于是,就有了“app 后端技术架构”这个技术专栏
(http://blog.csdn.net/column/details/mobilebackend.html)
后来我又想,为啥不建立一个后台交流的 qq 群,把对这方面有兴趣的小伙伴集在一起,
大家互相交流学习呢?于是,就有了“app 后端技术”qq 群:254659220
为了方便小伙伴阅读《app 后端设计》系列文章,于是我就把这系列文章制作成下面一
个文档。这个文档上的文章,大多数是本人在 2012,2013 年中开发社交 app 后台时的工作的
总结,现在看来,很多技术性的东西都已经过时了,但有些思想上的东西,还是有一定的参
考价值。请阅读文档的各位小伙伴注意:最新的文章,请到本人的博客
(http://blog.csdn.net/newjueqi)上阅读,我会不定期更新里面的内容。
分享越多,收获越多!!!
app 后端设计
作者:曾健生,博客专栏:http://blog.csdn.net/newjueqi ,qq:190678908
app 后端设计(1)—api
(1) Restful 设计原则
Restful 风格:RESTfu 设计原则,它被 Roy Felding 提出(在他的”基于网络的软件架构“论
文中第五章)。而 REST 的核心原则是将你的 API 拆分为逻辑上的资源。这些资源通过 http
被操作(GET ,POST,PUT,DELETE)。
但现在看,一般的操作只有两种:GET ,POST。
这个设计原则最简单的应用就是根据 object 而不是页面来设计 api。最开始的时候,app
的一个页面需要什么数据,api 就返回什么数据。结果随着 app 的 UI 不断改版,需要的数据
不断变化,不停地修改 api,最后当 api 的改动会影响以前的版本的时候,只能写一个新的
api 版本,最后弄得 api 中有很多_V2,V3 这样的标志,恶梦!
后来在网站的重构过程中,就根据 object 来设计 api,但根据 object 来设计,又有一个
问题,一个大 object 可能包含很多小 object,是一个 api 返回全部小 object,还是分为多个
api 返回?根据业务和技术,带宽等仔细考虑吧。
(2) api 的命名
其中一个原则,一看 api 名字就知道这个 api 是干啥。在创业团队中,一般就只有一个
人负责后台,当你要负责几十甚至上百个 api,你就知道不能“望名知 api”是个什么样的痛
苦。
(3) 安全性
请看 http://blog.csdn.net/newjueqi/article/details/18887571
(4) api 返回数据
app 客户端的语言 java 和 object-c 都是强类型语言,所以怎么处理空值显得特别重要,
不合理的设计很容易造成 app 的闪退。
从后台的角度来说,api 中返回的数据中,正确值和空值的类型必须一样,举例,用户
名的字段是“realname": "xxx”,如果用户名为空,则应该返回“realname": ""。如果返回值
是一个 array,空数据则返回一个空 array,绝对禁止 null 值。
对于客户端,必须用个全局的函数来处理所有 api 的返回数据,需要有一个机制:对于
某个客户端需要数据,如果 api 中缺失,客户端自动补上并给予默认值。这个机制在我们的
实践中大大减少了 app 的闪退。
同时,在数据库设计的时候,一个合理的设计必须是所有字段都有默认值,不应该允许
null 值。null 在大量的语言和数据库中,会带来无穷的问题。对于这个数据库设计原则,我
app 后端设计
作者:曾健生,博客专栏:http://blog.csdn.net/newjueqi ,qq:190678908
以前不太明白,现在经历了一年的 api 设计后,终于懂得。
如果客户端是 php,还有一个问题,php 中数组和字典都是 array,但在 java 和 object-c
中是不一样,这个问题一定要注意。
(5)图片的处理
在不同版本的 app 中,各种不同尺寸的手机中,同一张图片显示的尺寸可能是不一样,
如果每次都需要用返回原图,然后在客户端处理,则极大浪费网络资源。而如果是后台处理
好图片才返回,则又是一个挑战,怎么有效保存和裁剪多种图片尺寸呢例如,一开始头像只
需要返回 60*60 的尺寸,后来在新的版本需要返回 70*70, 又出了一个新版本,需要返回
80*80, 每次增加一个新的尺寸,怎么在数据库上记录下来。这个问题在一开始做 api 的时候
没考虑,后来不得不用了一个极端的方法,没增加新的图片尺寸,就在数据库中增加一个新
的 字 段 , 保 存 并 生 成 新 的 图 片 尺 寸 , 结 果 最 后 数 据 库 的 头 像 字 段 有
"avatar","avatar_60_60","avatar_70_70","avatar_80_80",这种极度恶虐的设计。
最后,针对图片,我们才用了这样的策略:(1)客户端本地缓存图片,只有没有合适的
图片,才去服务器取。(2)当客户端需要某种尺寸的图片,由客户端告诉服务端图片的尺寸,
服务端动态生成并缓存起来。
例如,客户端需要图片(http://www.baidu.com/img/bdlogo.gif)的 80*80 的尺寸,则在
图片的路径加上宽和高的参数(类似于 CDN 的机制) http://www.baidu.com/img/bdlogo.gif?
w=80&h=80, 则服务器就生成 80*80 的尺寸并返回。
采用了这样的图片处理机制,数据库中只要有一个字段保存原图就行了,其它尺寸就由
客户端告诉服务端动态生成。以后无论什么尺寸的图片,数据库中都不需要记录,数据库只
有原图就行了。
(6)返回的提示信息
最科学的情况,服务端只返回信息代码,具体的文字提示由客户端决定。
如果文字信息是由服务端返回,则最起码要区分 2 种信息:提示用户的信息,提示客户
端程序员的信息。这两者的区别:
1. 提示用户的信息是要在让客户知道的,提示客户端程序员的信息不需要让客户知道
的。
2. 提示用户的信息文字很友好,客户不需要专业基础一看就知道是什么,提示客户端
程序员的信息则很专业,例如告诉客户端少传了哪个参数?哪个参数有问题等等。
(7)在线 api 文档和测试
app 后端设计
作者:曾健生,博客专栏:http://blog.csdn.net/newjueqi ,qq:190678908
我们网站的 api 在线测试文档,既是一份在线 api 文档,也是一个在线测试工具,极大
方便沟通和测试。每次客户端程序员觉得某个 api 有什么问题,我们就是这个在线工具上讨
论沟通的。客户端程序员最喜欢这个玩意了^-^。
上个图解一下馋(这个图是旧版的 api,已经弃用了):
负责做这个功能的同事专门写了篇博客详细介绍了这个在线 api 测试文档,还带有 demo:
剩余32页未读,继续阅读
资源评论
柚子君.
- 粉丝: 3970
- 资源: 555
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 基于智慧教室管理系统全部资料+高分项目+详细文档.zip
- 基于智慧教室监考系统,作弊检测和考生点名功能全部资料+高分项目+详细文档.zip
- 基于智慧教学辅助系统全部资料+高分项目+详细文档.zip
- 基于智慧酒店后台管理系统全部资料+高分项目+详细文档.zip
- 基于智慧景区管理系统,目前已完成票务系统、设备管理、停车场管理、用户权限控制、设备权限控制、小程序售票等功能的开发!全部资料+高分项目+详细文档.zip
- 基于智慧教育后台管理子系统全部资料+高分项目+详细文档.zip
- 基于智慧楼宇碳检测系统全部资料+高分项目+详细文档.zip
- 基于智慧课堂管理系统前端全部资料+高分项目+详细文档.zip
- 基于智慧课堂管理系统全部资料+高分项目+详细文档.zip
- 基于智慧农业集成管理系统全部资料+高分项目+详细文档.zip
- 基于智慧旅游售票管理系统全部资料+高分项目+详细文档.zip
- 基于智慧农业监控管理系统全部资料+高分项目+详细文档.zip
- 基于智慧农业系统全部资料+高分项目+详细文档.zip
- 基于智慧社区管理系统项目全部资料+高分项目+详细文档.zip
- 基于智慧书店管理系统全部资料+高分项目+详细文档.zip
- 基于智慧水务后台管理系统全部资料+高分项目+详细文档.zip
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功