ios开发框架有哪些,ios基于什么开发

iOS单元测试框架有哪些？

OCUnit 是 OC 官方测试框架， 现在被 XCTest 所取代。

XCTest 是与 Foundation 框架平行的测试框架。

GHUnit 是第三方的测试框架。 github地址

OCMock都是第三方的测试框架。 github地址

相关问答

Q1: ios 系统架构分为哪四层？uikit框架属于哪一层

千峰扣丁学堂iOS开发为您解答：

1、Core

OS层：位于iOS框架的最底层，主要包含内核、文件系统、网络基础架构、安全管理、电源管理、设备驱动、线程管理、内存管理等。简而言之，该层提供了最低级的、系统级的服务。

2、Core

Services层：可称之为核心服务层，顾名思义，它提供诸如字符串管理、集合管理、网络操作、URL实用工具、联系人管理、偏好设置等服务。除此之外，它还提供很多基于硬件特性的服务，如GPS、加速仪、陀螺仪等。该层包含了Core

Location、Core Motion、SystemConfiguration、Foundation与Core

Foundation子模块。其中Foundation与Core Foundation子模块提供了对公共数据类型(字符串、集合等)的抽象，Core

Foundation中的Core Data子模块可以实现对象图形管理与对象持久化。

3、Media层：依赖于Core

Services层提供的功能，主要负责图形与多媒体服务。它包含了CoreGraphics、Core Text、OpenGL ES、Core

Animation、AVFoundation、Core Audio等与图形、视频和音频相关的功能模块。

4、Cocoa

Touch层：是直接向iOS应用程序提供各种基础功能的支持。其中的UIKit框架提供各种可视化控件供应用程序使用，如窗口、视图、视图控制器与各种用户控件等。另外UIKit也定义了应用程序的默认行为和事件处理结构。

Q2: 请问ios游戏开发需要哪些知识

基础是要过关的，oop、多线程、db、基本算法或数据结构是必须的。

还要熟练掌握Objective-C语言，C/C++语言；3.熟悉Cocoa开发框架，包括UI、网络等方面，熟悉IOS开发工具和相关开发测试工具的使用，掌握常用的数据结构与常用算法，较好的逻辑思维分析和表达和沟通能力，要有一定的自学能力，较强的团队协作意识。

更多关于ios游戏开发需要哪些知识，进入：查看更多内容

Q3: 刚刚，阿里开源 iOS 协程开发框架 coobjc！

阿里妹导读：刚刚，阿里巴巴正式对外开源了基于 Apache 2.0 协议的协程开发框架 coobjc，开发者们可以在 Github 上自主下载。

coobjc是为iOS平台打造的开源协程开发框架，支持Objective-C和Swift，同时提供了cokit库为Foundation和UIKit中的部分API提供了 协程 化支持，本文将为大家详细介绍coobjc的设计理念及核心优势。

从2008年第一个iOS版本发布至今的11年时间里，iOS的异步编程方式发展缓慢。

基于 Block 的异步编程回调是目前 iOS 使用最广泛的异步编程方式，iOS 系统提供的 GCD 库让异步开发变得很简单方便，但是基于这种编程方式的缺点也有很多，主要有以下几点：

针对多线程以及尤其引发的各种崩溃和性能问题，我们制定了很多编程规范、进行了各种新人培训，尝试降低问题发生的概率，但是问题依然很严峻，多线程引发的问题占比并没有明显的下降，异步编程本来就是很复杂的事情，单靠规范和培训是难以从根本上解决问题的，需要有更加好的编程方式来解决。

上述问题在很多系统和语言开发中都可能会碰到，解决问题的标准方式就是使用协程，C#、Kotlin、Python、Javascript 等热门语言均支持协程极其相关语法，使用这些语言的开发者可以很方便的使用协程及相关功能进行异步编程。

