自從Notification
被引入以后,蘋果就不斷的更新優(yōu)化,但這些更新優(yōu)化只是小打小鬧,直至現(xiàn)在iOS 10開始真實(shí)的進(jìn)行大改重構(gòu),這讓開發(fā)者也體會(huì)到UserNotifications
的易用,功能也變得非常強(qiáng)大。
iOS 9 之前的通知
1.在調(diào)用方法時(shí),有些方法讓人很難辨別,容易寫錯(cuò)方法,這讓開發(fā)者有時(shí)候很苦惱。
2.利用在運(yùn)行時(shí)和非運(yùn)行時(shí)捕獲通知的路徑還不1致。
3.利用在前臺(tái)時(shí),是沒法直接顯示遠(yuǎn)程通知,還需要進(jìn)1步處理。
4.已發(fā)出的通知是不能更新的,內(nèi)容發(fā)出時(shí)是不能改變的,并且只有簡(jiǎn)單文本展現(xiàn)方式,擴(kuò)大性根本不是很好。
iOS 10 開始的通知
1.所有相干通知被統(tǒng)1到了UserNotifications.framework
框架中。
2.增加了撤消、更新、中途還可以修改通知的內(nèi)容。
3.通知不在是簡(jiǎn)單的文本了,可以加入視頻、圖片,自定義通知的展現(xiàn)等等。
4.iOS 10相對(duì)之前的通知來講更加好用易于管理,并且進(jìn)行了大范圍優(yōu)化,對(duì)開發(fā)者來講是1件好事。
5.iOS 10開始對(duì)權(quán)限問題進(jìn)行了優(yōu)化,申請(qǐng)權(quán)限就比較簡(jiǎn)單了(本地與遠(yuǎn)程通知集成在1個(gè)方法中)。
iOS 10 通知學(xué)習(xí)相干資料:
UserNotifications: 蘋果官方文檔 -
蘋果官方視頻1 -
蘋果官方視頻2 -
蘋果官方視頻3
活久見的重構(gòu) - iOS 10 UserNotifications 框架解析
WWDC2016 Session筆記 - iOS 10 推送Notification新特性
iOS 9中默許HTTP的網(wǎng)絡(luò)是不推薦使用的,固然我們也能夠把NSAllowsArbitraryLoads
設(shè)置為YES
禁用ATS
。不過iOS 10從2017年1月1日起蘋果不允許我們通過這個(gè)方法跳過ATS
,也就是說強(qiáng)迫我們用HTTPS
,如果不這樣的話提交App可能會(huì)被謝絕。但是我們可以通過NSExceptionDomains
來針對(duì)特定的域名開放HTTP
可以容易通過審核。
參考學(xué)習(xí)文章以下:
關(guān)于 iOS 10 中 ATS 的問題
iOS 10 開始對(duì)隱私權(quán)限更加嚴(yán)格,如果你不設(shè)置就會(huì)直接崩潰,現(xiàn)在很多遇到崩潰問題了,1般解決辦法都是在info.plist
文件添加對(duì)應(yīng)的Key
-Value
就能夠了。
以上Value
值,圈出的紅線部份的文字是展現(xiàn)給用戶看的,需要自己添加規(guī)范的提示說明,不能為空。目前解決辦法基本都1樣,參考學(xué)習(xí)文章以下:
兼容iOS 10:配置獲得隱私數(shù)據(jù)權(quán)限聲明
上圖我們看到,自己新建的1個(gè)工程啥也沒干就打印1堆爛78糟的東西,我覺得這個(gè)應(yīng)當(dāng)是Xcode 8
的問題,具體也沒細(xì)研究,解決辦法是設(shè)置OS_ACTIVITY_MODE : disable
以下圖:
相干問題連接:
stackoverflow問答
在我們開發(fā)中有可能用到UIStatusBar
1些屬性,在iOS 10 中這些方法已過期了,如果你的項(xiàng)目中有用的話就得需要適配。上面的圖片也能發(fā)現(xiàn),如果在iOS 10中你需要使用preferredStatusBar
比如這樣:
//iOS 10
- (UIStatusBarStyle)preferredStatusBarStyle {
return UIStatusBarStyleDefault;
}
隨著開發(fā)者對(duì)UICollectionView
的信賴,項(xiàng)目中用的地方也比較多,但是還是存在1些問題,比如有時(shí)會(huì)卡頓、加載慢等。所以iOS 10 對(duì)UICollectionView
進(jìn)1步的優(yōu)化,由于敘述起來比較復(fù)雜耗費(fèi)時(shí)間,在這里只提供學(xué)習(xí)參考文章以下:
WWDC2016 Session筆記 - iOS 10 UICollectionView新特性
以下是官方文檔的說明:
Most graphics frameworks throughout the system, including Core Graphics, Core Image, Metal, and AVFoundation, have substantially improved support for extended-range pixel formats and wide-gamut color spaces. By extending this behavior throughout the entire graphics stack, it is easier than ever to support devices with a wide color display. In addition, UIKit standardizes on working in a new extended sRGB color space, making it easy to mix sRGB colors with colors in other, wider color gamuts without a significant performance penalty.
Here are some best practices to adopt as you start working with Wide Color.
由于之前我們都是用RGB
來設(shè)置色彩,反正用起來也不是特別多樣化,這次新增的方法應(yīng)當(dāng)就是1個(gè)彌補(bǔ)吧。所以在iOS 10 蘋果官方建議我們使用sRGB
,由于它性能更好,色采更豐富。如果你自己為UIColor
寫了1套分類的話也可嘗試替換為sRGB
,UIColor
類中新增了兩個(gè)Api
以下:
+ (UIColor *)colorWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0);
- (UIColor *)initWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0);
// The textContentType property is to provide the keyboard with extra information about the semantic intent of the text document.
@property(nonatomic,copy) UITextContentType textContentType NS_AVAILABLE_IOS(10_0); // default is nil
在iOS 10 UITextField
添加了textContentType
枚舉,唆使文本輸入?yún)^(qū)域所期望的語義意義。
使用此屬性可以給鍵盤和系統(tǒng)信息,關(guān)于用戶輸入的內(nèi)容的預(yù)期的語義意義。例如,您可以指定1個(gè)文本字段,用戶填寫收到1封電子郵件確認(rèn)uitextcontenttypeemailaddress
。當(dāng)您提供有關(guān)您期望用戶在文本輸入?yún)^(qū)域中輸入的內(nèi)容的信息時(shí),系統(tǒng)可以在某些情況下自動(dòng)選擇適當(dāng)?shù)逆I盤,并提高鍵盤修正和主動(dòng)與其他文本輸入機(jī)會(huì)的整合。
當(dāng)我們手機(jī)系統(tǒng)字體改變了以后,那我們App
的label
也會(huì)隨著1起變化,這需要我們寫很多代碼來進(jìn)1步處理才能實(shí)現(xiàn),但是iOS 10 提供了這樣的屬性adjustsFontForContentSizeCategory
來設(shè)置。由于沒有真機(jī),具體實(shí)際操作還沒去實(shí)現(xiàn),如果理解毛病幫忙指正。
UILabel *myLabel = [UILabel new];
/*
UIFont 的preferredFontForTextStyle: 意思是指定1個(gè)樣式,并讓字體大小符適用戶設(shè)定的字體大小。
*/
myLabel.font =[UIFont preferredFontForTextStyle: UIFontTextStyleHeadline];
/*
Indicates whether the corresponding element should automatically update its font when the device’s UIContentSizeCategory is changed.
For this property to take effect, the element’s font must be a font vended using +preferredFontForTextStyle: or +preferredFontForTextStyle:compatibleWithTraitCollection: with a valid UIFontTextStyle.
*/
//是不是更新字體的變化
myLabel.adjustsFontForContentSizeCategory = YES;
iOS 10 以后只要是繼承UIScrollView
那末就支持刷新功能:
@property (nonatomic, strong, nullable) UIRefreshControl *refreshControl NS_AVAILABLE_IOS(10_0) __TVOS_PROHIBITED;
判斷系統(tǒng)版本是我們常常用到的,特別是現(xiàn)在大家都有可能需要適配iOS 10,那末問題就出現(xiàn)了,以下圖:
我們得到了答案是:
//值為 1
[[[[UIDevice currentDevice] systemVersion] substringToIndex:1] integerValue]
//值為10.000000
[[UIDevice currentDevice] systemVersion].floatValue,
//值為10.0
[[UIDevice currentDevice] systemVersion]
所以說判斷系統(tǒng)方法最好還是用后面的兩種方法,哦~我忘記說了[[UIDevice currentDevice] systemVersion].floatValue
這個(gè)方法也是不靠譜的,好像在8.3
版本輸出的值是8.2
,記不清楚了反正是不靠譜的,所以建議大家用[[UIDevice currentDevice] systemVersion]
這個(gè)方法!
Swift判斷以下:
if #available(iOS 10.0, *) {
// iOS 10.0
print("iOS 10.0");
} else { }
參考文章以下:
iOS 平常工作之經(jīng)常使用宏定義大全
大家都升級(jí)了Xcode 8
,但是對(duì)插件依賴的開發(fā)者們,1邊哭著1邊去網(wǎng)上尋覓解決辦法。那末下面是解決辦法:
讓你的 Xcode8 繼續(xù)使用插件
但是看到文章最后的解釋,我們知道如果用插件的話,可能安全上會(huì)有問題、并且提交審核會(huì)被謝絕,所以建議大家還是不要用了,解決辦法總是有的,比如在Xcode
中添加注釋的代碼塊也是很方便的。
我用Xcode 8
和Xcode 7.3
分別測(cè)試了下,以下圖:
創(chuàng)建1個(gè)Label
然后讓它自適應(yīng)大小,字體大小都是17
最后輸出的寬度是不1樣的,我們?cè)倏?下,下面的數(shù)據(jù)就知道為何升級(jí)iOS 10
以后App
中有的文字顯示不全了:
Xcode 8打印 | Xcode 7.3打印 |
---|---|
1個(gè)文字寬度:17.5 | 1個(gè)文字寬度:17 |
2個(gè)文字寬度:35 | 2個(gè)文字寬度:34 |
3個(gè)文字寬度:52 | 3個(gè)文字寬度:51 |
4個(gè)文字寬度:69.5 | 4個(gè)文字寬度:68 |
5個(gè)文字寬度:87 | 5個(gè)文字寬度:85 |
6個(gè)文字寬度:104 | 6個(gè)文字寬度:102 |
7個(gè)文字寬度:121.5 | 7個(gè)文字寬度:119 |
8個(gè)文字寬度:139 | 8個(gè)文字寬度:136 |
9個(gè)文字寬度:156 | 9個(gè)文字寬度:153 |
10個(gè)文字寬度:173.5 | 10個(gè)文字寬度:170 |
英文字母會(huì)不會(huì)也有這類問題,我又通過測(cè)試,后來發(fā)現(xiàn)英文字母沒有問題,只有漢字有問題。目前只有1個(gè)1個(gè)修改控件解決這個(gè)問題,暫時(shí)沒有其他好辦法來解決。
(本條更新于:2016-09⑴8)
在Xcode 8
之前我們使用Xib
初始化- (void)awakeFromNib {}
都是這么寫也沒甚么問題,但是在Xcode 8
會(huì)有以下正告:
如果不喜歡這個(gè)正告的話,應(yīng)當(dāng)明確的加上[super awakeFromNib];
我們來看看官方說明:
You must call the super implementation of awakeFromNib to give parent classes the opportunity to perform any additional initialization they require. Although the default implementation of this method does nothing, many UIKit classes provide non-empty implementations. You may call the super implementation at any point during your own awakeFromNib method.
(本條更新于:2016-09⑵0)
很多人都反應(yīng)Xcode 8
沒有之前編譯快了,乃至有些人慢的辣眼睛。但是我的沒有感覺很慢,跟之前差不多,我覺得跟電腦應(yīng)當(dāng)有1些聯(lián)系吧,有的開發(fā)者幾個(gè)月不重啟電腦,電腦里運(yùn)行1堆線程,1堆沒用的垃圾。下面是加速Xcode
編譯的方法,感興趣的可以去看1下:
提高Xcode編譯速度
點(diǎn)擊打開鏈接