首页>会议文档 >

咕咚 唐平麟 - 第十年的选择

page:
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择
咕咚 唐平麟 - 第十年的选择

咕咚 唐平麟 - 第十年的选择

所属会议:WOT 2017全球架构与运维技术峰会( World Of Tech 2017 )会议地点:北京


下载

手机看
活动家APP客户端

扫二维码下载
或点击下载
Android iOS

1188次
浏览次数
WOT 2017全球架构与运维技术峰会( World Of Tech 2017 )所有文档 搜狐畅游 黎志刚 - 畅游运维自动化探索之旅 苏宁 王富平 - 多维分析平台实践 苏宁云商 朱羿全 - 苏宁易购全站HTTPS实践之路:如何做到兼顾安全与性能 淘宝 陈康贤(龙隆) - 网游直充如何应对大促及突发的流量高峰 腾讯 赵志辉 - 腾讯蓝鲸DevOps类应用的设计与实践 听云 廖雄杰 - 全栈APM--打造端到云的全方位监控体系 豌豆公主 陈超 - 如何打造一支高战斗力的技术团队 玩多多 单泽兵 - 互联网+玩具租赁的典型技术实战 美团 王兴星 - O2O广告的探索之路 网易云 刘超 - 网易容器云实践与云计算的那些坑 网易 马进 - 网易NDC高可用实践 新浪微博 付稳 - 新浪微博混合云DCP平台介绍与业务上云实践 新浪微博 张雷 - 微博服务化的实践与演进 新浪微博 侯青龙 - 新时代下的微博LNMP架构 新美大餐饮平台 何轼 - 新美大外卖订单系统架构实践 一下科技 汤力嘉 - CTO的管理之道 一下科技 邓铮 - 高性能视频播放调度系统 美团点评 张宇石 - 美团点评移动网络优化实践 美团点评 家尤勇 - 美团点评分布式监控 CAT 系统架构演进 蘑菇街 丁小明 - 蘑菇街搜索推荐架构的探索之路 去哪儿网 马文 - 基于Mesos、Docker构建Elasticsearch as a Service 盛邦 李春鹏 - 可知、可感、可查、可控——打造新一代Web安全治理体系 思科 徐洪涛 - 构建面向威胁的企业网络安全防御体系 搜狗运维 张博 - 搜狗智能运维实践 ThoughtWorks 钟健鑫 - DevOps Transformation Design 阿里巴巴 李钰(绝顶) - HBase in Alibaba Search 阿里巴巴 王晶昱 - 阿里企业级互联网架构实践 阿里巴巴 李灼灵(千慕) - 客服SAAS实时分析架构演进-从NoSQL到时序数据库 百度外卖 张建 - 运维平台从0到1 博睿宏远 程捷 - Web应用网络性能优化浅谈 滴滴出行 许令波 - 大流量网站的高可用建设经验 饿了么 许锦洋 - 移动动态化方案在蜂鸟的架构演进 虎牙直播 刘亚丹 - YY游戏私有云建设历程 华为 马全一 - 基于容器技术实现 DevOps Orchestration 今日头条 王烨 - 今日头条大数据平台的演进 金山云 郝明非 - 金山云直播点播基础服务演进 京东 鲍永成 - 京东新一代容器集群平台 京东商城 张克房 - 京东全链路压测军演系统(ForceBot)分享 九合创投 王啸 - 技术真的只是青春饭? 58到家 沈剑 - 微服务架构解耦利器与最佳实践 58到家 任桃术 - 58到家消息平台架构优化实践 Airbnb 丁辰 - Airbnb的Streaming ETL AWS 张侠 - 云时代架构和运维的新趋势 Brocade SE manager聂小云 - WLAN容量设计和性能优化实践 Google 梁宇凌 - On-Device AI架构及案例分析 Hulu 李彬 - Hulu视频直播系统架构:挑战与关键技术 LinkedIn 罗轶民 - 微服务在大型互联网公司的应用及其挑战 Stitch Fix 王建强 - 数据驱动的决策辅助与产品智能化

文档介绍

今年是移动互联网的第十年,单页App扩展到了超级App,甚至有的App开始了向简单的操作系统的演进。我们的App从什么发展而来,未来要到哪里去?如何在快速迭代的同时,继续演进技术和架构来满足业务方需求,保证安全性和提升用户体验?

