汽车SOA-AUTOSAR-IOS架构分析
参考文献链接
https://mp.weixin.qq.com/s/DUEDZ6bR7zmoW3D5PTJZAA
https://mp.weixin.qq.com/s/B6vCm1wAh50vnMAzfNpQbQ
https://mp.weixin.qq.com/s/IYGmfvSAYwstQZl48p8jKg
https://mp.weixin.qq.com/s/dHQfmeCO7J1saAT67zy1fg
https://mp.weixin.qq.com/s/TfEii72e8oxnHt_lfMeaQQ
https://mp.weixin.qq.com/s/bpRjlvXqaNd0tuKC3zuNmw
汽车SOA主要功能模块及开发流程
近年来，汽车“新四化”（智能化、网联化、电动化、共享化）的快速推进，给汽车行业带来了新的技术变革，汽车的功能变得越来越复杂，尤其是智能座舱、智能驾驶、智能底盘的出现，促使汽车电子电气架构也相应地发生变革。
随着汽车智能化发展、汽车功能的增加，汽车上的电子控制单元（Electronic Control Unit，ECU）也越来越多，每个ECU的信号都必须在设计时进行静态规划和路由，为了应对这种增长带来的挑战，汽车行业正在采用1种新的架构，即面向服务的体系架构（Service-Oriented Architecture,SOA）。
SOA是从遵循服务导向原则的可重用服务中构建复杂软件系统的方法。SOA也是1个组件模型，将应用程序的不同功能单元（称为服务），通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务以1种统一和通用的方式进行交互。SOA可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中因软件代理交互而产生的人为依赖性。
SOA的特点是松耦合性、路径透明、可复用性、一定的标准化，不涉及底层编程接口和通讯模型。
SOA在IT行业中已经使用了多年，旨在描述和构建分布式系统。同时，面向服务的设计在汽车工业中也变得极为重要。
传统汽车通讯是基于信号的通讯方式，即信息发送者不关心谁接收而只负责将信号发送出去，接收者也不关心是谁发送的，而只负责接收信号，这种方式适用于有限大小控制数据的应用场景。
SOA代码灵活性强，支持请求/响应模式，支持复杂的数据模型，可扩展性强，能够满足自动驾驶等应用场景下，大量数据的动态交互，可以对系统进行部分更新，如图1所示。

图1 面向信号与面向服务对比
汽车领域采用SOA的优势是能加快车辆与互联网的互联互通。比如，能够将各种新功能灵活地与互联网集成；能够实现更高效的车载自动诊断系统OBD（On Board Diagnostics，OBD）及空中下载技术（Over-The-Air Technology，OTA）软件升级，有助于实现各种远程诊断、预诊断功能；能够大幅提升影音娱乐功能的用户体验，能够实现不同平台间的各种App共享功能；更便于实现平台架构升级；同时各个服务可以由不同团队独立开发，可以缩短车辆开发的时间。
Wonseon和Seung设计了端到端的SOA，如图2。

图2 端到端面向服务的架构
在传统的车载网络中：
（1）许多ECU是基于CAN等旧式IVN进行工作。
（2）大量的车辆信息和功能也来自旧式IVN。
（3）基于以太网的ECU上的新应用程序应可以访问这些信息/功能。
在本架构中，主要的功能模块有SOA适配器（SOA Adaptor），SOA网关（G/W），SD代理（SD Proxy）和服务路由（Service Router）。下面将介绍各个模块的功能。
3.1 SOA适配器
（1）将信息/功能从旧式IVN转换为“服务”，任何基于以太网的ECU上的应用程序都可以轻松访问。
（2）在以太网方面，服务是在SOME/IP协议之上提供的。
（3）可以在旧版IVN和基于以太网的IVN之间的“桥接ECU”上实现，例如域控制单元，区域控制器等。也可以仅在具有以太网接口的非桥接ECU上实现。
（4）SOA适配器提供的服务可以动态更改。
3.2 SOA网关
（1）处理与外部设备/网络互通相关的问题。
（2）必要时转换协议并翻译。
（3）缓存外部信息以处理外部网络的可用性和成本问题。
（4）应用策略并执行服务级别的访问控制。
（5）应该在具有外部连接的ECU上实施。
3.3 SD代理
（1）可以使用SD代理实现集中式SD。通过1个称为“SD代理”的中央模块交换服务发现消息。SOME/IP-SD消息也可用于ECU与SD代理之间的通信。
（2）分布式SD方法的安全和流量问题可以由集中式SD处理。每个服务只能由允许的ECU查找和订阅。可以有效地监视服务可用性和搜索/订阅尝试。
3.4 服务路由
可以使用服务路由器来处理来自SOA分布式性质的问题。服务只能通过服务路由器来使用。服务路由可以应用于选定的服务。SD代理可用于高效的服务路由实施，安全和资源问题可以得到有效处理，可以基于域、ECU、服务甚至方法来控制服务访问，策略也可以动态应用。
SOA是汽车以太网和IP带来的汽车系统/软件体系架构的创新，其概念可以扩展到从传统ECU到外部设备的端到端范围。SOA适配器和SOA网关可以分别用于旧设备和外部设备。通过使用其他SOA实体可以有效地管理SOA。端到端SOA支持快速高效地部署各种互联汽车服务。
刘佳熙等在面向服务架构汽车软件开发方法和实践中，提出SOA汽车软件的分成模型，如图3示。

图3 SOA汽车分层模型
该模型主要包括3个层级：元服务、基础服务和应用服务，通过不同的服务层级来分别对应不同层级的汽车业务逻辑。
元服务是最小单元。包括汽车的传感器和执行器等的基本接口。基础服务是中间层服务，在利用元服务的基础上，可自定义汽车业务模块，比如利用自车状态服务和雷达传感器等服务，组合出环境信息融合的服务。应用服务是最顶层的服务，可以访问和调用基础服务以帮助其解决业务问题。
在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的SOA汽车软件架构。宝马公司在新一代的E/E架构中引入了SOA的方法，如图4所示。SOA为整个系统提供大量的抽象服务。严格的封装和层次结构允许针对接口和使用敏捷方法进行测试，并且降低了系统复杂性。在各代汽车之间重用软件组件将变得更加简单。


图4 BMW下一代E/E架构
大众MEB平台车载应用服务架构（In-Car Appli⁃cation-Server,ICAS），采用了1种可升级的新方法，如图5所示。采用集中式功能与应用程序软件和I/O功能分离的架构，来降低整体系统复杂性和应用程序之间的依赖性，同时可以高效快速地开发客户功能，提供一些客户职能所需的基本服务，并且利用面向服务的通信。

图5 大众MEB平台车载应用服务架构升级方法示例
在该架构中还强调，SOA是数字化的关键，如图6所示，该架构的优点如下：

图6 面向服务通信架构
（1）采用面向服务的通信；
（2）使用服务发现和发布/订阅进行动态绑定；
（3）数据表示主要基于REST（表述性状态传递）过渡到统一接口、无状态、关注点分离；
（4）接口的向前和向后兼容性。
最后，通过提高可更新性、可升级性、重用能力和便携性，使大众汽车可以实现各种功能。
在AUTOSAR自适应平台（Adaptive Platform，AP）设计中，为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可扩展性，AP遵循了面向服务的体系结构理念。
SOA通常具有AP所具有的系统间特性。例如，服务可以驻留在应用程序运行的本地ECU上，也可以位于远程ECU上，该远程ECU也在运行另一个AP例。
上汽组建“零束”软件子公司，聚焦基于SOA技术的智能驾驶系统工程，同时推出“Z-ONE”的SOA开放平台，致力于打造上汽SOA的软件生态。该平台是以SOA理念打造整车功能，将汽车各个功能模块化。同时可以让第3方开发者甚至是普通用户参与到软件功能的打造。
威马汽车在2021年4月交付的威马W6汽车，率先推出了车辆自定义场景编程功能，实现25种能力、自定义场景超100个、手机端与车机端的同步，未来将携手用户及开发者，打开“千人千面”的全新格局。
Andreas等开发面向服务的车用应用程序，并使用空中软件更新部署。主要流程如图7所示。

