ios10之解決關(guān)于"_OBJC_CLASS_$_UNUserNotificationCenter", referenced from:

關(guān)于"OBJC_CLASS$_UNUserNotificationCenter", referenced from:問題

屏幕快照 2016-09-27 14.53.16.png

問題如上圖所示:解決方案在如下位置link binary With中導(dǎo)入U(xiǎn)serNotifications.framework框架

屏幕快照 2016-09-27 14.55.17.png

順手引申一篇好文
轉(zhuǎn)載自:http://www.cnblogs.com/jukaiit/p/5881062.html
2016年9月7日,蘋果發(fā)布iOS 10。2016年9月14日,全新的操作系統(tǒng)iOS 10將正式上線。

作為開發(fā)者,如何適配iOS10呢?

1.Notification(通知)

自從Notification被引入之后,蘋果就不斷的更新優(yōu)化,但這些更新優(yōu)化只是小打小鬧,直至現(xiàn)在iOS 10開始真正的進(jìn)行大改重構(gòu),這讓開發(fā)者也體會(huì)到UserNotifications的易用,功能也變得非常強(qiáng)大。

iOS 9 以前的通知

1.在調(diào)用方法時(shí),有些方法讓人很難區(qū)分,容易寫錯(cuò)方法,這讓開發(fā)者有時(shí)候很苦惱。

2.應(yīng)用在運(yùn)行時(shí)和非運(yùn)行時(shí)捕獲通知的路徑還不一致。

3.應(yīng)用在前臺(tái)時(shí),是無法直接顯示遠(yuǎn)程通知,還需要進(jìn)一步處理。

4.已經(jīng)發(fā)出的通知是不能更新的,內(nèi)容發(fā)出時(shí)是不能改變的,并且只有簡單文本展示方式,擴(kuò)展性根本不是很好。

iOS 10 開始的通知

1.所有相關(guān)通知被統(tǒng)一到了UserNotifications.framework框架中。

2.增加了撤銷、更新、中途還可以修改通知的內(nèi)容。

3.通知不在是簡單的文本了,可以加入視頻、圖片,自定義通知的展示等等。

4.iOS 10相對之前的通知來說更加好用易于管理,并且進(jìn)行了大規(guī)模優(yōu)化,對于開發(fā)者來說是一件好事。

5.iOS 10開始對于權(quán)限問題進(jìn)行了優(yōu)化,申請權(quán)限就比較簡單了(本地與遠(yuǎn)程通知集成在一個(gè)方法中)。

如果使用了推送,修改如圖:

![Uploading 575661-20160918170238256-1807962290_816091.png . . .]

2.ATS的問題

iOS 9中默認(rèn)非HTTS的網(wǎng)絡(luò)是被禁止的,當(dāng)然我們也可以把NSAllowsArbitraryLoads設(shè)置為YES禁用ATS。不過iOS 10從2017年1月1日起蘋果不允許我們通過這個(gè)方法跳過ATS,也就是說強(qiáng)制我們用HTTPS,如果不這樣的話提交App可能會(huì)被拒絕。但是我們可以通過NSExceptionDomains來針對特定的域名開放HTTP可以容易通過審核。

NSExceptionDomains方式 設(shè)置域。可以簡單理解成,把不支持https協(xié)議的接口設(shè)置成http的接口。

具體方法:

1)、在項(xiàng)目的info.plist中添加一個(gè)Key:App Transport Security Settings,類型為字典類型。

2)、然后給它添加一個(gè)Exception Domains,類型為字典類型;

3)、把需要的支持的域添加給Exception Domains。其中域作為Key,類型為字典類型。

4)、每個(gè)域下面需要設(shè)置3個(gè)屬性:NSIncludesSubdomains、NSExceptionRequiresForwardSecrecy、NSExceptionAllowsInsecureHTTPLoads。

如圖:

575661-20160918170238256-1807962290.png

細(xì)節(jié)提示:在iOS9以后的系統(tǒng)中如果使用到網(wǎng)絡(luò)圖片,也要注意網(wǎng)絡(luò)圖片是否是HTTP的哦,如果是,也要把圖片的域設(shè)置哦!
3.iOS 10 隱私權(quán)限設(shè)置

