React本機在生產中崩潰

我們使用React Native構建了一款應用程序，以改進我們以前的Cordova應用程序的UX和功能。React本機在生產中崩潰

一切都很順利。幾個月的開發，QA，應用程序審查，然後我們發佈到App Store。它適用於我們嘗試過的所有設備，從iPhone 4到iPhone 6s +，我們在iOS 8.3（可以通過xCode下載的最早模擬器）上測試到10.0。

發佈之後，很多用戶開始報告該應用在閃屏甚至消失之前崩潰。我們在應用程序審查，測試或其他任何地方未見過的行爲。

我們調查了xCode中的「崩潰」，他們顯然沒有出現，因爲數百名用戶經歷了崩潰，我們只能看到少數 - 這似乎與創業無關。

我們發佈了Crashlytics集成的更新版本，但這也沒有幫助。我們也沒有得到Crashlytics這個具體問題的錯誤，這意味着這個問題可能發生在

任何想法我應該在哪裏看下？我們真的不想恢復到舊版本，並失去了數月的工作。

該應用程序使用大約100MB的內存，當一切都加載，所以這應該不是我想的問題。它發生在所有設備上的所有iOS版本上。我們無法將錯誤隔離到只有特定用戶。

來源

2016-11-21 ewooycom

是Crashlytics給你一個崩潰的堆棧跟蹤，或者是你沒有得到任何有關的任何更新回到你所有的崩潰？如果你什麼都看不到，那麼甚至在Crashlytics初始化發生之前它可能會崩潰。 –

這裏有一些信息缺失，我們需要幫助你：首先，crashlytics會給你什麼？其次，你能隔離一個這樣做的設備嗎？（這將是最重要的）。好消息是，一旦你獲得了這樣的設備，你通常可以在本地發佈設備並進行復制。一旦你有了上面的內容，我覺得這個問題會很快得到解決。醫生不能在沒有看到病人的情況下對待他人。 – GantMan

在Crashlytics初始化之前一定會發生崩潰。我無法隔離正在發生的設備。我會相應地更新這個問題。 – ewooycom

的問題了，因爲我們和用戶之間的溝通不良的這麼長時間來解決。應用程序實際上是不會崩潰，只是沒有啓動（這是在一些用戶的眼中相同）。

當我們發現後，我們意識到其中一個事件沒有觸發（隱藏擴展啓動畫面的事件），這是用戶卡住的地方。我們使用的一個庫沒有正確處理錯誤情況，這使我們的工作變得更加困難。在測試中我很幸運地進入該狀態，並且可以從那裏繼續。

我更新了處理該場景的代碼，現在問題已解決。

來源

2016-11-30 23:18:52 ewooycom

我有這個問題。哪個活動應該開火？你是如何解決這個問題的？ –

當似乎沒有任何其他分析途徑時，我會採取簡單的伐木後退措施。

我以前在生產iOS應用程序中使用了以下技術。這是一項需要設置的工作，但一旦做到這一點，它對於未來的其他許多問題都是非常有用的。不僅僅是崩潰，而且還有其他奇怪的行爲，用戶報告你無法在測試環境中複製這些行爲。

