《高性能iOS 應(yīng)用開發(fā)》之降低你 APP 的電量消耗

高性能iOS 應(yīng)用開發(fā)

在編寫高性能 代碼時, 電量消耗是一個需要重點處理的重要因素, 就執(zhí)行時間和 CPU 資源的利用而言, 我們不僅要實現(xiàn)高效的數(shù)據(jù)結(jié)構(gòu)和算法, 還需要考慮其他的因素,如果某個應(yīng)用是個電池黑洞,那么一定不會有人喜歡他
電量消耗除了 CPU 外,還有一些硬件模塊:網(wǎng)絡(luò)硬件, 藍牙,GPS, 麥克風(fēng),加速計,攝像頭,揚聲器,和屏幕.
我們可以帶著以下問題來看這篇文章:

  • 消耗電量的關(guān)鍵領(lǐng)域有哪些
  • 如何降低電量的消耗
  • 如何在 IOS 應(yīng)用中分析電源, CPU 和資源的使用

一 CPU

不論用戶是否正在直接使用, CPU 都是應(yīng)用所使用的主要硬件, 在后臺操作和處理推送通知時, 應(yīng)用仍然會消耗 CPU 資源


iOS 設(shè)備與處理器

應(yīng)用計算的越多,消耗的電量越多.在完成相同的基本操作時, 老一代的設(shè)備會消耗更多的電量(換電池呀 哈哈哈 開個玩笑),計算量的消耗取決于不同的因素

  • 對數(shù)據(jù)的處理
  • 待處理的數(shù)據(jù)大小---更大的顯示屏允許軟件在單個視圖中展示更多的信息,但這也意味著要處理更多的數(shù)據(jù)
  • 處理數(shù)據(jù)的算法和數(shù)據(jù)結(jié)構(gòu)
  • 執(zhí)行更新的次數(shù),尤其是在數(shù)據(jù)更新后,觸發(fā)應(yīng)用的狀態(tài)或 UI 進行更新(應(yīng)用收到的推送通知也會導(dǎo)致數(shù)據(jù)更新,如果此用戶正在使用應(yīng)用,你還需要更新 UI)

沒有單一原則可以減少設(shè)備中的執(zhí)行次數(shù),很多規(guī)則都取決于操作的本質(zhì), 以下是一些可以在應(yīng)用中投入使用的最佳實踐

  • 針對不同的情況選擇優(yōu)化的算法
    例如,當(dāng)你在排序時,如果列表少于43個實例, 則插入排序優(yōu)于歸并排序, 但實例對于286時, 應(yīng)當(dāng)使用快速排序,要優(yōu)先使用雙樞軸快速排序而不是傳統(tǒng)的單樞軸快速排序
  • 如果應(yīng)用從服務(wù)器接受數(shù)據(jù),盡量減少需要在客戶端進行的處理
    例如如果一段文字需要在客戶端進行渲染,盡可能在服務(wù)器將數(shù)據(jù)清理干凈
    我曾經(jīng)做個一個項目, 因為服務(wù)器的實現(xiàn)主要用于服務(wù)桌面用戶,所以返回的文本中包含 HTML 標(biāo)簽, 清理 HTML 標(biāo)簽的工作并沒有放在客戶端進行, 而是放在了服務(wù)端實現(xiàn),從而減少了設(shè)備上的計算過程, 降低了處理時間
  • 優(yōu)化靜態(tài)編譯(ahead-of-time,AOT)處理
    動態(tài)編譯處理的缺點在于他會強制用戶等待操作完成, 但是激進的 AOT 處理則會導(dǎo)致計算資源的浪費, 需要根據(jù)應(yīng)用和設(shè)備選擇精確定量的 AOT 處理.
    例如,在 UITableView 中渲染一組記錄時,在載入列表是處理全部的記錄并不是明智之舉,基于單元格的高度,如果設(shè)備可以渲染 N 條記錄, 那么3N 或4N 則是一個理想的數(shù)據(jù)載入規(guī)模, 類似的,用戶快速滑動,則不應(yīng)立即載入記錄,而應(yīng)推遲帶滾動速度下降到某一閾值.精確的閾值應(yīng)該由每個單元格的處理時間和單元格的 UI 的復(fù)雜性來決定

二 網(wǎng)絡(luò)