图7 汽车的SOA开发流程
研究背景如下：在巴塞罗那举行的2019年世界移动通信大会上，梅赛德斯·奔驰展示了1款经过改装的车辆，可与开源SuperTuxKart游戏一起用作沉浸式游戏系统。游戏是使用真实的方向盘控制游戏中的车辆，空调模拟虚拟赛车的气流、温度效果。
Andreas假设车辆类型的制造商现在想要开发这样的游戏系统并将其部署到车辆上，可作为车主购买的可选更新，其开发流程如下。
5.1 需求分析
首先，进行需求分析，具体过程如下：
（1）主机将显示1个赛车视频游戏。声音应来自车载音响系统。
（2）游戏中的效果应由实车反映，例如：空调应根据游戏中的场景（即驶过火山）和虚拟车的速度调节气流和温度。游戏中的撞车事故应通过可逆安全带拉紧器告知用户。电动座椅调节器和按摩器可产生更多的触觉效果。在虚拟比赛开始时，车内的环境照明应用作交通信号灯。
（3）虚拟车辆的水平动力学应根据当前方向盘角度得出。
（4）虚拟车辆的速度应从油门踏板和制动踏板得出。
（5）中指定的效果体验应与视频游戏中显示的情况相匹配。
（6）游戏的最小帧速率应为30 fps。
（7）效果的延迟应等于或小于1帧持续时间（最小帧频）。
还存在一些非功能性需求：
（1）此功能应部署在现有汽车上，无需对硬件进行任何修改。
（2）该功能不得损害机动车的安全。
（3）只有在车辆周围环境允许安全操作时，该功能才有效。
5.2 起草软件和系统架构
根据起草软件和系统架构，构建面向服务的部分。
在“SuperTuxKart”应用程序的需求定义完成后，起草软件和系统架构。本样例中关注需求第2～4步，为此一共设计了3个步骤。
5.2.1 分解
实现“SuperTuxKart”应用程序的必要组件在某种程度上遵循面向服务、面向信号的方法。
面向服务的部分：在这部分中，“Super-TuxKart”应用程序被描述为1个服务消费者组件（客户端）。消费的服务是喷油嘴服务（Nozzle）和转向/踏板状态服务（Steering/Pedal status）。其中，转向/踏板状态服务接口目的是定期接收踏板和转向角的状态，为“Super⁃TuxKart”应用程序提供施加的踏板压力和转向角；喷油嘴服务接口目的是实现对油泵执行器的控制，“Su⁃perTuxKart”应用程序根据游戏中的场景和虚拟车辆的速度以所需的喷嘴效果强度刺激界面。如图8所示。

图8 面向服务部分的架构
面向信号的部分：软件架构的某些部分不会由服务接口实现，而是由经典的面向信号的方法。通常考虑与传感器和执行器密切相关的软件功能。对于该应用，必要的传感器是踏板和转向装置。执行器则是由喷油嘴表示。为了将3个组件集成到软件架构草案中，引入了图9中的信号接口。传感器踏板和转向装置为转向/踏板状态服务提供接口；执行器喷油嘴为喷油嘴服务提供接口（图9）。

图9 信号接口
5.2.2 部署
接下来，用适合的网络技术部署软件架构。考虑3个通信网络，包括：以太网，底盘/动力总成网络，LIN网络。
（1）第1个网络是以太网拓扑。3个ECU通过1个中央以太网交换机互连。ECU 1是中央计算平台。在ECU 1上，部署“SuperTuxKart”应用程序。对于踏板/转向服务，底盘/传动系统域的域控制器ECU2作为部署目标给出。以类似的方式，车身域的域控制器ECU3作为部署喷油嘴服务的目标。
（2）第2个底盘/传动系统网络：该网络描述两种基于CAN和FlexRay协议的系统总线拓扑结构连接到底盘/传动系统域的域控制器。。
（3）第3个网络描述了基于LIN协议的系统总线拓扑。在此网络中，专注于油泵执行器，该执行器部署在专用的LIN组件上，并由喷油嘴服务控制。混合通信如图10所示。

图10 网络混合通信
5.2.3 网络通信
“Super-TuxKart”应用程序所需的网络通信是以太网拓扑中面向服务的通信与CAN、FlexRay和LIN系统总线拓扑中的经典面向信号的通信相结合。
5.3 开发阶段
应用程序的开发阶段主要有3部分。
5.3.1 构建基础组件
SOA中的主要基础组件是API存储库，是1个中央数据库，包含详细的有关服务及其功能和接口的信息。可以部署到车辆内计算平台的应用程序可以使用这些服务为客户提供额外的功能。
5.3.2 现有服务的使用
一旦应用程序确定了需求，将通过API存储库并尝试找到可以满足所有要求的服务。理想情况下，存储库中的服务可以满足所有要求。在这种情况下，应用程序可以使用API存储库提供的接口描述来设计软件。由于面向服务架构的解耦性质，不需要对域控制器或背后的ECU进行修改。在“SuperTuxKart”示例中，应用程序设计将根据需求调整空调的气流，并在API中寻找合适的服务存储库。会找到喷油嘴服务并集成此服务接口到应用程序中。
5.3.3 创建新服务
当API存储库中的服务不能满足应用程序的需求时，需要联系API的创建者来进行更新API存储库，以满足开放的要求。由于这个扩展过程大大减慢了新应用程序的设计，因此API存储库设计时应提供尽可能多的功能。
5.4 空中更新
要通过空中更新汽车嵌入式系统的软件，需要2部分：一部分由汽车制造商维护服务器，用于管理更新程序包；另一个负责接收，验证和分发更新程序的客户端，将文件更新到相应的ECU。
更新客户端功能通常在车辆的中央网关平台上实现，该平台可直接访问主机并代表通信总线之间的中央通信点。下载的更新包括1个或多个交叉编译的二进制文件，准备在相应的ECU中进行刷新。中央网关的更新功能（或服务）负责检查更新包，并将二进制文件分发到目标ECU。
该研究表明，使用现有服务可以较少的协调并提高开发速度。如果任何应用程序始终都可以使用现有服务，则可能会带来安全方面的挑战（即访问行驶中的车辆的主动悬架系统）。因此，有必要对汽车SOA的访问控制管理进行研究。
“分析和设计面向服务的架构”，“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节。
为了实现汽车智能驾驶，通用高性能计算平台是未来新型E/E架构的硬件基础，而SOA则是“软件定义汽车”的软件基础。通过SOA平台，实现软硬件解耦、终端用户、汽车厂家及第3方开发者携手共建跨品牌、跨平台、跨车型的软件开发能力，打造以用户体验为核心，各方开发者共同参与、合作共赢的智能汽车生态。
在此生态里，汽车企业将不只是生产制造汽车，还将成为移动出行的服务供应商，能够面向用户提供多种多样的软件服务。SOA软件平台上多方的协同合作，将为软件汽车的不断进化和用户体验的不断提升提供源源不绝的动力。未来，车主可以根据乘员数量、道路情况、目的地甚至自己心情等不同条件，在车机及移动端APP上下载配置不同的功能，满足个性化需求。在SOA软件平台的帮助下，通过数据、算法、软件的不断积累和迭代升级，最终汽车将由执行指令的冰冷机械，进化为能够实时交流、洞察需求、主动服务的“有生命的出行伙伴”。
汽车面向服务软件架构SOA

