日期: 2021 年 6 月 16 日

Web服务器父与子 Apache和Tomcat区别

熟悉三国的朋友都知道曹操,曹操有二十五个儿子,其中*得曹操宠爱的是曹丕、曹植、曹彰三个,曹丕性格阴冷,擅长政治;曹植才华横溢,放浪不羁;曹彰武艺高强,战功卓著。曹操一直希望这三个儿子当中选取自己的继承人,*后与曹操性格*为相近的曹丕脱颖而出。但是我们永远都不会否认曹植的才华和曹彰的武功。

Apache是世界使用排名*的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是*流行的Web服务器端软件之一。在Apache基金会里面Apache Server永远会被赋予*大的支持,毕竟大儿子*亲嘛,而Apache的开源服务器软件Tomcat同样值得关注,毕竟Tomcat是开源免费的产品,用户会给予*大的支持。但是经常在用Apache和Tomcat等这些服务器时,你总感觉还是不清楚他们之间有什么关系,在用Tomcat的时候总出现Apache,总感到迷惑,到底谁是主谁是次,因此特意在网上查询了一些这方面的资料,总结了一下。(51CTO编辑推荐:Tomcat 7功能与应用指南)

解析一:

Apache支持静态页,Tomcat支持动态的,比如Servlet等,

一般使用Apache+Tomcat的话,Apache只是作为一个转发,对JSP的处理是由Tomcat来处理的。

Apche可以支持PHPcgiperl,但是要使用Java的话,你需要Tomcat在Apache后台支撑,将Java请求由Apache转发给Tomcat处理。

Apache是Web服务器,Tomcat是应用(Java)服务器,它只是一个Servlet(JSP也翻译成Servlet)容器,可以认为是Apache的扩展,但是可以独立于Apache运行。

这两个有以下几点可以比较的:

◆两者都是Apache组织开发的

◆两者都有HTTP服务的功能

◆两者都是免费的

不同点:

Apache是专门用了提供HTTP服务的,以及相关配置的(例如虚拟主机、URL转发等等)

Tomcat是Apache组织在符合Java EE的JSP、Servlet标准下开发的一个JSP服务器.

Runtime r=Runtime.getRuntime();
Process p=null;
try
{
p=r.exec(“notepad”);
}
catch(Exception ex)
{
System.out.println(“fffff”);
}

解析二:

Apache是一个Web服务器环境程序,启用他可以作为Web服务器使用,不过只支持静态网页 如(ASP,PHP,CGI,JSP)等动态网页的就不行。

如果要在Apache环境下运行JSP的话就需要一个解释器来执行JSP网页,而这个JSP解释器就是Tomcat, 为什么还要JDK呢?因为JSP需要连接数据库的话 就要jdk来提供连接数据库的驱程,所以要运行JSP的Web服务器平台就需要Apache+Tomcat+JDK。

整合的好处是:

◆如果客户端请求的是静态页面,则只需要Apache服务器响应请求。

◆如果客户端请求动态页面,则是Tomcat服务器响应请求。

◆因为JSP是服务器端解释代码的,这样整合就可以减少Tomcat的服务开销。

C是一个结构化语言,如谭老爷子所说:它的重点在于算法和数据结构。C程序的设计首要考虑的是如何通过一个过程,对输入(或环境条件)进行运算处理得到输出(或实现过程(事务)控制),而对于C++,首要考虑的是如何构造一个对象模型,让这个模型能够契合与之对应的问题域,这样就可以通过获取对象的状态信息得到输出或实现过程(事务)控制。

解析三:

Apache:侧重于HTTP Server

Tomcat:侧重于Servlet引擎,如果以Standalone方式运行,功能上与Apache等效 , 支持JSP,但对静态网页不太理想;

Apache是Web服务器,Tomcat是应用(Java)服务器,它只是一个Servlet(JSP也翻译成Servlet)容器,可以认为是Apache的扩展,但是可以独立于Apache运行。

换句话说,Apache是一辆卡车,上面可以装一些东西如Html等。但是不能装水,要装水必须要有容器(桶),而这个桶也可以不放在卡车上。

小结

总体来说,Tomcat也许永远不会成为Apache*重要的产品,但是谁也阻止不了Tomcat成为主流产品,Apache对于这个小儿子同样也会给相当大的关心

iOS截图保存到图库不显示全图的”Bug”

首先,原谅我起了这么一个奇怪的标题,QA一脸真诚的给咱报了这么一个bug,咱们总得人人真真的看看再说吧.

首先,我们有个需求是截取屏幕,然后在下面拼接一小块,然后保存起来.

这个保存后的图片在手机自带的Photos(相册)应用里面的展示会是横向拉满,然后上下两部分在屏幕外头(而测试给我说的其他的App保存到本地的图片都是显示的全图)。

经过我的一些测试后发现,这个也不能说是bug,只能说是苹果的相册App的一个“特性”。当宽高比大于某一个值的时候,相册App显示图片就会全缩显示所有。当宽高比小于这个值的时候,会宽度拉满,高度上下会在屏幕外面,双击才能缩放显示全部内容。

为什么Windows/iOS操作很流畅而Linux/Android却很卡顿呢

先说是不是,再问为什么。
我就知道有人会这么说,然而那样就成了一篇议论文了,而我只是想写一篇随笔。所以,不管事实是不是那样,反正我就是觉得Windows,MacOS,iOS都很流畅,而Linux,Android却很卡。当然了,这里说的是GUI,如果考量点换成是Web服务的吞吐和时延,那估计结论要反过来了,不过那是客户端程序感觉到的事,作为人,who cares!
我写这篇文章还有一个意思,那就是想牵引一个话题,如果我们想把Linux,Android(当然,Android内核也是Linux)优化到GUI不再卡顿,我们应该怎么做。
大概是去年,一个炎热的午后,吃过午饭我和同事们在公司附近晃悠,就讨论 “为什么苹果手机就不卡,安卓手机不管多贵都很卡。” 记得一位同事说,iOS在GUI方面做了很多的优化,而Android却没有。
这话说对了!不过更为重要的一点是, 不谈具体场景谈优化,都是瞎折腾!
Windows也好,iOS也好,都知道自己的应用场景,因此针对自己的应用场景做了优化之后,妥妥在自己拿手的场景下甩Linux在该场景下的表现几条街了。
下面开始正式的技术层面的分析之前,先声明几点。
  • 本文并不是在说Linux系统总体上很卡顿,而只是说Linux系统桌面版的GUI程序相比Winddows很卡顿,如果真觉得本文是在喷Linux,那就当是喷Linux桌面的吧。
  • 本文不准备讨论X window和Windows窗口子系统一个在用户态一个在内核之间的差异,这无关紧要。我的想法是,即便是你将X window扔进内核,现有的Linux内核处理GUI,该卡顿还是卡顿。
  • 本文仅从调度算法的角度来评价为什么Windows/iOS不卡顿而Linux却卡顿,当然还有别的视角,但并不是本文主题。
  • Windows内核调度的线程而不是进程,但是本文统一采用进程这个术语,没有别的原因,只是因为进程的概念是和现代操作系统概念相始终的,而线程是后来的概念。
先看服务对象,仅此就将Windows,MacOS/iOS和Linux的使用场景区分开来:
  • Windows/MacOS/iOS系统,主要是被人操作,用来提供写文档,游戏,做报表,画图,上网浏览,视频播放等服务。
  • Linux系统,主要提供网络服务,用来支撑各种远程的客户端,为其提供数据处理和查询,数据生成,数据存储等服务。
事实证明,Linux在其专业的领域已经做的足够好,但是问题是,为什么它在GUI处理方面却总是一直很糟糕呢?这就要看具体场景的差异了。
对于网络服务而言,其场景的行为是 可预期的 ,我们可以将这些场景简单归结为:
  • 公平快速处理网络并发请求。
  • 公平快速处理并发磁盘IO。
  • 高吞吐CPU密集型数据处理与计算。
Linux优秀的O(1) O(1)O(1)调度器以及后来的CFS调度器可以非常完美的cover上述三个场景,至于说为什么,不必多说,简单归纳如下:
  • 无论是O(1) O(1)O(1)的基于优先级的时间片轮转还是CFS的基于权重的时间配额,均可以既满足优先级的差别服务需求又保证高吞吐率,这些都来自于调度器本身而不是依靠频繁的切换。
  • 额外的简单启发式*惩机制可以让网络IO以及磁盘IO的响应度更高,同时又不影响CPU密集型计算服务的高吞吐。
上面的第二点是一个额外的辅助,照顾IO过程快速获得响应,这是一个非常棒的辅助,但是注意,再棒的启发式算法也总是辅助性的,提高响应度就是个辅助性的锦上添花的功能,以高吞吐为目标才是根本。
IO过程对于一台Linux服务器而言是与外界交互的唯一渠道,通过该渠道可以将处理好的数据送出到网络或者磁盘,同时从网络或者磁盘获取新的数据,换句话说, IO过程类似一道门。 但也仅仅是一道门。
照顾IO过程获得高响应度这件事是为了让门开得更大,通行效率更高!
熟悉Linux内核调度器变迁的都应该知道O(1) O(1)O(1)到CFS过渡的这段历史,即2.6.0内核开始一直到2.6.22为止的这些版本,采用Linux内核划时代的O(1) O(1)O(1)调度器,随后由于两个原因:
1、O(1) O(1)O(1)调度器动态范围太大或者太小。
2、IO补偿机制不到位,时间片分配不公平。
为了解决这些问题,Linux内核切换到了CFS调度器。
切换到了CFS调度器,事实上,人们更多指望的是CFS能够让进程时间片分配更加公平,多个进程运行更加平滑,如此一来,上GUI界面的话,岂不是就不卡顿了。
然而还是卡顿,本质原因是,场景根本就不对路子。
在Linux服务器的场景中,优先级和时间片是正相关的,无论是O(1) O(1)O(1)调度器的静态线性映射的时间片,还是CFS的动态时间配额,都是优先级越高的进程其每次运行的时间也就越久,但是实际上,这两者并不是一回事。
在更复杂的场景中,正确的做法应该是参考 时间管理的四象限法则 来设计进程调度器。其中:
  • 优先级表示紧急性。
  • 时间片表示重要性。