iOS 10 開始對隱私權(quán)限更加嚴(yán)格,如果你不設(shè)置就會(huì)直接崩潰,現(xiàn)在很多遇到崩潰問題了,一般解決辦法都是在info.plist文件添加對應(yīng)的Key-Value就可以了。

575661-20160918164446868-505879984.png

以上Value值,圈出的紅線部分的文字是展示給用戶看的,必須添加。

4.Xcode 8 運(yùn)行一堆沒用的logs解決辦法

575661-20160918114127228-2093692903.jpg

上圖我們看到,自己新建的一個(gè)工程啥也沒干就打印一堆爛七八糟的東西,我覺得這個(gè)應(yīng)該是Xcode 8的問題,

具體也沒細(xì)研究,解決辦法是設(shè)置OS_ACTIVITY_MODE : disable如下圖:

第一步:

575661-20160919101042684-1974264450.png

第二步:

575661-20160919101103902-448062410.png

第三步:

添加參數(shù):

Name :OS_ACTIVITY_MODE

Value : disable

575661-20160919101202996-1273097948.png

5.iOS 10 UIStatusBar方法過期:

575661-20160918114216825-2072979176.jpg

在我們開發(fā)中有可能用到UIStatusBar一些屬性,在iOS 10 中這些方法已經(jīng)過期了,如果你的項(xiàng)目中有用的話就得需要適配。

上面的圖片也能發(fā)現(xiàn),如果在iOS 10中你需要使用preferredStatusBar比如這樣:

//iOS 10 - (UIStatusBarStyle)preferredStatusBarStyle { return UIStatusBarStyleDefault;
}

6.iOS 10 UICollectionView 性能優(yōu)化

隨著開發(fā)者對UICollectionView的信賴,項(xiàng)目中用的地方也比較多,但是還是存在一些問題,比如有時(shí)會(huì)卡頓、加載慢等。所以iOS 10 對UICollectionView進(jìn)一步的優(yōu)化。

UICollectionView cell pre-fetching預(yù)加載機(jī)制
UICollectionView and UITableView prefetchDataSource 新增的API
針對self-sizing cells 的改進(jìn)
Interactive reordering
  在iOS 10 之前,UICollectionView上面如果有大量cell,當(dāng)用戶活動(dòng)很快的時(shí)候,整個(gè)UICollectionView的卡頓會(huì)很明顯,為什么會(huì)造成這樣的問題,這里涉及到了iOS 系統(tǒng)的重用機(jī)制,當(dāng)cell準(zhǔn)備加載進(jìn)屏幕的時(shí)候,整個(gè)cell都已經(jīng)加載完成,等待在屏幕外面了,也就是整整一行cell都已經(jīng)加載完畢,這就是造成卡頓的主要原因,專業(yè)術(shù)語叫做:掉幀.
要想讓用戶感覺不到卡頓,我們的app必須幀率達(dá)到60幀/秒,也就是說每幀16毫秒要刷新一次.

iOS 10 之前UICollectionViewCell的生命周期是這樣的:
1.用戶滑動(dòng)屏幕,屏幕外有一個(gè)cell準(zhǔn)備加載進(jìn)來,把cell從reusr隊(duì)列拿出來,然后調(diào)用prepareForReuse方法,在這個(gè)方法里面,可以重置cell的狀態(tài),加載新的數(shù)據(jù);
2.繼續(xù)滑動(dòng),就會(huì)調(diào)用cellForItemAtIndexPath方法,在這個(gè)方法里面給cell賦值模型,然后返回給系統(tǒng);
3.當(dāng)cell馬上進(jìn)去屏幕的時(shí)候,就會(huì)調(diào)用willDisplayCell方法,在這個(gè)方法里面我們還可以修改cell,為進(jìn)入屏幕做最后的準(zhǔn)備工作;
4.執(zhí)行完willDisplayCell方法后,cell就進(jìn)去屏幕了.當(dāng)cell完全離開屏幕以后,會(huì)調(diào)用didEndDisplayingCell方法.
  iOS 10 UICollectionViewCell的生命周期是這樣的:
