码迷,mamicode.com
首页 > 移动开发 > 详细

iOS 应用架构浅谈

时间:2015-11-28 15:00:05      阅读:214      评论:0      收藏:0      [点我收藏+]

标签:

当我们讨论客户端应用架构的时候,我们在讨论什么?

其实市面上大部分应用不外乎就是颠过来倒过去地做以下这些事情:

简单来说就是调API,展示页面,然后跳转到别的地方再调API,再展示页面。

 App确实就是主要做这些事情,但是支撑这些事情的基础,就是做架构要考虑的事情。

  • 调用网络API

  • 页面展示

  • 数据的本地持久化

  • 动态部署方案

上面这四大点,稍微细说一下就是:

  • 如何让业务开发工程师方便安全地调用网络API?然后尽可能保证用户在各种网络环境下都能有良好的体验?

  • 页面如何组织,才能尽可能降低业务方代码的耦合度?尽可能降低业务方开发界面的复杂度,提高他们的效率?

  • 当数据有在本地存取的需求的时候,如何能够保证数据在本地的合理安排?如何尽可能地减小性能消耗?

  • iOS应用有审核周期,如何能够通过不发版本的方式展示新的内容给用户?如何修复紧急bug?

上面几点是针对App说的,下面还有一些是针对团队说的:

  • 收集用户数据,给产品和运营提供参考

  • 合理地组织各业务方开发的业务模块,以及相关基础模块

  • daily build 自动打包,提供给产品体验,给测试观测性能

 所以当我们讨论客户端应用架构的时候,我们讨论的差不多就是这些问题。

架构设计的方法 

所有事情最难的时候都是开始做的时候,当你开始着手设计并实现某一层的架构乃至整个app的架构的时候,很有可能会出现暂时的无从下手的情况。不管你采用什么方法,全局观、高度的代码审美能力、灵活使用各种设计模式一定都是贯穿其中的。 

第一步:搞清楚要解决哪些问题,并找到解决这些问题的充要条件

  你必须得清楚你要做什么,业务方希望要什么。而不是为了架构而架构,也不是为了体验新技术而改架构方案。以前是MVC,最近流行MVVM,如果过去的MVC是个好架构,没什么特别大的缺陷,就不要推倒然后搞成MVVM。

  搞清楚对于业务方而言的真正充要条件很重要!这决定了你的架构是否足够易用。另外,传的参数越少,耦合度相对而言就越小,你替换模块或者升级模块所花的的代价就越小。

第二步:问题分类,分模块

  这个不用多说了吧。

第三步:搞清楚各问题之间的依赖关系,建立好模块交流规范并设计模块

   关键在于建立一套统一的交流规范。要注意的是,一定是建立一套统一的交流规范,不是两套,不是多套。你要坚持你的价值观,不要摇摆不定。要是搞出各种五花八门的规范出来,一方面有不切实际的炫技嫌疑,另一方面也会带来后续维护的灾难。

第四步:推演预测一下未来可能的走向,必要时添加新的模块,记录更多的基础数据以备未来之需

  很多称职的架构师都会在这时候考虑架构未来的走向,以及考虑做完这一轮架构之后,接下来要做的事情。一个好的架构虽然是功在当代利在千秋的工程,但绝对不是一个一劳永逸的工程。软件是有生命的,你做出来的架构决定了这个软件它这一生是坎坷还是幸福。

第五步:先解决依赖关系中最基础的问题,实现基础模块,然后再用基础模块堆叠出整个架构

   这一步也是验证你之前的设计是否合理的一步,随着这一步的推进,你很有可能会遇到需要对架构进行调整的情况。这个阶段一定要吹毛求疵高度负责地去开发,不要得过且过,发现架构有问题就及时调整。否则以后调整的成本就非常之大了。

第六步:打点,跑单元测试,跑性能测试,根据数据去优化对应的地方 

你得用这些数据去向你的leader邀功,你也得用这些数据去不断调整你的架构。

总而言之就是要遵循这些原则:自顶向下设计(1,2,3,4步),自底向上实现(5),先测量,后优化(6)。

iOS 应用架构浅谈

标签:

原文地址:http://www.cnblogs.com/caohexin-Blog/p/5002599.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!