随着移动技术飞速发展。如今，app已成为企业发展的重要战略。与此同时，伴随着业务量的增长，愈来愈多的app也在不断地挑战着每一个移动端研发人员的知识深度，而移动端技术人员也在这个不断接受挑战的过程中，成就了今天的互联网+手机时代。除了国内，app开发在国际领域也崭露头角逐渐的受到更多外国友人的青睐。
作为一家在基金、金融行业高速发展的，app面临着多重挑战，如庞大的用户群体、高频的基金业务、交易安全可靠性等等。基金移动端的开发小伙伴在技术和业务的多重压力下，不断推进着基金理财移动端的架构演进。以下就从某款基金app来分析
首先介绍下大环境背景，某款基金app来在前端后端使用的金融云mpaas（移动即服务）平台。简单说就是通过这个平台把支付宝app多年的开发经验沉淀下来，帮助生态伙伴进行金融客户端的开发，提高其适应移动互联网生态的产品研发能力，同时在手机端运营app中也嵌入了安全、风控能力，并结合支付宝app的众多应用场景来进行金融业务创新。
ios版app早期架构
在2015年爱理财appios的第一个版本诞生，那时候架构很简单，基本上就是在传统的mvc的架构基础上封装了一个网络服务层构建而成的，当时ios端整体架构爱理财app经历从无到有的阶段，为了快速上线抢占市场，其移动端app开发的mvc架构成了短平快思路的首选。
一、在早期mvc的体系架构中
-mpaas层主要负责提供一些最低层的功能支持，如数据库，rpc网络请求，分享等等
-thapiclient层为整个app网络请求的封装层，提供所有网络请求接口的请求和接受等功能
-services层为整个app业务逻辑封装层，比如
-实现账号登陆注册业务的saaccountservice
-实现爱基金相关业务的salovefundservice
-实现银行卡相关业务的sabankcardservice
-实现买入卖出相关业务的sabusinessservice
-controller层为view和services层之间的一层，提供各个模块的ui和业务实现的连接功能
-view层为用户展现ui和用户交互ui层
这种架构随着版本迭代开发出现了越来越多的问题，在开发的后期会由于其超高耦和性，从而造就庞大controller层，而这也是一直被人所诟病。最终的mvc都从model-view-controller走向了massive-view-controller的终点，其最严重的结果就是control层的代码越来越多越来越臃肿难于扩展维护，同时control层和view层之间存在一些较高的耦合。
二、app20版本架构
基于上述我们遇到的问题，我们在原来的传统架构上又做了重新调整和优化，提出了ios端架构v20，在新版本的项目内开始逐步重构采用mvvm+分层架构模式解耦，使controller层逐步缩小并分解解耦，业务逻辑分模块下沉。调整在原有的controller层和service层之间插入了一个viewmodel层(紫色的),对于此次架构调整优点如下:
-只用来做中转层不参与业务逻辑等处理
-对上(view层)只提供页面展示所需数据,对下调用(viewmodel层)暴露出的业务逻辑接口，方便进行功能,业务逻辑的单元测试
-viewmodel层实现整个业务逻辑,实现对上层只提供接口因此此层灵活,易维护
三、app30版本架构
我们在20版本架构中完成了内部竖向解耦，在v30版本（当前正在内部测试阶段）架构中我们将逐步实现各个层同层内部中子模块的解耦工作（横向解耦）如同层之间各个子模块之间调用相互依赖,严重影响各个模块之间的解耦,如a模块内部(甚至外部)依赖b,c模块而b,c模块又依赖a模块,这种相互依赖相互include的情况导致各个模块相互不能独立,严重影响编译速度和扩展性，灵活性等，当前在v30版本中为了完成横向解耦我们内部开发实现一个动态路由组件（），是一套可根据规则或下发规则自动实现页面跳转流转的组件，其主要目的为了模块间可以方便容易的横向解耦，拆分，路由，降级容错等初衷。
在app内部中还有一些其他优秀的组件如启动保护组件，crash安全保护组件，h5容器组件等等，我们相信一个好的优秀的app离不开内部优秀的架构框架同样也离不开一些基础组件的建设，就如同打桩是基础，才能盖好高楼，完善易用的组件是楼一砖一瓦，只有基础有了砖瓦完善了才有机会把楼修得高修的雄伟起来。
总之，app架构的技术优化没有尽头，我们会继续以开发效率、性能、质量、新技术几个纬度不断推进，希望未来可以有更多内容分享给业内同行。
文章来源：