互联网软件架构是否会对汽车软件传统嵌入式领域系统架构产生影响。今天随着小星来一起讨论一下汽车面向服务软件架构SOA是什么，以及会给汽车行业带来哪些变革吧。
什么是SOA架构
面向服务架构SOA概念面向服务架构SOA，即（Service-OrientedArchitecture）由Gartner提出并广泛应用于互联网软件架构。目前互联网服务协议Http等就基于SOA架构开发，为各层协议提供透明的服务接口，同时减少外界对各层协议的影响。SOA架构的两大特征是灵活性和业务相关性。灵活性体现在SOA架构中可以用一个服务替换另一个服务时仅仅需要考虑服务接口，而无需担心其底层的技术实现。业务相关性体现在SOA架构中服务与业务产生了紧密的联系，每一个服务对应业务流程中的一项任务。SOA架构的特点
传统软件架构（左）和自适应平台SOA架构（右）的差别简单来说面向服务SOA软件架构具有如下特点和特征：1）可重用：一个服务创建后能用于多个应用和业务流程。2）松耦合：软件上层不需要知道技术实现的细节，服务之间是松耦合的。3）接口定义明确：基于服务描述语言明确定义接口，是服务交互的基础。4）基于开放标准：比如在汽车行业中SOA软件通常基于AUTOSAR开放标准开发。基于SOA架构的AUTOSAR自适应平台将比传统软件架构更加的灵活并与业务紧密相关，基于服务与接口的实现与底层技术实现松耦合。SOA架构在汽车中的应用 汽车传统电气架构
（左）和软件中心架构（右）SOA架构在汽车中的应用背后的推动力就是随着车辆功能的多样化，越来越多的信息需要跨域分享。而分立控制器即使已经近百个之多仍然跟不上功能的增长速度。而基于智能座舱、主动安全、底盘、车身和安全域控制器的架构能够从系统上降低成本、重量和功耗，还能够依托芯片和软件的创新快速演进。因此基于面向服务SOA的域控制器架构成为智能汽车发展的必然趋势。 汽车面向服务SOA的域控制器架构具体来说，智能汽车系统正朝着面向服务的域控制器架构演进。域控制器面向动力、主动安全、信息娱乐、智能互联、能量管理、舒适功能等服务，通过软件和数字化平台能够跨域操作芯片组成的电子部件从而个性化控制底层的底盘、车身、动力和悬挂等机械部件。这里的架构变革依托于高算力芯片、底层固件、最高权限的监控系统以及上层的面向服务的各种操作系统组成。各司其职高效运作才促成了基于域控制器架构的信息共享成为可能。
SOA架构为汽车行业带来的变革具体是什么
SOA架构为汽车行业带来的变革随着汽车革命向纵深发展，SOA架构为汽车行业带来的变革包括服务软件越来越丰富，智能汽车逐渐成为一个数据决定体验、软件定义汽车的移动智能终端。通过面向服务的网关基于以太网和高速CAN总线将自动驾驶、车身舒适、车内用户体验、车云互联、动力总成和车辆动态域控制器紧密相连。对于传感器和执行器基于开放标准和松耦合面向服务SOA架构进行管理

基于SOA的汽车电气架构重构中国电动汽车百人会理事长陈清泰在以“迎接新能源汽车市场化发展新阶段”为主题的2022中国电动汽车百人会论坛之高层论坛中曾提到：“软件定义汽车的一个重要特征就是使汽车具备了自进化的能力，正在由一个买到手就开始落后的死物转化成一个可以不断进化的新物种，驱动汽车功能进化的是数据，而保障数据采集处理和利用的是软件，从这个意义上说，数据决定体验，软件定义汽车并不夸张。就是说同样的汽车、同样的芯片、同样的算力，但是数据丰富了，软件迭代进步了，不仅可以不断给用户提供安全、暖心、愉悦的新服务、新体验，而且根据用户的偏好不同，汽车也可以成为千车千面的个性化的产品性能。”
基于SOA架构的软件空中升级OTASOA架构的实施现状麦肯锡咨询公司曾经在公开报告中SOA架构在汽车核心零部件的实施当中扮演着重要角色。车辆从原来硬件为主的各种传感器、发动机或电机动力单元和车身工业设计，向软件主导的用户体验娱乐平台、自动驾驶操作系统、基于云端大数据分析、应用软件APP和服务以及车辆共享等新业务模式方向快速演进。
SOA架构在汽车核心零部件的实施麦肯锡在报告中还提到科技新势力没有传统造车理念的禁锢和资产存量的拖累，把互联网思维终端是提供服务载体的概念融入到汽车产品定义和营销模式之中。相比全球主流的传统车企8.5%的软件工程师占比，科技新势力的软件工程师比例达到了62.2%占绝对主导地位。在软件工程师的配置比例和投入是传统车企的平均28倍之多。对于软件体验的高度重视，让科技新势力在进入网联化、智能化深度竞争的阶段显现出更强的竞争力。

传统车企（上）和科技新势力（下）SOA实施对比综上所述，介绍了互联网软件架构当中广泛使用的面向服务SOA架构，基于面向服务SOA的域控制器架构成为智能汽车发展的必然趋势，以及SOA架构给汽车行业的带来各种变革和实施现状。希望今天的介绍能够让大家更好地了解汽车行业数据决定体验软件定义汽车的新趋势。
SOA新架构
1 前言
借鉴SOA（Service Oriented Architecture）架构在IT行业所体现出的优势，部分主机厂开始将其引入到了汽车行业中。
在SOA架构中，将所有的功能都定义为独立的服务，服务之间通过交互和协调完成业务的整体逻辑。由于各服务都采用标准化的服务接口，所以在服务的交互过程中，不需要考虑交互双方的内部细节，同时SOA 架构中软件对硬件以及操作系统具有高的独立性，这些特点都将成功地解决由于功能增多而带来整车网络拓扑、整车线束以及各控制器控制策略复杂度增加的问题，同时基于各功能的服务化模式，可进一步优化车辆售后服务模式，可以将车辆功能的部分选择权交到用户手里，进而最大程度地满足用户需求，以此来提高用户的满意度和体验感。
主机厂可以基于SOA架构的优势，建立自己的软硬件平台，整车各控制器的软硬件开发都遵守统一的开发架构及标准，这样可以有效地缩短整车的研发周期（已开发功能可以灵活复用，新开发功能可以多方参与）、降低开发成本。
汽车远程诊断以一种新的思路建立了车辆与云（V2C）之间的通讯。一方面，可以将传统的售后诊断仪功能转移到云平台上，以此解决传统诊断仪由于对硬件的依赖而导致使用范围受限的问题，如可以通过远程诊断系统对不同人员进行诊断仪不同功能级别的授权，进而扩大其使用范围，车主也可以获得一定级别的权限，自主进行车辆部分功能的诊断；另一方面，整车厂可以通过远程诊断系统对所有车辆的信息进行实时的监测和管理，同时利用收集到的车辆信息数据做进一步分析，可以用于提升车辆的研发质量。
2 远程诊断系统方案的设计
远程诊断系统的架构如图1 所示，主要包括以下5部分：远程诊断（RemoteDiagnosis,RD）请求发起者、远程诊断服务器、远程诊断客户端、远程诊断人机交互以及待诊断部件。

图1 远程诊断系统架构
（1） 远程诊断请求发起者
试验阶段的试验人员、售后阶段的售后维修人员以及车主等相关人员，其都可以根据自身所具有的对应权限使用手机APP或WEB端发起相应远程诊断请求。
（2） 远程诊断服务器
为管理车辆数据与远程诊断客户端信息，在远程诊断发起之后，将验证后的远程诊断请求转化为定义好的数据或脚本，并发送给对应的远程诊断客户端。远程诊断服务器在接收到远程诊断客户端的应答或接收主动上报之后，对数据进行存储以及相应的计算分析，远程诊断服务器的内部主要工作组件及工作流程如图2所示。