智能的網(wǎng)絡(luò)訪問管理可以讓應(yīng)用響應(yīng)的更快,并有助于延長電池壽命.在無法訪問網(wǎng)絡(luò)時,應(yīng)該推遲后續(xù)的網(wǎng)絡(luò)請求, 直到網(wǎng)絡(luò)連接恢復(fù)為止.
此外,應(yīng)避免在沒有連接 WiFi 的情況下進行高寬帶消耗的操作.比如視頻流, 眾所周知, 蜂窩無線系統(tǒng)(LTE,4G,3G等)對電量的消耗遠遠大于 WiFi信號, 根源在于 LTE 設(shè)備基于多輸入,多輸出技術(shù),使用多個并發(fā)信號以維護兩端的 LTE 鏈接,類似的,所有的蜂窩數(shù)據(jù)鏈接都會定期掃描以尋找更強的信號.
因此:我們需要

  • 在進行任何網(wǎng)絡(luò)操作之前,先檢查合適的網(wǎng)絡(luò)連接是否可用
  • 持續(xù)監(jiān)視網(wǎng)絡(luò)的可用性,并在鏈接狀態(tài)發(fā)生變化時給與適當(dāng)?shù)姆答?/li>

三 定位管理器和 GPS

這個知識點我項目中并沒有用到定位相關(guān)的功能 ,不過也總結(jié)一下書中所講的知識點 有用的定位功能的朋友可以參考此知識點來優(yōu)化自己的 app

我們都知道定位服務(wù)是很耗電的,使用 GPS 計算坐標(biāo)需要確定兩點信息:

  • 時間鎖
    每個 GPS 衛(wèi)星每毫秒廣播唯一一個1023位隨機數(shù), 因而數(shù)據(jù)傳播速率是1.024Mbit/s GPS 的接收芯片必須正確的與衛(wèi)星的時間鎖槽對齊
  • 頻率鎖
    GPS 接收器必須計算由接收器與衛(wèi)星的相對運動導(dǎo)致的多普勒偏移帶來的信號誤差

計算坐標(biāo)會不斷的使用 CPU 和 GPS 的硬件資源,因此他們會迅速的消耗電池電量
先來看一下初始化CLLocationManager并高效接受地理位置更新的典型代碼


#import "LLLocationViewController.h"
#import <CoreLocation/CoreLocation.h>

@interface LLLocationViewController ()<CLLocationManagerDelegate>
@property (nonatomic, strong)CLLocationManager *manager;
@end

@implementation LLLocationViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    self.manager = [[CLLocationManager alloc]init];
    self.manager.delegate = self;    
}

- (void)enableLocationButtonClick:(UIButton *)sender{
    
    self.manager.distanceFilter = kCLDistanceFilterNone;
    // 按照最大精度初始化管理器
    self.manager.desiredAccuracy = kCLLocationAccuracyBest;
    
    if (IS_IOS8) {
        [self.manager requestWhenInUseAuthorization];
    }
    [self.manager startUpdatingLocation];
}

- (void)locationManager:(CLLocationManager *)manager
     didUpdateLocations:(NSArray<CLLocation *> *)locations{
    
    CLLocation *loc = [locations lastObject];
    // 使用位置信息
}
3.1 最佳的初始化
  • distanceFilter
    只要設(shè)備的移動超過了最小的距離, 距離過濾器就會導(dǎo)致管理器對委托對象的 LocationManager:didUpdateLocations:事件通知發(fā)生變化,該距離單位是 M
  • desiredAccuracy
    精度參數(shù)的使用直接影響了使用天線的個數(shù), 進而影響了對電池的消耗.精度級別的選取取決于應(yīng)用的具體用途,精度是一個枚舉 我們應(yīng)該依照不同的需求去恰當(dāng)?shù)倪x取精度級別

距離過濾器只是軟件層面的過濾器,而精度級別會影響物理天線的使用.當(dāng)委托方法 LocationManager:didUpdateLocations:被調(diào)用時,使用距離范圍更廣泛的過渡器只會影響間隔.另一方面,更高的精度級別意味著更多的活動天線,這會消耗更多的能量

3.2 關(guān)閉無關(guān)緊要的特性

判斷何時需要跟蹤位置的變化, 在需要跟蹤的時候調(diào)用 startUpdatingLocation方法, 無須跟蹤時調(diào)用stopUpdatingLocation方法.

