分析：網路部分是另起乙個執行緒後台執行的，其中還涉及讀取sqlite**，最開始懷疑是不是第一次產生了資料，第二次資料庫中有資料，讀取時有問題，後來還真發現了乙個可能為null指標的問題，但是這塊修改了，閃退依舊。
然後想著打日誌排查，但是release模式不好排查，只好將日誌寫入檔案，看執行到**崩潰，就這樣一步步加日誌，最後發現是執行到乙個從網路位元組流讀取int64_t的時候崩潰的，**如下：
var = (int64_t)ntohll( *(uint64_t*)buf );
其中ntohll是我寫的乙個從網路序轉換到主機序的乙個輔助函式（因為系統只提供了ntohs和ntohl兩個版本），在進入ntohll之前就崩潰了，這又讓我懷疑是不是函式呼叫棧爆了，因為在這一步之前還可以執行，這一步唯一的操作就是呼叫ntohll，需要乙個壓棧操作，雖然一般只有頻繁遞迴的情況才有可能出現，但是發現把函式呼叫展開成**還是會掛。
然後我又嘗試把變數位址都列印出來，因為buf雖然是個指標，但是它的初始位置是乙個陣列，並且可以保證沒有走出這個陣列，各種百思不得姐。
最後終於發現，是記憶體對齊引發的bug，也就是說，如果讀取乙個整型變數，不從某個對齊的位址（目前arm是4位元組對齊）開始讀取，那麼就會引發乙個硬體的exception（稱之為exc_arm_da_align）。
那麼為什麼在除錯時沒有引發這個bug呢？個人猜測是ios在這個模式下捕獲了這個異常，並且將其轉換為兩次記憶體請求了。
解決辦法：編譯器會將所有宣告的整型變數（或者多位元組變數，例如float、double）對齊到4的倍數，所以我們可以先memcpy到變數，再對變數操作。**如下：
memcpy( &var, buf, sizeof(var) ); var = (int64_t)ntohll( var );
不過memcpy也可能有問題，依賴於memcpy的實現（裡面不能出現未對齊的強轉指標），更保險的方法是自己寫個迴圈進行單個位元組的賦值。
iOS 關於UIImage的壓縮問題
uiimage img uiimage imagenamed example.png 兩種轉化方式，nsdata data uiimagejpegrepresentation img,0.0001 nsdata data1 uiimagepngrepresentation img nslog dat...
iOS 關於 iOS 10 中 ATS 的問題
相比於使用nsallowsarbitraryloads將全部 http 內容開放，選擇使用n ceptiondomains來針對特定的網域名稱，通過設定該網域名稱下的n ceptionallowsinsecurehttploads來開放 http 應該要相對容易過審核。需要訪問的網域名稱是第三方伺服...
iOS關於適配螢幕的問題 1
在以前，只要雖然蘋果就由3.5寸跟4寸屏，但是寬度都是沒有變化的，所以適配螢幕的問題還是很好做的。現在因為4.7寸的iphone6和5.5寸的iphone6 plus的寬度大了，適配起來就更加麻煩了 在網上找了很久，很多人說的都是影象 圖示的畫素問題，沒有提到怎麼適配。在這裡簡單說一下 但是這樣還是...