于是,如果不是因为Linux服务器场景过于单一简单,CPU的时间管理要复杂得多,比如调度器应该按照四象限法则设计成下面的样子:
1、处理重要且紧急事件的进程,需要赋予高优先级分配长时间片去抢占当前进程。
2、处理重要但是不紧急事件的进程,保持固有优先级分配长时间片就绪等待。
3、处理不重要但紧急事件的进程,提升优先级但不分配长时间片,处理完毕立即返回固有优先级。
4、既不重要也不紧急的后台进程,低优先级短时间片,系统闲了再调度。
后面我们会看到,Windows的调度器就是这般设计的。
我们先总体看看GUI系统的场景。
它的服务对象是人,和Linux的服务场景的行为可预期相反,人的操作是 不可预期 的!
Windows,MacOS/iOS这种Desktop系统的GUI进程,很多时候都是在等待人的进一步操作而睡眠,要么在等鼠标,要么在等键盘,要么在等声卡,显卡的输出,或者就是在将用户输入的信息往磁盘里写而等待IO完成,Desktop系统更多关注的是要对以上这些事件提供高效率的响应服务,而不是系统的数据吞吐。
Desktop在乎的是时延,而不是总吞吐,同时,这个时延还是区分对待的,有些时延的可容忍区间很大,比如网卡(网卡IO之所以优先级提升并不是很多,是因为首先网卡是有队列缓存的,而大多数的报文都是burst而来的,队列缓存可以平滑掉首包延迟,其次,由于光速*限,相比于网络延迟,主机调度延迟真的可以忽略不计。),有些却很小,比如键盘鼠标。所以说,Windows之类的Desktop系统 必须能够区分一个进程当前的紧急性和重要性。
Linux内核能做到这种区分吗?
Linux可以通过计算一个进程的平均睡眠时间判定它是不是一个交互式IO进程,从而决定要不是给它一定的优先级提升,但是也仅能做到这个地步,因为Linux内核无法得到更进一步的信息。
Linux内核不知道一个进程到底是不是IO进程还是说仅仅在一个时间段内有IO行为的CPU密集型进程,Linux内核也不知道一个进程被唤醒是因为键盘的数据到了,还是无关紧要的信号到了,所以这一切,Linux内核只能 启发式预测。
Linux内核仅仅跟踪一个睡眠时间而且还是平均的睡眠时间,是区别不出进程当前的紧急性和重要性的。没有外界的信息输入,仅靠启发预测,当前的AI算法貌似还没有到这个境界吧。换句话说,启发算法是不准确的。你看看Linux内核O(1) O(1)O(1)调度器的sleep_avg是如何计算并如何参与动态优先级调整的,就会明白我上面说的意思。
既然Windows系统的GUI操作比Linux流畅,那么想必Windows肯定是做到了进程当前的紧急性和重要性的区分咯?那是当然。它是如何做到的呢?
虽然Windows的调度器也是基于优先级的,也是抢占式的,也是同优先级轮转的,这看起来和Linux并没有什么区别,甚至从4.3BSD开始,几乎所有的操作系统的调度器基本都是按这个思路设计出来的,仅仅从 如何选出下一个投入运行的进程 这个算法上看,几乎所有的操作系统调度器都是一样的。Windows与众不同的原因在于 其对优先级的不同处理方式。
自4.3BSD以来,所有的基于优先级的抢占式调度器的优先级计算都包括两部分因子,即固有优先级和动态优先级:
640?wx_fmt=png
一直以来, 640?wx_fmt=png  只是起到了 微调 的作用,而 640?wx_fmt=png 才更具有参考意义,其比重更大。
640?wx_fmt=png
Windows与众不同,其弱化了进程(其实应该是线程,但是我就统一写成进程吧,为了照顾不懂Windows内核原理的读者)的初始基优先级 640?wx_fmt=png  ,而强化了动态优先级 640?wx_fmt=png  ,更重要的是,动态优先级的值并非来自预测,而是来自于 事件 ,事件本身的紧急性反馈到了动态优先级的值,而事件本身的重要性则反馈到了时间片:
640?wx_fmt=png
可以看出,Windows对于不同的事件定义了不同的优先级提升的具体数值, 将动态优先级的值和具体的事件做了精确的关联。
这些数值的定义上,甚至精细而贴心,详细的数值参见ntddk.h:

//
// Priority increment definitions.  The comment for each definition gives
// the names of the system services that use the definition when satisfying
// a wait.
//

//
// Priority increment used when satisfying a wait on an executive event
// (NtPulseEvent and NtSetEvent)
//

#define EVENT_INCREMENT                 1

//
// Priority increment when no I/O has been done.  This is used by device
// and file system drivers when completing an IRP (IoCompleteRequest).
//

#define IO_NO_INCREMENT                 0

//
// Priority increment for completing CD-ROM I/O.  This is used by CD-ROM device
// and file system drivers when completing an IRP (IoCompleteRequest)
//

#define IO_CD_ROM_INCREMENT             1

//
// Priority increment for completing disk I/O.  This is used by disk device
// and file system drivers when completing an IRP (IoCompleteRequest)
//

#define IO_DISK_INCREMENT               1

//
// Priority increment for completing keyboard I/O.  This is used by keyboard
// device drivers when completing an IRP (IoCompleteRequest)
//

#define IO_KEYBOARD_INCREMENT           6

//
// Priority increment for completing mailslot I/O.  This is used by the mail-
// slot file system driver when completing an IRP (IoCompleteRequest).
//

#define IO_MAILSLOT_INCREMENT           2

//
// Priority increment for completing mouse I/O.  This is used by mouse device
// drivers when completing an IRP (IoCompleteRequest)
//

#define IO_MOUSE_INCREMENT              6

//
// Priority increment for completing named pipe I/O.  This is used by the
// named pipe file system driver when completing an IRP (IoCompleteRequest).
//

#define IO_NAMED_PIPE_INCREMENT         2

//
// Priority increment for completing network I/O.  This is used by network
// device and network file system drivers when completing an IRP
// (IoCompleteRequest).
//
// 网卡IO之所以优先级提升并不是很多,是因为首先网卡是有队列缓存的,而大多数的报文都是burst而来的,队列缓存可以平滑掉首包延迟,其次,由于光速*限,相比于网络延迟,主机调度延迟真的可以忽略不计。
#define IO_NETWORK_INCREMENT            2

//
// Priority increment for completing parallel I/O.  This is used by parallel
// device drivers when completing an IRP (IoCompleteRequest)
//

#define IO_PARALLEL_INCREMENT           1

//
// Priority increment for completing serial I/O.  This is used by serial device
// drivers when completing an IRP (IoCompleteRequest)
//

#define IO_SERIAL_INCREMENT             2

//
// Priority increment for completing sound I/O.  This is used by sound device
// drivers when completing an IRP (IoCompleteRequest)
//

#define IO_SOUND_INCREMENT              8

//
// Priority increment for completing video I/O.  This is used by video device
// drivers when completing an IRP (IoCompleteRequest)
//

#define IO_VIDEO_INCREMENT              1

//
// Priority increment used when satisfying a wait on an executive semaphore
// (NtReleaseSemaphore)
//

#define SEMAPHORE_INCREMENT             1
———————

仔细看,你会注意到对于声卡而言,其IO完成时,优先级提升会很大,而磁盘,显卡这种却并不是很多,这充分体现了设计者的贴心。这充分考虑到了人耳的灵敏度和人眼的分辨率之间的对比,声音是作为流顺序输出的,耳朵很容易分辨出声音的卡顿,而对于图像而言,完全可以慢慢双缓冲刷层,人眼相比之下没有那么高的分辨率识别到,因此声卡事件必须优先处理。同时,对于磁盘,网卡之类的,人就更是感觉不到了。除了声卡之外,键盘鼠标操作的IO完成对于优先级提升的数值也很可观,因为键盘鼠标如果卡顿,人的输入会明显感觉到延迟,鼠标则显拖沓,这都是很容易识别的卡顿事件,所以Windows给予了进程更高的动态优先级来尽快处理这些事件。
对于窗口子系统而言,当一个窗口获得焦点时,对应的处理进程的优先级也会得到提升,这会给人一种 你操作的界面总是很流畅 的感觉,毕竟你操作的界面就是前台窗口,至于说此时后台窗口的处理进程,即便是僵死了你也不会有感觉,因为你并不操作它们呀,当你操作它们时,对应的处理进程的优先级就会提升。
所有的优先级提升都伴随着时间片的重新计算,但是和Linux不同的是,Windows并没有直接将进程优先级和时间片按照正相关关联起来,时间片是独立计算的,大多数时候,Windows对于所有的进程,不管优先级是多少,均采用同一个时间片。
如此看来,Windows虽然也是优先级调度的系统,但是其优先级却是 操作行为驱动的 ,这便是其与众不同之处。
Linux内核调度系统会精细区分磁盘事件的wakeup和键盘鼠标声卡事件的wakeup吗?不会。
说完了Windows为什么操作GUI会很流畅,该说点不好的了,Windows经常会死机,为什么呢?
这很大程度上也和上面描述的调度器有关。
仔细看这个操作行为驱动的动态优先级调度器,很大的一个问题就是容易饿死低优先级的进程,特别是Pbase P_{base}P
base
 很低的进程。
Windows的解决方案是采用一个后台进程(学名叫做平衡集管理线程)轮询的方式,将超过秒级都没有被调度的进程的优先级拉升到很高的位置参与抢占。
这个机制有啥问题呢?问题在于Windows需要第三方线程来缓解饥饿,而不是靠调度器自身,这便增加了调解失败的可能:
  • 第三方线程本身的问题没有按照预期工作。
  • 饥饿进程过多。
  • 饥饿进程优先级提升后又被抢占。
除了死机问题之外,Windows系统对于服务器版本的调度器调整做的也不够优雅,Windows仅仅是调整了服务器版本的系统参数,而几乎没有对调度的算法做任何修改。对于服务器版本,Windows只是将时间片延长了而已,同时几乎不再动态计算时间片,而是选择始终使用相同的一个足够长的值,以减少进程切换提高吞吐率。显然这种方式并不妥当,因为动态优先级根据事件的提升,还是会造成进程间不断抢占,从而影响吞吐。
不过,毕竟Windows是一个Desktop系统,本身就不是为高吞吐而生的,这种针对服务器版本的策略调整便是无可厚非了。正如Linux服务器虽然可以很完美应对高吞吐场景,其Desktop版本比如Ubuntu,Suse不也是心有余而力不足吗?虽然Linux内核也有动态优先级提升这一说。
该简单总结一下了。
在人机关联上,Windows更加靠近人这一端,适应了人的操作行为,为操作该机器的人提供了良好的短时延体验,Linux相反,它靠近机器一端,让CPU可以尽可能开足马力跑task而不是频繁切换,从而为客户端提供*大的数据吞吐。
640?wx_fmt=png
Windows的设计甚是精妙,考虑到了人的行为的每一个细节(除了对于死机的耐受力),除了动态优先级和具体时间精确关联之外,对于待机恢复时间deadline在7秒内也是很值得拍案,这个7秒的阈值考虑到了人的短期记忆的*限,如果有人突然想到了一个点子,需要打开电脑将其记录下来,那么打开电脑的时间如果超过了7秒,那么可能这个点子就溜走了,所以待机恢复时间必须限制在7秒以内,哇塞不哇塞。
对于MacOS/iOS没有过多的研究,但是可以想见应该也如Windows这般了。因为它们都处在人机关联的人的这一端。随便看了下MacOS的开发手册,找到了下面的段落:
640?wx_fmt=png
当我找和GUI和调度相关的东西时,就在上面这段的下面,有这个定义:
640?wx_fmt=png
嗯,看来内核也是能看到所谓的前台窗口的。
不管怎么说,Windows,MacOS/iOS这些系统,共同的特点就是 大多数情况下,同时只有一个焦点窗口在前端接受输入输出。 毕竟把窗口缩小排满一屏幕的很少见。然后呢?然后这就是一个典型的场景啊!
你看看Win10,不就可以设置为平板模式吗?
倾其机器和操作系统内核所有资源和机制照顾这少数的,几乎是唯一的前台焦点窗口的处理进程,这几乎就是单进程处理啊! 然后处理好用户的窗口切换即可,比如Windows的Ctrl-Tab。
Linux如若按照这个思路,单独再写一个调度器,替换掉CFS,而不是增加一个调度类,如此一来将系统中所有的进程统一按照 优先级和事件相关联 的方式对待,我想问题应该能优化不少。
已经快凌晨了,说点别的但是相关的吧。
Linux内核O(1) O(1)O(1)调度器的历史其实很短暂,2.6初始到2.6.22,但是非常经典的Linux内核方面的书,都是在描述这期间的Linux内核版本,这在当时就给了人们一个假象,O(1) O(1)O(1)调度器是无敌的,是划时代的,于是,当有了新的CFS调度器的时候,人们哇塞一声,O(1) O(1)O(1)只是银河系级别的,而CFS是宇宙级别的。
但其实,O(1) O(1)O(1)的意义只是优化了 如何快速找到下一个要运行的进程 ,虽然它也涉及了动态优先级的计算,但是这并不是它的重点。说实话,你若看看Windows的调度器,4.4BSD,SystemV4的调度器,基本上都是位图加优先级队列的形式,思路几乎是同一个,这么说来都是O(1) O(1)O(1)咯,而且人家这些调度器早在Linux还是O(n) O(n)O(n)调度器的时候就已经存在好几年了,却无人问津。
Windows内核的调度算法不为人知的原因除了其闭源之外,还有一个原因就是Windows内核方面的技术总体上推广的人太少,国内除了潘爱民一直在致力于这方面的推广之外,在没有别人了。估计是因为大家觉得Windows内核方面,Debug之外的东西,学了也没啥用吧。
你说Linux开源没错,BSD不也开源吗?怎么就没有人注意BSD的调度器实现呢?哈哈,开不开源无所谓,关键得能造势搞事情,而且获取方便,让大家用起来你的东西才真真的啊。Linux2.4版本说实话及其垃圾,但关键是很多人用起来了,这就是全部了。Solaris虽然设计完美优雅,可是有壁垒,没人用,*终也还是凉凉。同样的事情参考以太网。
通篇都在比较Windows和Linux的调度器如何影响人们的操作体验。*后说说iOS和Android吧,题外话,不涉及技术。
Android就是卡,不接受反驳。
再贵的Android机器也卡,三星的,华为的照卡不误,只是相比别的稍微好一点点而已。这意味着它们成不了街机。因为手机是买来用的,不是买来debug的,除了程序员没人在乎Android机慢的原因,即便是程序员也很少有折腾明白的,只是因为这份职业让他不用Android就不正确。不过现在互联网公司的程序员用iPhone的也多了,因为好用啊。再者说了,互联网公司程序员大概率以做业务逻辑为主,底层技术欠缺,无力debug,当然是什么好用用什么,iPhone贵,但是互联网程序员收入高啊。
*终,Android机的唯一优势就是价格,你让Android卖的和iPhone一样贵试试,分分钟被绞杀。要说还有唯一点五的,就是品牌,XX也不是吃素的,就算XX做的再烂,就凭它这牌子,也不缺市场,比如我就是XX用户,我并不是觉得XX的Android比小米的Android好,而是我喜欢XX这个公司,这个品牌,仅此而已。