图2 远程诊断服务器
远程诊断服务器内部的知识管理模块包含整车所有能够进行体检的系统失效模型，每个系统失效模型都是由组成该系统的关键零部件或所有零部件的失效模型组成，每个零部件失效模型以该零部件对应的特征参数（包括输出信号特征参数，零部件老化特征参数，工作效率特征参数等重要信息）以及故障信息为输入，根据参数的数目、各参数的重要程度以及故障信息等因素而构成，系统失效模型则根据各零部件的相关关系以及重要程度再基于各零部件的失效模型而构成。
（3） 远程诊断客户端
车端某个关键控制单元，负责与远程诊断服务器建立通讯的同时模拟诊断仪功能，将接收到的后台数据或脚本解析成对应的诊断指令发给车内目标控制器，收到该控制器应答之后将报文转化为与服务器定义好的格式发给远程诊断服务器。
（4） 远程诊断人机交互
车内用户辅助操作接口，用于远程诊断任务执行过程中与用户的交互。
（5） 待诊断部件
远程诊断的目标控制器。
3 远程诊断系统的应用
基于SOA 新架构所具有的车辆功能的灵活性以及汽车远程诊断系统连通了车、云之间通讯的优势，提出了为满足客户多样化需求而制定的相关应用，既可以有效地提高用户的满意度和体验感，同时也可以简化整车厂同一车型车系的结构，进而缩减相应车辆管理、生产线工作相关内容，提升整车厂工作效率。
3.1 车辆功能配置服务
基于该应用，用户可以通过手机客户端、车辆娱乐主机屏方式，查看自己车辆的当前硬件，哪些功能是可以新增或关闭的，针对功能的变更，详细变更内容清单、各项费用以及如需加装硬件对应详细信息都会呈现。如无需加装硬件，或已安装需求硬件，则通过在线付费或免费进行预约升级，满足功能升级条件后则自动升级。该应用可以最大程度地满足客户对新功能技术的需求，同时费用的透明化将进一步增加客户对品牌的信赖度。
整车厂基于新架构建立自己的软硬件平台，在所有控制器满足统一软硬件架构及开发流程的基础上，针对不同选装功能的支持情况进行控制器配置化管理，进而满足用户存在的不同选装需求的情况。
3.2 车辆体检服务
基于该应用，整车厂以及用户都可以发起车辆的体检服务，不同角色有着不同的体检方案，整车厂可以针对某一批量或某种车型发起集体体检服务，用户则可以对自己授权车辆发起体检。
根据体检内容的不同（可以对零部件、系统或整车进行体检）进而调用远程诊断服务器中不同的服务，该服务通过车、云的通讯将对应运行程序或脚本下载到车辆，车端远程诊断客户端会根据程序或脚本内容进行解析以及执行数据的收集，将收集完成的数据统一回传到远程诊断服务器中，该服务器中的健康分析模块根据此服务类型信息调用知识管理模块中对应的失效模型，基于预设的分析逻辑，最终分析得出服务的体检报告，进而呈现给服务的发起者。
用户根据该服务可以及时了解自己车辆的状态，进而保障自己每一次出行的安全性。整车厂可以根据该服务获取重要数据，进而逐步优化自己的远程诊断系统，保证系统准确性的同时也可针对车辆潜在的问题提前发现进而规避处理。
3.3 车辆快捷服务
基于该应用，用户可以快速获取车辆当前的故障状态以及自主清除车辆故障码。车辆故障码的实时获取以及对应故障描述可以帮助用户实时了解各控制器的状态，根据自身当前所处状态合理安排维修计划，避免因不了解情况而造成的恐慌。
用户也可以基于该应用实时了解车辆保养情况以及各控制器相关信息，提前合理安排车辆的保养计划以及保证车辆所有控制器随时处于最新状态，使得车辆处于最佳工作状态。
服务功能结构如图3所示：

图3 车辆快捷服务功能结构
3.4 车辆在线诊断仪服务
基于该应用，4S店或相关专业人员可以根据不同的授权等级在线进行传统诊断仪相关功能的操作。操作人员需要向整车厂申请对应在线诊断仪服务需求的授权，获取权限后可以通过移动终端设备下载对应应用进行相关诊断仪功能操作。
在线诊断仪服务的实施，将传统的故障或问题车辆需要开往或被拖运到售后维修店进行维修的方式转变为售后维修人员或专业人员主动到故障或问题车辆所在位置进行维修。服务方式的转变，将大大提升用户的满意度和体验感。
4 总结
近年来，随着汽车电子化程度的逐渐加大，在满足用户多样化需求的同时，整车线束以及整车网络架构也在逐渐复杂化。在当前以“安全”为背景的社会主题下，如何在保证满足用户多样化需求以及服务的前提下，有效地降低车辆故障发生的概率以及缩短车辆研发周期变得尤为重要。
（1）汽车行业SOA 新架构的引入，可以有效地解决因车辆功能增多而使得整车网络架构、整车线束复杂化的问题，优化整车架构，降低车辆故障发生率；同时主机厂可以基于SOA架构独立性的优势，建立自己的软硬件平台，整车各控制器的软硬件开发在遵守统一的开发架构及标准下，可以有效地缩短整车的研发周期，降低开发成本。
（2）汽车远程诊断系统实现了车辆与云之间的通讯，为整车厂研发提供了一个新的平台，基于此平台开发了面向整车厂或用户的一系列相关应用，以此实现整车厂的闭环式研发以及新的售后服务模式，同时也最大程度的满足了用户的多样化需求，在保证用户满意度以及体验感的前提下也提高了用户的行车安全。
（3）基于远程诊断系统所具备的车辆数据获取的便利性、灵活性，在车辆数据逐步积累的前提下，结合大数据分析技术的快速发展，未来针对远程诊断与大数据技术相结合方向的研究，将会是必然的趋势，也定当在车辆研发的数据闭环方面以及相关新领域，如车辆故障预测等方面表现出可观的优势。
AUTOSAR的生与死
如果没有特斯拉的出现，汽车行业平静的日子或许能维持的更久一些。
2017年7月，Model 3正式开始交付。在数家车企和机构对其进行从外到内的细致拆解之后，得出的结论包括：“其电子电气架构堪称杰作”、“比丰田和大众领先六年”、“做不到”……
Model 3颠覆了传统的电子电气架构，创造性地使用了域控制器，并让讲Linux一种语言，彻底抛弃了在传统汽车世界里“不容置喙”的权威软件架构——AUTOSAR。
特斯拉的做法相当于在一个几乎所有人都用木头盖房子的世界里，用砖和水泥盖了一个房子。
是异类，但却成为智能汽车时代的引领者。
在特斯拉的“刺激”之下，一场汽车软件革命呼啸而来。
分布式电子电气架构显然已经落伍，而系统软件架构AUTOSAR，又能否追赶上智能化的浪潮？车企是否需要和特斯拉一样，彻底打破一切传统，才能真正掌握自己的生与死？
传统车企的命运开始在这场剧烈的革命中变得飘忽不定。
一
当前，全球几乎所有的整车开发都需要依赖AUTOSAR，是汽车广泛使用的嵌入式系统软件架构，是汽车世界中最权威的软件开发规则。
这样一套复杂、严谨、庞大的规则体系的建立，还要从一个个小小的电子控制单元（ECU）说起。
1950s—1970s，是汽车电子技术的起步时期，一些车企开始用电子零部件来代替机械部件，改善车辆的性能。但这一阶段，汽车电子还只是在汽车收音机、电子喇叭、电压调节器等比较简单的领域发挥作用。
70年代末到80年代初，集成电路以及16位以下的微处理器在汽车上开始应用，电子装置开始应用在机械装置无法解决的复杂控制功能方面，包括自动门锁，自动除霜系统、装车预警系统、自动巡航等。
到了90年代，汽车电子已经深入到可以实现各种功能的综合系统，包括发动机控制与自动变速器控制为一体的动力传动控制系统、制动防抱死系统等。
随着汽车电子的发展，ECU从最开始简单的控制收音机，逐步深入到汽车的各个角落，成为驱动汽车执行每一个动作的大脑。
时至今日，一辆普通轿车上，ECU的数量已经达到70个以上，车辆功能越复杂，ECU数量则更多。
1993年，一辆奥迪A8上面使用的ECU数量仅有5个，但到了2010年，ECU数量就已经突破了100个。

