iOS开发流程分享

为什么分享iOS开发流程?

1.分享移动端的一些流程和知识,便于后期开发过程中,能更好理解和配合移动端

2.了解一下其他端的知识,丰富大家对移动端的知识库

3.虽然不是同一个技术栈,但是有些有用的技术开发流程,也许大家能有互相借鉴的地方

4.分享和记录是对个人技术巩固和成长的一种绝佳的方式

iOS开发前期准备工作

• 硬件端

macbookpro + 不同版本和尺寸的测试机 + 数据线

• 开发工具

Xcode

• 苹果开发者账号

  测试、分发和上线必备

• 代码仓库服务器

  git + submodules

iOS概述

苹果家族里有各类操作系统 iOS、iPadOS、macOS、watchOS 和 tvOS

iOS作为家族中最重要也是大家最熟悉的一员.

iOS的系统架构分为四个层次：( iOS是基于UNIX内核，android是基于Linux内核)

核心操作系统层（Core OS layer）、核心服务层（Core Services layer）、媒体层（Media layer）和可触摸层（Cocoa Touch layer）。

IOS系统结构图：

1、Core OS是位于iOS系统架构最下面的一层是核心操作系统层，它包括内存管理、文件系统、电源管理以及一些其他的操作系统任务。它可以直接和硬件设备进行交互。作为app开发者不需要与这一层打交道。

2、Core Services是核心服务层，可以通过它来访问iOS的一些服务。

3、Media是媒体层，通过它我们可以在应用程序中使用各种媒体文件，进行音频与视频的录制，图形的绘制，以及制作基础的动画效果。

4、Cocoa Touch是可触摸层，这一层为我们的应用程序开发提供了各种有用的框架，并且大部分与用户界面有关，本质上来说它负责用户在iOS设备上的触摸交互操作。

iOS开发语言介绍及选择

Swift&Objective-C介绍:

先来看看维基百科对Swift和Objective-C的介绍

一、swift与OC的共同点: 1、OC出现过的绝大数概念,比如ARC、协议、扩展类、匿名函数等,在swift中继续有效. 2、swift和OC公用一套运行时环境,swift的类型可以桥接到OC ,反之亦然

二、现阶段swift能完全取代Objective-C么?

不行,因为apple内部一直在用Objective来做一些Framework的开发,底层也不可能用swift来实现,所以现在更多的替代是体现在外部开发

三、swift和OC的优缺点

1. swift是类型安全的语言,注重安全,OC注重灵活(主要基于runtime运行机制)
2. swift注重面向协议编程、函数式编程、面向对象编程,OC注重面向对象编程
3. swift注重值类型,OC注重指针和引用
4. swift容易阅读,文件结构和大部分语法建议
5. swift 可选类型,是用于所有数据类型,而不仅仅局限于类,相对于OC的nil更加安全和简明
6. swift中的泛型类型更加方便和通用,而非OC中只能为集合类型添加泛型
7. swift中各种方便快捷高阶函数（Swift的标准数组支持三个高阶函数：map，filter和reduce,以及map的扩展flatMap
8. swift增加了两种全权限,细化权限.open > public > internal(默认)> fileprivate > private

最终开发语言的选择:

1.通过以上的比较,OC能做的Swift基本上都可以实现,再结合目前Swift5.0之后,swift语法已经非常稳定

2.Apple主推的也是Swift语言,包括2019年新出来的SwiftUI框架也是基于Swift语言开发的.

3.所以需要拥抱变化,拥抱新的技术

最后决定:项目可采用纯Swift语言开发,当然可能接入的第三方SDK会有不可避免的OC语言的混入

框架选择

UIKit&SwiftUI

SwiftUI:

SwiftUI 于 2019 年度 WWDC 全球开发者大会上发布，它是基于 Swift 建立的声明式框架。该框架可以用于 watchOS、tvOS、macOS、iOS 等平台的应用开发，等于说统一了苹果生态圈的开发工具。

UIKit:

UIKit 框架提供的类是基础的UI类库，用于创建基于触摸的用户界面，所有iOS 应用程序都是基于UIKit，它提供应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。 UIKit 通过控制器对象管理屏幕上显示的内容，界面的跳转，来组织应用程序。