IOS框架和服务

在iOS中框架是一个目录,包含了共享资源库,用于访问该资源库中储存的代码的头文件,以及图像、声音文件等其他资源。共享资源库定义应用程序可以调用的函数和方法。

    iOS为应用程序开发提供了许多可使用的框架,并构成IOS操作系统的层次架构,分为四层,从上到下依次为:Cocoa Touch Layer(触摸UI层)MediaLayer(媒体层)Core Services Layer(核心服务层)Core OS Layer(核心OS层)

 低层次框架提供IOS的基本服务和技术,高层次框架建立在低层次框架之上用来提供更加复杂的服务和技术,较高级的框架向较低级的结构提供面向对象的抽象。

 在开发应用时应尽可能使用较高级的框架。如果要开发的国内在高层框架中没有提供,你也可以使用较低层框架和技术。

 Foundation UIKit框架是应用编程用到的两个主要的框架,能够满足大多数应用程序的开发需求。

 UIKit框架提供的类,用于创建基于触摸的用户界面。所有 iOS 应用程序都是基于 UIKit, 没有这个框架,就无法交付应用程序。UIKit提供应用程序的基础架构,用于在屏幕上绘图、处理事件,以及创建通用用户界面及其中元素。UIKit还通过管理屏幕上显示的内容,来组织应用程序。

Foundation框架为所有应用程序提供基本的系统服务。应用程序以及 UIKit和其他框架,都是建立在 Foundation 框架的基础结构之上。     Foundation框架提供许多基本的对象类和数据类型,使其成为应用程序开发的基础。它还制定了一些约定(如用于取消分配等任务),使代码更加一致,可复用性更好。

整个框架架构图如下:

%title插图%num

%title插图%num

 

Cocoa Touch Layer(触摸UI层)

CocoaTouch Layer包含创建ios应用关键的框架。该层包含的框架定义应用的外观,也提供基本的应用基础和关键的技术支持,例如多任务、触摸输入、推送通知和许多其它的高级系统服务。在开发应用时,应当首先研究该层的技术和技术看是否能够满足需要。

1.1 Cocoa Touch Layer包含如下关键技术

1).AirDrop

  AirDrop允许用户与附近设备共享图片、文档、urls链接以及其它种类的数据。

2)、Text Kit

TextKit是处理文本和排版的一个全功能、高级别的类集合。使用Text Kit你能在段落、列或者页上对带有风格的文本进行布局;也能在任意区域(如图形)周围布局流动的文本;还能用它来管理多种字体。

开发应用时应该首先考虑使用Text Kit来进行文本呈现,而不是Core TextText Kit与所有UIKit中的基于文本的控制集成允许应用更容易地创建、编辑、显示和存储文本。

3)、UIKit Dynamics

UIKit dynamics用来为符合UIDynamicItem协议的UIView对象或其它对象规定动画行为。通过在应用的UI中集成真实世界行为和特性进,动画行为为应用提供了一种增强用户体验的方式。

4)、Multitasking

ios中多任务用来设计来使电池使用时间*大化。

5)、Auto Layout

自动布局帮助你使用非常少的代码来建立动态接口。

使用AutoLayout定义如何在用户接口上布局元素的规则,这些规则表达了视图类之间的关系,如规定一个按钮总是处于它的父窗口的左边缘20个点。

Auto Layout中使用的实体是被称为constraintsObjective-C对象。

6)、Storyboards

串联图 是设计应用用户接口的推荐方式。串联图让你在一个地方就能够设计全部的用户接口,方便在一个位置看到所有的视图和视图控制器以及理解它们是如何一起工作的。串联图的一个重要的部分是定义segues(segues是从一个视图控制器到另一个的转换)。这些转换代表用户接口之间的交互。你可以使用XCOE来可视的定义这些转换或者通过编程启动它们。

 你能使用一个单串联图文件来存储所有的应用视图控制器和视图,或者使用多个视图串联图文件来组织用户接口。

在应用建立时间,Xcode读取串联图文件的内容并把它分成多个能独立加载的离散的片断,以便获得更好的性能。UIKit框架提供了相应的类来从程序中存取一个串联图的内容。

7)、UI State Preservation

UI状态保存能够使应用表现的一直运行,从而为用户提供无缝的体验。如果系统遇到内存压力,系统可能安静地强制停止一个或多个后台应用。

当应用从前台移到后台时,该服务能保存应用的视图和视图控制器的状态。在下次应用重新启动时,能够使用先前保存的状态信息来恢复视图和视图控制器到它们先前的配置,使应用表现得好像一直在运行。

8)、Apple Push Notification Service

苹果的推送通知服务提供了一种提示用户关于新信息的方式,即使应用当前不在激活运行状态。

使用该服务,你能推送文本通知,在应用图标上增加一个标记或者在任意时间触发声音提示。

这些消息让用户知道他们应该打开应用来接收相关信息。自Ios7开始,你甚至能推送无声的通知来让应用知道有了新的内容可以下载。

为了使用IOS应用的推送通知,用户需要做两部分的工作。首先应用必须登记该通知服务以及在通知被提交时处理相关的通知数据。第二,你必须提供一个服务端的进程来产生通知。

服务端的进程可以使用你自己的本地服务器或者使用苹果的推送通知服务。

9)、Local Notifications

本地通知作为推送通知机制的补充,可以给应用提供一种不依赖外部服务器产生本地通知的方式。

运行在后头的应用能使用本地通知作为当重要的事件发生时引起用户注意的一种方式。例如,运行在后台的导航应用能使用本地通知来提示用户什么时间该转弯了。

应用也能调度本地通知在将来的时间提交以及使那些通知在应用不运行也能被提交。

本地通知的一个优点是它们与你的应用是独立的。在一个通知已被调度,系统管理它的提交。另外当通知被提交时你的应用甚至不必运行。

10)、Gesture Recognizers

手势识别用来检测通常类型的手势。由于手势识别使用与系统检测手势相同的试探方法,因此手势识别为应用提供了一个一致的行为。为了使用它,你能在你的视图上附加手势识别功能和并给它提供一个在手势出现时要执行的方法。

手势识别跟踪原始的触摸事件和确定它们什么时候与想要的手势匹配。

11)、System View Controllers

许多系统框架为标准的系统接口定义了视图控制器。只要有可能,为了呈现一致的用户体验,就应该使用系统提供的视图控制器而不是创建一个新的。

2.2 Cocoa Touch层框架

CoCoa Touch层包含如下框架:

1、Address Book UI Framework(地址本UI框架)

该框架提供一个面向对象的编程接口。用来显示标准的系统接口,来创建新的联系人和编辑和选择已存在的联系人。

2、Event Kit UI Framework(月历事件UI框架)

该框架提供一个视图控制器来呈现标准的系统接口,来观察和编辑月历相关的事件。EventKit UI Framework基于Event Kit framework框架。

3、Game Kit Framework(游戏工具框架)

该框架实现对游戏中心的支持,让用户能够在线共享他们的游戏相关的信息。

4、iAd Framework(iAD框架)

该框架用来在应用中提供广告条。

当你想要显示广告时,广告条与用户UI上的标准的视图进行合并。

这些视图与苹果的iAd服务一起工作,自动处理、加载和呈现富媒体广告以及应答在那些广告条上的点击等所有相关的工作。

5、Map Kit Framework(地图工具框架)

MapKit提供与应用的UI组合的一个可滚动的地图。

除了显示一个地图,你能使用该框架接口来定制地图的内容和外观,也能使用注解来标记感兴趣的点,也能使用定制的内容来与地图内容叠置。例如,你可以在地图上来画一条公交路线,或者使用注解来高亮显示附近的商店和餐馆。

除了显示地图,MapKit框架还能与地图应用以及苹果的地图服务器集成来为用户指引方向。

地图应用能够给任意支持方向的应用提供方向的代理。如提供特定类型方向的应用,例如一个显示地铁路线的应用,能登记请求接收地图应用提供的方向。

应用也能向苹果的服务器请求步行或驾驶方向,并与他们定制的方向的路径信息混合来为用户提供完整的点到点体验。

6、Message UI Framework( 消息UI框架)

该框架用来在应用中提供编辑邮件和sms消息的支持。

编辑支持包括一个呈现到你的应用的视图控制器接口,并能设置这个视图控制器的一些区域,如接收人、主题、邮件主体和邮件想包括的任意附件。

在呈现视图控制器后,也能为用户提供一个在发送邮件之前可以编辑邮件的选项。

7、UIKit Framework

该框架提供实现图形和事件驱动的应用的至关重要的基础。包括:

1、基本的应用管理和基础设施,包括应用的主循环;

 