2017 年的 C++ 标准开始支持协程，Swift5 中也包含了协程相关的标准，从现在的发展趋势看基于协程的全新的异步编程方式，是我们解决现有异步编程问题的有效的方式，但是苹果基本已经不会升级 Objective-C 了，因此使用Objective-C的开发者是无法使用官方的协程能力的，而最新 Swift 的发布和推广也还需要时日，为了让广大iOS开发者能快速享受到协程带来的编程方式上的改变，手机淘宝架构团队基于长期对系统底层库和汇编的研究，通过汇编和C语言实现了支持 Objective-C 和 Swift 协程的完美解决方案 —— coobjc。

核心能力

内置系统扩展库

coobjc设计

最底层是协程内核，包含了栈切换的管理、协程调度器的实现、协程间通信channel的实现等。

中间层是基于协程的操作符的包装，目前支持async/await、Generator、Actor等编程模型。

最上层是对系统库的协程化扩展，目前基本上覆盖了Foundation和UIKit的所有IO和耗时方法。

核心实现原理

协程的核心思想是控制调用栈的主动让出和恢复。一般的协程实现都会提供两个重要的操作：

我们基于线程的代码执行时候，是没法做出暂停操作的，我们现在要做的事情就是要代码执行能够暂停，还能够再恢复。 基本上代码执行都是一种基于调用栈的模型，所以如果我们能把当前调用栈上的状态都保存下来，然后再能从缓存中恢复，那我们就能够实现yield和 resume。

实现这样操作有几种方法呢？

上述第三种和第四种只是能过做到跳转，但是没法保存调用栈上的状态，看起来基本上不能算是实现了协程，只能算做做demo，第五种除非官方支持，否则自行改写编译器通用性很差。而第一种方案的 ucontext 在iOS上是废弃了的，不能使用。那么我们使用的是第二种方案，自己用汇编模拟一下 ucontext。

模拟ucontext的核心是通过getContext和setContext实现保存和恢复调用栈。需要熟悉不同CPU架构下的调用约定(Calling Convention). 汇编实现就是要针对不同cpu实现一套，我们目前实现了 armv7、arm64、i386、x86_64，支持iPhone真机和模拟器。

说了这么多，还是看看代码吧，我们从一个简单的网络请求加载图片功能来看看coobjc到底是如何使用的。

下面是最普通的网络请求的写法：

下面是使用coobjc库协程化改造后的代码：

原本需要20行的代码，通过coobjc协程化改造后，减少了一半，整个代码逻辑和可读性都更加好，这就是coobjc强大的能力，能把原本很复杂的异步代码，通过协程化改造，转变成逻辑简洁的顺序调用。

coobjc还有很多其他强大的能力，本文对于coobjc的实际使用就不过多介绍了，感兴趣的朋友可以去官方github仓库自行下载查看。

我们在iPhone7 iOS11.4.1的设备上使用协程和传统多线程方式分别模拟高并发读取数据的场景，下面是两种方式得到的压测数据。

从上面的表格我们可以看到使用在并发量很小的场景，由于多线程可以完全使用设备的计算核心，因此coobjc总耗时要比传统多线程略高，但是由于整体耗时都很小，因此差异并不明显，但是随着并发量的增大，coobjc的优势开始逐渐体现出来，当并发量超过1000以后，传统多线程开始出现线程分配异常，而导致很多并发任务并没有执行，因此在上表中显示的是大于20秒，实际是任务已经无法正常执行了，但是coobjc仍然可以正常运行。

我们在手机淘宝这种超级App中尝试了协程化改造，针对部分性能差的页面，我们发现在滑动过程中存在很多主线程IO调用、数据解析，导致帧率下降严重，通过引入coobjc，在不改变原有业务代码的基础上，通过全局hook部分IO、数据解析方法，即可让原来在主线程中同步执行的IO方法异步执行，并且不影响原有的业务逻辑，通过测试验证，这样的改造在低端机(iPhone6及以下的机器)上的帧率有20%左右的提升。

简明

易用

清晰

性能

程序是写来给人读的，只会偶尔让机器执行一下。——Abelson and Sussman

基于协程实现的编程范式能够帮助开发者编写出更加优美、健壮、可读性更强的代码。