當(dāng)應(yīng)用在后臺運行或用戶沒有與別人聊天時,也應(yīng)該關(guān)閉位置跟蹤,也就說說,瀏覽媒體庫,查看朋友列表或調(diào)整應(yīng)用設(shè)置時, 都應(yīng)該關(guān)閉位置跟蹤

3.3 只在必要時使用網(wǎng)絡(luò)

為了提高電量的使用效率, IOS 總是盡可能地保持無線網(wǎng)絡(luò)關(guān)閉.當(dāng)應(yīng)用需要建立網(wǎng)絡(luò)連接時, IOS 會利用這個機會向后臺應(yīng)用分享網(wǎng)絡(luò)會話, 以便一些低優(yōu)先級能夠被處理, 如推送通知, 收取電子郵件等
關(guān)鍵在于每當(dāng)用戶建立網(wǎng)絡(luò)連接時,網(wǎng)絡(luò)硬件都會在連接完成后多維持幾秒的活動時間.每次集中的網(wǎng)絡(luò)通信都會消耗大量的電量
要想減輕這個問題帶來的危害,你的軟件需要有所保留的的使用網(wǎng)絡(luò).應(yīng)該定期集中短暫的使用網(wǎng)絡(luò),而不是持續(xù)的保持著活動的數(shù)據(jù)流.只有這樣,網(wǎng)絡(luò)硬件才有機會關(guān)閉

3.4 后臺定位服務(wù)

CLLocationManager提供了一個替代的方法來監(jiān)聽位置的更新. [self.manager startMonitoringSignificantLocationChanges]可以幫助你在更遠的距離跟蹤運動.精確的值由內(nèi)部決定,且與distanceFilter無關(guān)
使用這一模式可以在應(yīng)用進入后臺后繼續(xù)跟蹤運動,典型的做法是在應(yīng)用進入后臺時執(zhí)行startMonitoringSignificantLocationChanges方法,而當(dāng)應(yīng)用回到前臺時執(zhí)行startUpdatingLocation 如下代碼

- (void)applicationDidEnterBackground:(UIApplication *)application {
    [self.manager stopUpdatingLocation];
    [self.manager startMonitoringSignificantLocationChanges];
}
- (void)applicationWillEnterForeground:(UIApplication *)application {    
    [self.manager stopMonitoringSignificantLocationChanges];
    [self.manager startUpdatingLocation];    
}
3.5 在應(yīng)用關(guān)閉后重啟

在其他應(yīng)用需要更多資源時, 后臺的應(yīng)用可能會被關(guān)閉.在這種情況下, 一旦發(fā)生位置變化,應(yīng)用會被重啟,因而需要重新初始化監(jiān)聽過程,若出現(xiàn)這種情況,application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions方法會受到鍵值為UIApplicationLaunchOptionsLocationKey的條目
如下代碼: 在應(yīng)用關(guān)閉后重新初始化監(jiān)聽

- (void)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // 因缺乏資源而關(guān)閉應(yīng)用后, 監(jiān)測應(yīng)用是否因為位置變化而被重啟
    if (launchOptions[UIApplicationLaunchOptionsLocationKey]) {
// 開啟監(jiān)測位置的變化
        [self.manager startMonitoringSignificantLocationChanges];
    }
}

四 屏幕

屏幕非常耗電, 屏幕越大就越耗電.當(dāng)然,如果你的應(yīng)用在前臺運行且與用戶進行交互,則勢必會使用屏幕并消耗電量
這里仍然有一些方案可以優(yōu)化屏幕的使用

4.1 動畫

當(dāng)應(yīng)用在前臺時, 使用動畫, 一旦應(yīng)用進入了后臺,則立即暫停動畫.通常來說,你可以通過監(jiān)聽 UIApplicationWillResignActiveNotificationUIApplicationDIdEnterBackgroundNotification的通知事件來暫涂叫希或停止動畫,也可以通過監(jiān)聽UIApplicationDidBecomeActiveNotification的通知事件來恢復(fù)動畫

4.2 視頻播放

我在上家公司就是做視頻類App的,當(dāng)時就采用了這個技術(shù) 保持屏幕常亮

在視頻播放期間,最好保持屏幕常量.可以使用UIApplication對象的 idleTimerDisabled屬性來實現(xiàn)這個目的.一旦設(shè)置了 YES, 他會阻止屏幕休眠,從而實現(xiàn)常亮.
與動畫類似,你可以通過相應(yīng)應(yīng)用的通知來釋放和獲取鎖

4.3 多屏幕