2、用户接口管理,包括对storyboards和nib文件的支持;

3、一个用来封装用户UI内容的视图控制器模式;

4、 标准系统视图和控制对象;

5、提供处理触摸和运动事件的支持;

6、支持包括与iCloud集成功能的文档模式;

7、 图形和窗口支持,包括支持外部显示器;

8、多任务支持;

9、打印支持;

10、 定制标准UIKit控制的外观;

11、支持文本和web内容;

12、剪切、复制、粘贴的支持;

13、支持动画UI;

14、通过url语义和框架接口与系统提供的其它应用集成的能力;

15、对有障碍用户的可存取性的支持;

16、支持ApplePush Notification服务;

17、本地通知调度和提交;

18、pdf 创建;

19、支持定制像系统键盘行为一样的用户输入视图;

20、支持创建与系统键盘交互的定制的文本视图;

21、支持通过email,Twitter, Facebook和其它服务共享内容。

也支持一些设备特定功能的集成,例如

1、内建的摄像机;

2、用户的图片库;

3、设备名和模式信息;

4、电池状态信息;

5、接近传感器信息;

6、来自附件耳机的远程控制信息

二、MediaLayer(媒体层)

媒体层包含在应用中实现多媒体体验的图形、声音、视频技术和框架。使用这层的技术可以使你容易的建立更加好看和好听的应用。

2.1 包含的关键技术

2.1.1 图形技术

高质量的图形是所有应用的重要的组成部分。IOS提供了许多帮助你定制艺术和图形屏幕的技术。IOS图形技术为其提供了广泛的支持,并可以与UIKit视图架构无缝工作。

你能使用标准的视图来快速提交高质量的接口,或者使用本层的图形技术创建你自己的定制视图来提交一个更加丰富的图形体验。

1)、UIKit graphics

UIKit定义的绘制图像和Bézier路径,以及动画视图内容的高级别技术。

UIKit视图提供快速和有效的方式来呈现图像和文本内容。

UIKIT视图也能通过显示和使用UIKitdynamics技术进行动画,并为用户提供反馈,促进用户交互。

 

2)、CoreGraphics 框架

 

CoreGraphics也称作Quartz,是对定制的2D向量和图像呈现提供支持的本地绘制引擎。

该框架提供的引擎虽然没有OpenGLES引擎速度快,但该框架能够很好地适合于呈现定制的2d图形和动态图像。

3)、CoreAnimation框架

CoreAnimation也是Quartz核心框架的一部分,是优化应用动画体验的基础技术。

UIKit视图基于 Core Animation提供视图级别的动画支持。

当你想对动画行为有更多控制时也能直接使用CoreAnimation。

4)、Core Image

CoreImage提供非破坏的方式操作视频和静态图像。

5)、OpenGL ES及GLKit

OpenGLES使用硬件加速接口来处理先进的2d 和3d 呈现。OpenGLES通常由游戏开发者或想实现沉浸式图像体验的开发者使用。

OpenGLES框架提供对呈现过程的全部控制,以及提供创建平滑动画所需要的帧速。

GLKit是一组Objective-C类,以便能够使用面向对象接口来提供OpenGL ES的强大能力。

6)、Text Kit和CoreText

Text Kit是UIKit框架的家族,用来来执行*好的排面和文本管理。如果你的应用实现先进的文本操作,Text Kit提供与应用视图的无缝集成。

CoreText是处理先进排面和布局的低级别的c语言框架。

7)、Image I/O

ImageI/O提供读写大多数图像格式的接口。

8)、Assets Library

AssetsLibrary框架让你存取用户的图片、视频和媒体。

你想在应用中集成用户自己的内容时可以使用该框架。

 

2.1.2 声音技术

声音技术工作于底层硬件之上,为用户提供更加丰富的声音体验。这些体验包括播放和记录高质量的声音、处理MIDI内容以及使用设备内建的声音 等能力,

1). Media Player framework

该框架是一个高级别的框架, 用来为用户提供对iTunes库存取的容易方式,也提供对播放轨迹和播放列表的支持。

当你想快速在应用中集成声音以及不需要控制播放行为时可以使用该框架。

2)、AV Foundation

AVFoundation是管理声音以及视频播放和记录的面向对象接口。

在记录声音和想对声音播放过程有更好的控制时可以使用该框架。

3)、OpenAL

OpenAL是一个提供位置音效的跨平台的工业标准技术和接口。

游戏开发者经常使用该技术来提供高质量的声音。

4)、Core Audio

Core Audio是一组简单和智能的接口来记录和播放声音以及MIDI内容。

在需要对声音有更好控制时使用该框架。

2.1.3  视频技术

视频技术提供管理应用中的静态视频内容或者播放来自Internet的视频流的支持。

对于带有适当的记录硬件的设备,该框架还能够记录视频以及与应用进行集成。

1).UIImagePickerController

UIImagePickerController是一个选择用户媒体文件的UIKit视图控制器。

2)、Media Player

MediaPlayer框架提供一组呈现视频内容的简单易用的接口,该框架支持全屏和小窗口视频播放,也为用户提供可选的播放控制。

3)、AVFoundation

AVFoundation提供先进的视频播放和记录能力。

在需要对视频呈现和记录有更多的控制时使用该框架,例如在实时应用中分层显示实时视频和应用提供的其它内容。

4)、CoreMedia

CoreMedia框架为操作媒体定义低级别的数据类型和接口。

当你需要对视频内容有无比的控制时可以使用该框架。

 

2.1.4  AirPlay技术

 

AirPlay让应用串流声音和视频内容到Apple TV或者串流声音内容到第三方扬声器和接收器。

AirPlay内建于许多框架,包括UIKit、Media Player、AVFoundation、Core Audio。因此在大多数情况你不需要为了支持它做任何事。在使用那些框架时,当播放内容时自动获得AirPlay支持。当用户选择使用AirPlay播放内容时系统自动进行路由。

2.2包含的框架

MediaLayer提供如下框架和服务。

2.2.1、Assets Library 框架

AssetsLibrary 框架(AssetsLibrary.framework)提供对用户设备上图片应用管理的图片和视频的存取。

使用该框架来存取用户保存的图片相册或导入到设备的任意相册中的图片,你也能保存新的图片和视频到用户的图片相册。

2.2.2、AV Foundation 框架

AVFoundation 框架 (AVFoundation.framework)提供一组播放、记录和管理声音和视频内容的Objective-C类。

当你想在应用的ui接口无缝集成媒体能力时使用该框架。

你也能使用它来进行更先进的媒体处理,例如同时播放多个声音或者控制播放和记录过程的多个方面。

该框架提供的服务包括:

1)声音会话管理,包括对系统声明你的应用声音能力;
2)对应用媒体资源的管理;
3)对编辑媒体内容的支持;
4)捕捉声音和视频的能力;
5)播放声音和视频的能力;
6)轨迹管理;
7)媒体元数据的管理;
8)立体拍摄;
9)声音之间的精确同步;
10)提供一个确定声音文件细节内容的Objective-C接口,例如数据格式,采样率,通道数;
11) 通过AirPlay串流内容。

     2.2.3、Core Audio 框架

Core Audio是一个对声音处理提供本地支持的框架家族。这些框架支持声音的产生、记录、混合和回放。你也能使用这些接口处理MIDI内容以及串流声音和MIDI内容到其它应用。

Core Audio框架包括如下框架:

CoreAudio.framework

定义Core Audio框架使用的所有数据类型。

AudioToolbox.framework

提供声音文件和声音流的播放和记录服务。也提供管理声音文件,播放系统警告声音,在某些设备上触发震动的支持。

AudioUnit.framework

提供使用内建声音单元。也提供使你的应用的声音内容作为对其它应用可视的声音组件的支持。

CoreMIDI.framework

提供与MIDI设备通讯的标准方式,包括硬件键盘和合成器。你使用这个框架来发送和接收MIDI消息以及与通过dock连接器或网络连接到IOS设备的MIDI外设交互。

MediaToolbox.framework

提供对声音tap接口的存取。

2.2.4、Core Graphics 框架

CoreGraphics.framework包含Quartz 2D绘制api。

Quartz是一个原先用在OS X的先进的、向量绘制引擎。Quartz支持路径绘制,抗锯齿呈现,剃度,图像,颜色,坐标空间转换以及pdf 内容创建、显示和分析等功能。

虽然这个api是C-based接口,但它使用了面向对象抽象来表现基本的绘制对象,因此使它容易存储和重用图形内容。

2.2.5、Core Image 框架

CoreImage 框架(CoreImage.framework)提供一组强大的内建过滤器来操作视频和静态图像。

你能在触摸弹起、纠正图片以及面部和特征检测等许多方面使用这些内建的过滤器。这些过滤器的先进特点是它们操作在非破坏方式,即原先的图像不被改变。

这些过滤器针对底层硬件进行了优化,因此它们是快速和有效的。

2.2.6、Core Text 框架

CoreText 框架 (CoreText.framework)提供一个对文本进行布局和字体处理的简单的、高性能的C-based接口。

该框架用在不使用TextKit但仍想获得在字处理应用中发现的先进文本处理能力。

该框架提供了一个智能的文本布局引擎,包括在其它内容周围环绕文本的能力,它也支持使用多种字体和呈现属性的先进的文本风格。

2.2.7、Core Video 框架

CoreVideo 框架 (CoreVideo.framework)为Core Media框架提供缓冲和缓冲池支持。多数应用从不直接使用该框架。

2.2.8、Game Controller 框架

GameController 框架 (GameController.framework)让你在应用中发现和配置针对iPhone/iPod/iPad设备的游戏控制器。

游戏控制器可以是物理连接到iOS设备或者是通过蓝牙无线连接。GameController框架当控制器可获得时通知你的应用让应用可以规定哪个控制器输入与你的应用相关。

2.2.9、GLKit 框架

GLKit框架 (GLKit.framework)包含一组简化创建OpenGLES应用的Objective-C based 单元类。

GLKit支持应用开发的四个关键领域

1)GLKViewGLKViewController类提供一个OpenGLES视图和其呈现循环的标准实现。

OpenGLES视图代表应用管理底层的framebuffer对象。应用只需在视图上绘制。
       2) GLKTextureLoader类提供在你的应用中使用图像转换和加载线程,允许应用自动加载纹理图像到应用的上下文。

  能够异步或同步加载纹理。当异步加载纹理时,应用应提供一个完成处理块,该处理块在纹理加载进应用上下文时被调用。
3)GLKit框架提供向量、矩阵和3d 旋转以及提供OpenGLES 1.1上的矩阵。

 4)GLKBaseEffect,GLKSkyboxEffect,和GLKReflectionMapEffect类实现给通用图形操作提供可配置的图形着色。尤其GLKBaseEffect类实现了OpenGL ES 1.1规范上的光亮和材质模式,简化了移植一个应用从OpenGL ES 1.1到OpenGL ES*后版本的努力。

2.2.10、Image I/O 框架

ImageI/O 框架(ImageIO.framework)提供输入和输出图像数据和图像元数据的接口。

该框架利用CoreGraphics数据类型和功能,并支持在ios 上所有的可获得的标准的图像类型。你能使用这个框架存取Exif和IPTC元数据属性。

2.2.11、Media Accessibility 框架

MediaAccessibility 框架 (MediaAccessibility.framework)管理媒体文件中closed-caption内容的呈现。

该框架与新的设置配合工作可以让用户决定是否允许closed-caption显示。