1.用戶滑動(dòng)屏幕,屏幕外有一個(gè)cell準(zhǔn)備加載進(jìn)來,把cell從reusr隊(duì)列拿出來,然后調(diào)用prepareForReuse方法,在這里當(dāng)cell還沒有進(jìn)去屏幕的時(shí)候,就已經(jīng)提前調(diào)用這個(gè)方法了,對比之前的區(qū)別是之前是cell的上邊緣馬上進(jìn)去屏幕的時(shí)候就會(huì)調(diào)用該方法,而iOS 10 提前到cell還在屏幕外面的時(shí)候就調(diào)用;
2.在cellForItemAtIndexPath中創(chuàng)建cell,填充數(shù)據(jù),刷新狀態(tài)等操作,相比于之前也提前了;
3.用戶繼續(xù)滑動(dòng)的話,當(dāng)cell馬上就需要顯示的時(shí)候我們再調(diào)用willDisplayCell方法,原則就是:何時(shí)需要顯示,何時(shí)再去調(diào)用willDisplayCell方法;
4.當(dāng)cell完全離開屏幕以后,會(huì)調(diào)用didEndDisplayingCell方法,跟之前一樣,cell會(huì)進(jìn)入重用隊(duì)列.
在iOS 10 之前,cell只能從重用隊(duì)列里面取出,再走一遍生命周期,并調(diào)用cellForItemAtIndexPath創(chuàng)建或者生成一個(gè)cell.
在iOS 10 中,系統(tǒng)會(huì)cell保存一段時(shí)間,也就是說當(dāng)用戶把cell滑出屏幕以后,如果又滑動(dòng)回來,cell不用再走一遍生命周期了,只需要調(diào)用willDisplayCell方法就可以重新出現(xiàn)在屏幕中了.
iOS 10 中,系統(tǒng)是一個(gè)一個(gè)加載cell的,二以前是一行一行加載的,這樣就可以提升很多性能;
iOS 10 新增加的Pre-Fetching預(yù)加載
這個(gè)是為了降低UICollectionViewCell在加載的時(shí)候所花費(fèi)的時(shí)間,在 iOS 10 中,除了數(shù)據(jù)源協(xié)議和代理協(xié)議外,新增加了一個(gè)UICollectionViewDataSourcePrefetching協(xié)議,這個(gè)協(xié)議里面定義了兩個(gè)方法:

  - (void)collectionView:(UICollectionView *)collectionView prefetchItemsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths NS_AVAILABLE_IOS(10_0);
  - (void)collectionView:(UICollectionView *)collectionView cancelPrefetchingForItemsAtIndexPaths:(NSArray<NSIndexPath *> *)indexPaths  NS_AVAILABLE_IOS(10_0);

在ColletionView prefetchItemsAt indexPaths這個(gè)方法是異步預(yù)加載數(shù)據(jù)的,當(dāng)中的indexPaths數(shù)組是有序的,就是item接收數(shù)據(jù)的順序;
   CollectionView cancelPrefetcingForItemsAt indexPaths這個(gè)方法是可選的,可以用來處理在滑動(dòng)中取消或者降低提前加載數(shù)據(jù)的優(yōu)先級(jí).
   注意:這個(gè)協(xié)議并不能代替之前讀取數(shù)據(jù)的方法,僅僅是輔助加載數(shù)據(jù).
   Pre-Fetching預(yù)加載對UITableViewCell同樣適用.

7.iOS 10 UIColor 新增方法

以下是官方文檔的說明:

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.

In iOS 10, the UIColor class uses the extended sRGB color space and its initializers no longer clamp raw component values to between 0.0 and 1.0. If your app relies on UIKit to clamp component values (whether you’re creating a color or asking a color for its component values), you need to change your app’s behavior when you link against iOS 10.

When performing custom drawing in a UIView on an iPad Pro (9.7 inch), the underlying drawing environment is configured with an extended sRGB color space.

If your app renders custom image objects, use the new UIGraphicsImageRenderer class to control whether the destination bitmap is created using an extended-range or standard-range format.

If you are performing your own image processing on wide-gamut devices using a lower level API, such as Core Graphics or Metal, you should use an extended range color space and a pixel format that supports 16-bit floating-point component values. When clamping of color values is necessary, you should do so explicitly.

Core Graphics, Core Image, and Metal Performance Shaders provide new options for easily converting colors and images between color spaces.

因?yàn)橹拔覀兌际怯肦GB來設(shè)置顏色,反正用起來也不是特別多樣化,這次新增的方法應(yīng)該就是一個(gè)彌補(bǔ)吧。所以在iOS 10 蘋果官方建議我們使用sRGB,因?yàn)樗阅芨茫矢S富。如果你自己為UIColor寫了一套分類的話也可嘗試替換為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);