使用屏幕比休眠鎖或暫停/恢復(fù)動畫要復(fù)雜得多

如果正在播放電影或運行動畫, 你可以將它們從設(shè)備的屏幕挪到外部屏幕,而只在設(shè)備的屏幕上保留最基本的設(shè)置,這樣可以減少設(shè)備上的屏幕更新,進而延長電池壽命

處理這一場景的典型代碼會涉及一下步驟

  • 1 在啟動期間監(jiān)測屏幕的數(shù)量 如果屏幕數(shù)量大于1,則進行切換
  • 2 監(jiān)聽屏幕在鏈接和斷開時的通知. 如果有新的屏幕加入, 則進行切換. 如果所有的外部屏幕都被移除,則恢復(fù)到默認(rèn)顯示

@interface LLMultiScreenViewController ()
@property (nonatomic, strong)UIWindow  *secondWindow;
@end

@implementation LLMultiScreenViewController

- (void)viewDidAppear:(BOOL)animated{
    [super viewDidAppear:animated];
    [self updateScreens];
}

- (void)viewDidDisappear:(BOOL)animated{
    [super viewDidDisappear:animated];
    [self disconnectFromScreen];
    
}

- (void)viewDidLoad {
    [super viewDidLoad];    
    [self registerNotifications];    
}

- (void)registerNotifications{
    
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    [nc addObserver:self selector:@selector(scrensChanged:) name:UIScreenDidConnectNotification object:nil];
}

- (void)scrensChanged:(NSNotification *)nofi{
    [self updateScreens];
}

- (void)updateScreens{
    
    NSArray *screens = [UIScreen screens];
    if (screens.count > 1) {
        UIScreen *secondScreen = [screens objectAtIndex:1];
        CGRect rect =secondScreen.bounds;
        if (self.secondWindow == nil) {
            self.secondWindow = [[UIWindow alloc]initWithFrame:rect];
            self.secondWindow.screen = secondScreen;
            
            LLScreen2ViewController *svc = [[LLScreen2ViewController alloc]init];
            svc.parent = self;
            self.secondWindow.rootViewController = svc;
        }
        self.secondWindow.hidden = NO;
    }else{
        [self disconnectFromScreen];
    }
}

- (void)disconnectFromScreen{
    
    if (self.secondWindow != nil) {
        // 斷開連接并釋放內(nèi)存
        self.secondWindow.rootViewController = nil;
        self.secondWindow.hidden = YES;
        self.secondWindow = nil;
    }
}

- (void)dealloc{
    
    [[NSNotificationCenter defaultCenter] removeObserver:self];
    
}

五 其他硬件

當(dāng)你的應(yīng)用進入后臺是, 應(yīng)該釋放對這些硬件的鎖定:

  • 藍牙
  • 相機
  • 揚聲器,除非應(yīng)用是音樂類的
  • 麥克風(fēng)

基本規(guī)則: 只有當(dāng)應(yīng)用處于前臺時才與這些硬件進行交互, 應(yīng)用處于后臺時應(yīng)停止交互

不過揚聲器和無線藍牙可能例外, 如果你正在開發(fā)音樂,收音機或其他的音頻類應(yīng)用,則需要在應(yīng)用進入后臺后繼續(xù)使用揚聲器.不要讓屏幕僅僅為音頻播放的目的而保持常量.類似的, 若應(yīng)用還有未完成的數(shù)據(jù)傳輸, 則需要在應(yīng)用進入后臺后持續(xù)使用無線藍牙,例如,與其他設(shè)備傳輸文件

六 電池電量與代碼感知

這一條我發(fā)現(xiàn) 摩拜單車小程序 做的挺好的,如果晚上騎車掃描二維碼的話是需要開閃光燈達到照亮二維碼的效果, 但是如果你的手機處于低電量的話 ,你的閃光燈是打不開的, 這一個細(xì)節(jié)就說明了用戶體驗很重要,他首先會保證不讓你的手機因為閃光燈而直接關(guān)機

一個智能的應(yīng)用會考慮到電池的電量和自身的狀態(tài), 從而決定是否執(zhí)行資源密集消耗性的操作.另外一個有價值的點是對充電的判斷,確定設(shè)備是否處于充電狀態(tài)

來看一下此處的代碼實施