然而，进入传统汽车的底层，会惊讶地发现，这是一个无比混乱的世界。
这些独立的“小电脑”如同一个个独立的王国，说着不同的语言，彼此之间通过CAN/LIN总线进行微弱的通信。
管理这些ECU的难度不亚于管理一个“小宇宙”。大众品牌一台车上的70多个控制单元的操作软件可以来自多达 200 家不同的供应商。可想而知，让协调起来是多么困难。
一名来自德国的汽车工程师Alex Voigt在一篇文章中形象的比喻：
“一只章鱼有 8 个手臂，每个手臂都有自己的小脑子来管理。这 8 个小脑子与中央大脑进行通讯。科学家尚未弄清这一切如何运作，以及为什么这些手臂不会互相挡住。
汽车面临着本质相同的挑战，但进展并不乐观。各个控制器的“手臂”仍在按照自己的方向行动，没有协调，很快就能耗尽车辆中可用的能量。”
然而，汽车就是在这样混乱的状态下渡过了40多年。
更致命的是，早期ECU的软件和硬件高度耦合，紧紧地捆绑在一起，很难将彼此拆开。
软件和硬件之间如此亲密的关系，给车企和供应商带来了巨大的痛苦。
每当需要更换新的硬件时，都需要对ECU的软件进行重新编写和大规模的修改，随之而来的还有一系列的测试。任何微弱的变动都将带来灾难性工作量。
这一切都导致了整车开发周期漫长无比，并且车企需要为此支付高昂的研发费用。
汽车的软硬件之间亟需一个类似于电脑操作系统与应用程序之间的“中间件”，将软硬件解耦。
于是，AUTOSAR应运而生。

二
将全球各家车企和供应商的软件开发标准统一，无疑需要汽车界巨头们的强大号召力。
2003年，由全球最大规模的几家汽车企业、零部件供应商以及电子、半导体、软件系统公司，联合成立了一个汽车开放系统架构联盟——AUTOSAR联盟，并推出了一个开放化、标准化的汽车嵌入式系统软件架构——AUTOSAR规范。
目前AUTOSAR联盟已经囊括了100多个会员。各会员依据其对AUTOSAR的贡献及责任分为三个等级：核心合作伙伴（Core Partners）、高级合作伙伴（Premium Partners）、发展合作伙伴（Associate Partners）。
包括大众、丰田、宝马、戴姆勒、大陆、博世、福特等在内的9家核心公司是AUTOSAR协议的发起人，也负责AUTOSAR开发模式的筹划、管理和调控。

由此，一个史上最为庞大的汽车软件联盟形成了，在这些主力军的加持下，汽车行业大大小小的企业都纷纷投入AUTOSAR的怀抱，AUTOSAR也成为了最权威的软件开发标准。
在AUTOSAR刚刚兴起的时候，一些公司甚至会将使用AUTOSAR架构作为宣传点，使用AUTOSAR则代表着车辆有最靠谱的安全保障。
在AUTOSAR架构中，系统软件被规规整整的进行了分层，看起来井然有序，如同一篇逻辑清晰的文章。
整个架构从上到下分层依次为：应用层（Application Software Layer），运行时环境（Runtime Environment，RTE），基础软件层（Basic Software Layer，BSW），微控制器（Microcontroller）。
每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。

