APP架构思考

整体架构

一般都是先有PC互联网，再有移动互联网。当移动互联网开始发展的时候，PC端基本已经相当成熟了。因此，一开始移动互联网都是作为PC端的补充而存在的，架构也是简单而直接。这么做短期内能快速落地，但是随着业务的发展，就需要进行架构改造，这是当前很大一部分的现状。

单体应用.jpg

这里最重要的一点是给APP客户端一个独立的后台，独立开发，独立部署，从架构层面彻底摆脱PC思维无线化。

整体架构.png

• 企业一般先有PC端，再推APP端。应当根据移动自身的特点进行架构的设计，而不是以模块叠加的方式加到现有的PC端体系之中
• APP要有自己独立的服务端，图中“无线网关”部分，跟PC的服务端进行良好的隔离，实现逻辑和物理层面的解耦。
• 客户端和“无线网关”之间的通信推荐用HTTPS，目前苹果在推全网HTTPS化，这是趋势。无线安全问题有越来越热的趋势。
• “无线网关”部分对APP来讲是后台，对于后台系统来讲是前端，目前的开发语言一般是Java或者PHP。在组织结构上，这部分人员应该划入APP开发团队，这样能够保证移动开发的完整性。图中虚线框部分。
• 后台服务可以统一成一套，让APP和PC共用。
• 通用逻辑，比如安全、日志、监控、缓存等等，能够从客户端剥离的，尽量都放到“无线网关”部分。---能后台实现的，就不要放客户端。客户端要写3遍，后台只要写一遍，并且可以随时升级打补丁。
• 路由层要做好流量控制，实现“灰度发布”，更好地控制风险
• 适配层要将后台服务各种不同的接口统一为一种，HTTPS+JSON，方便客户端调用。同时，可以考虑对多个SOA服务做聚合，缓存，业务逻辑，对APP提供粗粒度的数据，减少APP网络请求的次数，提升性能。
• 从落地实施上，整个开发也可以分为无线开发，后台开发两部分。先定好SOA的接口，无线开发（客户端+无线网关）就可以按照自己的进度进行，不需要依赖后台服务是否可用。遇到后台服务还没有好的情况，可以将测试数据在无线网关，在内部测试服务器上部署。无线端提前ok，对后台服务的开发和测试也是有利的。

客户端架构

这一层是对APP的横向拆分，根据业务的特点，分为Native，H5，SDK三块。

客户端架构.jpg

• H5目前已经比较普及。一个原则是能用H5做的，就不需要用Native来实现了。比如一些具体的业务，一些信息的介绍等等。
• SDK化也是简化APP架构的一个比较好的方式。包含UI的，比如支付收银台；不包含UI的，比如加解密，都是可以的。一开始出现的原因可能是公司之间或者部门之间合作，进行敏感信息隐藏。目前可以作为一种简化架构，提高模块复用的良好方式。比如登录注册模块，第三方登录，分享，支付，加密加签等等都可以考虑做成SDK插件。
• SDK化和SOA服务化的主要区别是解决思路的不同。SDK化是模块的横向切分，进行部门间、公司间协作。SOA服务化的思路是独立、单一、解耦、提高复用，最好是在分层之后再按模块分类。因为不同的层，分类的标准都有可能不同。

iOS Native 架构

在多年的实际APP开发中，听到报问题最多的两点是

1. 视觉图还没有给
2. API接口没数据

根据这两点，将传统的APP分为三层。界面层只做界面相关的事情，和UI一起开发；数据层专门负责API接口的实现，和APP后台一起开发。业务逻辑层主要用来实现业务规则，做到与数据和界面无关，尽量提高复用度。

当然，考虑将逻辑层和数据层独立出来的原因，是随着APP规模的扩大，为了达到方便部门间合作，模块复用，敏感数据隔离等目的。

这里的思路主要有以下几点

• 三层模型，切出尽量薄的界面层和数据层，主动应变
• SOA服务化，进行解耦，提高复用
• framework化，从物理上实现模块间的隔离

iOS Native架构.jpg

界面层

• 用Storyboard为主开发界面
• 用imageset管理图片
• 按页面流程划分模块，分到不同的文件夹中，大小要适中
• 一个模块一个Storyboard，一个imageSet；Storyboard不要超过7到10个Scene。就算是只有一个Scene也可以单独放置在一个Storyboard中。
• 一个Scene，这个就是View，对应一个ViewModel, 一个ViewController。采用MVVM思想，给ViewController减负。
• 将AppDelegate中的一些实现代码下沉到逻辑层，AppDelegate只作为程序生命周期的调度者，不做具体的事情，实现AppDelegate的减负。
• 规范组件是View，考虑复用；

组合模式，考虑用xib实现，所见即所得
继承模式，从系统的控件一级继承，用代码实现
远期考虑用framework封装，方便在多项目中复用

• 多用Storyboard和xib，少用代码，除规范组件之外，其他的不考虑复用。应对变化是最优先考虑。
• 顶级目录用workspace，每个项目用一个project来表示，采用集中化的管理模式

逻辑层

• 整个逻辑层可以封装成logic.framework，方便隔离，多项目复用
• 按照业务进行模块划分
• 一些跟具体业务无关的内容按照工具箱的思路进行封装，比如各种日期转换工具
• 按照SOA思路，每个模块都封装独立的framework

数据层

• 整个数据层可以封装成data.framework，方便隔离，多项目复用
• 按照数据存储方式进行模块划分
• 按照SOA思路，每个模块都封装独立的framework

技术选择

• 开发语言选择Swift，放弃Object-C
• 第三方库管理工具选择Carthage，放弃Pods
• SDK化工具选择framework，放弃.a , .bundle方式

兼容性

• 优先向上兼容，其次向下兼容
• 良好支持两个版本，主流只需要支持3个版本

当前最低支持iOS8或者iOS9；放弃iOS7；为即将到来的iOS10提前做好准备

• 硬件支持2个大版本

当前支持iPhone5，iPhone5S，iPhone5C，iPhone6，iPhone6S，iPhone6Plus，iPhone6S Plus；放弃对iPhone4，iPhone4S的支持；等iPhone7出来之后，逐步减少对iPhone5系列的支持
从屏幕尺寸来说，当前支持4英寸，4.7英寸，5.5英寸；放弃对3.5英寸屏支持。设计可以4.7英寸为主，用autolayout，进行屏幕尺寸适配

• 跟上苹果的节奏，每年进行一次重构，将软件和硬件的支持逐步升级。

碎片化控制是iOS开发一项重要特色
优先支持新特性，在AppStore中有加分项
控制warning数在个位数之内，及时进行系统API的替换

• 在时间上，根据苹果自身的发布时间，提前3个月开始进行

      </div>