2.2.12、Media Player 框架

MediaPlayer 框架(MediaPlayer.framework)提供应用中播放声音和视频的高级别支持。能够使用该框架做如下工作:

1) 播放视频到用户屏幕或通过AirPlay到另外的设备屏幕。能够全屏幕播放视频或以可改变视图大小的方式播放。

2)存取用户的iTunes音乐库。能够播放音乐轨迹和播放列表、搜索音乐、给用户提供一个媒体picker呈现接口。

3)配置和管理电影的回放。

4) 在锁定屏幕和app 切换窗口上显示NowPlaying信息。当内容通过AirPlay提交时还能显示到AppleTV上。

5)检测视频通过AirPlay被串流的时间。

2.2.13、OpenAL 框架

OpenAudio Library (OpenAL)接口是用来在应用中提供位置音效的跨平台的标准。

能够使用该接口在游戏和其它需要位置音效输出的程序中实现高性能、高质量的声音。

因为OpenAL是跨平台的标准,在iOS使用OpenAL编写的代码能够容易地移植到许多其它平台。

2.2.14、OpenGL ES 框架

OpenGLES 框架 (OpenGLES.framework)提供绘制2d和3d内容的工具, 它是一个C-based的框架。

该框架以*接近设备硬件的方式为全屏沉浸式应用例如游戏提供细粒度的图形控制和高的帧率。

你能够与EAGL配合使用这个框架,为OpenGL ES 绘制调用和UIKit的本地窗口对象之间提供接口。

该框架支持OpenGLES 1.1, 2.0, 3.0规范。2.0规范增加了片段和顶点着色的支持,3.0规范增加了更多的功能,包括多个呈现目标和变换反馈。

2.2.15、Quartz Core 框架

QuartzCore 框架(QuartzCore.framework)包含Core Animation接口。

Core Animation是一个先进的复合技术,使用它能容易创建快和有效的view-based的动画。

复合引擎利用底层硬件来有效的实时操作视图内容。

只需规定动画的起始点,CoreAnimation做剩下的工作。

因为Core Animation内嵌在UIView架构的底层,因此它总是可用的。

2.2.16Sprite Kit 框架

SpriteKit 框架 (SpriteKit.framework)框架为2d和2.5d游戏提供硬件加速的动画系统。

SpriteKit提供大多数游戏需要的基础,包括一个图形引擎和动画系统,声音播放支持,一个物理仿真引擎。  使用SpriteKit不需你自己创建这些事情,使你聚焦在内容设计和内容的高级别的交互上。

在Sprite Kit应用中内容组织为场景。一个场景包括纹理对象,视频,路径图形,核心图像过滤器和其它的特效。SpriteKit利用这些对象,确定这些对象到屏幕上的*有效的方式。当在场景中到了动画内容的时刻,你能使用SpriteKit来显式规定你想执行的行动或使用物理仿真引擎来为那些对象定义物理行为(例如重力、引力或排拆力)。

除了SpriteKit框架,也有其它Xcode工具来创建颗粒发射效果和纹理图。你能使用Xcode工具来管理应用资源和快速地更新Sprite Kit场景。

 

三 CoreServices Layer(核心服务层)

CoreServices Layer包含应用需要的基础的系统服务。这些服务中的核心是CoreFoundation和Foundation框架,定义了所有应用使用的基本类型。

该层也包含独立的技术来支持一些其它功能, 例如位置、iCloud、社交媒体和网络。

3.1 包含的高级功能:

Peer-to-Peer Services(点到点服务)

这个Multipeer Connectivity框架提供通过蓝牙进行p2p连接的能力。

你能使用p2p连接来启动与附近设备的通讯会话。

虽然p2p连接主要用在游戏中,你也能在其它类型的应用中使用这个功能。

iCloud Storage(云存储)

iCloud存储让应用把用户文档和数据写到一个中心位置,用户然后能从他们的计算机和ios 设备存取这些数据。

使用iCloud可以使用户文档无所不在,意味着用户能从任何设备阅读或编辑那些文档,而不需要显式的同步或文件传输。存储文档到用户的iCloud账户也为用户提供了一层安全。即使用户的设备丢失,那些设备上的文档如果已经保存到iCloud就不会丢失。

应用能以两种方式使用 iCloud存储,每一种有不同的使用意图:

1) iCloud文档存储。

可以使用这个功能在用户的iCloud账户存储用户文档和数据。

2)iCloud键值存储。

使用这个功能在应用之间共享数据。

大多数应用使用iCloud文档存储来共享来自用户账户的文档。使用iCloud文档存储用户关心的是文档能否能够在设备之间共享以及他们是否能够从一个给定设备查看和管理那些文档。

相對的,iCloud键值存储是应用与应用的其它实例共享小量数据(几十k字节)的方式,应用应当用它存储非紧急的应用数据,例如设置。

Automatic Reference Counting(自动引用计数)

AutomaticReference Counting(ARC)是一个编译级别的功能,用它来简化Objective-C对象生命周期过程的管理,以此代替用户必须记住什么时候应该保持和释放对象。

ARC评估对象的生命周期需求和自动在编译时间插入适当的方法调用。

ARC用来代替ios 的早期版本中存在的传统的管理内存的编程模式。

新创建的工程自动使用ARC。XCODE也提供了移植工具帮助你转换遗留的工程来使用ARC.

Block Objects(块对象)

BlockObjects是一个能够与你的C或Objective-C代码集成的C语言的构造块。一个blockobject本质上是一个异步功能和相关的数据。在其它语言中有时也被称做closure或lambda。

Blocks尤其用作回调或放在你需要一种容易的组合执行代码和相关数据方式的地方。

在ios,通常在下面的场景使用Blocks:

1)作为代理或代理方法的代替;

2) 作为回调功能的代替;

3)为某个一次性操作实现其完成处理函数;

4)  在一个集合中的所有项上执行一个任务;

5)与提交队列一起执行异步任务。

Data Protection(数据保护)

DataProtection允许应用利用设备上已有的内建的加密方法来使用用户的敏感数据。

当应用指定一个特定的文件被保护时,系统在磁盘上以加密格式存储该文件。当设备锁定时,该文件的内容不能被应用和任何潜在的侵入者存取。可是当设备由用户解锁时,一个解密key被创建允许你的应用存取那个文件。

用户也可以使用其它级别的数据保护机制。

实现数据保护需要你考虑如何创建和管理你想保护的数据。应用必须设计在数据的创建时间加密数据,以及当用户锁定或解锁设备时为存取条件改变做好准备。

File-Sharing Support(文件共享支持)

File-SharingSupport使用户数据文件在iTunes 9.1和以后上可被其它应用获得。一个应用声明支持文件共享使它的/Documents目录下的内容对其它用户可获得。用户然后当需要时能够把文件从iTunes移进或移出应用的Documents目录。

这个特征不允许应用与相同设备上的其它应用共享应用,这需要粘贴板或一个文档交互控制器对象。

应用为了允许文件共享支持,需要做如下工作:

1、 在应用的Info.plist文件中增加UIFileSharingEnabled键,并设置其值为YES。

2)、在你的应用的Documents中放你想共享的文件;

3、当设备插进用户的计算机时,iTunes在选中设备的Apps标签下显式一个文件共享节;

4、用户然后能够增加文件到设备的文档目录或移动文件到桌面。

支持文件共享的应用应该能够识别文件什么时候增加到其Documents目录和做出适当的应答。例如应用可以使任意新文件的内容可以从它的接口获得。也应该从不把Documents目录的文件列表呈现给用户来请求用户决定对那些文件做什么。

Grand Central Dispatch

GrandCentral Dispatch(GCD)是一个BSD技术,应用可以用来管理其任务的执行。

GCD与高优化的核组合成一个异步编程模式,来提供方便和更有效的对线程的替代。GCD也为许多低级别的任务提供一个方便的选择,例如读和写文件描述符,实现定时器和监视信号和处理事件。

In-App Purchase(应用内购买)

In-App Purchase 提供在应用中销售应用特定的内容和服务以及来自iTunes的内容的能力。

这个功能使用StoreKit框架实现,并提供使用用户的iTunes账号来处理金融方面的事务需要的基础。

应用处理全部用户体验和供购买的内容及可获得服务的呈现。作为可下载的内容,你能把可下载的内容放到你自己的服务器或使用苹果的服务器。

SQLite

SQLite库让你在你的应用中嵌入一个轻量级的sql数据库,而不需要运行一个分离的远程数据库服务进程。从你的应用,你能创建本地数据库文件,管理数据库表和表中的数据记录。

SQLite库为通用功能使用设计,但已经被优化来提供对数据记录更快速的存取。

XML Support

Foundation框架提供一个NSXMLParser类用来从一个xml文档中引出元素。

操作xml内容的额外的支持由libxml2库提供支持。libxml2开源库让你快速地分析或写任意的xml数据和转换xml内容到html.

3.2 Core Services Frameworks(核心服务框架)

Core Services Frameworks包含下面的一些框架。

1)、Accounts Framework(帐户框架)

Accounts框架 (Accounts.framework)为确定的用户账号提供单点登录模式。

单点登录通过消除用户分离的多个账号需要的多次登录提示,来增强用户体验。它也通过为应用管理账号认证过程来简化开发模式。

该框架需要与Social框架配合使用。

2)Address Book Framework(地址本框架)

AddressBook 框架(AddressBook.framework)提供可编程存取用户的联系人数据库的方式。

如果应用使用联系人信息,你能使用该框架来存取和修改联系人信息。例如一个聊天应用可以使用该框架来引出可能的联系人列表,通过联系人列表来启动一个会话以及在特定视图显示那些联系人。

重要提示:存取用户的联系人数据需要用户的明确的许可。应用因此必须准备好用户拒*存取的情形。应用也鼓励提供Info.plist键来描述需要存取的原因。

3)Ad Support Framework(广告支持框架)

AdSupport 框架 (AdSupport.framework)提供存取应用用于广告功能的一个标识。

该框架也提供一个指示用户是否选择广告跟踪的标志。应用在试图存取广告标识前需要度和判断这个标志。

4)CFNetwork 框架

CFNetwork框架 (CFNetwork.framework)是高性能的使用面向对象对网络协议进行抽象的一组C-based接口。这些抽象提供对协议栈细节的控制,使它容易使用低级别的构造例如BSDsockets。

你能使用该框架简化与ftp或http服务器通讯或决定dnshosts的任务。使用CFNetwork 框架,你能:

1、使用BSD sockets。

2、使用SSL或TLS创建安全连接。

3、决定dnshosts。

4、与HTTP服务器、认证HTTP服务器、HTTPS服务器交互。

5、与FTP服务器交互。

6、发布、解决和浏览Bonjour服务。

               CFNetwork物理和理论上基于BSD sockets。

5)Core Data 框架

                CoreData 框架 (CoreData.framework)框架是管理MVC应用中的数据模式的一种技术。

        CoreData框架打算在数据模式是高结构化的应用中使用。

      代替编程定义数据结构,在xcode中能够使用图形工具来建立一个表现你的数据模式的纲要。在运行时,你的数据模式实体的实例通过CoreData框架被创建、管理和获得。

通过为你的应用管理其数据模式,CoreData大大减少了必须书写的代码量。CoreData也提供如下功能:

1、为优化性能在SQLite数据库中存储对象数据;

2、一个管理数据表视图结果的 NSFetchedResultsController类;