协程可以帮助我们在编写并发代码的过程中减少线程和锁的使用，提升应用的性能和稳定性。

本文作者：淘宝技术

Q4: 移动APP开发框架盘点2：Web移动前端框架大全

开源项目其实有一个成熟周期，这个周期大概是三年左右，自React框架在2013年发布并引爆了前端框架的大潮，这个属于前端的周期就此开始了。

之后在2015年5月开源的React Native又开启了属于Web移动前端的周期，15-16年，18-19年，21-22年正好就是属于移动前端的三个爆发点。

三年前，在第一个成熟收获期，我盘点了移动开发框架。在这第二个成熟收获期，理所当然要来盘点一波。

不过，当我点开github项目的code-frequency时，还是被这个准到吓人的周期猜想惊呆了，先给你们看一波，剩下的自行验证。

1、

2、

再来说第二个比较有意思的发现，停止维护的项目绝大多数是Vue框架项目。

盘点开始的时候我还觉得React框架处于绝对劣势，到完成时我发现React无论在选择面还是成熟度上都超过了Vue。

原因我这里就不分析了，反正大家都有自己的看法。

网页类框架就是前端组件框架，这一次虽然有大量项目停止维护，但是也有很多项目坚持了下来，而且还涌现出了一批新项目。

大厂占了主导，因为这些年大厂在移动开发上的需求，远高于其它方面。个人项目要坚持确实不易。

本来是想要做一个验证项目，把所有框架都试用一遍并给出推荐度的。由于进度太慢，还是下一次再发吧。

这次的重点是渐进类框架，就是所谓多端同构框架（小程序框架）。这几年国内的重点的各种小程序平台，所以多端框架的需求很是旺盛。

不过大多数先行者都没挺过来还是让我很意外，只有Taro成功了，想想还是有很多让人唏嘘的东西。

在这里还是先预测一波吧，因为这一类框架最变化最大，最终还是有很多框架要出局的。

渐进类框架是一个过渡性的产品，最终会变成桥接类框架的一部分，所以，与桥接类框架协同才是框架的出路。

这个赛道基本全是大厂了。

腾讯新一代跨端开发框架Hippy

Hippy一看就是淘宝Weex的对标项目，Kpi功能全面压制。所以官方支持 React 和 Vue 两种主流前端框架。在Weex2019年实质停更后发布，要不要这么卷？

Hippy 2.x 架构主要分成三层，UI(JS) 层 Hippy-React 和 Hippy-Vue 负责驱动 UI 指令生成；中间层 C++ HippyCore 负责抹平平台差异性和提供高性能模块；渲染层 Android 和 iOS 负责提供终端底层模块、组件，并与布局引擎通信。

对Weex惨遭遗弃，我上次就说过：「ReactNative提供工具，Weex提供框架，将平台差异化屏蔽（Write Once, Run Everywhere）。所以Weex则注定功能相对弱小，并且坑比较多。」Weex最终下马也是必然的，淘宝又发布升级版北海，为了实现（Write Once, Run Everywhere），它采用自绘，而且是基于Flutter自绘。

所以Hippy3.x就一如既往的Kpi功能层层加码，很有腾讯风格。在未来的 3.x 中业务与渲染层中的具体实现可根据用户实际场景进行切换：业务层上不再局限于 JS 驱动，还可选择（如：DSL/Dart/WASM 等）其它语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底层基于 Flutter 进行渲染。

Kraken 不限制上层开发者使用的框架，无论你是使用 Vue 、Rax 还是 React 都可以开发 Kraken 应用。

Kraken 的 runtime 通过 JS Engine Binding 的方式提供了一系列 Web 标准的 API 接口，调用相应 API 会执行相关逻辑并创建一系列需要发送给 Dart 层处理的指令。

Kraken 其实就是一个小程序平台，而且追求全平台完全一致。我虽然认为各平台不一致是很自然的事情，但是也表示理解，毕竟别人吹牛有当真的传统（KFC表示认同）。