應用程序應該做的第一件事是檢查如果以前的啓動是通過讀取下一個步驟應該在開始和先前啓動的結束被寫入默認某些值（細節成功與否）。如果以前的啓動不成功，給用戶選擇以某種「安全模式」運行（這意味着取決於你的應用在啓動時要做的事情，但對我而言，這意味着不加載任何數據，或者做除了顯示UI之外，沒有任何與數據相關的項目;對於某些應用程序，甚至可以加載完全不同的UI，其中僅包括診斷工具或數據刪除/重置工具）。
確定上一次啓動是否正常（或者這是有史以來的第一次啓動）之後，應用程序應該做的下一件事是儘快將某種「startupBegan」狀態寫入默認值，然後稍後只有當它完全啓動時（「完全啓動」意味着依賴於應用程序，但是您確實要確保用戶界面在這一點上完全響應，並且正在顯示它需要的所有內容;這可能有點難以確定，因爲有些事情在啓動畫面消失後才運行;如果找不到任何其他方式，我想你可以用計時器觸發它，但這會是相當難看 - 最好找到一些方法來確定啓動是否完全完成）。這些值可以用來確定啓動是否開始，但沒有完成，並且是步驟1（上面）用來確定前一次啓動是否成功的。
在應用程序中包含大量日誌記錄，並將日誌寫入文件。我認爲有第三方工具可以實現此目的，但是我編寫了自己的方法（如下），只需將stderr重定向到文件，如果在生產環境中運行並且未連接到XCode。請注意，NSLog()寫入stderr，而不是stdout。
使應用程序能夠將日誌文件發送到您的支持電子郵件地址 - 這必須在應用程序的「安全模式」（以及正常模式下）中可用。在正常模式下，我將其做得相當晦澀，以至於一切正常時用戶不會注意到它（例如，在「設置」或「關於」視圖底部的按鈕）。我告訴用戶如何在提交支持請求時找到該按鈕，我真的很需要這些支持請求。
在每次啓動時旋轉日誌以防止它們消耗太多空間，但一定要保持幾次旋轉，否則只會從「安全模式」啓動中獲取日誌，這是毫無用處的。

對此有許多變化是可能的。包括諸如只在用戶爲其配置設置時才啓用日誌記錄的事情。有時，當用戶報告特定問題時，您可能需要在代碼的特定區域添加大量日誌記錄，然後在問題解決後重新刪除它（如果您擔心記錄周圍的性能/存儲問題）。

對於我（的Objective-C）應用程序，對於包括我的代碼在啓動狀態寫入默認的地方是如下（可能有更好的地方更適合您的應用程序）：

「startupBegan」早在應用程序委託的application:didFinishLaunchingWithOptions:
「startupCompleted」在端視圖控制器的viewDidAppear（NOT viewWillAppear！有很多東西可以去錯了這兩者之間發送）

PS。我的舊的日誌重定向和輪換方法是像這樣（的Objective-C）：

- (void)logRedirectRotate { 
    // If stderr not going to an XCode console (then running in production) 
    if (! isatty(STDERR_FILENO)) { 
     // Rotate logs 

     int rotationsCount = 3; 
     NSMutableArray *logRotations = [NSMutableArray array]; 

     for (int i = 0; i < rotationsCount; i++) { 
      [logRotations addObject:[pathToLogsDir stringByAppendingPathComponent:[NSString stringWithFormat:@"appnameorbundleid.%d.log", i]]]; 
     } 

     [[NSFileManager defaultManager] removeItemAtPath:[logRotations lastObject] error:nil]; 

     for (int i = rotationsCount - 1; i > 0; i--) { 
      [[NSFileManager defaultManager] moveItemAtPath:[logRotations objectAtIndex:i - 1] toPath:[logRotations objectAtIndex:i] error:nil]; 
     } 

     // Redirect stderr to current log file rotation 
     freopen([[logRotations objectAtIndex:0] cStringUsingEncoding:NSASCIIStringEncoding],"a+",stderr); 
    } 
}

來源

2016-11-24 01:01:55

您的建議非常感謝。我開始實施，但是在完成之前我們走上了正軌。我會給你賞金，因爲我從你的答案中得到了一些有益於未來的想法。謝謝！ – ewooycom

嘿謝謝！很高興聽到你解決了。我很好奇聽到實際發生的事情，所以讀你自己的答案很有意思。 –

我有這個問題，我的情況可能很具體，但我會分享我的經驗。

這裏的關鍵是應用程序只在生產中崩潰，所以它只是在生產中被解僱了，這是搞亂了構建。在我們的案例中，罪魁禍首是縮小的React's dependencies之一。

東西拿走：

密切注視你的依賴
使用崩潰日誌

來源

2017-03-09 01:55:19 tropicalfish

React本機在生產中崩潰

回答

相關問題