演讲实录

咕咚作为中国最大的运动社交服务平台,其APP需要与手机硬件绑定的非常多,基本使用到手机里所有芯片和感应器,所以相对于其他APP在架构的选择上会更加保守一些。为了照顾与手机硬件的绑定,咕咚几乎没有用到React Native等动态化的技术,为了保证系统的稳定性,咕咚更偏向于选择原生实现。架构上偏保守的实现会相对比较复杂,而咕咚就面临着这样的难题。
咕咚最开始选择的是MVC的框架。经典的MVC与苹果的MVC不太一样,苹果的MVC里的Model(数据管理者)、View(数据展示者)、Controller(数据加工者)是互相联系的,导致所有对Model的操作必须经过Controller,如此一来, Controller会越来越大。在经典的MVC里面,View跟Controller是可以同性的,而苹果的则不可以,Cocoa MVC = MVC + Data Service缺少了View跟Model之间的联系,这就是为什么苹果的架构里面Controller会越来越大,最后会导致非常大的问题。
胖Model包含了部分弱业务逻辑。胖Model要达到的目的是,Controller从胖Model这里拿到数据之后,不用额外做操作或者只要做非常少的操作,就能够将数据直接应用在View上。瘦Model只负责业务数据的表达,所有业务无论强弱一律到Controller上。瘦Model要达到的目的是,尽一切可能去编写细粒度Model,配套各种helper类或方法来对弱业务做抽象,强业务依旧交给Controller。一旦选择了胖Model,Controller拿到数据之后,不用做太多的选择,就可以把数据显示在Controller里面。有时候为了选择,咕咚也会使用瘦Model,但是不敢将任何业务逻辑都不写到Model里面,只是把Model当做一个存储数据的目的。这时候业务的处理还是需要Controller,这两种设置其实本身没有什么高低之分,但是对于咕咚来说还是胖Model更适合一些。
不论是服务端、前端还是客户端,搜集模式是开发者们都最常用的,资料也相对完全。可是MVC的架构导致了高耦合和复杂的代码,为了解决这个问题再引入下一个架构。在MVC里边,怎么去划分这个代码才更加地清晰、更加地合理,唐平麟老师认为 “要严格让Model变成一个胖Model”,这样便于View Controller不用做复杂的程序就能获得数据。
但是有些时候在设计框架的时候,并没有严格的去设计,这时就需要引入另外一种模式, MVVM。它仅仅做了一件事情,就是把View Controller拆开了,把View Controller拆成了View Model,把之前Controller对于Model的控制代码全部放到了View Model里去。如此一来,业务逻辑就会非常地清晰、框架也会更加地明显。View Controller仅仅是做显示性的东西,View Model是做业务上的处理, Model可以设计成胖Model,也可以设计成瘦Model,如果设计成胖Model的话,可以把最简单的逻辑放在Model里面去处理,如果设计成瘦Model的话,可以把全部数据都放到View Model去处理。
MVVM的View Controller不像在MVC里的View Controller,MVVM的是View Controller + View,皆统成一层,而这一层都是做显示的逻辑。值得注意的是,在做视图层和View Model层的话,这两个之间要用一个Data绑定的技术,为了实现这个Data绑定,不能用第三方的库补充。View Model的角色是处理业务逻辑,除了被View层持有,也会持有Model。简而言之,View Model是一个从上到下互相持久的关系,在MVC架构里面经常会造成三者之间的相互持有,为了开发过程,可能让Model、Controller与View之间会产生相互持有的关系。
从MVC一直到MVVM,当程序越来越复杂的时候,开发者们必须严格地去定义每一个工作模块应该干什么,只有这个时候代码才能更加地清晰可靠。
唐平麟老师在此建议大家,“我希望大家在以后的工作里面,在项目组里面还是倾向于用比较简单的MVC的架构,但是在项目启动的时候一定要严格区分好这三者之间的关系,这三者之间什么代码能写、什么代码不能写,什么代码应该放在什么里面,比如说我Model里面一定要用胖Model,我在Controller里面一定不能够操作View层的动画,我在View里面一定不能去写用户跟业务代码相关的逻辑,如果说我们做好这三点的话,我们在MVC里面依然是可以去做架构的。”

×

打开微信扫一扫,分享到朋友圈