分层架构是实现软硬件分离的关键，也使得汽车嵌入式系统控制软件开发者，得以在ECU软件开发与验证过程中，摆脱对硬件系统的依赖。
AUTOSAR的出现极大的解决了车企和供应商们最大的苦恼，大大降低了软硬件之间的耦合度。所带来的好处是显而易见的：
1.有利于提高软件的复用度，使软件可以跨平台复用；
2. 便于软件的交换与更新；
3. 软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；
4. 减少手工代码量，减轻测试验证负担，提高软件质量；
5. 使用一种标准化的数据交换格式，方便各个公司之间的交流合作。
这些优势，使得各个企业在保证软件质量的同时，大大降低了开发的风险与成本。
AUTOSAR不仅在软件的功能、接口上进行了一系列的标准化，还提出了一套规范化的开发流程与方法，使得更多的软件供应商进入汽车电子行业，大家都遵循同一个标准去开发。
总而言之，有了AUTOSAR架构，车企可以完全成为“甩手掌柜”，不需要再管难度最大的底层软件问题。
三
任何事物都有两面性，AUTOSAR在解决问题的同时也带有着很多先天和后天的弊端。
首先，AUTOSAR是巨头们制定的游戏规则，成为了巩固自己垄断地位的方式。巨头们通过AUTOSAR设定了一套技术壁垒，将想进入汽车行业的玩家挡在自己的世界之外。
目前全世界范围内能开发完整的基于AUTOSAR架构底层协议栈的公司寥寥无几，国内更是几乎为零。大部分Tier 1和主机厂都无法自己建立AUTOSAR架构，主机厂和Tier 1需要向少数几家供应商购买底层软件。
当然，购买这些软件需要付出昂贵的费用，一个ECU的开发费都在几十万左右，如果“全套”下来，开发费至少要在千万级别之上。
这笔钱几乎等同于进入汽车世界的“门票”。
据一家车企的开发人员透露，如果不采用AUTOSAR架构，供应商甚至无法及时提供硬件。大家都是遵照AUTOSAR标准开发，如果想特立独行，不好意思，只能先等等，以及，付出更高的开发费用。
此外，AUTOSAR面面俱到的规范文件也给软件工程师们带来了繁杂的工作。这些规范如同八股文一样，工程师们需要按照严苛的按照标准进行“写作”，不可以越雷池一步。而AUTOSAR的标准高达上百页，工程师们以一己之力很难真正理解。
但是，这些都不足以颠覆AUTOSAR的地位，在传统汽车世界里的重要性是毋庸置疑的。
对AUTOSAR来说，最致命的是，是传统汽车时代的产物，进入到智能汽车时代，已经力不从心，尽显疲态。
当前汽车产业迎来了智能化的转型浪潮，整车电子电气架构架构开始由分布式变为域集中式，又逐渐成为中央集中式，大大的提升了算力利用率，减少算力设计总需求，并让数据统一交互，实现整车功能协同。此外，线束也大大缩减，降低了故障率并减轻了质量。而车载网络也由LIN/CAN总线向车载以太网发展。
传统的AUTOSAR架构（Classic AUTOSAR）已经不能适应智能化的需求。
当然，AUTOSAR本身也开始与时俱进，推出了Adaptive AUTOSAR，主要面向更复杂的域控制器和中央计算平台的电子电气架构。
此前车辆单一的Classic AUTOSAR架构也开始逐步向 Classic AUTOSAR 和 Adaptive AUTOSAR混合式架构。
在混合式的架构中，Classic AUTOSAR应用于传统嵌入式 ECU 中，包括发动机控制机和电机控制器，而Adaptive AUTOSAR更多的应用于 ADAS和自动驾驶等对于计算能力和带宽通信要求更高的领域中。出于对于汽车安全的要求， Adaptive AUTOSAR 还介入驱动底层。
然而，当《建约车评》询问镁佳科技创始人庄莉和理想汽车智能与系统副总裁范皓宇，Adaptive AUTOSAR是否可以真正满足智能化的需求，得到的答案都非常肯定：不能。
在特斯拉出现之前，传统汽车采用的电子电气架构是分散的ECU，而特斯拉是第一家对整车电子电气架构进行大刀阔斧变革的车企，并采用CCM中央计算模块，将4G模块、ADAS域控制器和智能座舱的计算单元，整合在一块主板上，形成了汽车的“中央计算平台”。
中央计算平台算力更高、处理能力更强。显然是分散式的、仅能处理单一任务的ECU无法企及的。
两个处理器有着天壤之别，特斯拉在中央计算平台的基础上形成了基于Linux开发的实时操作系统，而AUTOSAR则是在独立的ECU基础上开发的中间件。
正如功能手机向智能手机转换，需要有新的架构和新的操作系统来支持智能手机丰富多样的功能。如果工程师们试图通过修改塞班系统来让功能手机变成和搭载Andriod、iOS系统一样的智能手机，难度无异于“点石成金”。
因此，在车内的硬件处理器架构发生变化之后，此前面向ECU开发的中间件和操作系统，已经不再适用于新的面向域控制器和中央计算平台的硬件构架，无法继续作为操作系统和中间件。
新的操作系统对内存、文件系统、多任务调度有很好的支持，而此前的ECU只有一个任务在重复执行。所以在这种情况下，Autosar为了适应新的变化，推出了Adaptive Autosar。
然而，参照功能手机的时代，曾经的塞班系统面对智能手机的浪潮挣扎了很久，但无论付出多大努力，也根本无法成为一个完全为智能手机设计的操作系统。
同样，AUTOSAR无法通过修补一个为ECU设计的构架，来适应新的中央计算平台。
这是AUTOSAR与生俱来的弱点。
范皓宇指出，AUTOSAR出现背景本身就是电气化，而不是智能化。这样的一套框架能够让整车厂和多个不同供应商之间在软件部分有共通的框架，确保稳定可靠的功能从物理连接变成电气连接。
在智能化的趋势下，计算平台和系统架构的演进方向，应该是让整车可以持续迭代、升级，改善性能以及用户体验，并能够提高应用开发效率，这需要一个更加统一和高效的操作系统。
仅仅保证功能稳定标准可靠是不能满足需求的，用一个统一的确保稳定可靠的架构，来承载灵活多变是很难实现的。
庄莉指出，随着每个时代硬件的发展，为上一个时代的硬件设计的软件构架都会被自然地淘汰。一个时代的硬件，需要一个为专门设计的软件构架来配合。
AUTOSAR的的另一个危机在于，在智能汽车时代，软件已经成为汽车的大脑，是整车最核心的部分，软件的背后是用户和海量的数据，以及整车OTA能力，如果车企没有软件能力，等同于将自己的命运交付到别人手中。
AUTOSAR架构对于车企而言，就如同一栋已经盖好的房子，住户无法决定高度、面积和户型，唯一可以改变的只有内部的装修。这也就大大限制了车企的自由度，失去了自己的个性，更重要的是失去了底层控制能力。
基于AUTOSAR开发的控制器的软件工作由供应商完成，供应商占据着绝对的主导权，也意味着车企想要整车OTA必须通过供应商完成。
车企只能依靠卖硬件赚钱，这样的盈利模式显然已经不够“性感”。
看看特斯拉最近的举动，就不难理解整车OTA对车企未来命运的重要性。
将整车OTA做到出神入化地步的特斯拉，已经开始利用这一强大的能力为自己赚钱。
今年2月份，特斯拉开始为美国地区的Model 3 长续航后驱版以及长续航后驱升级版车型提供后排座椅加热升级包，升级包的价格为300美元。
5月9日，特斯拉官又方针对model 3长续航全轮驱动版车型推出了付费升级加速能力的服务，通过OTA升级，可以将车辆百公里加速能力从4.6秒提升到4.1秒。为此，车主需要花费1.41万元。
OTA彻底改变了车企的盈利模式，让车企和用户之前不再是“一锤子买卖”，可以通过软件升级提供新功能来持续赚钱，并且没有任何额外成本。这样的诱惑，是任何企业都难以抗拒的。
如果将底层软件能力交给供应商来做，首先车企和供应商之间存在博弈，能不能实现要打个问号。即使可以实现，供应商也要从中收取一大笔费用，车企或许只有喝汤的份。
同样类比智能手机，很难想象如果操作系统以及核心软件不掌握在苹果手中，每次系统更新推送都是由供应商代为处理，是否还会获得和今天一样的使用体验，而世界上也会少了一家万亿市值的科技公司。
由此，有能力的车企正在疯狂地试图将软件能力夺回来，建立自己的软件开发能力。
在这样的背景下，AUTOSAR的权威地位正在被动摇。是上一个时代的强者，但终将落幕。
四
传统车企和汽车人正在觉醒。
前奥迪研发负责人兼董事会成员彼得·梅滕斯（Peter Mertens）于 2020 年 6 月说：“实话实说，站在个人的观点上，其实一直睡到了现在的状态。”“做了错误的决定。太信任供应商会以某种方式实现。”
汽车工程师Alex Voigt指出“没有软件，车企将失去数字时代的黄金，即客户数据”、“没有软件，公司大概就是个组装低利润的金属盒子的企业，并且这个低利润的金属盒子是个毫无价值的普通商品。”
然而，汽车企业日益增长的对软件部分的控制欲，与自身落后的软件开发能力之间的矛盾，已经成为当前最主要矛盾。
大众集团当前所遭遇的困境，说明了一切。
2018年8月23日，大众汽车集团新任CEO赫伯特·迪斯宣布将斥资35亿欧元打造vw.OS，开始向数字化进行激烈的转型。
为了实现智能化，做到真正意义上的“软件定义汽车”，大众打破了原先近百个ECU的域架构，重构汽车产品。建立自己的vw.OS、E3整车电子电子架构以及Volkswagen Automotive Cloud。
6月19日，前大众负责数字服务和软件的董事会成员Christian Senger称，公司希望使用开源方式改进其正在开发的基于软件的汽车操作系统。
Senger表示：“操作系统不是自己能够控制的东西。将定义核心，然后立刻加入开源组件，从而制定标准。这将为合作创造机会。”
这相当于大众希望自己建立一套标准的软件架构，为各个品牌和供应商提供一个开放的、通用的平台。最终的目标就是取代AUTOSAR。
Senger同时指出，主机厂目前非常依赖第三方开发，导致效率极其低下。
大众希望保留对整个汽车电子电气架构的控制，软件能力是确保长期竞争力的唯一途径。仅出于这个原因，大众不能让第三方完全获取车辆中的数据，这些数据应该留在公司内部。
VW.OS 将使得大众自主定义软件、OTA 等需求得以实现。但这也同时意味着，作为AUTOSAR的核心成员，大众集团的心已经开始动摇。
高达70亿欧元的投入、5000人的庞大软件团队，都只为一个目标：实现大众汽车的数字化转型。
然而，让这位百年汽车工业巨头万万没想到的是，这一行行代码写起来真的让人感到“头秃”。
变革的强力推动者迪斯，甚至已经为此付出了惨重的代价。
7月1日起，迪斯不再担任大众乘用车品牌 CEO 的职务；紧接着在7月12日又有消息传出，迪斯的心腹、大众品牌软件研发负责人Christian Senger已经“被离职”……
一场由软件问题引发的血雨腥风，在沃尔夫斯堡上空弥漫。
隔行如隔山，传统车企相当于进入到了一个自己完全陌生的领域。
作为在数字化转型方面决心最大、投入最狠的大众，尚且举步维艰，那么其它大批传统的车企的命运又将如何？
在中国，魏建军宣布长城汽车将从传统的汽车制造商转型为全球科技出行公司；上汽正在如火如荼的筹建软件中心——零束。大量传统车企开始行动，但能否真正成功，还需要时间的验证。
专业的软件人才，将成为这场变革中的中坚力量。
大量的车企并没有办法像特斯拉一样，构建一套属于自己的软件架构，而目前一些新兴车企采取的办法是，在汽车传统机械部分选择继续使用AUTOSAR，充分利用其优势，而在与智能化有关的、需要灵活变化的部分，开始搭建自己的架构。
当然，这一部分也是未来汽车产品中最为核心的部分，将掌握在自己手中才真的安心。
毫无疑问的是，这些拥有软件能力的车企，将在未来智能化的竞争中脱颖而出。
然而，绝大多数的车企尚没有半点软件开发能力，最终的结局恐怕只能沦为组装厂，赚取微薄的生产加工费用。
生存还是死亡，这并不是个问题。
结尾：
曾经，汽车的世界如同时间凝固一般。
五花八门的尖端科技在手机这个五英寸见方的空间里展现的淋漓尽致，并时不时通过OTA进行软件升级，带给人们新的体验。
然而，汽车这个更有想象力的移动空间却仿佛成了被科技和互联网遗忘的角落，四个轮子拖着沉重的躯壳，日日夜夜坚守着作为代步工具的唯一使命。
是时候发生些改变了。
但目前的现状是，大多数传统车企处于有心无力的状态，甚至大批的车企还没有真正苏醒过来。
像大众一样坚定地喊出转型并不容易，但更不容易的是真正的转型成功。
IOS系统架构
IOS系统架构
本文包含 Apple IOS 框架列表及其概述。尝试将大多数 iOS 框架置于底层，可以帮助新开发人员入门并了解IOS开发大概。希望能帮助。
CORE SERVICES Layer:
核心服务层中存在一些重要的框架，可帮助 iOS 操作系统自修复并提供更好的功能。如上所示，是架构中的第二低层。以下是该层中存在的一些重要框架：

  1. Address Book Framework-The Address Book Framework 提供对用户联系方式的访问.
  2. Cloud Kit Framework-应用程序和 iCloud 之间的数据同步.
  3. Core Data Framework-用于管理模型视图控制器应用程序的数据模型，对SQLlite做了一定封装.
  4. Core Foundation Framework-为 iOS 应用程序提供数据管理和服务功能.
  5. Core Location Framework-该框架向应用程序提供位置和导航信息.
  6. Core Motion Framework-访问设备上所有基于运动的数据.
  7. Foundation Framework-提供了许多基本的对象类和数据类型，比如数字，字符串，数组，集合，字典，处理日期时间，自动化内存管理，文件，归档，处理几何数据结构等.
  8. HealthKit Framework-处理用户的健康相关信息.
  9. HomeKit Framework-用于与用户家中连接的设备进行通话和控制.
  10. Social Framework-访问用户社交媒体帐户的界面.
  11. StoreKit Framework-支持从 iOS 应用程序内部购买内容和服务.
  12. JavaScriptCore Framework
    在 Swift、Objective-C 和基于 C 的应用程序中运行 JavaScript 程序的能力。还可以使用 JavaScriptCore 将自定义对象插入到 JavaScript环境中
  13. SafariServices
    在应用程序中启用 Web 视图和服务。
    MEDIA Layer:
    在媒体层的帮助下，将启用系统的所有图形视频和音频技术。这是架构中的第二层
  14. ULKit Graphics-设计图像和动画视图内容框架
  15. Core Graphics Framework-支持 2D 矢量和基于图像的渲染广告，是 iOS 的原生绘图引擎。.
  16. Core Animation-用于优化 iOS 中应用程序的动画体验
  17. Media Player Framework-支持播放播放列表并使用户能够使用 iTunes 库。.
  18. AV Kit-各种易于使用的接口，用于视频演示、录制和播放音视频.
  19. Open AL-用于提供音频的行业标准技术。.
  20. Core Images-图像处理提供了高级支持。.
  21. GL Kit-通过硬件加速接口管理高级 2D 和 3D 渲染.
    COCOA TOUCH（应用层）
    COCOA Touch 也称为应用层，充当用户使用 iOS 操作系统的界面。支持触摸和运动事件以及更多功能。
  22. EvenKit Framework-使用视图控制器来查看和更改事件的标准系统界面.
  23. GameKit Framework-支持用户使用游戏中心在线共享游戏相关数据.
  24. MapKit Framework-提供了一个可滚动的地图，可以将其包含在应用程序的用户界面中.
  25. PushKit Framework-框架提供注册支持.
  26. PDFKit Framework
    在应用程序中显示和操作 PDF 文档。
  27. Core NFC
    为用户提供有关其物理环境和其中真实世界对象的更多信息
  28. ARKit
    提供虚拟现实交互增强
  29. Core-ML
    集成机器学习环境
    其他
    可以看到还有N多层集成，每次IOs系统更新还会发布不少

