NS前缀的含义在 iOS 开发里NS是 ‌NeXTSTEP‌ 的缩写是苹果收购 NeXT 公司后继承下来的历史命名前缀代表这些类来自 Cocoa/Cocoa Touch 框架。‌‌平时看到的NSString、NSArray、NSDictionary这些类都属于 Foundation框架的基础部分而它们的名字最早可以追溯到 NeXTSTEP操作系统。1996 年苹果收购 NeXT公司 后为了兼容旧代码就把这套命名习惯原样保留了下来。‌‌ 常见 NS 类速览‌NSString‌处理文本字符串‌NSArray‌有序集合‌NSDictionary‌键值对集合‌NSObject‌所有 Objective-C 类的基类‌NSUserDefaults‌用户默认设置管理‌NSFileManager‌文件管理在 iOS 语境下NS前缀指的就是 NeXTSTEP 的遗产。‌‌为什么苹果要保留NeXT的命名?苹果保留NeXT的NS命名核心是‌技术传承与现实工程需求的双重选择‌并非单纯的情怀致敬。 最直接的原因向后兼容1996年苹果收购NeXT时NeXTSTEP已经积累了大量成熟的第三方应用和企业级代码。如果直接改掉所有NS前缀这些已有的程序会直接失效开发者的迁移成本会高到无法接受。保留NS命名能让老代码几乎无缝运行在新系统上这是当时苹果最迫切的需求 。 解决Objective-C的先天缺陷Objective-C本身没有命名空间机制不同厂商写的类很容易出现名字冲突。用NS作为全局前缀能把Foundation框架的系统类和用户自定义类、第三方库类明确区分开从根源上避免重名冲突这也是苹果后续所有框架都用双字母前缀UI、CA、CG等的统一规范来源 。 救急的现实背景当时苹果自己的下一代操作系统Copland项目已经彻底烂尾Mac OS 7的老旧架构完全撑不住未来的发展。NeXTSTEP是当时市面上唯一成熟、先进、能直接商用的面向对象操作系统苹果几乎是把整套系统直接拿过来改造成Mac OS X。连带着它的命名体系、开发工具链后来演变成Xcode也原样保留NS前缀自然就成了新系统的基础标识 。️ 技术文化的传承NS前缀本身就是NeXTSTEP技术遗产的符号它见证了乔布斯离开苹果后打磨出的这套先进系统最终反过来拯救了陷入绝境的苹果。保留它既是对那段历史的致敬也让全球开发者能快速熟悉这套新框架不用重新学习一套完全陌生的命名体系 。Foundation、UIKit、Cocoa的区别‌Cocoa是Mac/iOS开发的总框架集合。Foundation是其中与界面无关的基础层UIKit则是iOS上负责界面的那部分。‌ 可以这样理解Cocoa是“全家桶”Foundation是“底层工具包”UIKit是“界面组件库”。‌‌ 三者关系‌Cocoa‌面向对象的原生API集合Mac上由Foundation AppKit组成iOS上由Foundation UIKit组成也叫Cocoa Touch。‌Foundation‌基础框架提供字符串、数组、字典、日期、文件管理等非界面功能类名以NS开头。‌UIKit‌iOS界面框架提供窗口、视图、按钮、手势等UI组件类名以UI开头。‌‌ 核心区别‌职责不同‌Foundation管数据、文件、网络等底层服务UIKit管界面展示和用户交互。和界面无关的类基本在Foundation和界面相关的在UIKit。‌继承关系‌UIKit里的UIView继承自UIResponder最终继承自Foundation里的NSObject说明UIKit构建在Foundation之上。‌平台差异‌Mac上的图形框架是AppKit类名也以NS开头iOS上换成了UIKit但两者都共用Foundation。‌‌ 实际使用写iOS应用时两者几乎总是同时出现——用Foundation处理业务数据用UIKit搭建界面。比如用NSString存文本再用UILabel显示出来一个管数据一个管展示。‌‌编译器Objective-C 是一种编译语言这意味着你的源代码被转换成了高度优化过的机器码。 执行这项任务的软件是编译器。Xcode的前身项目构造器使用的都是GNU GCC编译器(GNU Compiler Collection)。多年以来苹果为这个编译器做了很多调整和贡献。在 2007 年 一种新型的、现代化的编译系统被创建出来被称为 LLVM(Low Level Virtual Machine)。 它最初是作为苹果公司图形库的一部分因为它使源代码被编译成高效的字节码格式苹果公司用这项技术使它们的图形可以运行在任何 GPU 或 CPU 之上而不需要为每个目标做特定的手动调整。LLVM 还有其他的优势其中最主要的或许是:它的中段编译格式保留了很多关于源代码(这些源代码是它衍生的来源)的信息远多于 GCC 和其他编译器。例如这使它可以 跟踪变量何时被使用和弃置然后在它们的基础上做出判定。这个特点使 ARC 得以运行。 从本质上讲这种编译器能定位某个变量不再被使用的确切时机并且确定它的内存特性 从而自动插入合适的内存管理方法。基于 20 世纪 70 年代编译器设计基础的 LLVM 已经被证明是非常强大的而且跟 GCC 相比更易于扩展。因此苹果公司已经把它的编译工作移至全心全意支持 LLVM 项目上 甚至雇用该项目的领导者和主要贡献者做全职工作。基于已经奠定的基础苹果公司正在 把越来越多的编译器支持的特性植入 Objective-C 语言如 ARC 以及 OS X 10.8 和 iOS 6.0 中引入的新对象的文字声明。