- (BOOL)shouldProceedWithMinLevel:(NSUInteger)minLevel{
    
    UIDevice *device = [UIDevice currentDevice];
    // 打開電池監(jiān)控
    device.batteryMonitoringEnabled = YES;
    
    UIDeviceBatteryState state = device.batteryState;
    // 在充電或電池已經(jīng)充滿的情況下,任何操作都可以執(zhí)行
    if (state == UIDeviceBatteryStateCharging ||
        state == UIDeviceBatteryStateFull) {
        return YES;
    }    
    // UIdevice 返回的 batteryLevel 的范圍在0.00 ~ 1.00
    NSUInteger batteryLevel = (NSUInteger)(device.batteryLevel * 100);
    if (batteryLevel >= minLevel) {
        return YES;
    }
    return NO;
}

我們也可以得到應(yīng)用對 CPU 的利用率

// 需要導(dǎo)入這兩個頭文件
#import <mach/mach.h>
#import <assert.h>

- (float)appCPUUsage{
    kern_return_t kr;
    task_info_data_t info;
    mach_msg_type_number_t infoCount = TASK_INFO_MAX;    
    kr = task_info(mach_task_self(), TASK_BASIC_INFO, info, &infoCount);    
    if (kr != KERN_SUCCESS) {
        return -1;
    }    
    thread_array_t thread_list;
    mach_msg_type_number_t thread_count;
    thread_info_data_t thinfo;
    mach_msg_type_number_t thread_info_count;
    thread_basic_info_t basic_info_th;
    
    kr = task_threads(mach_task_self(), &thread_list, &thread_count);
    if (kr != KERN_SUCCESS) {
        return -1;
    }
    float tot_cpu = 0;
    int j;
    for (j = 0; j < thread_count; j++) {
        thread_info_count = THREAD_INFO_MAX;
        kr = thread_info(thread_list[j], THREAD_BASIC_INFO, thinfo, &thread_info_count);
        
        if (kr != KERN_SUCCESS) {
            return -1;
        }        
        basic_info_th = (thread_basic_info_t)thinfo;
        if (!(basic_info_th -> flags & TH_FLAGS_IDLE)) {
            tot_cpu += basic_info_th -> cpu_usage / TH_USAGE_SCALE * 100.0;
        }
    }
    vm_deallocate(mach_task_self(), (vm_offset_t)thread_list, thread_count * sizeof(thread_t));
    return tot_cpu;
    
}

當(dāng)剩余電量較低時,提醒用戶,并請求用戶授權(quán)執(zhí)行電源密集型的操作,---當(dāng)然,只在 用戶同意的前提下執(zhí)行
總是用一個指示符(也就是進度條百分比)顯示長時間任務(wù)的進度, 包括設(shè)備上即將完成的計算或者只是下載一些內(nèi)容.向用戶提供完成進度的估算, 以幫助他們決定是否需要為設(shè)備充電

七 最佳實踐

以下的最佳實踐可以確保對電量的謹(jǐn)慎使用, 遵循以下要點,應(yīng)用可以實現(xiàn)對電量的高效使用.

  • 最小化硬件使用. 換句話說,盡可能晚的與硬件打交道, 并且一旦完成任務(wù)立即結(jié)束使用
  • 在進行密集型任務(wù)前, 檢查電池電量和充電狀態(tài)
  • 在電量低時, 提示用戶是否確定要執(zhí)行任務(wù),并在用戶同意后再執(zhí)行
  • 或提供設(shè)置的選項,允許用戶定義電量的閾值,以便在執(zhí)行秘籍型操作前提示用戶

下邊代碼展示了設(shè)置電量的閾值以提示用戶.


- (IBAction)onIntensiveOperationButtonClick:(id)sender {
    
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    
    BOOL prompt = [defaults boolForKey:@"promptForBattery"];
    int minLevel = [defaults integerForKey:@"minBatteryLevel"];
    
    BOOL canAutoProceed = [self shouldProceeWithMinLevel:minLevel];
    
    if (canAutoProceed) {
        [self executeIntensiveOperation];
    }else{
        
        if (prompt) {
            UIAlertView *view = [[UIAlertView alloc]initWithTitle:@"提示" message:@"電量低于最小值,是否繼續(xù)執(zhí)行" delegate: self cancelButtonTitle:@"取消" otherButtonTitles:@"確定"];
            [view show];
        }else{
            
            [self queueIntensiveOperation];
        }
    }
}

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    
    if (buttonIndex == 0) {
        [self queueIntensiveOperation];
    }else{
        [self executeIntensiveOperation];
    }
}