IOS-Kit
参考
1.https://vikaskore.medium.com/a-overview-of-ios-frameworks-79fa2d195694
2.https://vikaskore.medium.com/overview-of-ios-11-frameworks-fb80ed30b150
3.https://developer.apple.com/documentation/technologies” />

iOS 架构 DEMO
一、关于组件化
组件化似乎是项目发展壮大过后必然要做的事情，能让各个业务线的工程师不需要过多的关注其他业务线的代码，有效的提高团队整体效率。然而实施组件化的时机是在需求相对稳定、产品闭环形成过后。所以本文不会应用组件化，但是这里简单谈谈业界的组件化方案。
组件化的核心问题就是组件间如何通讯。“软件工程的一切问题都能通过一个间接的中间层解决。”中介模式很自然的运用起来：

这样虽然能统一组件间的通讯请求，但是却没有避免 Mediator 和目标组件的耦合，ModuleA 工程中仍然需要导入 ModuleB 。
所以重点问题落在了解耦上：

要达到 Mediator 和目标组件的解耦，就需要实现之间的间接调用（图中虚线），既然是间接调用，必然需要一种映射机制。在 iOS 开发中，业界大概有三种方式来处理。
(1) 使用 URL -> Block 解耦
简单来说就是将组件的调用代码放入 block 中，然后 URL 作为 key，block 作为 value，存入一个全局的 hash 容器，组件通过一个 URL （比如 “native/id=10/type=1” ）向 Mediator 发起请求，Mediator 找到对应的代码块执行。由此，解开了 Mediator 和目标组件的耦合。
这种方案的缺陷很多：组件越多常驻内存越多；解析 URL 逻辑复杂；URL 无法表述具体语言相关的对象类型。所以这种方式并不适合组件化解耦。
(2) 使用 Protocol 解耦
阿里的 BeeHive 是该方案的很好实践，笔者阅读了一下源码，大致工作原理如下：注册 Protocol 对应的组件，这个和上面说的 URL->Block 方式如出一辙，只不过这里是 Protocol-> Module ；组件申请访问时导入对应的 Protocol 通过 Mediator 获取到对应的组件对象。由于协议的表述能支持所有的对象类型，所以这种方式能基本解决组件间通信的需求。
BeeHive 注册组件有几种方式，一种是监听了动态链接时 image 二进制文件加载完成的回调，通过修改代码段的方式判断对应的模块进行注册；第二种是在 +load 方法里面注册；第三种是异步注册，但是这种方式存在一个问题，可能组件使用方准备使用组件的时候，这个组件还未注册成功。
BeeHive 还为组件设置了优先级的概念，通过数组来保持优先级排序，在源码中能看到一些数组排序的逻辑，这就带来了相当多的高时间复杂度的运算。
所以，组件数量过多的话，会延长动态链接库的过程。
BeeHive 为了让每一个组件享有独自的 app 生命周期、3D touch 等功能，会将这些系统级的事件发送给每一个组件，且不谈大量的方法调用损耗，必须让入口文件 AppDelegate 继承自 BeeHive 的 BHAppDelegate，笔者感觉侵入性过强，并且当开发者需要复写 AppDelegate 方法的时候，还要注意让super调用一下，可以说很不优雅了。
在基于协议的组件化方案中，组件使用方能直接拿到目标组件的实例，那么使用者可能对该实例进行修改，这可能会带来安全问题。
(3) 使用 Target-Action 解耦
Casa Taloyum 前辈的 iOS应用架构谈 组件化方案 为此做出了最佳实践。
Mediator 使用 Target-Action 来间接的调用目标组件，无需专门注册。组件维护者需要做一个 Mediator 的分类，通过硬编码调用目标组件，然后组件使用者只需要依赖这个分类就行了。封装的 Mediator 源码只有简单的 200+ 行代码，并且很易懂。这也让开发者能对组件化的实施更加有信心，不会因为基础设施的错误而束手无策。
小总结
关于以上组件化的简单表述仅代表笔者的个人见解，由于笔者并没有真正的实施组件化，所以理解可能有误。
虽然笔者设计的 iOS 架构不会应用组件化，但是这给架构设计带来了前瞻性的引导，这非常重要。
二、模块化思维划分文件
在团队开发中，项目发展到后期总是会出现某些文件或代码难以管理，出现这种情况的主要原因通常是项目开发过程中对文件的管理过于随意。
开发者应该尽量将所有代码文件归于模块，而不要出现模拟两可的文件。而笔者这里说的模块，是有具体意义的模块，比如图片处理模块、字体处理模块，而不是诸如 Public、Common 等无具体意义的代码文件。
试想，在多人开发中，当所有人都觉得有些代码不知道怎么归类的时候，就会往 Public 里面扔。当某天想要整理一下这个 Public，会发现已经无从下手；或者当需要迁移项目中的某个业务模块时，会附带迁移一些模块，当这个模块是有意义的（比如图片处理模块），迁移成本会非常低，但是当这个藕断丝连的模块是 Public 时，时间成本可能高于想象，估计会将完整的拷贝过去，而又对新项目造成了污染。
全局的公共文件是产生垃圾代码的源头。笔者认为几乎所有的代码都是可以归类为模块的。
大致梳理了一个文件分类，当然这个分类是灵活的，只是要分模块划分：

  • GeneralModules 放项目独有的通用配置模块（比如通用颜色模块、通用字体模块） – ToolModules 放工具类模块（比如系统信息模块） – PackageModules 放基于业务的一些封装（比如提示框模块、加载菊花模块） – BusinessModules 放业务模块（比如购物车、个人中心）
    具体里面放了些什么，可以查看笔者的 DEMO。
    三、减少全局宏的使用
    很多时候，过多的宏让项目很不整洁，每一个开发者都往全局文件添加宏，而往往只是一段简单的代码，笔者认为开发中应该尽量少使用宏，原因如下：
    • 宏在预编译阶段替换为实际代码，存在效率问题
    • 使用宏的地方可能只需要一块内存，但是宏替换过后开辟了多个（这种情况应该用常量替换宏）
    • 可能存在潜在的宏命名冲突
    • 宏包装过多的代码难以理解和调试
    • 代码迁移时需要处理全局的宏
    实际上，非得使用宏的地方并非那么多，比如需要定义一个全局的导航栏字体方便使用，可以将通用字体的配置参数作为一个模块：
    @interface YBGeneralFont : NSObject/** 导航栏标题字体 /+ (UIFont )navigationBarTitleFont;@end
    或者用常量来代替宏：
    .hFOUNDATION_EXTERN NSString * const kNotify_xxx; //xxx通知 key.mNSString * const kNotify_xxx = @“kNotify_xxx”;
    这么做也便于转换思维，毕竟 swift 中是没有宏的。
    四、去基类化设计
    代码设计中，应该尽量避免基类的使用，也就是说，不应该总是要求开发者去继承基类来做功能。使用基类将造成不可避免的耦合，为业务的长期发展带来阻碍（当然某些情况是可以使用基类的）。
    其实使用基类就算了，若是将大量的业务逻辑放入基类中将是灾难的开端。试想，当项目新成员一来就看见成千上万行的基类代码TA作何感想？
    另外一种场景，当需要将项目中的某个模块迁移到其他项目，或者需要将其他项目合并入当前项目，基类的合并将是一个非常头疼的问题，藕断丝连的模块和代码会让抓狂。
    那么，类的工具方法应该放哪儿？对所有类的统一配置应该放哪儿？对封装模块的个性化定制应该怎么做？
    装饰模式
    类的工具方法，按道理说可以提取为模块，但是有些场景可能显得不够简洁。
    其实只要留意 iOS 官方的 API，就不难发现装饰模式的大量应用，使用数个分类将大量的方法按照功能分类，会清晰且优雅：
    @interface UIViewController (YBGeneral)/     基础配置 /- (void)YBGeneral_baseConfig;@end@interface UIViewController (YBGeneralBackItem)/* 配置通用系统导航栏返回按钮 /- (void)YBGeneral_configBackItem;/* 重写该方法以自定义系统导航栏返回按钮点击事件 */- (void)YBGeneral_clickBackItem:(UIBarButtonItem *)item;@end
    不过要注意的时，定义分类的时候一定要加一个前缀标识以避免方法覆盖。
    AOP
    面向切面编程在 iOS 领域经典的应用就是利用 Runtime 去 Hook 方法：
    @implementation UIViewController (YBGeneralHook)+ (void)load { [self YBGeneralHook_exchangeImplementationsWithOriginSel:@selector(viewDidLoad) customSel:@selector(YBGeneralHook_viewDidLoad)];}+ (void)YBGeneralHook_exchangeImplementationsWithOriginSel:(SEL)originSel customSel:(SEL)customSel { Method origin = class_getInstanceMethod(self, originSel); Method custom = class_getInstanceMethod(self, customSel); if (origin && custom) { method_exchangeImplementations(origin, custom); }}- (void)YBGeneralHook_viewDidLoad { NSLog(@“进入：%@”, self); [self YBGeneral_baseConfig]; if (self.navigationController && [self.navigationController.viewControllers indexOfObject:self] != 0) { [self YBGeneral_configBackItem]; } [self YBGeneralHook_viewDidLoad];}@end
    代码中统一配置了 UIViewController 的系统导航栏返回按钮，注意这里调用的业务配置方法都是定义在 UIViewController 的分类里面的。若有某些导航栏需要格外配置返回按钮的需求，可以拓展一个属性来控制。
    面向协议设计模式
    对于一些封装的组件，多考虑使用协议来个性化定制，继承作为最差方案，而非是首选方案。
    定义一个遵守组件定制协议的属性是常用的解决方法：
    @property (nonatomic, strong) id strategy;
    不同的属性作为不同的策略，组件内部通过调用对应的协议方法实现个性化定制。而当使用者想要改变策略时，只需要更改这个属性就行了。面向协议设计模式结合策略模式是一个很好的实践。
    五、MVC？MVP？MVVM？VIPER？
    业务具体的架构模式是个让很多开发者头疼的问题，因为有时候能让复杂业务更清晰，有时候却因为胶水代码过多而臃肿。
    实际上为什么要严格的遵守架构模式呢？为什么每一个业务模块的架构模式都要一模一样呢？
    认为正确的架构思路一定是根据业务来的，不同的模块，不同的业务线完全可以有不同的架构，只需要架构足够清晰不至于晦涩。
    大致设计了一下架构的主旋律：