8.iOS 10 UITextContentType

// 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ù)期的語義意義。例如,您可以指定一個(gè)文本字段,用戶填寫收到一封電子郵件確認(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ì)的整合。

9.iOS 10 字體隨著手機(jī)系統(tǒng)字體而改變

當(dāng)我們手機(jī)系統(tǒng)字體改變了之后,那我們App的label也會(huì)跟著一起變化,這需要我們寫很多代碼來進(jìn)一步處理才能實(shí)現(xiàn),但是iOS 10 提供了這樣的屬性adjustsFontForContentSizeCategory來設(shè)置。因?yàn)闆]有真機(jī),具體實(shí)際操作還沒去實(shí)現(xiàn),如果理解錯(cuò)誤幫忙指正。

UILabel myLabel = [UILabel new]; /
UIFont 的preferredFontForTextStyle: 意思是指定一個(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;

10.iOS 10 UIScrollView新增refreshControl

575661-20160918114540839-1874104118.png

iOS 10 以后只要是繼承UIScrollView那么就支持刷新功能:

@property (nonatomic, strong, nullable) UIRefreshControl *refreshControl NS_AVAILABLE_IOS(10_0) __TVOS_PROHIBITED;

11.iOS 10 判斷系統(tǒng)版本正確姿勢

判斷系統(tǒng)版本是我們經(jīng)常用到的,尤其是現(xiàn)在大家都有可能需要適配iOS 10,那么問題就出現(xiàn)了,如下圖:

575661-20160918114620576-1303627103.jpg

我們得到了答案是:

//值為 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 { }

12.Xcode 8 插件不能用的問題

大家都升級(jí)了Xcode 8,但是對于插件依賴的開發(fā)者們,一邊哭著一邊去網(wǎng)上尋找解決辦法。那么下面是解決辦法:
讓你的 Xcode8 繼續(xù)使用插件(http://vongloo.me/2016/09/10/Make-Your-Xcode8-Great-Again/?utm_source=tuicool&utm_medium=referral )

但是看到文章最后的解釋,我們知道如果用插件的話,可能安全上會(huì)有問題、并且提交審核會(huì)被拒絕,所以建議大家還是不要用了,解決辦法總是有的,比如在Xcode中添加注釋的代碼塊也是很方便的。

13.iOS 10開始項(xiàng)目中有的文字顯示不全問題

我用Xcode 8 和Xcode 7.3分別測試了下,如下圖:

575661-20160918114911979-1889192985.jpg

Xcode 8

575661-20160918114920417-1828331146.jpg

Xcode7

創(chuàng)建一個(gè)Label然后讓它自適應(yīng)大小,字體大小都是17最后輸出的寬度是不一樣的,我們再看一下,
下面的數(shù)據(jù)就知道為什么升級(jí)iOS 10 之后App中有的文字顯示不全了:

575661-20160918115047642-1072358093.png

英文字母會(huì)不會(huì)也有這種問題,我又通過測試,后來發(fā)現(xiàn)英文字母沒有問題,只有漢字有問題。
目前只有一個(gè)一個(gè)修改控件解決這個(gè)問題,暫時(shí)沒有其他好辦法來解決。

14.Xcode 8使用Xib awakeFromNib的警告問題

在Xcode 8之前我們使用Xib初始化- (void)awakeFromNib {}都是這么寫也沒什么問題,但是在Xcode 8會(huì)有如下警告:

575661-20160918164934170-318856946.png

官方解釋:
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.

你必須調(diào)用父類實(shí)現(xiàn)awakeFromNib來給父類來執(zhí)行它們需要的任何額外的初始化的機(jī)會(huì)。
雖然這種方法的默認(rèn)實(shí)現(xiàn)不做任何事情,許多UIKit類提供非空的實(shí)現(xiàn)。
你可以調(diào)用自己的awakeFromNib方法中的任何時(shí)候超級(jí)實(shí)現(xiàn)。

15、推送的時(shí)候,開啟Remote notifications
You've implemented -[<UIApplicationDelegate> application:didReceiveRemoteNotification:fetchCompletionHandler:],
but you still need to add "remote-notification" to the list of your supported UIBackgroundModes in your Info.plist.
解決方案:需要在Xcode 中修改應(yīng)用的 Capabilities 開啟Remote notifications,請參考下圖:

575661-20160919140245793-794728449.png

16、One of the two will be used. Which one is undefined.”
  objc[5114]: Class PLBuildVersion is implemented in both /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/AssetsLibraryServices.framework/AssetsLibraryServices (0x1109a5910) and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/PhotoLibraryServices.framework/PhotoLibraryServices (0x110738210). One of the two will be used. Which one is undefined.

在模擬器中、發(fā)現(xiàn)“One of the two will be used. Which one is undefined.”日志

查找資料發(fā)現(xiàn)原因:objc runtime 對所用app使用同一個(gè)命名空間(flat namespace),運(yùn)行機(jī)制如下:
首先二進(jìn)制映像被加載,檢查程序依賴關(guān)系
每一個(gè)二進(jìn)制映像被加載的同時(shí),程序的objc classes在objc runtime命名空間中注冊
如果具有相同名稱的類被再次加載,objc runtime的行為是不可預(yù)知的。一種可能的情況是任意一個(gè)程序的該類會(huì)被加載(這應(yīng)該也是默認(rèn)動(dòng)作)
17、Invalid Bundle - The asset catalog at 'Payload/XXXXX/Assets.car'
can't contain 16-bit or P3 assets if the app supports iOS 9.3 or earlier

575661-20160920180122621-1767554257.png

在 Xcode 8 中,當(dāng)你資源文件中[含有16位圖]或者[圖片顯示模式γ值為'P3']且iOS targets設(shè)定為iOS 9.3以下就會(huì)出現(xiàn)這個(gè)問題. 如果你的app需要支持廣色域顯示的話,那你必須得把target設(shè)置成iOS 9.3+,相反,如果你的app不需要支持廣色域且你想兼容 iOS 9.3 之前的項(xiàng)目,你就得把所有的16位的或者顯示模式為'P3'圖片全都替換成8位模式的SRGB顏色的圖片。

你可以通過運(yùn)行“assetutil”在iTunes Connect的錯(cuò)誤信息中找到16-bit 或 P3 資源文件。離線的解決方案如下:

1.導(dǎo)出項(xiàng)目的 ipa 文件

2.定位到該ipa文件修改后綴名.ipa 為 .zip.

  1. 解壓該 .zip 文件. 解壓后的目錄里面會(huì)有一個(gè)包含著你的 app bundle 文件的 Payload 文件夾.

  2. 打開終端病切換到你的app的Payload文件夾下的 .app bundle 文件夾內(nèi),形式如下:

cd path/to/Payload/your.app

  1. 用 find 命令定位到 Assets.car 文件 .app bundle , 形式如下:

find . -name 'Assets.car'

  1. 使用 assetutil 命令找到任何包含著 16-bit or P3 的資源文件, 對每個(gè) Assets.car 之行以下命令 :

sudo xcrun --sdk iphoneos assetutil --info /path/to/a/Assets.car > /tmp/Assets.json

  1. 打開上一步生成的 /tmp/Assets.json 文件并查找包含有 “DisplayGamut": “P3” 或者相關(guān)的內(nèi)容. 這段json的"Name"字段對應(yīng)的值就是16位或顯示的γ值為P3的資源文件名.
575661-20160920180323184-1049564596.png
  1. 找到這個(gè)資源文件修改為 8位的sRGB形式,重新編譯上傳你的app即可.

18、This version does not support documents saved in the Xcode 8 format. Open this document with Xcode 8 or later
  編輯項(xiàng)目時(shí)默認(rèn)使用Xcode8打開,導(dǎo)致我用Xcode7打開Xib是報(bào)錯(cuò):

This version does not support documents saved in the Xcode 8 format. Open this document with Xcode 8.0 or later

575661-20160921142554277-537167035-1.png

導(dǎo)致用Xcode8打開的Xib全部打不開,只能用編輯器將Xib里面的下面一句話刪除掉才能打開:

<capability name="documents saved in the Xcode 8 format" minToolsVersion="8.0"/>

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,431評論 6 544
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,637評論 3 429
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,555評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,900評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 72,629評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,976評論 1 328
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,976評論 3 448
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 43,139評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,686評論 1 336
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,411評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,641評論 1 374
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,129評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,820評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,233評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,567評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 52,362評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,604評論 2 380

推薦閱讀更多精彩內(nèi)容