mac os开发程序_mac os 程序开发 - CSDN
  • Mac OS X下使用Qt开发,需要配置Qt库和编译器。编译器只能使用苹果公司自主研发的Clang。1、分别下载并安装XCode和Command Line Tools(必须安装),安装完毕后,Clang就有了。...

    在Mac OS X下使用Qt开发,需要配置Qt库和编译器。编译器只能使用苹果公司自主研发的Clang。
    1、分别下载并安装XCode和Command Line Tools(必须安装),安装完毕后,Clang就有了。

    https://developer.apple.com/downloads/

    2、下载Qt并默认安装

    http://download.qt.io/official_releases/qtcreator/,得到安装包qt-creator-opensource-mac-x86_64-3.4.0.dmg。

    http://download.qt.io/official_releases/qt/,得到安装包qt-opensource-mac-4.8.7.dmg和qt-opensource-mac-4.8.7-debug-libs.dmg。

    前者是Qt release版的SDK,必须安装;后者是debug版的SDK,可选安装,如果用户需要单步断点调试,则必须安装。

    3、配置Qt

    (1)运行Qt Creator。进入“菜单","Qt Creator","偏好设置"。可以看到,”编译器“和”调试器“,已经默认设置好了。


    (2)用户需要手动配置Qt版本



    (3)再次进入”偏好设置“,用户需要手动配置构建套件。


    4、附录,关于LLVM和Clang

    http://www.llvm.org/

    http://clang.llvm.org/

    Low Level Virtual Machine (LLVM) 是一个开源的编译器架构,它已经被成功应用到多个应用领域。Clang ( 发音为 /klæŋ/) 是 LLVM 的一个编译器前端,它目前支持 C, C++, Objective-C 以及 Objective-C++ 等编程语言。Clang 对源程序进行词法分析和语义分析,并将分析结果转换为 Abstract Syntax Tree ( 抽象语法树 ) ,最后使用 LLVM 作为后端代码的生成器。
    Clang 的开发目标是提供一个可以替代 GCC 的前端编译器。与 GCC 相比,Clang 是一个重新设计的编译器前端,具有一系列优点,例如模块化,代码简单易懂,占用内存小以及容易扩展和重用等。由于 Clang 在设计上的优异性,使得 Clang 非常适合用于设计源代码级别的分析和转化工具。Clang 也已经被应用到一些重要的开发领域,如 Static Analysis 是一个基于 Clang 的静态代码分析工具。
    Clang 的开发背景 : 由于 GNU 编译器套装 (GCC) 系统庞大,而且 Apple 大量使用的 Objective-C 在 GCC 中优先级较低,同时 GCC 作为一个纯粹的编译系统,与 IDE 配合并不优秀,Apple 决定从零开始写 C family 的前端,也就是基于 LLVM 的 Clang 了。Clang 由 Apple 公司开发,源代码授权使用 BSD 的开源授权。

    5、附录,关于MinGW和GCC

    http://www.mingw.org/

    http://gcc.gnu.org/

           MinGW:一个可自由使用和自由发布的Windows特定头文件和使用GNU工具集导入库的集合,允许你生成本地的Windows程序而不需要第三方C运行时库。MinGW,即 Minimalist GNU For Windows。它是一些头文件和端口库的集合,该集合允许人们在没有第三方动态链接库的情况下使用GCC 产生 Windows32 程序。
      在基本层,MinGW 是一组包含文件和端口库,其功能是允许控制台模式的程序使用微软的标准C运行时间库(MSVCRT.DLL),该库在所有的 NT OS 上有效,在所有的 Windows 95 发行版以上的 Windows OS 有效,使用基本运行时间,你可以使用 GCC 写控制台模式的符合美国标准化组织(ANSI)程序,可以使用微软提供的 C 运行时间扩展。该功能是 Windows32 API 不具备的。下一个组成部分是 w32api 包,它是一组可以使用 Windows32 API 的包含文件和端口库。与基本运行时间相结合,就可以有充分的权利既使用 CRT(C Runtime)又使用 Windows32 API 功能。
    mingw工具集合
      实际上 MinGW 并不是一个 单纯的C/C++ 编译器,而是一套 GNU 工具集合。除开 GCC 以外,MinGW 还包含有一些其他的 GNU 程序开发工具 (比如 gawk bison 等等)。开发 MinGW 是为了那些不喜欢工作在 Linux(FreeBSD) 操作系统而留在 Windows 的人提供一套符合 GNU 的 GNU 工作环境。所以,使用 MinGW 我们就可以像在 Linux 下一样使用 GNU 程序开发工具。
      GCC 就是 MinGW 的核心所在,GCC 是一套支持众多计算机程序语言的编译系统,而且在语言标准的实现上是最接近于标准的。并且 GCC 几乎可以移植到目前所有可用的计算机平台。(我的电脑上就还装有 DevKitPro,里面包含 GCC 的 ARM(for GBA/DS/GP32) 和 MIPS(for PSP) 版本。)
      GCC 本身不像 VC 那样拥有IDE 界面(在 Windows 上也存在Dev C++ 之类的支持 MinGW 编译器的 IDE)。源代码编辑你可以选用任何你喜欢的文本编辑器(据说微软的开发人员包括 VC 的开发都不用 VC 所带的 IDE 编辑器,而是选用 GNU 的 VIM 编辑器)。然后使用 make 等工具来进行软件项目的编译、链接、打包乃至发布。而像 cvs(svn) 源代码版本控制工具可以让世界上任何一个角落的人都可以参与到软件项目中来。
      关于 MFC,微软基础库类,这个随 VC++ 携带的一个源代码公开的开发包,和其他 Windows 程序开发包是一样的。如果有 VC++ 的授权,你完全可以使用 MFC 的源代码,也就是你使用 GCC 来编译 MFC 程序是完全可以的。
      当然,GNU 下也很多 Windows 程序开发包,甚至有一些是支持跨平台使用的。不仅仅可以直接把源代码编译为 Windows 程序,也可以不经修改编译为其他操作系统的图形程序。
      不过 GNU 下,最流行的图形界面开发库是 GTK+与Qt。GTK+ 与Qt均提供跨平台支持。例如qt支持windows、linux、mac os x、windows CE、symbian、meego等操作系统平台,并且提供了Qt SDK(包含Qt creator集成开发环境)。Gtk也能很好的运行在 Windows 平台(比如 GIMP 和 Gaim),。
      总体说来,MinGW 就是 GNU工具集。GCC(GNU Compiler Collection,GNU编译器套装),是一套由 GNU 开发的编程语言编译器。它是一套以 GPL 及LGPL 许可证所发行的自由软件,也是 GNU计划的关键部分。

    展开全文
  • MAC OSX APP 开发入门篇

    2019-03-21 20:21:38
    MAC OSX APP 开发入门篇 欢迎使用Markdown编辑器 你好! 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章,了解一下Markdown的基本语法知识。 新的改变...

    转载自(https://macdev.io/ebook/start.html)
    准备工作
    Mac电脑
    Mac开发准备工作,Mac电脑不必说了

    只有用真正的Mac电脑才可以提升,熏陶你的审美,你才可能做出美的有价值的用户产品。如果你使用很普通的磨具想锻造出一把锋利的刀剑,你的力量,审美,意识,习惯都无法成就你成为一个伟大的工程师吧。

    Mac系统能提升你的工作效率,大大改善你的工作心情。只要你不去非官方的应用商店去下载App,你很少有各种病毒乱弹窗的烦恼,也不会遇到系统奔溃蓝屏的事儿。开机都是秒级的,会为你省的更多时间集中精力到你的工作上去。长期不关机,都不是什么事儿,就凭这一点Windows真是要大败下风。

    如果你有兴趣对Mac电脑拆个机,看看里面内部的结构,就会对苹果的工艺水平,产品标准更是肃然起敬,这真是一家伟大的公司。内外如一般的美!

    用Mac电脑开启你的Mac应用开发之旅吧!

    Xcode使用介绍
    Xcode是开发Mac应用软件的利器!去苹果官网注册AppleID,登录开发者中心可以免费下载。(你也可以使用AppCode,一个第三方的付费的 Objective-C、Swift 的集成开发环境)

    首次启动Xcode,选择Create a new Xcode project,(非首次运行Xcode,从菜单File-New->Project) 进入工程模版选择界面
    在这里XcodeStart插入图片描述

    选择OSX->Application->Cocoa Application

    ProjectTemplate

    输入工程名称HelloWorld,开发语言选择Objective-C。

    ProjectName

    完成第一个工程的创建。

    Xcode工作区
    工具栏:提供便捷的功能按钮入口。包括运行工程,终止工程的最常用的功能按钮。最右边是3个不同方向的工作区开关按钮。点击可以打开或关闭不同方向的侧边栏区域。

    工程结构导航区:位于最左边区域,可以方便的浏览工程所有文件。

    工程Target配置区:有6个分类的切换tab,管理工程各种配置。

    xib结构导航区:点击切换不同的控件,方便inspector

    Assistant Editor:管理代码和xib文件关联

    inspector面板区:位于最右边,能方便的对当前选中的内容进行管理设置

    控件工具箱:xib设计界面需要的各种控件库

    XcodeProject

    1.xib相关工作区

    xib结构导航区,xib界面设计区,xib inspector面板区,控件工具箱,Assistant Editor, 进行xib界面设计时必须熟练使用

    XcodeXib

    2.inspector面板区

    分成8个功能区,点击依次可以看到File,QuickHelp,Identity,Attributes,Size,Connections,Bindings,View Effects区。

    XibInspector

    Identity: 如果控件使用自定义的类,需要从Class下拉列表中选择

    Attributes:用来对每个控件不同风格样式属性设置

    Connections:用来控件响应的事件设置,控件对应的Outlet变量绑定

    3.Assistant Editor工作区

    从工程结构导航区选择要编辑的xib文件,点击菜单View->Assistant Editor->Show Assistant Editor后,Assistant Editor区出现。右侧出现代码编辑面板,可以辅助完成控件的事件Action,Outlet变量跟代码的绑定。

    AssistentEditorXib

    AssistentEditor

    工程结构
    我们来看看一开始建立的HelloWorld这个工程的组成部分。

    ProjectStruct1

    最左边是树形的导航目录,可以点击切换到不同的代码文件或资源目录进行统一管理。

    目录树顶部根节点为工程名称,选中后双击可以修改工程名称。里面2级目录依次为HelloWorld,HelloWorldTests,Products.所有的重量级的元素都在第一个HelloWorld目录里面。

    子目录HelloWorld里面AppDeleage是应用的代理,应用启动后第一个界面都是由这个文件控制的。

    AppDelegate
    AppDelegate.h
    #import <Cocoa/Cocoa.h>
    @interface AppDelegate : NSObject
    @end

    AppDelegate.m
    #import “AppDelegate.h”
    @interface AppDelegate ()
    @property (weak) IBOutlet NSWindow *window;
    @end
    @implementation AppDelegate

    • (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
      // Insert code here to initialize your application
      }
    • (void)applicationWillTerminate:(NSNotification *)aNotification {
      // Insert code here to tear down your application
      }
      @end

    在AppDelegate.h 申明了应用代理AppDelegate类,它必须继承NSApplicationDelegate协议。

    AppDelegate.m 中实现了applicationDidFinishLaunching 和 applicationWillTerminate 2个代理方法。applicationDidFinishLaunching中可以做一些应用启动前的初始化处理。应用退出前可以在applicationWillTerminate中做一些全局性数据区/内存/资源的清理释放。

    AppDelegate.m 中 还在接口中声明了一个NSWindow *window的XIB文件的IBOutlet输出变量。这样就可以在AppDelegate中直接操作控制window。比如说设置window的背景颜色,title标题,位置,大小等。Xcode自动生成的代码中没有对window做任何控制,因此删除这个IBOutlet类型的window定义也是可以的。

    Images.xcassets
    这个文件夹中对工程中使用的图片资源可以统一管理。其中Xcode会默认创建一个AppIcon的图片资源做为AppIcon是应用的安装图标。

    ProjectStruct2

    可以依次看到5种尺寸大小的icon图片,每一种都需要1x 2x 两种规格大小的图片。比如16pt的 就需要将16x16 和32X32 像素的图片分别拖入到1x,2x的虚线位置框里面。但是在这里设置AppIcon非常不方便,你会看到当前的工作区中最多能显示2种规格的,其他3种根本看不到,即使你把工作去拉大最多只能看到第3种规格的一半。后面我们会说明怎么通过其他方式设置App的安装和启动后在系统上显示的应用图标。

    可以点击底部+菜单按钮创建自己的Image Set,双击可以修改Image Set的名字。除了AppIcon以外,其他普通的图标资源都有1x 2x 3x 三种大小规格。

    MainMenu.xib
    这个xib文件是很关键的一个程序资源文件。应用启动的界面,应用的菜单都定义在其中。当然你完全可以不使用这个文件做应用的初始化界面,完全可以使用纯代码控制,这个我们在后续的章节在详细说明。

    点击HelloWorld窗口,最右边会出现控制面板,通过顶部的不同图标按钮来切换到不同功能控制区。

    AutoLayout
    Window-Autolayout

    Use Auto Layout选中表示使用自动布局机制来控制界面上元素的布局方式。相对于自动布局的另外一个方式就是坐标式布局,必须由代码显示的指定UI 元素之间的坐标位置关系。AutoLayout是苹果推荐的布局方式,我们后续的代码示例也基本上使用自动布局来说明。


    Window-Class

    每一种界面元素都是系统默认的标准类。如果想使用自定义的类,可以在输入你的自定义类名。这样xib文件被加载的时候会使用你定义的类中的初始化方法完成类加载。

    属性
    ProjectStruct3

    点击HelloWorld窗口,如上图切换到它的属性面板区。其中title字段可以修改window的标题。Title Bar 选中表示window是带有顶部标题,取消选中的话,窗口顶部的标题会消失。还有一个关键的Visible At Launch选中,表示应用启动时窗口自动显示。 如果你取消选中它,在运行Helloworld工程会发现,应用启动窗口不见了,只有顶部的菜单了。

    可以通过代码让它再次出现,在AppDelegate的applicationDidFinishLaunching中调用makeKeyAndOrderFront方法

    • (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
      // Insert code here to initialize your application
      [self.window makeKeyAndOrderFront:self];
      }
      Size
      Window-Size

    这里可以控制Window的大小,最大(Max)最(小Min)的高度/宽度。设置了最大最小高度/宽度后会影响应用启动会通过鼠标去拉长拉高window的范围,这个自己修改可以验证下。

    Connections
    Window-Assistant

    点击Xcode顶部View菜单中Assistant Editor选择Show Assistant Editor呼出类的定义文件AppDelegate。

    Window-Connection

    任何想通过代码修改UI界面上元素的属性/行为动作时,都需要对xib中的UI界面元素命名。在这面板Referencing Outlets部分,点击New Referencing Outlet 右侧的小圆,拖动这个小圆到类实现代码文件AppDelegate中@interface定义区,在弹出的窗口输入变量名称,完成界面UI元素绑定到Outlet类型的变量上。这样就可以使用这个变量完成对UI元素的各种控制。

    Supporting Files
    info.plist
    Project-Infoplist

    工程基本信息plist文件。plist是apple的(key,type,value)形式描述的文件格式,经常用来描述配置信息。

    Icon file:可以在这个字段输入icns格式的文件做为AppIcon图标。

    创建一个文件夹,文件夹名字后缀为iconset,将1024x1024的一张大图通过工具软件或者手工缩放成如下图的各种尺寸加到这个文件夹Icon.iconset。 拖动Icon.iconset文件夹到工程最左边的目录中的HelloWorld目录中。在Icon file字段输入Icon即可。

    IconSet

    Bundle identifier:应用的唯一标识字串。

    Bundle versions string, short:应用对外发布的版本号。

    Bundle version:应用内部版本号。提交到苹果等待审核中的版本,如果发现bug,可以撤下来重新提交,这时候Bundle versions string, short版本号保持不变,只需要对Bundle version版本号递增即可。

    Main nib file base name:指定应用启动时加载的xib文件名。

    Principal class:NSApplication

    main.m
    应用的入口。执行main函数,App运行时首先创建NSApplication实例加载xib文件,创建xib文件中定义的菜单/window实例。这个NSApplication就是Files Owner。NSApplication是是AppDelegate代理,因此会执行AppDelegate中的applicationDidFinishLaunching:方法来进行自定义的一些初始化。

    ProjectMain

    target
    定义了编译发布的单个产品需要的源文件,配置参数,依赖的库,部署系统版本环境,签名文件等。

    General
    除了可以通过plist文件修改应用的配置信息字段外,还可以选择target进入General面板 来修改plist文件中部分字段。
    Project-Infoplist-Visible

    Application Category:可以选择一个应用的分类,提交Mac Appstore必须要有分类。

    Deployment Info:Deployment Target设置应用支持的最低OSX系统版本。

    Capabilities
    Capabilites

    这里我们重点关注下App Sandbox,Apple现在要求上架Mac AppStore的应用必须使用沙盒,所以发布到Mac商店的应用你必须选择打开。
    如果你的应用要访问服务器的API接口,必须打开Outgoing Connections。
    Hardware里面必须选择打开Printing,否则审核不通过。
    File Accedd:如果你需要让用户选择访问本地的文件,User Selected File 中选择读/写权限。

    Capabilites-Sandbox

    Info
    Capabilites-info

    这里最上面部分跟直接查看info.plist 看到的内容一致.

    Document Types中可以设置应用跟文件的关联。比如你开发了一个图片应用,可以设置双击图片时自动运行你的应用,或者当鼠标右击菜单出现时里面可以出现你的应用。

    Build Settings
    Capabilites-buildsettings

    如果使用了非系统的第3方framework或者自己开发的framework,Code Signing 里面Other Code Signing Flags 必须设置为 --deep,否则无法正常打包发布到Mac Appstore。

    Build Phases
    Capabilites-buildphases

    Link binary With Libraries:点击+添加依赖的系统库。

    展开全文
  • 如果原来从事Windows软件开发,想跨足或转换至Mac OS X环境,需要知道那些东西?有什么知识技能可以快速运用在Mac OS X环境上的?这两个问题应该是Windows开发者进入Mac OS X环境最关心的问题。本文假设读者以往采用...

        如果原来从事Windows软件开发,想跨足或转换至Mac OS X环境,需要知道那些东西?有什么知识技能可以快速运用在Mac OS X环境上的?这两个问题应该是Windows开发者进入Mac OS X环境最关心的问题。本文假设读者以往采用微软的开发工具,并以C/C++/C#的任一种组合作为开发语言。

    大体说来,Windows和Mac OS X都是为桌面应用环境、图形用户接口(GUI)而设计的操作系统。虽然不同平台细节各有特色,但两者相近的抽象概念,其实远远多于相左之处。本文试图指出方向上明显的异同所在,而非详细列举各种细项差别。最后,我也将简短分享自己在开发跨平台软件时的一些技巧和心得。

    系统架构与开发环境的差异 

    用最简单的话来说,Mac OS X与Windows在架构与开发环境上最大的不同点在于:OS X是UNIX也不是UNIX;OS X主要开发工具Xcode使用GCC作为编译程序,与其他种类的UNIX相同;不过OS X也有独树一格的"bundle"软件包装格式这样的东西,成为它与其他操作系统不同之处。

    Windows和OS X都属于现代的操作系统,所以Windows在操作系统层级所提供的功能──执行文件与链接库加载、多任务与多线程、内存管理──在OS X上都找得到对等的API和作法。不过,相较于Windows在微软独力开发下,架构和API都维持着相对的一贯性(另一方面,也背负着各种历史遗迹和向下相容的包袱),Mac OS X则是底层源自NeXTSTEP的Mach微核心(现在称为XNU),而应用层(用准确的UNIX术语来说叫userland)来自FreeBSD 4。这件事情相当重要:OS X透过这样的架构,才拥有和一般Linux/FreeBSD相似的UNIX应用环境。有相当多Mac软件开发者喜欢在UNIX shell下工作,使用各种UNIX工具。在Windows上,必须加装Cygwin之类的环境才能办到。

    Apple几年前有则广告是「把其他牌子的UNIX送进/dev/null里」(用过UNIX的朋友应该不难体会其中的吹嘘意涵)。平心而论,OS X受益自UNIX环境之处不少。尤其,Apple使用了大量的open source工具。举例来说,Apple不像微软,没有自己的C语言编译工具,Apple用的是UNIX业界的标准──open source的GCC(其中当然有不少OS X的扩展功能就是)。虽然Apple有自己的开发环境Xcode,但是底层采用GCC这件事对开发者来说是相当重要的。同时,Apple的C/C++链接库用的也是GCC标准的stdc/stdc++。了解这个差异,在遇到与Microsoft C/C++ compiler不同的地方时,就更容易能找到解答的资源(这类型问题往往不限于OS X,其他UNIX平台也会发现)。

    但是Mac OS X并不完全是UNIX。它的GUI环境(Aqua)就完全不是一般Linux/FreeBSD所使用的X11。而在UNIX层之下的微核心也和其他UNIX不同。接下来这一点很重要:OS X虽然有和Windows .EXE和.DLL相对应的文件(OS X跟其他UNIX一样,可执行文件一般不加扩展名,UNIX系的动态加载链接库则冠以.dylib),但更重要的架构差异是bundle。

    Bundle概念承袭自NeXTSTEP。简单来说,就是由操作系统提供一种类似对象封装的文件包裹。OS X上最常见的bundle要属.app结尾的应用程序了。虽然.app外观上是个文件,在UNIX shell下看就能发现它其实是个目录,内含各种metadata(通常至少会有一个名为Info.plist的数据文件)、可执行文件、动态链接模块、各种资源等。除了.app外,OS X的各种框架档(以.framework结尾,是一种同时包含头文件及链接库的包装)、应用程序的外挂模块(通常以.bundle结尾)等等,都是以bundle形式呈现的。了解这个差异,才能了解为什么OS X上很少有程序需要额外的安装程序,也鲜少听说有所谓的"DLL hell"(因共享链接库版本不兼容造成的困扰)。

    项目 Windows Mac OS X
    操作系统最近桌面版本 Windows Vista Mac OS X 10.5 Leopard
    操作系统核心 NT Kernel XNU
    CLI Shell环境 CMD.EXE UNIX shell (bash/tcsh/etc., 可使用Terminal.app一类的终端机软件进入)
    GUI (Shell) 环境 Windows Explorer Aqua (Finder)
    程序二进制文件格式 Portable Executable (PE): .EXE, .DLL Mach-O "universal" binary (可执行文件通常不带附加名,DLL结尾为.dylib)
    用来辨认软件组件的方式 GUID bundle identifier (Java式的id,例如com.apple.TextEdit)
    厂商提供或贩卖的开发环境 Microsoft Visual Studio Xcode
    可视化的GUI制作工具 Visual Studio内建的WinForm designer Interface Builder
    C编译程序 Microsoft C Compiler GCC

    表一:Windows与Mac OS X在架构上的对照

    开发语言与API;Objecitve-C, Core API, Carbon, Cocoa 

    如果使用微软工具来开发Windows软件,就一定会碰到Platform SDK,MFC或者.Net平台,同时,也相对应到C、C++、C#和其他.Net平台所提供的语言(这种区分并不是绝对的,仅仅是为了方便接下来的模拟所做的简化)。在OS X上,Apple则是鼓励大家尽量采用Objective-C作为开发语言,并且熟悉Cocoa。

    接下来的问题既尴尬又麻烦。很多人会问:我们是否非学Objective-C不可?另外一个常见的问题是:Apple不是也有名叫Carbon的C API吗?(延伸出来的问题则是:可不可以用C++开发Mac程序?)。

    简单的答案(同时一定程度上也代表Apple的态度)是:要用Objective-C才能完全发挥OS X图形应用环境的长处,而Cocoa这个用Objective-C写成的API framework就是最佳的施力点。

    复杂的答案则是这样:

    OS X的本体,也就是所有非UNIX的部份,并不像Windows一开始就(几乎)全以C写成的。因此OS X没有所谓"Win32 API"这么纯粹的东西。OS X核心的、非GUI的服务和链接库,有时称为"Core API"。Core API大部分以C写成,并且多半奠基于CoreFoundation这套链接库之上。CoreFoundation提供了一贯的内存管理模式(CFRetain, CFRelease)、基础的数据型别(字符串、数组、字典)、property list文件管理、文件、网络存取等等。CoreFoundation使用上跟Win32 API有点相似,都透过存取handle的方式来达到某种近似「用C语言操作对象」的效果。但CoreFoundation最大的不同在于它还有reference counting的内存管理模式,大幅简化了内存管理的复杂性。

    至于Carbon,严格说来,是Mac OS X在发行之初,为了维持与Mac OS 9兼容,才提供一套以C写成的GUI工具集,主要包括所有的GUI组件(Apple 称为 HIToolbox ,HI 意思是 Human Interface)以及所有OS X之前的API(QuickDraw等等)。随着OS X 10.5的推出,Apple渐渐舍弃了旧式的API ,鼓励大家使用Objective-C写成的Cocoa来开发程序。Carbon现在的意义等于就是HIToolbox,也就是OS X GUI 的C API。

    但是,Apple在2007年夏天做了重大的宣布;Carbon不会有64-bit的版本。也就是说这一套C API是「没有未来」的。这意味着所有使用Carbon写成的软件──Microsoft Office、Adobe Photoshop都不可能顺利过渡到64-bit。至于像QT这一类跨平台的GUI kit也势必要顺应这项改变。

    其实Objective-C并不难学。由C转换到C++/C#时需要学习很多新观念、新用语,但Objective-C大体上只是在C语言上加上一层薄薄的、动态的面向对象层。Cocoa则是相当容易上手的API。透过Cocoa就可以用面向对象的方式存取OS X八成上的系统服务(其余两成可以用C来呼叫)。Objective-C可以跟C完全混用。同时Apple也提供了所谓的"Objective-C++",可以在C++程序中呼叫Objective-C程序,或者在Objective-C里撰写C++程序代码。Apple自家的浏览器Safari就有不少核心的程序代码(WebKit)使用了Objective-C++来撰写。 

    项目 Windows Mac OS X
    主要开发语言 C/C++/C#(及其他.Net支持的语言,如C++/CLI) Objective-C/Objective-C++/C/C++
    操作系统服务 Win32 API 系统服务多半可从POSIX layer用stdc/stdc++取用
    系统核心服务 Win32 API CoreFoundation/CoreServices
    绘图与GUI Win32 (GDI32, USER32) Quartz (C API)/HIToolBox (Carbon)/AppKit (Cocoa)
    面向对象的API .NET Framework/MFC Cocoa
    面向对象的GUI及绘图系统 WPF/GDI (with MFC) AppKit (Cocoa)以及Cocoa Graphics
    桌面应用程序的数据库方案 ODBC/ADO.Net CoreData
    基础绘图系统使用的单位 Pixel (GDI) Point (Quartz)
    默认的屏幕分辨率 96 DPI 72 DPI

    表二:开发语言与API的对照

    图形作业环境的差异:绘图系统 

    大家对OS X最主要的印象,想必还是它的图形作业环境。GUI的确是OS X与Windows差异最多的地方。

    在Windows环境里,传统上Win32 API同时包括了绘图(所谓的GDI/GDI+)和GUI组件(窗口、对话盒、按钮等等)的操作。到了.Net 3.0有所谓的WPF (Windows Presentation Foundation)。严格说来所有Windows上的概念和组件,都可以在OS X上找到相对应的作法。但是在架构上OS X确实和Windows有相当大的差异。

    OS X的绘图系统核心是Quartz。Quartz的绘图基础概念是路径(path),而不是像素(pixel)。惊人的事实是:Quartz是一套PDF绘图系统。所有Quartz能绘制的对象都能轻易转换为PDF文件。至于在图像处理上,Quartz提供了一套完整的合成模型(compositing model)。简单地说,Quartz赋予了Mac OS X极为优异的绘图能力。从一些细节就可以看出Quartz在视觉上的细致度:例如,OS X在显示字型时的去锯齿(anti-aliasing)处理就要比Windows来得细腻,在点阵影像的缩放上效果也往往比Windows好。OS X的应用程序可以轻易做出各种透明度的图层、以及为图形对象加上阴影、或者绘制不规则形状(但这并不代表你应该只是为了为了吹嘘而滥用这些功能,我们马上会提到用户体验这件事)。倒是有个细节应该马上一提,那就是Quartz的默认分辨率是72 DPI,所使用的单位是点(point),这跟PDF绘图系统是一致的,和Windows预设为96 DPI、以像素为单位的点阵式绘图系统很不一样。这在一开始可能很困扰人。因为在OS X上,不改变屏幕设定的情况下,12 pt的字,就真的会被会绘制成12 px(而在Windows上,12 pt却是16 px)。同时,Quartz默认的坐标系统跟数学上的习惯相同,也就是(0, 0)坐标起点是位于左下方,而不是一般计算机绘图使用的左上方(当然,Quartz有各种坐标变换功能,因此当然还是可以把(0, 0)设定为左上方的)。

    看似复杂,然而,当你开始想输出PDF(打印作业大幅简化)或进行精细的绘图工作时,慢慢就会发现Quartz这样设计的直观了。

    另外,Quartz的基础API是以C写成的,所有对象操作方式都跟CoreFoundation一样(从Quartz建立的对象都是用reference counting的方式在管理内存,同时也都可以用CFRelease来释放)。不过,Cocoa也提供了绝大多数的API对应。使用Objective-C来操作绘图对象会更轻松些。

    在Quartz之上,或者与Quartz并行的,还有Apple的各种图形和媒体相关的子系统。诸如可以快速制作动画的Quartz Composer、新一代文字输出编排系统CoreText、应用层的2D动画系统CoreAnimation,以及Apple的招牌多媒体架构QuickTime,还有业界标准的OpenGL,这些构成了Mac OS X在视觉及媒体经验上的核心。

    图形作业环境的差异:GUI,以及,用户体验 

    Windows上,尤其是Win32 API里面,绝大多数关于GUI的概念和技能,都可以直接转换到OS X上。OS X的GUI同样是采用事件驱动模型(event-driven model)来设计的,每个GUI应用程序同样都有所谓的run loop(或称event loop/message loop)。两者甚至在某些系统限制上也雷同:例如,.Net跟Cocoa都不鼓励或甚至禁止程序在主线程以外的地方创建或操作GUI对象。

    尽管如此,GUI是造就Mac OS X在外观上与其他平台不同的最大要素。与之相伴的是OS X对于用户体验近乎执着的追求。

    OS X在GUI上并没有一个特别的子系统。通常我们用接触到的API来区分。好比说如果用的是Carbon我们会称为HIToolkit,如果用的是Cocoa则会说是AppKit(Cocoa主要是由非GUI的Foundation──不要和CoreFoudation搞混了──以及提供GUI组件的AppKit所组成的)。Apple的开发工具中并没有类似Visual Basic一类把接口画完、在组件上点两下鼠标,把程序填进去就完成应用程序的工具或流程。最接近的是Interface Builder (IB)这套工具。IB做出来的.nib文件其实就是封存好的GUI对象,生成之后再回Xcode将必要的连结关系拉完,程序代码填上(通常量不会很多)就完成程序了。IB会是Xcode以外,OS X开发者最常用的工具。

    OS X提供的GUI组件特色为细腻、一致、直观。这并不代表OS X的GUI无法做复杂的设定和客制化。但是相较之下,OS X的应用程序更倾向于善用或组合现有的视觉元素,而较少自创新的custom control。这一点和Windows上,尤其是小型工具程序,喜欢一种程序就创造一种视觉风格,或是大量提供使用者可更换的skin,有着相当大的文化差异。虽然Apple自家的软件跟微软相似,喜欢提前使用下一个版本才出现的视觉风格或元素,有时让开发者觉得难以捉摸,但大体上遵守Apple自家的HIG (Human Interface Guideline)还是常态。

    我们提到了文化差异;OS X在视觉上的细腻,以及对用户体验的追求,造就了一种高要求的文化。这可以说是一种正向循环。我们或许很少听说哪个Windows开发者会为了icon向左偏了1 pixel而大改特改,或是要求自己的软件要在视觉及操作上符合哪个规范的一致性。但OS X的开发者真的会谈论并严肃看待这件事情(著名的icon设计商IconFactory以及独立软件商Panic是著名的两个代表),同样的也有相当多OS X使用者以同样严苛的标准看待他们使用的软件,甚至可能写信告诉你,指出你的软件在用户体验或视觉设计上的缺陷(笔者就曾经收到使用者来信,指出笔者的一个软件在pull-down menu中使用的icon「语意」不合乎用户对该种GUI组件的期待)。又好比说,从OS X 10.5 Leopard开始,icon最大可以大到512x512,Apple也强烈建议开发者要准备这么大的尺寸(除了原有的16x16、32x32、128x128之外)。这当然无形中提高了开发的挑战。Windows在XP以前仅支持16x16、32x32、48x48,直到Vista才开始加大到64x64和256x256。

    另一个与GUI不直接相关,但却影响用户体验的,是OS X的本地化(localization)系统。这一点也是和Windows不同的地方。OS X因为有bundle的设计,因此能让一个应用程序同时包装各种不同语系的资源文件,同时开发多语系程序在OS X上也相对容易(通常是以提供各种不同版本的.nib bundle放进应用程序bundle中Content/Resources/底下以语系区域来区分的子目录中就完成了。Windows程序设计一向以"resource file"概念来管理icon及本地化等「外部」资源,名称相似,开发方式却不那么一贯而直观;另外,OS X的语系是可以按照顺序fallback的,例如要是繁体中文语系档找不到,而用户在语言设定中将简体中文设定在繁体中文的后头,那么OS X便会尝试套用简体中文语系档),结果是OS X使用者对本地化同样有着高标准与高期待。另一方面,笔者也建议大家,除非软件确定只有中文用户使用,不然一开始先以英文界面开发,再加上中文的本地化资源,以长期来说是值得(甚至是必要)的投资。

    一些较难归类但同样重要的差别 

    Mac OS X跟Windows在软件开发作法上的差异还有很多,上述只就最大的方向差异阐释。有些较细微但值得一提的差别,我们也在这里简单说明。

    首先,OS X跟Windows一样,内部字符串编码以Unicode为准。但在操作系统不同的层级,使用方式并不相同。Windows的Unicode layer很一致地使用了UTF-16作为编码,并偏好使用BOM辅助判别。OS X的文件系统使用UTF-8,而CoreFoundation及Cocoa则用UTF-16。如果使用Cocoa自己的serialization机制,Cocoa会正确储存和还原UTF-16的位顺序。不过,笔者自己建议,尽可能使用UTF-8作为各种交换时的编码(相对于Windows对于UTF-8的支持不够干脆简明,Cocoa自己就提供了像stringWithUTF8String以及UTF8String两种NSString的method,方便在native string与UTF-8间的游走)。

    其次,相对于Windows使用registry来管理应用程序设定,Mac OS X使用的是一种叫做property list(文件扩展名为.plist,简称plist)的XML文件。Plist可以直接变成CoreFoundation及Cocoa的各种容器对象,也可以将后者轻易地serialize成plist。因此OS X上的应用程序大量使用plist作为配置文件的格式,甚至作为数据单元格式。将设定用个别文件储存也减少了Windows集中管理registry所带来的各种弊病。

    Mac OS X并不使用COM (Component Object Model)来作为面向对象的进程间通信(IPC; interprocess communication)的机制。因为用Cocoa写成的程序,可以透过Objective-C Distributed Object (DO)这个强大机制来达成IPC的任务。除此之外,因为bundle架构,OS X软件要设计外挂模块架构也相当容易。OS X有相当多支持外挂的应用程序,应归功于这种开发上的便利度。

    OS X应用程序能够利用所有OS X在UNIX环境上所提供的功能。同时OS X一安装好就已经帮你准备好了大量的open source链接库,例如可用来制作密码密钥认证的OpenSSL、负责解压缩的libz、内嵌式数据库引擎SQLite等等。这些都是加速开发的好帮手。

    最后要提的是,正因为OS X的文化与Windows有许多不同处,笔者建议跨足OS X的开发者应该要尽可能贴近甚至配合OS X的习惯。举例来说,大多数OS X应用程序都不需要安装程序,只需要直接将软件拷贝到想要存放的目录(通常是/Applications)即可。而解安装也就直接删除该.app bundle就解决了。在Windows上就没那么容易了(特别是有相当多组件依存关系的软件)。这些都是开发上需要注意的地方,但是开发者多付出一份心力,使用者就会多一份便利,终究会得到用户肯定的。

    项目  Windows  Mac OS X 
    系统内部编码 Unicode (UTF-16) Unicode (文件系统使用 UTF-8, 系统API一般使用 CFString/NSString, 内部使用UTF-16)
    语系处理 区分Codepage 不区分Codepage
    应用程序的设定管理方式 Windows registry Property list files
    IPC的几种方式 COM/Windows RPC Objective-C Distributed Object/Apple Event/BSD Socket
    脚本语言的支持 VBScript/JScript/CScript/DOS Batch script AppleScript/Perl/Ruby/Python/shell script 

    表三:一些重要的系统特性(摘录)

    项目 Windows (.NET) Mac OS X (Cocoa)
    字符串处理 System.String NSString 
    数据结构与容器 System.Collections NSArray/NSDictionary/etc. 
    HTTP网络存取 System.Net System.Net,NSURLConnection
    XML解译 System.XML NSXMLDocument etc.

    表四:几个代表性的.NET namespace/class在Cocoa中的对应class

    跨平台的建议 

    最后简短分享一些跨平台软件开发所可能遇到的问题。

    要同时在Windows和Mac上开发,有两种可能的思维方式。一种是追求真正的"write once, run everywhere"。此时开发的选择,可能是采用Java平台,Adobe的AIR,抑或使用C++搭配像QT这样的跨平台链接库。这三种主流方案各有千秋,但在视觉和用户体验上往往皆无法与原生(native)的Mac应用程序相比。

    因此,另一个方向则是体认到,要保有Windows及Mac各自平台的特长,就必须割舍GUI跨平台的可能性。也就是说,GUI是最无法移植到其他平台的部分。我们能做的是将共通的逻辑部分独立出来,然后开发两套前端接口(frontend)。若以在Windows及Mac上皆能使用为前提,共通逻辑开发语言的选择就很少了,不是C就是C++。所幸Windows和Mac上具有平台特色的语言,要和C++结合,也不是那么困难的事(在.Net上是透过C++/CLI,在Mac上是透过Objective-C++这两种扩展的语言)。

    不过,在开发共享部分的时候,最容易碰到的问题,恐怕还是要如何省下力气去做例如解译XML文件、存取网络这一类不是GUI的工作。这类工作的麻烦在于,Windows和Mac都各自提供了相当便利、但也绝对和平台相依的链接库(例如.Net的System.Xml,Cocoa的NSXMLDocument)。在这种情况下,我们也大体有两种选择:不是全部采用跨平台的链接库(例如使用expat来解译XML),就是善用面向对象的抽象化以及Abstract Factory这样的设计模式(design pattern),让程序逻辑呼叫抽象的接口,然后在于各自平台的版本中藉由呼叫平台相依的API来实现这些对象。

    结论 

    本文简要地讨论了Windows及Mac OS X在操作系统架构、开发环境、API、图形环境等环节上的相近处与不同的地方,也简单提出了跨平台应用程序开发的两种策略。事实上在两种平台上开发所需要了解的概念跟技能没有太大的不同,两种平台在性能上的差异也不大,但是在实现细节、视觉表现与用户体验上,OS X有自身独特的风格与文化。OS X软件开发社群常常说要"be a good Mac citizen"意思也就在此。了解这些差异和独特性是撰写合宜的OS X软件的第一步。

    展开全文
  • 最近因为博主自己的需求,而App Store上的App不能满足需求,或者是说,想借此机会涉猎一下Mac OS开发。之前一直臆想iOS开发Mac OS差不多,实则不然。 BTW 推荐一款非Apple官方的App Store, HackStore 是一款...

    打开 磁盘工具 -> 文件 -> 新建映像 -> 来自文件夹的映像

    资源文件夹内容

    配置 选择包括 .appApplications 替身 文件夹的路径,也就是上图说的 资源文件夹 路径

    点击 打开 ,配置相关信息 点击 存储 即可。

    自定义

    1 准备资源,包括:背景图片, .appApplications 替身 文件。

    2 创建一个空的映像文件

    配置信息

    3 配置资源 -- 配置背景图

    1)打开显示选项

    2)配置背景图

    3)隐藏背景图片文件

    使用 mv 命令进行重命名

    $ mv background.tif .background.tif
    

    4 配置资源 -- 拖拽 .appApplications 替身

    5 转换

    配置转换信息

    6 效果

    附言

    每次自定义类型打包dmg,都需要从零开始,不能使用上一次的未转换时的文件直接替换 .app 文件。否则,呈现的样式将不是CD样式。


    转自:http://www.tuicool.com/articles/z6naMvZ

    展开全文
  • Xcode是在Mac OS下进行C、C++编程一个...Xcode是开发OS X 和 iOS 应用程序的最快捷的方式。标准情况下,Xcode支持Objective-C、C、C++、Swift等语言。本文将通过一个简单的例子来演示在Mac OS下进行C/C++编程的基本方法
  • 一.Mac OS X内核编程开发官方文档: I/O Kit Fundamentals: I/O Kit基础 - Mac OS X系统内核编程 ...
  • [简历]  常用网名: 猪头三 出生日期: 1981.XX.XX 生理特征: 男 婚姻状况: 已婚 个人网站: http://www.x86asm.com Email: pliceman_110@163.com QQ交流: 643439947 编程生涯: 2001年~至今[13年]...开发语言: C/
  • Mac OS X搭建C#开发环境

    2017-10-25 15:07:19
    Mac OS X搭建C#开发环境 转载至:http://www.cnblogs.com/liunlls/p/charp-cross-platform.html 在Mac下想要用C#语言的话,首先得有个跨平台的.Net环境-Mono http://www.mono-project.com/ 有了Mono...
  • Mac OS X应用程序格式详解OS X 应用程序 格式讲解OS X 如何执行应用程序译者:51test2003 译自[url]http://0xfe.blogspot.com/2006/03/how-os-x-executes-applications.html[/url]作为长期的 UNIX 用户, 我通常有...
  • Windows下虚拟机安装Mac OS X VM12安装Mac OS X 10.11随着Iphone在国内大行其道,越来越多的开发者涌入IOS开发大军 中,但都苦于没有苹果机,本文即将介绍WIN虚拟MAC的教程。一、工具: Mac OS X 10.11 镜像文件...
  • 操作系统:Mac OS X Lion 10.7.3开发环境:Xcode4.2.1一.创建一个Cocoa Application项目1.[File]->[New]->[New Project]选择Mac OS X列表下的Application项,在右边窗口中选择[Cocoa Application]->[Next]2.输入...
  • Mac OS X Java 开发指南

    2008-12-29 12:49:00
    Mac OS X Java 开发指南本地平台集成应用程序和本地环境整合得越好,用户在使用时需要学习的东西就越少。一个好的应用程序看起来就好象是对主机平台的一种扩展。本章将讨论一些技术细节,这些细节将有助于使应用程序...
  •  本人是一个android的程序员,最近正在学习iphone的程序开发,就考虑在自己的笔记本上装一个Mac OS(virtualbox 4.1.4+Mac OS 10.6),刚开始,在网上找了一些关于虚拟机上装Mac操作系统的资料,好像比较简单,就是...
  • 本文选自《开发者头条》1 月 11 日最受欢迎文章 Top 3,感谢作者 黎浔 分享。欢迎分享:...暑假之后开始了人生里第一次真正意义上的实习、第一款App Store上架应用、全面转向了JavaScript全栈开发
  • Mac OS X之所以得到很多程序员的喜爱,其支持多种开发语言和程序运行环境的特性是一个重要原因。由于其根植于Unix系统,所以原生就支持传统的unix C/C++程序;当然GUI程序则更是OS X的强项;Java虚拟机在Mac OS X上...
  • 全面了解MAC OS X系统(以 Mac OS 9为例)
  • Mac OS线程开发包介绍

    2006-04-14 19:14:00
    Mac OS线程开发包介绍 Mac OS X提供了到几套API用于创建程序级别的线程。从行为上来看,这些API创建的线程的本质是一样的。 你可以根据你的程序(Carbon, Cocoa, Darwin)选择一套API函数, 同时也要考虑它的性能和...
  • 刚刚开始学习Java,一切从头开始。最初准备看书,一看全都是六七百页的书籍怕我一路看下去进展...比较值得总结的是开发环境的搭建,我自己用的Mac,跟教程不是很一致,自己试了一下简单做一下记录。 先试了一下电脑上是
  • Mac OS开发经常碰到的一个问题是,Apple特有的API的更新换代很快,一个API去年还用得好好的,在今年新发布的OS版本中就被弃用了,换成一个新的API。为了实现相应的功能,又为了使用程序能够同时支持老版本和新版本,...
  • 搭建环境初学STM32开发,首先解决开发环境的问题,由于Mac OS X系统下没有keil环境,故需要自己搭建开发环境,参考大师“胡茂晓 的 BLOG”:在Mac OS X中搭建STM32开发环境(1)等系列。编译环境搭好了,然后就是...
1 2 3 4 5 ... 20
收藏数 79,385
精华内容 31,754
关键字:

mac os开发程序