讓你的app優雅的crash三部曲
DESCRIPTION
MOPCON 2013TRANSCRIPT
讓你 app 優雅的 crash 三部曲
Hokila
MOPCON 2013
about me
•iOS developer
•ex-outsourcing app company
•enterprise app
•Cocoaheads Taipei
•Splashtop
Before Start
如果app不會crash的可以出去了
Before Start
如果app不會crash的可以出去了
等下的demo沒有crash 那就是失敗了
Before Start
我當app開發者這麼久，我發現一件事，通常使用者不會report crash，而是直接給一顆心評價
MOPCON 2012
源起
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
直接給一顆星
•app 如果4顆星以下佔多數，那一定是哪裡錯了
拿到（很多）一顆星
•app 如果4顆星以下佔多數，那一定是哪裡錯了
拿到（很多）一顆星
•發現一顆星很多，趕快修bug上新版本洗評價
crash rate?
•official app?
•memory leak
•0.1% ~0.3%
首部曲
crash 後
首部曲
crash 後可以不要給我一顆星嗎
怒氣發洩機制
托球給他殺 出現時機很重要
log 蒐集
•怒氣發洩機制
•詳細log
!
•error code
crash 後
正常⼈人都看不懂
error code
用文字敘述取代error code
和View 結合
demo uservoice
•許多負面評價留在app裡
•更了解user對app的觀感
•有些問題user彼此幫忙解決
benefit
•怒氣發洩機制
•詳細log
•error code
•user feedback / forum
crash 後
二部曲 crash 時
不是每個user 都會給comment 就是要給一顆星
UserVoice 缺點
不給comment /log那我就自己拿
•google analytics
•Crittercism
•Flurry
•Mixpanel
user tracking
iTune connect official crash report
demo crashlytics
benefit
•bug很多時、找到最值得解的bug
•順便找到user最喜歡用的功能
benefit
•bug很多時、找到最值得解的bug
•順便找到user最喜歡用的功能
•提高user黏滯性
Flurry
Flurry
Flurry
•Crashlytics
•Flurry
•Crittercism ($)
•TestFlight
•Google Analytics
•Bugsense ($)
•自己做的
catch exception
https://github.com/Hokila/LetMeCrash
https://speakerdeck.com/zonble/debug-debug
Debug Debug:Crash Report與各種常見疑難雜症
catch exception
https://github.com/Hokila/LetMeCrash
https://speakerdeck.com/zonble/debug-debug
Debug Debug:Crash Report與各種常見疑難雜症
Let’s demo
最後一部曲 crash 前
sales PM(UX) (SA) backEnd mobile clientUI
contribute cost/time consumption
首先我們要知道 app開發流程
要面對的問題
•app 賣不賣 / 有不有趣
•performance issue
•security issue
要面對的問題
•app 賣不賣 / 有不有趣
•performance issue
•security issue
http://www.slideshare.net/hokilaj/ios-app-security
iOS app security:analyze and defense
crash 前
•想想spec
•記得寫防禦程式，最好有alert
•除了依靠QA 外也要寫test code
•最常錯的是...
API verify
•testbed
•固定去看看api是否健在
•static query?
•問題都是出在access到不存在的資料
So
•後：crash 沒關係、不要給我一顆星就好
•中：要crash得有意義 (log、user tracking、feedback)
•前：做盡一切保護，避免crash