Kraken 现在也是一个小号浏览器，所以它的主要工作就是抠标准，毕竟它是一款基于 W3C 标准的高性能渲染引擎。

最后，我劝淘宝领导定Kpi要理智些，毕竟Hippy4我还蛮期待的。

滴滴出品的超轻量级动态化跨端开发框架，主打轻量和实用。

Hummer 以 JS 引擎为基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等业内知名 JS 引擎（这里本来还有个V8的，我删除了，源码里面没有，Kpi需要）。再配合经过调优的 Yoga 布局引擎，抹平了两端视图布局差异（性能更佳的自研布局引擎开发中）。顺便提一下，Hippy采用V8（功能更强）自研布局引擎（性能更佳）。

Hummer 的特点是抛弃了业界其他动态化跨端框架普遍使用的DSL层和VDOM层，因此原生 Hummer 不具备前端开发常用的响应式编程的能力，但同时换来的是接近原生开发的体验和性能。再以原生 Hummer 为基础，在此之上开发了一套基于MVVM架构的开发框架 —— Tenon ，通过 Tenon，可以把使用 Vue/React 编写的代码，转换成原生 Hummer 的代码。

Hummer也是一个小程序平台，而且超轻量。如果想要无限提升自己APP的能力，可以考虑嵌入Hummer。

Web移动前端框架正在迎来第三个高速发展期，各类框架得到极大繁荣。

个人在具体项目的贡献已经微乎其微了，创新、架构创新是唯一制胜的手段，这也是我看好React的根本原因。

最后，还是想做点微不足道的 探索 ，现在前端组件库层出不穷，更换组件库带来的代价有点大。想创建一个框架，来实现上次说的组件公约数和公倍数，无缝切换组件库。理论上支持所有组件库 ，也能为后来者提供弯道超车的机会。我想大厂可能没有需求，也不会愿意发布这种框架，毕竟都是平台部门说了算。

这个库就是useMobile，当然分为useMobileReact和useMobileVue。下次先发布useMobileReact。等我发布后，再来填上面表中缺的推荐度。

原文地址：

Q5: iOS开发——最简单web容器化框架

既然要承载 web 页面，一个原生的 WebView 必不可少。在 iOS 中，目前已经有两款高性能、功能齐全的 web 浏览器，UIWebView (=2.0)和 WKWebView(=7.0)。

当然，两种 web 浏览器选其一即可。网上有很多文章，包括我之前已经发表的博文中，都介绍过这两种浏览器，读者可以根据自己的需要选择。

就目前的情况看，UIWebView 发展了很多年，目前市面上大部分的 web 页面也都支持这样的浏览器，因此很多公司在选择的时候都使用这个，但是，我们知道，WKWebView 有太多改善前者的优点，而且也是苹果官方提倡大家使用的，为了性能，为了更多的特性，建议初次搭建的朋友采用 WKWebView。

为了实现 h5 与 native 之间的互相调用，我们需要在两者之间架一层桥来实现，关于 bridge，之前的文章也有介绍。

bridge 的功能包括：native 调用 h5，h5 回调 native，h5 调用 native，native 回调 h5。

有了 bridge，h5可以使用 native 支持的更多特性，native 可以获取 h5 页面加载的信息，也可以让 web 页面动态执行一些脚本做一些事。

总之，在 web 容器框架中，这个 bridge 还是很有必要的。

嗯，这个是辅助项，做了这一步可以进一步提高 web 容器的加载性能，而且资源缓存到本地后可以做到不依赖网络，提高用户体验。

通常有两种做法，

UIWebView 使用简单，而且现在用户的手机性能也已经不再是页面展示性能的瓶颈，所以，这里介绍的依然采用 UIWebView 作为 web 浏览器。

WebViewJavascriptBridge 是一款非常强大的第三方开源 bridge 库，同时支持 UIWebView 和 WKWebView。

git 地址

NJKWebViewProgress 是一款能使 UIWebview 显示加载进度的第三方开源框架，支持代理协议处理和 progressview 展示两种功能。

git 地址