3、对基本的文本编辑之外的undo/redo的管理;

4、支持属性值的校验;

5、支持传播改变确保对象之间的关系保持一致性;

6、支持分组、过滤和在内存中优化数据。

如果你开始开发一个新应用或计划对已有应用进行大的更新,应该考虑使用CoreData。

6)Core Foundation 框架

CoreFoundation 框架 (CoreFoundation.framework)是一组C-based接口,为ios应用提供基本的数据管理和服务功能。该框架包括如下支持:

    1.   集合数据类型(数组、集合等等);
    2.   应用打包Bundles;
    3. 字符串管理;
    4. 日期和时间管理
    5. 原始数据块管理
    6. Preferences管理;
    7. URL和流操作;
    8. 线程

   9、端口和socket通讯。

      CoreFoundation框架与Foundation框架紧密相关,为相同的基本功能提供Objective-C接口。

当你需要混合使用Foundation对象和Core Foundation类型时,你能利用两个框架之间存在的“toll-freebridging”。toll-free bridging”意味着你能可交换地在两个框架的方法和功能中使用一些CoreFoundation和Foundation类型。这个支持对许多数据类型可用,包括集合和字符串数据类型。

每个框架的类和类型描述声明一个对象是否是toll-freebridged以及在是的情况下来标识它连接到什么对象。

7)Core Location 核心位置框架

CoreLocation 框架  (CoreLocation.framework)为应用提供位置信息。该框架使用板上的GPS、蜂窝、或者Wi-Fi来定位用户的当前经度和纬度。

你可在你的应用中集成该技术为用户提供位置信息。例如,你可实现一个基于用户的当前位置搜索附近餐馆、商店或者银行的应用。CoreLocation框架也提供如下能力:

1) 在包括磁力计的ios设备上存取罗盘信息;

2) 基于地理位置或蓝牙beacon进行区域监视;

3) 支持使用蜂窝基站的低耗电的位置监视;

4)与MapKit配合来增强在特定情景下的位置数据的质量,例如开车时。

8)Core Media Framework(核心媒体框架)

CoreMedia 框架(CoreMedia.framework)提供由AV Foundation框架使用的低级别的媒体类型。大多数应用从不需要使用该框架,但少数需要更精确控制音视频内容创建和呈现的开发者可以使用它。

9)Core Motion Framework (核心运动框架)

CoreMotion 框架 (CoreMotion.framework)提供一组接口来存取设备上可获得的运动数据。

该框架支持使用一组新的block-based接口来存取原始和加工过的加速度计数据。对于带有陀螺仪的设备,你也能获得原始的陀螺仪数据和加工过的反应设备方向和旋转速度的数据。

你能在游戏或其它使用运动作为输入或作为增强用户体验的方式的应用中使用加速度计和陀螺仪两种数据。对于带有计步硬件的设备,你能存取它的数据来跟踪健康相关的运动。

10)Core Telephony Framework(核心电话框架)

CoreTelephony 框架 (CoreTelephony.framework)提供与蜂窝电话的通话相关的信息交互的接口。

可以使用该框架来获得用户的蜂窝服务提供者的信息。对于对蜂窝call事件感兴趣的应用例如VoIP应用也能在那些事件出现时被通知。

11)Event Kit 框架

EventKit 框架 (EventKit.framework)提供存取用户设备上的月历事件的接口。能够使用该框架来做如下事情:

1) 获得用户月历上存在的事件和提示;

2)增加事件到用户月历;

3)为用户创建提示和使它们出现在提示应用中;

4)为月历事件配置提示信号,包括设置提示信号应该什么时候触发的规则。

重要提示:存取用户的月历和提示数据需要用户的明确许可。应用因此必须准备好用户拒*的情形,也鼓励应用在其Info.plist文件中提供一个描述需要存取原因的键。

12)Foundation框架

Foundation框架 (Foundation.framework)提供Core Foundation框架提供的许多功能的Objective-C封装。该框架提供如下功能的支持:

      1.   集合数据类型(数组、集合等等);
      2.   应用打包Bundles;
      3. 字符串管理;
      4. 日期和时间管理
      5. 原始数据块管理
      6. Preferences管理;
      7. URL和流操作;
      8. 线程和运行环;
      9. Bonjour;
      10.  通讯端口管理;
      11.  国际化;
      12. 规则表达式匹配;
      13. Cache支持。

13)JavaScript  核心 框架

JavaScriptCore 框架 (JavaScriptCore.framework)为许多标准的JavaScript对象提供Objective-C语言的封装。使用该框架来执行JavaScript代码和分析JSON数据。

14)Mobile Core Services (移动核心服务框架)

MobileCore Services 框架(MobileCoreServices.framework)定义在通用类型标识符(UTIs)中使用的低级别类型。

15)Multipeer Connectivity Framework(多方连接框架)

MultipeerConnectivity 框架 (MultipeerConnectivity.framework)支持附近设备的发现,并与那些设备直接通讯(不需要Internet连接)。

使用该框架能够与附近设备通讯、容易的创建多人会话、支持可靠地传输顺序和实时数据。

该框架为发现和管理网络服务提供可编程和UI-based的选项。应用能在ui中集成MCBrowserViewController类来显示一个发现设备列表让用户选择。另外也能使用MCNearbyServiceBrowser类来可编程的查找和管理对方设备。

16)Newsstand Kit 框架

Newsstand应用为用户提供了一个阅读杂志和报纸的中心位置。想通过Newsstand提供杂志和报纸内容的出版商能够使用NewsstandKit 框架(NewsstandKit.framework)创建它们自己的iOS应用,让用户启动新杂志和报纸新闻的后台下载。在启动下载后,系统处理下载操作和当内容可获得时通知应用。

17)Pass Kit 框架

Passbook应用为用户提供了一个存储订货单、登机卡、入场券和商业折扣卡的位置。代替物理携带这些东西,用户现在能在IOS设备上存储它们,并和过去一样的方式使用。

Pass Kit 框架 (PassKit.framework)提供把这些功能集成到你的应用的Objective-C接口。

你能与web接口和文件格式信息组合使用该框架来创建和管理你们公司提供的电子入场券。

电子入场券由你们公司的web service创建并通过email、Safari或定制的应用提交到用户的设备。电子入场券本身使用特殊的文件格式,在提交之前被加密签名。文件格式标识关于提供服务的相关信息以及用户知道是什么服务的信息。

电子入场券也可以包含一个对卡进行校验的条码或其它信息,以便它能被兑换或使用。

18)Quick Look 框架

QuickLook 框架(QuickLook.framework)提供了一个预览应用不直接支持的文件内容的接口。

该框架主要打算用于应用从网络下载文件或处理来自不知道来源的文件的工作。

在得到文件后,你能使用该框架提供的视图控制器来直接显示文件的内容。

19)Safari Services 框架

SafariServices 框架 (SafariServices.framework)提供以可编程的方式增加URLs到用户的Safari的书签的支持。

20)Social Framework(社交框架)

Social框架(Social.framework)提供一个简单的接口来存取用户的社交媒体账号。

该框架取代Twitter框架并增加了其它社交账号,包括Facebook、Sina微博以及其它。

应用能使用该框架提交状态更新和图像到用户账号。该框架与Accounts框架一起为用户提供单点登录并确保存取的用户账号是经过准许的。

21)Store Kit 框架

StoreKit 框架 (StoreKit.framework)提供在ios应用中购买内容和服务的支持,也被称作应用内购买。

例如,你能使用该功能来允许用户去锁另外的应用功能。或者如果你是一名游戏开发者,你能使用它来提供另外的游戏级别。在这两种情况,StoreKit框架处理事务的收入方面事务,包括通过用户的iTunes账号处理付费请求,给应用提供关于购买的信息。

Store Kit聚集在事务的金融方面,确保事务正确和安全。你的应用处理事务的其它方面,包括购买接口的呈现和适当内容的下载(去锁)。

工作的分工让你能够控制购买内容的用户体验。由你决定你想呈现给用户什么样的购买接口和什么时候那样做,你也决定你的应用*好的提交机制。

22)System Configuration Framework(系统配置框架)

SystemConfiguration 框架(SystemConfiguration.framework)提供可达性接口,你能用它来确定设备的网络配置,也能使用该框架确定一个Wi-Fi或蜂窝连接是否在用以及一个特定的主机服务器是否能够存取。

四   Core OS Layer(核心OS层)

        CoreOS层包含其它大多数技术建在其之上的低级别的功能。虽然应用不直接使用这些技术,它们被其它框架使用。在需要显而易见的处理安全或与外设通讯的情形,你也能使用该层提供的框架。

4.1  Core OS包含的框架:

1)Accelerate 加速框架

Accelerate框架 (Accelerate.framework)包含执行数字信号处理、线性代数、图像处理计算的接口。

使用该框架的优点是它们针对所有的ios设备上存在的硬件配置做了优化,因此你能写一次代码确保在所有设备上有效运行。

2)Core Bluetooth Framework(核心蓝牙框架)

CoreBluetooth 框架 (CoreBluetooth.framework)允许开发者与蓝牙低耗电外设(LE)交互。

使用该框架的Objective-C接口能够完成如下工作:

1、扫描蓝牙外设,连接和断开发现的蓝牙外设;

2、声明应用的服务,转换ios 设备成其它蓝牙设备的外设;

3、 从IOS设备广播iBeacon信息;

4、保存你的蓝牙连接的状态,当应用重新启动时恢复那些连接;

5、蓝牙外设可获得性变化时获得通知。

3)External Accessory Framework(外部附件框架)

ExternalAccessory 框架(ExternalAccessory.framework)提供与连接到IOS设备的硬件附件通讯的支持。

附件能通过30-pin连接器或使用蓝牙无线与IOS设备进行连接。该框架给你提供了获得关于每一个可获得的附件信息和启动通讯会话的方式。然后,你可自由的使用附件支持的命令直接操作附件。

4)Generic Security Services Framework(通用安全服务框架)

GenericSecurity Services 框架 (GSS.framework)给ios应用提供一组标准安全相关的服务。该框架的基本接口规定在IETFRFC2743 andRFC4401。除了提供标准的接口,IOS还包括一些没有在标准中规定但被许多应用需要的一些管理证书需要的额外东西。

5)Security Framework(安全框架)

除了内建的安全功能,IOS也提供了一个明确的安全框架(Security.framework),你能用它来保证应用管理的数据的安全。

该框架提供管理证书、公有和私有key和信任策略的接口。支持产生加密安全伪随机码。它也支持在keychain(保存敏感用户数据的安全仓库)中保存证书和加密key。

公共加密库提供对称加密、hash认证编码(HMACs)、数字签名等额外支持,数字签名功能本质上与iOS上没有的OpenSSL库兼容。

在你创建的多个应用之间共享keychain是可能的。共享使它容易在相同的一套应用之间更平滑的协作。例如,你能使用该功能来共享用户口令或其它元素,否则可能使每个应用都需要提示用户。

为了在应用之间共享数据,必须为每个应用的Xcode工程配置适当的权限。

6)System

System级包含kernel环境、驱动以及操作系统级别的unix接口。kernel本身负责操作系统的每一个方面:如虚拟内存管理、线程、文件系统、网络和互联通信。在该层的驱动也提供在可获得的硬件与系统框架之间的接口。为了安全,对kernel和驱动的存取被限制到一组有限的系统框架和应用。