• DataCenter 负责数据的获取、处理、缓存等。
• Model 设计为“瘦” Model，便于复用和迁移；也考虑到数据源可能数量庞大，若 Model 设计得过于“胖”，会造成更多的内存占用。
• View 负责数据的展示，可以根据业务情况权衡是否需要 ViewModel 处理界面逻辑。
• ViewController 作为 DataCenter 和 View 的桥梁。

设计的项目目前不会很复杂，多数情况上面的架构就已经够用，若某个页面功能过多，完全可以提取一些额外的模块，比如 DataCenter 处理过于复杂，那就把数据的处理和缓存提取出来：xxxDataProcesser、xxxDataCache。这些都是灵活的，只需要按照模块化的思维提取，ViewController 的代码相信也不会太多。
关于响应式框架
Reactivecocoa 虽然强大，笔者以前也用过，不过是一个重量级框架，学习成本有点高，可能会因为团队成员对其了解不足导致难以定位的错误。
而美团的 EasyReact 似乎是一个福音，笔者大概浏览了一下源码，质量确实很高，对性能方面的处理很精致，基于图论算法的处理也感觉很棒，项目侵入性也很小。不过缺点就是太新了，需要开发社区一定时间的验证，暂时笔者持观望态度。
结语
本文只是作者思考过后对一个项目架构的简单设计，还有很多部分需要完善和补充，具体细节也可能会按照具体情况修改。Demo 只是一个雏形，希望和各位读者朋友能有所交流。

参考文献链接
https://mp.weixin.qq.com/s/DUEDZ6bR7zmoW3D5PTJZAA
https://mp.weixin.qq.com/s/B6vCm1wAh50vnMAzfNpQbQ
https://mp.weixin.qq.com/s/IYGmfvSAYwstQZl48p8jKg
https://mp.weixin.qq.com/s/dHQfmeCO7J1saAT67zy1fg
https://mp.weixin.qq.com/s/TfEii72e8oxnHt_lfMeaQQ
https://mp.weixin.qq.com/s/bpRjlvXqaNd0tuKC3zuNmw