区别:

在 UIKit 框架中，界面上的每一个元素都需要开发者进行布置，期间有不少计算工作，例如长宽的改变或是屏幕可视面积的变化等。这种线性的方式被称为指令式 (imperative) 编程。以一行文字为例，放置在哪个坐标、宽度多少、在哪里换行、怎么断句、字形字号是多少、最终高度多少、是否需要缩小字号来完全显示等，这些都是开发者在制作界面时要考虑和计算妥当的问题。到了第二年，用户可能会换更大屏幕的手机，系统支持动态字体调节等新功能，此时原先的程序不进行适配就可能出现显示问题，开发者就需要回头进行程序的重新调试。

换做 SwiftUI 之后，上述的很多变量就被系统接管了。开发者要做的就是直观的告诉系统放置一个图像，上面加一行文字，右边加一个按钮。系统会根据屏幕大小、方向等自动渲染这个界面，开发者也不再需要像素级的进行计算。这被称为声明式 (declarative) 编程。

链式调用修改属性

链式调用是 Swift 语言的一种特性，就是用来使用函数方法的一种方式。可以像链条那样不断地调用函数，中间不需要断开。使用这种方式开发者可以给界面元素添加各种属性，只要愿意，同样能够事无巨细的安排页面元素的各种细节。

优缺点:

1.成熟稳定 : UIKit > SwiftUI (相对于高度成熟的 UIKit 和 AppKit 来说，SwiftUI 还十分年轻，它周围的生态也远远 没有达到成熟)

2.布局优势:SwiftUI > UIKit

3.技术社区环境: UIKit > SwiftUI

4.可扩展性: SwiftUI > UIKit ( 未来可在多平台使用一套代码)

5.接入项目可行性:UIKit (目前还在SwiftUI的学习和研究之中)

最后决定:项目暂时采用UIKit ,后期SwiftUI版本稳定,以及对SwiftUI掌握和应用更成熟的时候,逐步替换为SwiftUI

组件化开发的选择

随着项目功能的不断迭代，业务主线也随之越来越多，造成耦合越来越严重，编译越来越慢，后期变得难以维护，测试依赖性强等一系列问题。为了解决此类情况，我们需要考虑使用组件化开发。

优势： 1、独立：独立开发、编译、运行、测试、维护，不受业务逻辑影响；

2、重用：代码复用性高，对于基础的配置代码、相似的功能代码均可以多项目利用；

3、高效：得益于各个组件独立，可以根据需求任意增删模块，实现高效迭代；

4、便于后期团队开发,每个人负责不同模块,进行组件化开发,互不干扰,减少代码冲突等

劣势:

1.由于需要考虑适应性,和可扩展性,开发难度增加和成本的增加,开发时间的增加

2.需要维护各个组件,以及对各个组件的发布,增加开发成本

最后决定:采用组件化开发

设计模式选择

MVVM

开发阶段

1.根据业务、UI、UE要求,设计相应的框架,进行技术调研等等

2.根据产品文档需求以及UI页面设计,设计代码结构

3.根据业务和UI的设计,创建相应的模块化或者组件化的私有仓库.

4.自测完成,发布组件

5.主项目中,更新最新版本的组件库,联调、测试

测试

1. 核心主角:开发者账号

2. 硬件配备:Apple测试机和数据线

3. 软件辅助:Xcode和要测试的应用程序

4. jekins自动化打包测试

5. 接入第三方奔溃检测SDK

上线

一、创建App ID

二、创建证书请求文件 （CSR文件）

三、创建发布证书 （CER）

四、创建Provisioning Profiles配置文件 （PP文件）

五、在App Store创建应用

六、打包上架

总结

graph TD
A([选择开发语言:Swift])-->B([选择UI框架:UIKit])-->C([选择代码的开发方式:组件化])-->D([代码设计模式:MVVM])-->E([正式进入开发模式])-->F([完成小模块后,进行测试])-->G([准备上传Appstore所需的所有材料])-->H([上传正是环境ipa包至AppStore,等待苹果审核 ])-->I([上线前,进行规模测试,可采用testFlight])-->J([测试无重大bug,发布至App Store])