270度 ios

2017-09-29 11:10:25 rainbowFactory 阅读数 1892

业务场景中需要在键盘弹起后重新布局,在review代码时发现收到UIKeyboardDidShowNotification通知时是用如下方式获取键盘frame:

CGRect keyboardFrameBeginRect = [[[notification userInfo] valueForKey:UIKeyboardFrameBeginUserInfoKey] CGRectValue];

iOS 11之前没有问题,iOS11之后部分场景获取frame的高度为零

解决方案:

CGRect keyboardFrameBeginRect = [[[notification userInfo] valueForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];

2016-03-31 10:10:37 guojigang8963869 阅读数 444
1.状态栏
状态栏一般高度为20像素,在打手机或者显示消息时会放大到40像素高,注意,两倍高度的状态栏在好像只能在纵向的模式下使用。如下图
iOS <wbr>各种控件默认高度


用户可以隐藏状态栏,也可以将状态栏设置为灰色,黑色或者半透明的黑色。

如果需要隐藏状态栏可以使用调用:
[[UIApplication sharedApplication] setStatusBarHidden:YESanimated:NO];
或者在应用程序文件Info.plist中将UIStatusBarHidden键设为ture。


2.导航栏
在纵向模式下导航栏为44像素高,在横向模式下为32像素高,导航栏提供了一个很少用的提示模式,该模式将高度扩展了30像素,在纵向模式下为320*74像素,在横向模式下为480*74像素。
要向导航栏添加提示,则设置self.navigationItem.prompt =@"................"。

iOS <wbr>各种控件默认高度


3.选项卡  工具栏
选项卡为48像素高,工具栏为44像素高。此两个UI元素通长不用于横向模式。
iOS <wbr>各种控件默认高度

典型的带有导航栏和状态栏的应用程序为纵向显示保留了320*416的区域,为横向保留了480*268的区域。如果使用选项卡栏或者工具栏则会使高度再次减少48或者44像素。

4.键盘和pickerView
此一般都为横向320*216像素,纵向为480*162像素。

另外,UISwitch默认为94*28像素,UISegmentedControl通长为44像素高。

UITextField高度一般至少为30像素。

5.UIScreen类
[[UIScreen mainScreen]applicationFrame]一般会根据正在使用的工具栏,状态栏,导航栏来返回可用的区域。


iPhone和iPad下各种常见控件的宽度和标准是一样的,所以这里就用iPhone说明。
 
以下是常见的几种控件的高度。Statusbar,Navigationbar和Tabbar的宽度极其图标大小。
iOS <wbr>各种控件默认高度


下表是更为详细的参数,包括了Statusbar,Navigationbar、Tabbar、toolbar和Keyboard等等
iOS <wbr>各种控件默认高度
2017-12-23 11:07:25 elzza 阅读数 11592

IOS与安卓的区别:

  1. 两者运行机制不同:
    1. IOS采用的是沙盒运行机制
    2. 安卓采用的是虚拟机运行机制
  2. 两者后台制度不同:
    1. IOS中任何第三方程序都不能在后台运行
    2. 安卓中任何程序都在后台运行,直到没有内存才会关闭
  3. 两者最高权限指令不同

    1. IOS中用于UI指令权限最高,
    2. 安卓中数据处理指令权限最高。
  4. 两者实现机制解释

    1. iphone**沙盒机制**解释:

      1. 应用程序位于文件系统的严格限制部分,程序不能直接访问其他应用程序。
      2. 杀毒软件中的沙盒技术解释一下:
        “沙盒”技术是发现可疑行为后让程序继续运行,当发现的确是病毒时才会终止。
      3. “沙盒”技术的实践运用流程是:
        让疑似病毒文件的可疑行为在虚拟的“沙盒”里充分表演,“沙盒”会记下它的每一个动作;当疑似病毒充分暴露了其病毒属性后,“沙盒”就会执行“回滚”机制,将病毒的痕迹和动作抹去,恢复系统到正常状态。
    2. 安卓虚拟机机制解释:

      1. android本身不是为触摸屏打造的,所以所有的应用都是运行在一个虚拟的环境中,由底层传输数据到虚拟机中,再由虚拟机传递给用户UI,任何程序都就可以轻松访问其他程序文件。
      2. 软件方面:苹果的软件靠ITUNES赚钱还需要相应的许可所以相对而言质量要比较高一些。 安卓软件可以随便开发随便弄软件质量会不是很高,但是也有精品的软件。

是否开源

由于安卓是开源的,软件和硬件不是一体的,所以可以刷不同的ROM,适合喜欢研究手机的人。
Android抗衡iOS还是有些力不从心,比如在移动应用开发者的收入方面,平台的整合度,操作的流畅度等。尤其在企业级市场,几乎已被iOS全面占领,新兴的企业都表示更加青睐iOS而非所谓“开放”、基于Linux内核、拥有双核甚至四核……的Android设备。
企业级用户对稳定和实时性的需求恰恰就是Android的软肋,网络上一个段子很能表现Android的窘境:“Android用户三大爱好:刷机重启换电池”,还有人出来解释“为什么Android永远不会比iOS流畅”,并称Android是本着学、赶、超的思路诞生并发展起来,在黑莓时代Android设备最早是按照全键盘机型作为参考,后来iPhone的横空出世才导致Android瞬间改头换面,于是为后面的图形渲染等等埋下了隐患。
Android是第一个内置支持Java的操作系统,Android应用程序使用java语言编写。Android开发水平的高低很大程度上取决于Java语言核心能力是否扎实。iOS苹果的iPhone和iPad应用开发都指定使用同一开发语言:Objective-C语言。Objective-C是Cocoa的本地编程语言,Coaco框架和大多数应用程序都使用该语言编写而成。但是您也可以使用Python、Ruby等其他编程语言开发应用程序,并且此种开发方式也可使用Cocoa框架。苹果打造的是一个封闭的生态环境。他们严格控制着应用商店并且对在他们地盘外产生的收益手段虎视眈眈。广告收益是苹果封闭环境内的主要漏洞。显而易见的是他们不能堵上这个漏洞。从苹果目前的心态上看,他们想通过iAds在该漏洞中插上一手,苹果感兴趣的是控制住这块巨大的肥水不会往外流。
而在另一方面你还有Android。它开源,生态环境开放,市场也开放。而把这些都融合起来还是Google,这家Android平台的开发者本身也是一家广告公司。

使用体验

一、流畅性碾压性优势

由于Android系统采用了虚拟机的运行机制,这就需要消耗更多的系统资源了运行App,即便升级到Android 4.X,甚至Android 5.X,系统流畅性还是不如iOS。iOS无论是桌面滑动、App的内部操作,屏幕与指尖都似乎带有“粘性”一般,这就使得手指触控到哪里,屏幕就会马上指向哪里,而Android呢?看似已经媲美了iOS的流畅,但只是媲美,多数还是不及iOS流畅,即便Android的触控延迟只有0.1秒其实就已经分出胜负了。
这里的流畅并不是指手机应用的打开速度、关机速度。流畅指的是运行速度、触控速度,因为这才是最直观的影响用户体验部分。以笔者手中使用的iPhone5为例,自2012年使用至今从未刷机,系统依然流畅不卡,而反观与同时期的Android系统手机……

二、iOS系统的软件App多优先升级

并不是软件升级快就代表好用,但至少软件升级可能会为我们带来额外的功能体验,拿最近的微信举例,苹果iOS系统优先升级并推出了朋友圈的“小视频”功能,而Android系统则多等了几个星期的时间。绝大多数主流的应用软件都以iOS系统开发升级为优先级,只有少数未通过苹果审核上架、或特殊应用才会在Android先放出。
说到软件App方面为何iOS系统升级快,这得益于苹果有一套独特的与开发者分享收入的计划,有了利益关系,这能够让开发者更加有动力、更积极的开发和升级应用。而谷歌虽然也为Android开发了专属的应用商店,但在国内的环境下国人使用的并不多,况且升级速度并不快,体验尝鲜还要遥遥无期的等待。

三、iOS游戏不要数据包,Android玩大型游戏很麻烦

iOS的游戏直接通过官方App Store或在越狱后通过各种第三方助手安装即可,这期间除了部分老旧设备可能出现不兼容的游戏外,其它均完美被支持,没有游戏数据包一说。而Android玩家,如果要下载一个大型的游戏,必须要通过安装游戏主程序+额外下载几百MB不等的数据包才行,如果是主流的高通CPU还好,但凡碰到非主流的CPU的话,那游戏数据包可能就遥遥无期了,开发者心情好的话会为CPU做适配,否则就只有无限等待或移植的命运。
(注:Android系统的大型游戏,需要在安装游戏之后再下载数据包,数据包会针对手机的处理器以及GPU专门优化,如果选择了没有经过优化的数据包,可能出现无法运行或者贴图错误等情况。iOS系统则是在下载游戏的时候一同下载数据包,不存在单独下载的情况。所以相同的一款游戏,Android系统可能只有几十M的大小,而iOS则达到了1G以上,这就是因为Android没有数据包而iOS包含了数据包。)
再者,iOS目前的分辨率只有5种左右,而Andorid则大大小小的包含了近10种左右,再由于盗版或开发者利益关系原因,开发者更倾向于对iOS优先适配。同时,游戏的质量(包括画面精美程度、触控流畅性等等)整体也要高于Andorid系统。或许有同学说Android打开游戏的速度要快于iOS,笔者想说,玩游戏是比打开的速度吗?

四、小偷即使偷走也不会泄露隐私

自从iOS 7系统之后,苹果增加了安全保护机制,即如果进行二次刷机或强行开启手机的锁屏密码,必须要输入原有的Apple ID的密码进行解锁才行。我们不能防止手机被偷,也不指望被偷后能够找回(虽然可以定位,但是否可以找回完全凭自己本事。),但至少可以保证我们手机内的资料或隐私不被居心不良者窃取。小偷拿走手机后最多当配件廉价的卖掉。
Android系统虽然同样有密码保护机制,但相比苹果而言就要逊色一些,稍微懂点的人只要进入Recovery后,就能刷机或清理数据,手机的密码形同虚设了。虽然有少部分手机做到了二次加密,但大多数的Android系统在这方面还是比较脆弱。
(注:Recovery模式指的是一种可以对安卓机内部的数据或系统进行修改的模式,也叫工程模式(类似于windowspe)。在这个模式下我们可以刷入新的安卓系统,或者对已有的系统进行备份或升级,也可以在此恢复出厂设置。)

五、更省电、功耗控制好

系统机制的不同导致了Android会占用更多的资源来支撑系统运行,官方宣称的3000毫安时电池实际使用也不过一天的时间,而iOS系统的iPhone虽然看似电池容量不高,但得益于精心优化,它在待机耗电大约只有Android系统的30%左右,使用耗电更是只有25%-75%。
iOS系统采用独立唤醒技术,以及为处理器量身定制的芯片,在待机时更省电,使用时的耗电详情呈“线性”趋势。虽然有部分Android手机续航强,但多为高容量的电池,并且使用长时间后,由于系统或电池的原因,更是会出现“跳电”的现象。

六、没有强迫症根本不用清后台

“不清理后台会很费电”、“不清理后台会很卡”……反正也不知道什么时候起,手机清理后台就成了必须要做的了,至于原因就为了亮点,不卡、省电。不过这只对Android系统有效,iOS系统完全没有清理后台的操作,同样耗电、流畅性也不会被影响。
怀疑鄙人说的不对?自己试试看就知道了。至于有些同学说两大系统真假后台的问题,这个就仁者见仁了,没有人敢说Andorid的后台机制最好,也没有人保证iOS的后台机制更适合。

七、iOS更稳定不易死机

许多问题我们虽然不想承认,但却是客观存在的事实,下至低端入门、上至旗舰顶配,Android系统在长时间使用后,都会或多或少出现些不稳定现象,比如最不能忍的死机现象,可换电池的手机还好,扣个电池就恢复了,但不可拆卸的电池手机就只能等待重启或长按关机键恢复了。
iOS也会死机,但相比较之下出现死机的几率要少很多。

八、综合实力最好的影像系统

目前搭载iOS系统的设备最高规格的摄像头为800万像素,但即便是这样,凭借iOS系统的精心优化,它仍是目前智能手机中综合体验最好的手机之一(包括对焦速度、成像速度、成片速度、成片率、多场景拍照等综合而定)。而搭载Android系统目前已经达到了2070万像素级别,感光原件甚至更好,但拍照的综合体验来看,iOS的优势依旧明显。

九、双核战8核

由于iOS高度整合、优化、封闭性,让它无论是在各方面的表现十分优异,其中最值得欣慰的一点目前的iOS系统有着自己的一套生态体系,即便是使用双核处理器,配合定制的GPU处理单元,在综合表现来看同样不输Android,要知道现在8核处理器已经不足为奇。

总结:

虽然笔者列举了9项iOS相比Android的优势,但同时也并不否认iOS还存在许多可以学习改进的地方。而对于许多功能性的东西,笔者并没有将越狱的范畴考虑在内,如越狱后iOS能实现比现在更多更好的功能体验。
其实,争了几年了,都说自己的系统好用,但事实上两大系统各有优劣势,谈不上哪个系统最好。iOS系统优势慢慢的被追赶,Android的多样性逐渐被整合,这一切都是时间的问题而已,好与不好这都是相对的。对于我们普通使用者来说,哪个系统最好不重要,适合自己最重要。但至少从目前来看,iOS系统的系统级体验,还是需要Android来积极学习的。

原文链接:https://bbs.feng.com/read-htm-tid-11099942.html

2015-11-01 19:52:49 tongwei117 阅读数 4717

对tableView三种计算动态行高方法的分析

tableView是一个神奇的东西,可以这么说,就算是一个初学者如果能把tableView玩的很6,那编一般的iOS的需求都问题不大了。tableView是日常开发中用烂了的控件,但是关于tableView中的自定义cell的动态行高,还是有一些玄机的。笔者本次主要是因为预估行高的方法的问题作为了一个契机顺带写了此文对几种动态行高方法的分析。

旧方法

现在常规的动态行高的计算方法还是用

[str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size

这其中需要先传入一个最大尺寸和一个属性字典,特殊的格式要求都写在属性字典中。

NSDictionary *attrs = @{NSFontAttributeName : font};

整个流程的基本思想大概就是:用一个字符串对象来调用此方法,中间需要传入一个属性字典来告知字体和样式,然后根据字符串长度的多少来算出应该给多大的frame。前面传进的size一般可以设置最大宽度。 此方法一般写成分类便于调用。

#import "NSString+Size.h"
@implementation NSString (Size)
/**
* 类方法计算size大小
*/
+ (CGSize)sizeWithString:(NSString *)str andFount:(UIFont *)font andMaxSize:(CGSize)size
{
NSDictionary *attrs = @{NSFontAttributeName : font};
return [str boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size;
}
/**
* 对象方法计算size大小
*/
- (CGSize)sizeWithFount:(UIFont *)font andMaxSize:(CGSize)size;
{
NSDictionary *attrs = @{NSFontAttributeName : font};
return [self boundingRectWithSize:size options:NSStringDrawingUsesLineFragmentOrigin attributes:attrs context:nil].size;
}
@end

这些方法从字面上看也比较容易理解。
调用时的代码基本就是取到一个字符串,传入一个font和一个最大size,如下把宽设置成了270就是最大宽度为270高度往下顺延的话就把高度写成MAXFLOAT

NSString *text = _message.text;
CGSize textSize = [text sizeWithFount:[UIFont systemFontOfSize:14] andMaxSize:CGSizeMake(270, MAXFLOAT)];

然后在frame中取到最下面一个空间的maxY,从而让每一个cell在set方法中就得到自己的行高 ,然后通过cell的类方法返回。

新方法
随着iOS8的自动布局和Interface builder越来越成熟,逐渐衍生出了一种先用storyboard或xib界面再算自定义行高的方法。
这种方法一般需要先搭建一个图形化界面。如下图大概搭一个比较复杂的cell。

这里写图片描述

首先可以清晰的看出,用IB搭建看上去很快就能搭建完毕,并且有的图片或是view的背景设置了之后能看出界面大概的感觉。这里需要注意的就是label设置约束的方法,普通控件一般都要设置四个约束才能固定位置,label和button只设置两个约束(只需要写固定位置的两条约束,不需要写自身宽高的约束)也不会报错,但是需要在editor中设置sizeToFit,这样可以根据字数自动给你分配一个控件的大小。

这里写图片描述

一般评论类的label肯定都是字数比较多的,这时2条约束就不够了需要再设置一个最大宽度的约束,如图1我设置的方法是,把评论label与左右边界的间隙给设定了,这个在IB中叫Leading(前)和Training(后),高的约束我们没有写如果字数超过了一行他就会自己往下顺延。 这么写相较于把宽度约束写死的好处是会自动根据屏幕适配不管屏幕多大都是左右空出若干像素。这样做也有局限性,就是假设给这个label设置一个背景色,如果字数就5个字背景色也会延伸到一整行。如果QQ聊天页面也这样做,不管是几个字都是一整行的聊天气泡那会很丑。于是有了一种少则背景也少,多也不超过最大宽度的做法,就是设置label的width的less than来设置最大宽度。这么做如果字数不足一行的话,约束也会自动缩到与label长度匹配。

这里写图片描述
如果这个页面用纯手码写,可想而知会非常麻烦。
用IB页面做自定义行高的计算方法也更简单。也就是里面模型的set方法正常写,给自己的UI控件赋值。然后在tableView的行高方法heightForRow中,先给cell的模型赋值,然后再使用一次

[cell layoutIfNeeded];

他会自动根据填进去数值来布局,然后我们直接在这个方法中返回最下面一个控件的bottom位置+若干间隙,以此来作为行高即可。
真正的布局其实也就是用了这一行代码,并且可以做到屏幕适配不用if判断各种frame。但这样写也有一些问题,首先就是这么写从结构上来看不合理。这个行高方法中不应该写这些赋值语句。官方还是其他大神说不合理的原因,应该是这个方法应该仅仅是用来算出行高并显示的,会调用多次,如果在这里赋值性能会很差。这么说有道理,把这里面的每行代码都看一遍,能看出性能较差的方法主要就是这两行:1.给cell里模型赋值 2.layoutIfNeed 。如果调用多次这个方法那这两行也会执行多次,所以这应该是不科学的。  我实际的做法是在其中设置一个行高缓存字典,并且找一个肯定不会重复的标识来做key值。每一行cell计算行高前都先拿自己的id去行高缓存字典里取一下看有没有值,如果有则直接返回对应的value,如果没有再计算。这样可以使这性能比较差得两行代码只执行一次。达到优化效果。

MTFBNoReplyCell *feedbackNoreplyCell = [MTFBNoReplyCell cell];
NSString *thisId =[NSString stringWithFormat:@"%d", feedbackModel.feedbackid];
// MTLog(@"%@",[self.cellHeightCache valueForKey:thisId]);
CGFloat cacheHeight = [[self.cellHeightCache valueForKey:thisId] doubleValue];
if (cacheHeight) {
// MTLog(@"返回缓存的行高");
return cacheHeight;
}
// MTLog(@"耗性能的行高");
feedbackNoreplyCell.feedbackDetailModel = feedbackModel;
[feedbackNoreplyCell layoutIfNeeded];
[self.cellHeightCache setValue:@(feedbackNoreplyCell.replyBtn.bottom+16) forKey:thisId];
return feedbackNoreplyCell.replyBtn.bottom+16;

大概的思想如上所示。 如果这个tableView的数据不会随时改变较为固定的话,可以把取到的模型作为value以indexpath.row为key存一个缓存字典这样也能优化一些。行高方法里取过了,cellForRow就可以直接用了。

预估行高方法
这里我想重点说一下这个预估行高的方法estimatedHeightForRowAtIndexPath 。这个方法可能大部分人一说到这个,就说这个方法好啊,预估行高方法可以减少heightForRow的调用次数,使得性能达到优化。 孰不知实际运用中是存在着一定问题的。
就拿整个tableView来说 他是继承自scrowView的,scrowView能够滚动是因为它有contentSize。tableView在初次加载的时候也需要算出自己的contentSize(而且会算不止一次),也就是说需要调一下所有的行高方法然后自己内部给他累加一下算出整个contentSize。如果在行高方法里设置一个打印会看到方法会调用很多次。这时如果有一个预估方法return 100。那它就能很快算出总值了。就会减少行高方法的调用,在实际用到某一行时再调用。
但是可能会出现如下左图的问题。

问题的原因就是,一开始预估方法给每行预估了一个行高,然后后面实际加载的行高与预估的行高不合时,会出现cell上下的“窜动”给人卡卡的感觉。对此我的思想是,如果是动态的且cell的复杂度较高,行与行之间差距大的时候,就直接不要写预估行高方法了吧,让他自己算吧哪怕多调用几次,毕竟上面已经写过缓存行高字典了,性能姑且是可以hold住了,并且不会出现“窜动”情况。如右图所示。
但是如果是固定行高有一种或是三种不同的cell,行高分别是120,150,200。你在预估行高了写个return 150。遇到行高与预估不等时,却也不会出现“窜动”。我推测应该是estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在,这两者同时存在才会出现“窜动”的bug。所以我的建议是:只要是固定行高就写预估行高来减少行高调用次数提升性能。如果是动态行高就不要写预估方法了,用一个行高的缓存字典来减少代码的调用次数即可。
关于上面行高的新方法和旧方法的对比,我的总结是:首先新方法肯定性能上是比旧方法要差一些的。具体体现在两个方面,1是在IB页面开发的东西,程序一启动就会全部加载进内存由系统托管,以至于有的界面你已经把导航控制器的栈顶控制器给pop了,发现内存还没有下降。2是新方法和旧方法有一个本质的区别,旧方法是直接算,算你需要多大的尺寸就告诉你,新方法则是先强制布局然后看你占了多大的尺寸再告诉你,这两者一对比,新方法就是多了一个强制布局的过程,这肯定是会对性能造成一定影响的,那具体影响多少?关于滑动计算行高我还不知道有什么可以明确一个数据的对比,我只能用肉眼看屏幕的滑动来区分对比,我的感觉就是基本没差别,如果要说有的话新方法可能会非常轻微的卡顿,换而言之就是同一个页面,旧方法编完需要10小时,新方法编完需要3小时,但是新方法的性能略差于旧方法。就看你自己怎么衡量了。当然非常庞大的项目还是建议用旧方法,毕竟一点一点的“略差于”积累在一起就是很差了。

关于iOS8新的行高特性

首先是有了一个新的用法。写在viewdidload里

self.tableView.estimatedRowHeight = 50.0f;
self.tableView.rowHeight = UITableViewAutomaticDimension;

这就没什么好说的了,苹果自己帮你把动态行高计算了,所有乱七八糟的都不用管了。 但是暂时说这些基本没用,因为现在还看不到哪个公司的项目不适配iOS7,就算出了iOS9感觉也不会让你直接适配iOS8的,iOS7还会存在相当长一段时间,毕竟以后新系统版本改变应该都不会有iOS6到7变化那么大了,除非啥时候苹果总设计师乔纳森伊夫下台了。

2016-07-28 15:05:17 bitcser 阅读数 5533
注意,这是image旋转,而不是将imageView旋转(imageView的旋转就太简单了),原理就是使用quartz2D来画图片,然后使用ctm变幻来实现旋转。

+(UIImage *)image:(UIImage *)image rotation:(UIImageOrientation)orientation

{

    long double rotate = 0.0;

    CGRect rect;

    float translateX = 0;

    float translateY = 0;

    float scaleX = 1.0;

    float scaleY = 1.0;

    

    switch (orientation) {

      case UIImageOrientationLeft:

           rotate =M_PI_2;

           rect =CGRectMake(0,0,image.size.height, image.size.width);

           translateX=0;

           translateY= -rect.size.width;

           scaleY =rect.size.width/rect.size.height;

           scaleX =rect.size.height/rect.size.width;

          break;

      case UIImageOrientationRight:

           rotate =3 *M_PI_2;

           rect =CGRectMake(0,0,image.size.height, image.size.width);

           translateX= -rect.size.height;

           translateY=0;

           scaleY =rect.size.width/rect.size.height;

           scaleX =rect.size.height/rect.size.width;

          break;

      case UIImageOrientationDown:

           rotate =M_PI;

           rect =CGRectMake(0,0,image.size.width, image.size.height);

           translateX= -rect.size.width;

           translateY= -rect.size.height;

          break;

      default:

           rotate =0.0;

           rect =CGRectMake(0,0,image.size.width, image.size.height);

           translateX=0;

           translateY=0;

          break;

    }

    

   UIGraphicsBeginImageContext(rect.size);

  CGContextRef context =UIGraphicsGetCurrentContext();

   //CTM变换

    CGContextTranslateCTM(context, 0.0, rect.size.height);

    CGContextScaleCTM(context, 1.0, -1.0);

    CGContextRotateCTM(context, rotate);

    CGContextTranslateCTM(context, translateX,translateY);

    

    CGContextScaleCTM(context, scaleX,scaleY);

   //绘制图片

    CGContextDrawImage(context, CGRectMake(0,0,rect.size.width, rect.size.height), image.CGImage);

    

  UIImage *newPic =UIGraphicsGetImageFromCurrentImageContext();

    

    return newPic;

}


ios: 画半个椭圆

阅读数 4241