代碼對應(yīng)的配圖如下

電量水平的閾值和提示選項在應(yīng)用中的設(shè)置
  • 設(shè)置由兩個條目組成:promptForBattery(應(yīng)用設(shè)置中的撥動開關(guān),表明是否要在低電量時給予提示)和miniBatteryLevel(區(qū)間為0~100的一個滑塊,表明了最低電量------在此示例中,用戶可以自行調(diào)整),在實際項目中應(yīng)用的開發(fā)人員通常根據(jù)操作的復(fù)雜性和密集性對閾值進行預(yù)設(shè).不同的密集型操作可能會有不同的最低電量需求
  • 在實際執(zhí)行密集操作之前,檢查當(dāng)前電量是否足夠, 或者手機是否正在充電.這就是我們判斷是否可以進行后續(xù)處理的邏輯,圖中你可以有自己的定制---最低電量和充電狀態(tài)

用戶總是隨身攜帶者手機,所以編寫省電的代碼就格外重要, 畢竟手機的移動電源并不是隨處可見,不過現(xiàn)在北京的街電共享充電寶好像很不錯 本人逛街會經(jīng)常使用街電充電寶,但還是要盡可能的為用戶省電
在無法降低任務(wù)復(fù)雜性時, 提供一個對電池電量保持敏感的方案并在適當(dāng)?shù)臅r機提示用戶, 會讓用戶感覺很良好, 并且因此會成為你 APP 的永久用戶

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末猴抹,一起剝皮案震驚了整個濱河市哗脖,隨后出現(xiàn)的幾起案子作喘,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,839評論 6 482
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡赖瞒,警方通過查閱死者的電腦和手機女揭,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,543評論 2 382
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來冒黑,“玉大人田绑,你說我怎么就攤上這事÷盏” “怎么了掩驱?”我有些...
    開封第一講書人閱讀 153,116評論 0 344
  • 文/不壞的土叔 我叫張陵,是天一觀的道長冬竟。 經(jīng)常有香客問我欧穴,道長,這世上最難降的妖魔是什么泵殴? 我笑而不...
    開封第一講書人閱讀 55,371評論 1 279
  • 正文 為了忘掉前任涮帘,我火速辦了婚禮,結(jié)果婚禮上笑诅,老公的妹妹穿的比我還像新娘调缨。我一直安慰自己,他們只是感情好吆你,可當(dāng)我...
    茶點故事閱讀 64,384評論 5 374
  • 文/花漫 我一把揭開白布弦叶。 她就那樣靜靜地躺著,像睡著了一般妇多。 火紅的嫁衣襯著肌膚如雪伤哺。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,111評論 1 285
  • 那天者祖,我揣著相機與錄音立莉,去河邊找鬼。 笑死七问,一個胖子當(dāng)著我的面吹牛蜓耻,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播械巡,決...
    沈念sama閱讀 38,416評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼刹淌,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了坟比?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,053評論 0 259
  • 序言:老撾萬榮一對情侶失蹤嚷往,失蹤者是張志新(化名)和其女友劉穎葛账,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體皮仁,經(jīng)...
    沈念sama閱讀 43,558評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡籍琳,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,007評論 2 325
  • 正文 我和宋清朗相戀三年菲宴,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片趋急。...
    茶點故事閱讀 38,117評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡喝峦,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出呜达,到底是詐尸還是另有隱情谣蠢,我是刑警寧澤,帶...
    沈念sama閱讀 33,756評論 4 324
  • 正文 年R本政府宣布查近,位于F島的核電站眉踱,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏霜威。R本人自食惡果不足惜谈喳,卻給世界環(huán)境...
    茶點故事閱讀 39,324評論 3 307
  • 文/蒙蒙 一希太、第九天 我趴在偏房一處隱蔽的房頂上張望茬末。 院中可真熱鬧,春花似錦巴席、人聲如沸大猛。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,315評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽胎署。三九已至吆录,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間琼牧,已是汗流浹背恢筝。 一陣腳步聲響...
    開封第一講書人閱讀 31,539評論 1 262
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留巨坊,地道東北人撬槽。 一個月前我還...
    沈念sama閱讀 45,578評論 2 355
  • 正文 我出身青樓,卻偏偏與公主長得像趾撵,于是被迫代替她去往敵國和親侄柔。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,877評論 2 345

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