IOS提供一组存取许多操作系统低级别功能的接口。应用通过LibSystem库存取这些功能。该C based的接口提供如下功能的支持:

1) 多任务(POSIX线程和GCD)

2) 网络(BSDsockets)

3) 文件系统存取

4) 标准I/O

5) Bonjour和DNS服务

6)  位置信息

7)  内存分配

8) 数学计算

7) 64-Bit Support

IOS原先是为32-bit架构的设备设计的。自iOS 7,开始支持在64-bit进行编译、链接和调试。所有的系统库和框架是支持64位的,意味着它们能在32-bit和64-bit应用中使用。当以64-bit运行时编译时,应用可能运行的更快,因为在64-bit模式可以获得额外的处理器资源。

iOS使用OS X和其它64-bitUNIX系统使用的LP64模式,意味着在这些系统移植时不会碰到太头疼的事。

与ios相比,android为什么越用越卡

这是大家的普遍体验:android用着用着就很卡,而且经常要许多不必要的清理操作

四大因素决定 浅析iOS为什么比安卓流畅

当别人问苹果手机问什么比Android手机运行流畅,自己也回答不出来个所以然,所以就搜集了这个文章,分析的还是很专业的,特来和大家分享。同时也对文章中的不足做了补充。

优先级别不同:iOS*先响应屏幕

不少人都反应苹果iPhone要 比一般Android手机流畅,这是一个现象要说是大问题谈不上,毕竟两者是完全两个不同的系统所以严格来说放在一起对比是不公平的。不过因为 Android以及iOS是当下两大主流操作系统,对比抗衡之类的说法自然难以避免。今天我们就来谈谈为什么iOS产品在使用过程中会让人觉得更加流畅一 些,而为何一些Android手机则容易出现卡顿延迟的情况。

  当我们使用iOS或者是Android手机时,*步就是滑屏解锁找到相应程序点击进入。而这个时候往往是所有操控开始的*步骤,iOS系统 产品就表现出来了流畅的一面,但Android产品却给人一种卡顿的现象,更别说后续深入玩游戏或者进行其它操控了。这是为什么?

其实这与两个系统的优先级有关,iOS对屏幕反应的优先级是*高的,它的响应顺序依次为TouchMediaServiceCore架构,换句话说当用户只要触摸接触了屏幕之后,系统就会*优先去处理屏幕显示也就是Touch这 个层级,然后才是媒体(Media),服务(Service)以及Core架构。而Android系统的优先级响应层级则是 ApplicationFrameworkLibraryKernal架构,和显示相关的图形图像处理这一部分属于Library,你可以看到到第三位才 是它,当你触摸屏幕之后Android系统首先会激活应用,框架然后才是屏幕*后是核心架构。

iOS系统优先处理Touch层级(图片来自网络)
%title插图%num
Android 系统架构(来自网络)

  可以看到优先级的不同导致了iOS产品以及Android手机在操控过程中的表现差异,当你滑动屏幕进行操控的时候,iOS系统会优先处理 Touch层级,而Android系统则是第三个才响应Library层级,这是造成它们流畅度不同的因素之一。不过优先级对系统流畅性有有影响不假,但 并不是**对的,造成两系统之间流畅性不一的现象还有其它因素,我们可以接着往下看。

硬件工作配置不同:iOS基于GPU加速

目前智能手机硬件装备竞赛当中,其实处理器等配置已经达到了一个瓶颈期,各大旗舰产品在硬件比拼当中基本上没有太大的区别,而这时候GPU就成 为了一个凸显差异的重要因素。一些大型软件像是3D游戏对GPU性能要求都会比较高,苹果iPhone产品采用的Power VR SGX系列GPU在当下来说非常的主流,跑分测试数据证明了它并不会比一些旗舰级别的Android产品差劲。

A6处理器集成了Power VR SGX543显示芯片(图片来自网络)

  而iOS系统对图形的各种特效处理基本上正好都是基于GPU硬件进行加速的,它可以不用完全借助CPU或者程序本身,而是通过GPU进行渲染以 达到更流畅的操控表现。但是Android系统产品则并非如此,因为Android需要适应不同的手机硬件,需要满足各种差异配置,所以很多图形特效大多 都要靠程序本身进行加速和渲染,并严重依赖CPU运算的操作自然会加大处理器的负荷,从而出现卡顿的问题。虽然Android 4.0以及4.1等更高版本中进行了改进将硬件加速设为默认开启,但依旧无法做到所有特效全部都靠GPU进行加速。在很多Android手机里面都自带有 “是否开启GPU渲染”这个功能选项,不过开启之后的改善也是微乎其微。

iOS图形特效基于GPU加速渲染

  屏幕*先响应的优先级关系,再加上iSO本身GPU加速程序的特性,使得大家在操控过程中感觉iOS手机拥有着不错的流畅性。因为它本身的整个 流程都是在为*大化的流畅做服务,不管是*印象的滑动接触屏幕,还是你进一步使用程序之后的更深层操作都是如此。而GPU加速这点特性,应该是它优于 Android系统流畅性的又一个因素。

开发机制不同:安卓机制效率低

Android的编程语言是JAVA,而iOS的则为Objective-C,不过要是说Android系统之所以有些卡顿是因为JAVA开发 语言的关系,或者是拿它和Objective-C对比肯定会有人提出质疑。Objective-C的优势是效率高但比较“唯一”,而JAVA的优势则是跨 平台不过运行效率相对偏低,其实这两个编程语言所带来的机制不同,就已经造成了各自系统之间的流畅性差异化。

Android系统架构(图片来自网络)

  iOS的Objective-C,编译器gcc,而这个gcc编译出来的代码又被苹果专为iOS架构优化到了*致,运行过程中也不需要虚拟机在 中间插手,执行效率自然很高引自网络。这一段话应该是iOS系统本身运行程序的执行过程,而Android是通过JAVA虚拟机来执行,并且系统需要占用 大量内存来换取执行速度,再加上不定期的内存自动回收机制,从而直接导致了卡顿现象的出现。

iOS系统架构有着不错的运行效率

  Android的JAVA编程本身运行效率比Objective-C低一些,而且再加上内存自动回收的机制,所以造成了一些卡顿不流畅的现象出现。但根据技术人员讲解,现代的 JAVA虚拟机效率已经不再是*大的瓶颈,Android 4.0系统版本之后的卡顿现象明显得到了改善,所以这也是有用户并没有发现自己新买的Android手机出现太多卡顿现象的原因。看来编程语言和机制已经 被Android进行了改善,这同样也不是造成它与iOS流畅性偏差的唯一因素,不过影响却是实实在在存在着。

应用程序:安卓APP无法统一

有了优先级的关系,有了GPU加加速的影响,还有两个系统各自编程以及机制的问题,似乎已经可以说明为什么iOS相比Android更为流畅的 原因。但*终还有一个问题是就是应用程序,很显然用户觉得卡顿都是在运行软件的过程中产生,毕竟没有安装任何应用的初始出厂手机基本上都不存在不流畅或者 延迟等现象,而且一款智能手机不安装任何应用程序那也不符合用户的购买初衷和使用行为。所以归根结底,Android相比iOS的应用程序,到底出了什么 问题?

App Store是苹果和iOS的另一个标志

  因为iOS产品的封闭性,所以所有的APP运行对象都比较单一,因为每个应用程序都是被运行在iPhone,iPad等iOS产品当中,它们有 着很高的硬件利用效率。因为iOS系统的配件供应商只有那么几家,CPU也是一年换一次,这点不像Android终端年年变月月变,开发者很难遇见未来终 端分辨率会包含多少种,GPU驱动会包含哪些等等,所以相对来说Android应用开发成本较高且收益较慢。而iOS应用开发则因为软硬件垂直整合而受 益,这样一来苹果自然就保证了应用本身其与硬件产品之间的完美结合程度。

其实Android和iOS两大系统APP开发情况的不同,也正是它们开发和不开放的特性所造成的。如果要是拿旗舰Android手机加上一个 专为这款旗舰产品设计的游戏,来和苹果iPhone 5运行对比的话,你真的不会遇到Android旗舰机出现卡顿延迟的问题,为什么因为这款游戏针对这款手机设计,在软硬等方面都达到了*大化的兼容和优 化,自然就不会出现停滞的现象。

Android App虽然奋力追赶在但数量和质量上并未超越iOS

 

而Android系统程序要被安装在各种符合要求的手机上面,开发者也不可能针对所有的机器型号进行开发,只能在比较主流的机器上进行测试并保证运行效 果,所以他们为了兼顾整个产品线只能不得不降低游戏体验以达到高中低产品可以共用的效果。*后那些占据了Android终端份额的大量大众用户们由于自己 的手机不是旗舰产品而得不到流畅的使用体验,自然而然就会产生Android产品不如iOS流畅的抱怨。

写在*后:

不管是iOS产品感觉比Android流畅还是真的比它流畅,其实说到底原因很简单。苹果会花费一年甚至两年的时间去开发一个桌面icon,一 种字体,并去测试屏幕点位,而Android终端中除了Nexus系列之外似乎没有太多产品可以做到用这么长的时间去做这么细致的事情。有网友说得 好,Android做的更多的是“让系统跑起来”,而iOS拥有着苹果做的更多的则是“让系统以*高的效率跑起来”,或许这就是iOS产品比 Android更流畅的原因吧。但更好的一面的是随着谷歌对Android的持续升级以及各厂商对自家产品的循序改进,使得越来越多的Android终端 正在摆脱卡顿不流畅的束缚,未来安卓用户的期待同样有望得到更好的满足。

iOS多任务(iPad分屏模式)

首先,拿苹果官方的图来说说

%title插图%num
苹果将这个功能称作iPad多任务

使用前准备.
要将你iPad的旋转方向设置为全部支持.

%title插图%num
使用LaunchScreen.storyboard而不是LaunchImage.

%title插图%num
有人可能会问,如果我仅仅想支持全部旋转方向而不想支持多任务怎么办呢.我们可以通过在info.plist文件中添加一个UIRequiresFullScreen(PS:这个键值在info.plist里头找不到)的Boolean类型的键,设置为YES的时候就不会有拆分行为.设置为NO的时候就能拆分.

如何检测当前App是否支持多任务:

// readonly
let multitaskingSupported = UIDevice.current.isMultitaskingSupported;
%title插图%num

各个拆分形式对应的尺寸:

%title插图%num

如何在屏幕发生改变(也就是拆分视图大小发生改变)的时候动态改变布局呢.
1.按照自动布局指南、Size Classes(主要作用是不同屏幕适配)、模拟屏幕大小和方向.
2.LaunchScreen.storyboard必须采用自动布局.
3.通过实现UITraitEnvironment和UIContentContainer协议中的方法来响应特征收集和大小更改.
4.响应应用程序状态转换委托方法调用,如iOS应用程序编程指南中的应用程序执行状态中所述.

iOS系统的特点-iOS为什么运行更流畅

1、进程管理机制-不允许后台进程;

2、用户事件响应优先级;

3、GPU加速;

4、系统内存管理机制;

5、运行机制-机器码直接运行-非虚拟机。

了解iOS各个版本新特性总结

iOS7新特性

· 在iOS7当中,使用麦克风也需要取得用户同意了。如果用户不允许app使用麦克风的话,那么需要使用麦克风的app就不能接收不到任何声音

· [NSArray firstObject]的实现,iOS4之前只是一个私有的方法

· UIImage.renderingMode着色(Tint Color),可以设置一个UIImage在渲染时是否使用当前视图的Tint Color。

· UIScreenEdgePanGestureRecognizer可以从屏幕边界即可检测手势

· 使用Core Image来检测眨眼以及微笑iOS给Core Image增加了两种人脸检测功能:CIDetectorEyeBlink以及CIDetectorSmile。这也就是说你现在可以在照片中检测微笑以及眨眼。

 

iOS8新特性

· 当使用iOS8定位的时候需要请求用户授权,且在info.plist里添加字段NSLocationAlwaysUsageDescription 请求用户授权的描述

· size classes是为了解决storyboard只能订制一种屏幕样式的问题,它不再是具体的尺寸,而是抽象尺寸通过宽/高 的compact、any、regular 组成了九种组合包含了所有苹果设备的尺寸。

· iOS8中,字体是Helvetica,中文的字体有点类似于“华文细黑”。只是苹果手机自带渲染,所以看上去可能比普通的华文细黑要美观。iOS9中,中文系统字体变为了专为中国设计的“苹方” 有点类似于一种word字体“幼圆”。字体有轻微的加粗效果,并且*关键的是字体间隙变大了!

 

iOS9新特性

· iOS9系统发送的网络请求将统一使用HTTPs,将不再默认使用HTTP等不安全的网络协议,而默认采用TLS 1.2。服务器因此需要更新,以解析相关数据。如不更新,可通过在 info.plist 中声明,倒退回不安全的网络请求。

· 将允许出现这种场景:同一app中多个location manager:一些只能在前台定位,另一些可在后台定位

· bitcode的理解应该是把程序编译成的一种过渡代码,然后苹果再把这个过渡代码编译成可执行的程序。bitcode也允许苹果在后期重新优化我们程序的二进制文件,有类似于App瘦身的思想。

· stackView

· Multasking:多任务特性,三种形式

· 临时调出的滑动覆盖:Slide Over

视频播放的画中画模式(Picture in Picture)(AVPlayerViewController默认支持。MPMoviePlayerViewController被deprecated掉了,不支持)
iPad真正同时使用两个App

· UI Test:iOS9.0之前加入异步代码测设和性能测试,可以说Xcode自带的测试框架已经能满足*大部分单元测试的需求了,但是这并不够,因为开发一个iOS app从来都是很注重UI和用户体验的,之前UI测试使用KIF,Automating,iOS9.0的Xcode给出了自带的XCUITest的一系列工具,和大多数UI测试工具类似,XCUI使用Accessbility标记来确定view,但因为是Apple自家的东西,可以自动记录操作流程,所以只要书写*后的验证部分就好了,比其他UI测试工具方便多了

· Swift2

· APP Thinning:app为了后向兼容,都同时包含了32bit和64bit,在图片资源2X和3X的一应俱全,下载的时候只需要当前机型对应的一套资源,但是却要全部打包下载,现在只需要升级iOS9,就可以省很多流量

· 3D touch

· 地图显示实时的交通状况

· 人工智能siri更加智能,几个大城市的地铁及火车站入口都有详细的标识

· 手机电池的低功耗设置

· Spootlight,你的设备会向推荐*近通话过的联系人,使用过的APP以及你可能感兴趣的去处、信息呈现更精彩

 

 

iOS10新特性

· SiriKit 在 iOS 10 里面开发者可以使用 Siri SDK,这可能是 iOS 10 *重要的新 SDK之一。从此开发者可以使用原生API提供语音搜索、语音转文字消息甚至更多常见语音功能。

· Proactive Suggestions 貌似是一个和 CoreSpotlight 有整合的使用建议的东西。

· Message App Extension 在 iOS 10 里面开发者可以给 Message.app 提供两种 App Extension,分别是可以提供一个表情包,和一个自定义的界面,用于表情搜索等。

· User Notifications 这个 API 让你可以处理本地或远程的用户通知,并且可以基于某个条件,例如时间或者地理位置。这个异常强大,好像可以在通知里包含图片和视频了,貌似可以拦截并替换自己 app 发下来的 payload。

· Speech Recognition 见闻知意,语音识别 API,可以把音频流实时的转换为文本。虽说早期版本已经有了TTS语音转文字,但毕竟Siri语义识别的加入让机器对自然语义的把握更精准,详见Speech.framework

· App Search Enhancements 对 CoreSpotlight 的增强,其中我比较感兴趣的是 Visualization of validation results。

· Widget Enhancements 为了配合 iOS 10 锁屏下面 Widget 的体验,苹果提供了 widgetPrimaryVibrancyEffect 和 widgetSecondaryVibrancyEffect 用于定制化 Widget 的界面。

· CallKit callkit框架 VoIP应用程序集成与iPhone的通话界面,给用户一个很棒的体验,锁屏后VoIP网络电话可以直接用iPhone系统UI接听了。

· App Extensions 其实上面也有提到,iOS 10*重要的开发特点就是允许第三方应用对自带基础app的拓展关联, 全新 7 种 App Extension:
Call Directory(VoIP回调)

Intents(接Siri、Apple map等服务)

Intents UI(接Siri、Apple map等服务的自定义界面)

Messages(iMessage拓展)

Notification Content(内容通知)

Notification Service (服务通知)

StickerPack(iMessage表情包)

· Custom Keyboard 对第三方键盘的改进 通过 handleInputModeListFromView:withEvent: 可以弹出系统键盘列表。同时使用 documentInputMode 可以检测输入上下文中的语言,你可以对输入方式进行一些类似于对齐方式的调整。

另外需要注意的是,和以往历代iOS版本推出一样,新陈代谢,有新SDK、新API的开放,也会有旧的API被遗弃,所以好好检查你的项目,使用了被遗弃的API要尽快修改,以免不兼容!还有个要注意的问题 iOS10 对隐私权限的管理更为严格 ,比如访问的摄像头、麦克风等硬件,都需要提前请求应用权限、允许后才可以使用,或者现在要提前声明,虽然以往要求不严格

ios系统的特点

iOS优势

1). 比较稳定,因为他是一个完全封闭的系统,不开源,但是这个系统有他自己严格管理体系,比如app store的app应用;他有自己的评审规则,另外很多软件是需要收费的,这在一定程度上也说明它平台系统的缜密性。但是安卓呢,安卓是一个开源并且免费得软件,但是,这个系统本身安全性不高,并且平台系统散乱,形成了一个系统多个硬件的情况,但是由于    系统开源,造成了软件免费,盗版猖狂的情况,但是,安卓发布ics后,或许我们会看到一个整合过的优秀的开源手机平台

另外,由于Android系统采用了虚拟机的运行机制,这就需要消耗更多的系统资源了运行App,即便升级到Android 4.X,甚至Android 5.X,系统流畅性还是不如iOS。

2). 安全性:沙盒机制:保护用户数据,实现不同程序之间的隔离。程序安装后,系统会通过计算得到唯一的id,用这个id表示程序安装路径。该程序只能访问自己沙盒内的文件和应用。对于用户来说,保障移动设备的信息安全具有十分重要的意义,不管这些信息是企业和客户信息、或者是个人照片、银行信息或者地址等,都必须保证其安全。苹果 对iOS生态采取了封闭的措施,并建立了完整的开发者认证和应用审核机制,因而恶意程序基本上没有登台亮相的机会。iOS设备使用严格的安全技术和功能, 并且使用起来十分方便。iOS设备上的许多安全功能都是默认的,无需对其进行大量的设置,而且某些关键性功能,比如设备加密,则是不允许配置的,这样用户 就不会意外关闭这项功能。

3). 软件与硬件整合度高. iOS系统的软件与硬件的整合度相当高,使其分化大大降低,在这方面要远胜于碎片化严重的Android。这样也增加了整个系统的稳定性,经常使用iPhone的朋友也能发现,手机很少出现死机、无响应的情况。

4). 界面美观、易操作

苹果在界面设计上投入了很多精力,无论是从从外观性还是到易用性,iOS都致力于为使用者提供*直观的用户体验。iOS系统给人的*感觉就是简洁、美观、有气质,并且操作简单,用户上手很快,用起来有种手到擒来、行云流水的感觉。

5). 应用数量多、品质高iOS所拥有的应用程序是所有移动操作系统中*多的,iOS平台拥有数量庞大的app和第三方开发者,几乎每类app都有数千款,并且优质应用*多,这是其他移动操作系统

6). .虚拟内存机制

*iOS和Mac OS都具有内存机制,每个进程都拥有自己的虚拟地址空间,IOS不能使用页面文件扩展进程的地址空间。系统内存不足时,会发送给应用程序一条消息,应用程序受到后释放自己地址空间的空闲内存。

7). 有统一要求的垃圾处理机制,不会越用越慢,也不需要额外装垃圾处理软件来拖慢系统。

 

iOS劣势:

1.封闭性带来的问题是无法比拟的。

由于iOS系统的封闭性,所以无法像Android这样的开源系统一样任由用户更改系统的设置,因此系统可玩性就相对弱一些。一些高手级的用户可以通过越狱安装一些插件来增加可玩性,不过对于大部分小白用户来说,越狱还是有一定难度的。

2.过度依赖iTunes

苹果的大部分数据导入导出,例如歌曲以及电影的下载等都需要通过电脑来配合操作才能完成,可以说离不开电脑和iTunes软件的帮助,所以会让很多用户觉得操作起来相对繁琐。

3.让人蛋疼的输入法

iOS自带的输入法一直是令国内用户很蛋疼的一点,主要是它不支持9宫格输入,只有全键盘和手写两种模式,这就和中国消费者的使用习惯有一定的出入,并且输入法这种系统层级的应用无法通过安装软件来更改,因此很多人就选择了越狱这条路。

友情链接: SITEMAP | 旋风加速器官网 | 旋风软件中心 | textarea | 黑洞加速器 | jiaohess | 老王加速器 | 烧饼哥加速器 | 小蓝鸟 | tiktok加速器 | 旋风加速度器 | 旋风加速 | quickq加速器 | 飞驰加速器 | 飞鸟加速器 | 狗急加速器 | hammer加速器 | trafficace | 原子加速器 | 葫芦加速器 | 麦旋风 | 油管加速器 | anycastly | INS加速器 | INS加速器免费版 | 免费vqn加速外网 | 旋风加速器 | 快橙加速器 | 啊哈加速器 | 迷雾通 | 优途加速器 | 海外播 | 坚果加速器 | 海外vqn加速 | 蘑菇加速器 | 毛豆加速器 | 接码平台 | 接码S | 西柚加速器 | 快柠檬加速器 | 黑洞加速 | falemon | 快橙加速器 | anycast加速器 | ibaidu | moneytreeblog | 坚果加速器 | 派币加速器 | 飞鸟加速器 | 毛豆APP | PIKPAK | 安卓vqn免费 | 一元机场加速器 | 一元机场 | 老王加速器 | 黑洞加速器 | 白石山 | 小牛加速器 | 黑洞加速 | 迷雾通官网 | 迷雾通 | 迷雾通加速器 | 十大免费加速神器 | 猎豹加速器 | 蚂蚁加速器 | 坚果加速器 | 黑洞加速 | 银河加速器 | 猎豹加速器 | 海鸥加速器 | 芒果加速器 | 小牛加速器 | 极光加速器 | 黑洞加速 | movabletype中文网 | 猎豹加速器官网 | 烧饼哥加速器官网 | 旋风加速器度器 | 哔咔漫画 | PicACG | 雷霆加速