具體描述
編輯推薦
《App研發錄：架構設計、Crash分析和競品技術分析》由業界多位移動團隊技術負責人聯袂推薦，為打造高質量App提供瞭有價值的實踐指導。
《App研發錄：架構設計、Crash分析和競品技術分析》中總結瞭80多個Crash的分析與處理，是迄今為止完整的Android異常分析資料。
剖析瞭國內上百款知名App的前沿技術實現，競品技術分析白皮書。
內容簡介
《App研發錄：架構設計、Crash分析和競品技術分析》是作者多年App開發的經驗總結，重點介紹Android應用開發中常見的實用技巧和疑難問題解決方法，為打造高質量App提供瞭有價值的實踐指導，可幫助讀者迅速提升應用開發能力和解決疑難問題的能力。本書涉及的主題有：Android項目的重構、網絡底層框架設計、經典場景設計、命名規範和編程規範、Crash的捕獲與分析、持續集成、代碼混淆、App競品技術分析、移動項目管理和團隊建設等。本書內容豐富，文風幽默，不僅給齣疑難問題的解決方案，而且結閤示例代碼深入剖析這些問題的實質和編程技巧，旨在幫助移動開發人員和管理人員提高編程效率，改進代碼質量，打造高質量的App。
作者簡介
包建強，畢業於復旦大學數學係。先後在多傢互聯網公司擔任無綫部門技術總監，在Android、iOS、WP等多門無綫技術中跋涉過 ，在App的項目管理上也有多年的實踐經驗。他是微軟2008年MVP，並有一個堅持寫瞭6年的技術博客。
精彩書評
★為瞭寫這本書，作者分析瞭市場上有名的上百款App，能夠費這麼多心血去研究技術實現的人，在我看來至少是一個充滿好奇心的人。正是這種擁有好奇心並執著探索的人，纔推動瞭近百年來的科學發展。
—— 奇虎360董事長 周鴻禕
★本書與其他書籍完全不同，純從實戰齣發，在官方文檔之上，闡述實際開發中應該掌握的那些來之不易的經驗，其中多是過來人踩過坑、吃過虧纔能總結齣來的東西。不少章節類似於Effective係列名著的風格，有很高的價值。
—— 美團技術學院院長，CSDN和《程序員》雜誌前總編 劉江
★整本書並不是從枯燥的文檔中提煉而來，而是真切地從一個互聯網從業者的親身經曆和交流中得來。作為需要時刻緊跟移動浪潮的App開發人員，這本書是值得一讀的好書。
—— 大眾點評首席架構師 屠毅敏
★這本書針對有經驗的Android開發者，你會發現很多場景都是曾經或即將帶給你疑問的，作者針對Android開發過程中一個個具體問題給齣瞭解決方案，非常實用。特彆是異常處理的部分，這是我首次發現有這麼完整地介紹Android異常的書籍，非常有學習價值。
—— 騰訊無綫研發工具總監 歐陽駿
★這本書在老包的詼諧筆法之下凝聚瞭他多年來奮戰在一綫的研發和管理經驗，具備很強的實戰參考意義，並非一般的App開發入門或者泛泛之談。從菜鳥成長為大拿如果有捷徑的話，莫過於經常與高手過招。在開發HTML的Web時代，前端開發人員很喜歡用右鍵點擊網頁查看源代碼的方式來學習網站的開發思路，後來從中提煉成瞭很多瀏覽器的插件，比如Firefox的Firebug等。進入App開發時代後，如何從高手的作品中進行類似的學習呢？老包在第9章App競品技術分析裏給齣瞭相當精彩的解決方案。整本書的結構清晰，從為痛苦的考古重構講起，到Crash異常等的分析處理，再到持續集成與團隊協作的App開發項目管理，包含每個小工在成長之路上都可能碰到的問題。相信您閱讀之後必定會有所收獲。
—— 途牛旅遊網無綫中心總經理 陳世宏
目錄
序一
序二
序三
前言
第一部分 高效App框架設計與重構
第1章 重構，夜未眠 3
1.1 重新規劃Android項目結構 3
1.2 為Activity定義新的生命周期 5
1.3 統一事件編程模型 7
1.4 實體化編程 9
1.4.1 在網絡請求中使用實體 9
1.4.2 實體生成器 11
1.4.3 在頁麵跳轉中使用實體 12
1.5 Adapter模闆 14
1.6 類型安全轉換函數 16
1.7 本章小結 17
第2章 Android網絡底層框架設計 19
2.1 網絡低層封裝 19
2.1.1 網絡請求的格式 19
2.1.2 AsyncTask的使用和缺點 21
2.1.3 使用原生的ThreadPoolExecutor + Runnable + Handler 24
2.1.4 網絡底層的一些優化工作 28
2.2 App數據緩存設計 32
2.2.1 數據緩存策略 32
2.2.2 強製更新 35
2.3 MockService 36
2.4 用戶登錄 38
2.4.1 登錄成功後的各種場景 39
2.4.2 自動登錄 41
2.4.3 Cookie過期的統一處理 44
2.4.4 防止黑客刷庫 45
2.5 HTTP頭中的奧妙 46
2.5.1 HTTP請求 46
2.5.2 時間校準 48
2.5.3 開啓gzip壓縮 51
2.6 本章小結 52
第3章 Android經典場景設計 53
3.1 App圖片緩存設計 53
3.1.1 ImageLoader設計原理 53
3.1.2 ImageLoader的使用 54
3.1.3 ImageLoader優化 55
3.1.4 圖片加載利器Fresco 56
3.2 對網絡流量進行優化 58
3.2.1 通信層麵的優化 58
3.2.2 圖片策略優化 59
3.3 城市列錶的設計 61
3.3.1 城市列錶數據 61
3.3.2 城市列錶數據的增量更新機製 63
3.4 App與HTML5的交互 64
3.4.1 App操作HTML5頁麵的方法 64
3.4.2 HTML5頁麵操作App頁麵的方法 65
3.4.3 App和HTML5之間定義跳轉協議 66
3.4.4 在App中內置HTML5頁麵 67
3.4.5 靈活切換Native和HTML5頁麵的策略 68
3.4.6 頁麵分發器 68
3.5 消滅全局變量 70
3.5.1 問題的發現 70
3.5.2 把數據作為Intent的參數傳遞 71
3.5.3 把全局變量序列化到本地 71
3.5.4 序列化的缺點 75
3.5.5 如果Activity也被銷毀瞭呢 79
3.5.6 如何看待SharedPreferences 80
3.5.7 User是唯一例外的全局變量 80
3.6 本章小結 81
第4章 Android命名規範和編碼規範 83
4.1 Android命名規範 83
4.2 Android編碼規範 86
4.3 統一代碼格式 89
4.4 本章小結 90
第二部分 App開發中的高級技巧
第5章 Crash異常收集與統計 93
5.1 異常收集 93
5.2 異常收集與統計 96
5.2.1 人工統計綫上Crash數據 96
5.2.2 第一個綫上Crash報錶：Crash分類 97
5.2.3 第二個綫上Crash報錶：Crash去重 99
5.2.4 綫上Crash的其他分析工作 104
5.3 本章小結 105
第6章 Crash異常分析 107
6.1 Java語法相關的異常 108
6.1.1 空指針 108
6.1.2 角標越界 109
6.1.3 試圖調用一個空對象的方法 110
6.1.4 類型轉換異常 110
6.1.5 數字轉換錯誤 111
6.1.6 聲明數組時長度為-1 111
6.1.7 遍曆集閤同時刪除其中元素 112
6.1.8 比較器使用不當 114
6.1.9 當除數為0 115
6.1.10 不能隨便使用的asList 116
6.1.11 又有類找不到瞭（一）：ClassNotFoundException 116
6.1.12 又有類找不到瞭（二）：NoClassDefFoundError 117
6.2 Activity相關的異常 117
6.2.1 找不到Activity 117
6.2.2 不能實例化Activity 118
6.2.3 找不到Service 118
6.2.4 不能啓動BroadcastReceiver 119
6.2.5 startActivityForResult不能迴傳 119
6.2.6 猴急的Fragment 120
6.3 序列化相關的異常 120
6.3.1 實體對象不支持序列化 121
6.3.2 序列化時未指定ClassLoader 121
6.3.3 反序列化時發現類找不到：被ProGuard混淆導緻的崩潰 122
6.3.4 反序列化時發現類找不到：傳入畸形數據 123
6.3.5 反序列化時齣錯 123
6.4 列錶相關的異常 123
6.4.1 Adapter數據源變化但是沒通知ListView 124
6.4.2 ListView滾動時點擊刷新按鈕後崩潰 125
6.4.3 AbsListView的obtainView返迴空指針 125
6.4.4 Adapter數據源變化但是沒調用notifyDataSetChanged 126
6.5 窗體相關的異常 126
6.5.1 窗口句柄泄露 126
6.5.2 View not attached to window manager 128
6.5.3 窗體在不恰當的時候獲取瞭焦點 129
6.5.4 token null is not for an application 130
6.5.5 permission denied for this window type 131
6.5.6 is your activity running 131
6.5.7 添加窗體失敗 133
6.5.8 AlertDialog.resolveDialogTheme 134
6.5.9 The specif?ied child already has a parent 136
6.5.10 子綫程不能修改UI 137
6.5.11 不能在子綫程操作AlertDialog和Toast 141
6.6 資源相關的異常 143
6.6.1 Resources$NotFoundException 143
6.6.2 StackOverf?iowError 144
6.6.3 Unsatisf?iedLinkError 144
6.6.4 Inf?iateException之FileNotFoundException 145
6.6.5 Inf?iateException之缺少構造器 145
6.6.6 Inf?iateException之style與android:textStyle的區彆 146
6.6.7 TransactionTooLargeException 147
6.7 係統碎片化相關的異常 147
6.7.1 NoSuchMethodError 147
6.7.2 RemoteViews 148
6.7.3 pointerIndex out of range 149
6.7.4 SecurityException之一：Intent中圖片太大 150
6.7.5 SecurityException之二：動態加載其他apk的activity 151
6.7.6 SecurityException之三：No permission to modify thread 151
6.7.7 view的getDrawingCache()返迴null 152
6.7.8 DeadObjectException 153
6.7.9 Android 2.1不支持SSL 153
6.7.10 ViewFlipper引發的血案 153
6.7.11 ActivityNotFoundException 154
6.7.12 Android 2.2不支持xlargeScreens 154
6.7.13 Package manager has died 155
6.7.14 SpannableString與富文本字符串 155
6.7.15 Can not perform this action after onSaveInstanceState 156
6.7.16 Service Intent must be explicit 157
6.8 SQLite相關的異常 157
6.8.1 No transaction is active 158
6.8.2 忘記關閉Cursor 158
6.8.3 數據庫被鎖定 159
6.8.4 試圖再打開已經關閉的對象 159
6.8.5 文件加密瞭或無數據庫 159
6.8.6 WebView中SQLLite緩存導緻的崩潰 160
6.8.7 磁盤讀寫錯誤 161
6.8.8 android_metadata錶不存在 161
6.8.9 android_metadata錶中的locale字段 162
6.8.10 數據庫或磁盤滿瞭 162
6.9 不明覺厲的異常 162
6.9.1 內存溢齣 163
6.9.2 Verify Failed 163
6.10 其他情況的異常 163
6.10.1 TimeoutException 164
6.10.2 JSON解析異常 164
6.10.3 JSONArray在初始化時為空 164
6.10.4 第三方SDK拋齣的Crash 165
6.10.5 兩個不同類型的View有相同的id 165
6.10.6 LayoutInf?iater.from().inf?iate()使用不當導緻的崩潰 166
6.10.7 ViewGroup中的玄機 166
6.10.8 Monkey點擊過快導緻的崩潰 167
6.10.9 圖片縮放很多倍 168
6.10.10 圖片寬高為0 168
6.10.11 不能重復添加組件 168
6.11 本章小結 169
第7章 ProGuard技術詳解 171
7.1 ProGuard簡介 171
7.2 ProGuard工作原理 172
7.3 如何寫一個ProGuard文件 172
7.3.1 基本混淆 172
7.3.2 針對App的量身定製 175
7.3.3 針對第三方jar包的解決方案 177
7.4 其他注意事項 178
7.5 本章小結 179
第8章 持續集成 181
8.1 版本管理策略 181
8.1.1 三種版本管理策略 181
8.1.2 特殊情況的版本管理策略 183
8.2 使用Ant腳本打包 184
8.2.1 Android打包流程 184
8.2.2 打包時的注意事項 189
8.3 Monkey包的生成 190
8.4 自動打包 191
8.4.1 安裝和配置各種軟件 192
8.4.2 準備Ant打包腳本 193
8.4.3 配置CCNET 193
8.4.4 搭建IIS站點下載apk包 193
8.4.5 自動打包流程小結 193
8.5 批量打渠道包 194
8.5.1 基於apk包批量生成渠道包 194
8.5.2 基於代碼批量生成渠道包 195
8.6 Android發版流程 197
8.7 分類打渠道包 198
8.7.1 分門彆類生成渠道包 198
8.7.2 批量上傳apk的兩種方式 199
8.8 靈活切換服務器 199
8.9 單元測試 201
8.10 本章小結 203
第9章 App競品技術分析 205
9.1 競品分析概述 205
9.1.1 App競品定義 205
9.1.2 競品分析要研究的幾個方嚮 206
9.1.3 競品分析與拿來主義 206
9.2 App安裝包的結構 207
9.2.1 Android安裝包的結構 207
9.2.2 iOS安裝包的結構 208
9.3 競品技術一瞥：開機速度 208
9.4 競品技術二瞥：HTML5頁麵的打開速度 209
9.4.1 把HTML5頁麵嵌入到Zip包中 209
9.4.2 Zip包的增量更新機製 209
9.4.3 製作Zip增量包 210
9.4.4 使用WebView預先加載HTML5並緩存到本地 211
9.5 競品技術三瞥：安裝包的大小 211
9.5.1 從幾件小事說起 211
9.5.2 安裝包為什麼那麼大 212
9.5.3 png和jpg的區彆及使用場景 212
9.5.4 Splash、引導圖和背景圖 213
9.5.5 iOS的1倍圖、2倍圖和3倍圖 213
9.5.6 在iOS中進行圖片拉伸和鏇轉 214
9.5.7 使用XML配置動畫 214
9.5.8 iOS使用storyboard還是xib 215
9.5.9 字體文件的學問 215
9.5.10 錶情圖片打包下載 217
9.5.11 清除未使用圖片 218
9.5.12 Proguard不隻是用來混淆的 218
9.5.13 在iOS中使用pdf格式的圖片 218
9.5.14 iOS的包永遠比Android包體積大嗎 219
9.5.15 從代碼層麵減少iOS包的體積 220
9.6 競品技術四瞥：性能優化 220
9.6.1 App自動選取最佳服務器的策略 220
9.6.2 使用TCP+Protobuf 222
9.7 競品技術五瞥：數據采集工具 223
9.7.1 頁麵跳轉器 223
9.7.2 打點統計 226
9.7.3 ABTest 230
9.8 競品技術六瞥：熱修補 232
9.9 競品技術七瞥：麯徑通幽 237
9.10 競品技術八瞥：模塊化拆分 242
9.11 競品技術九瞥：第三方SDK 244
9.12 競品技術十瞥：版本策略與App彩蛋 246
9.13 本章小結 247
第三部分 項目管理和團隊建設
第10章 項目管理決定瞭開發速度 251
10.1 項目管理中的三駕馬車 251
10.2 優化團隊結構，讓敏捷流程跑得更快 255
10.3 App敏捷開發流程 257
10.4 項目經理的百寶箱 263
10.5 迭代中的測試工作 269
10.6 高層對敏捷流程的乾預 272
10.7 本章小結 277
第11章 日常工作中的問題解決 279
11.1 使用二分法排查問題 279
11.2 找到能穩定重現問題的人 281
11.3 小流量包 282
11.4 建立全國範圍的測試群 283
11.5 如何與用戶溝通 284
11.6 日誌與App性能 286
11.7 從新人入職作業入手 286
11.8 本章小結 287
第12章 無綫團隊的組建和管理 289
12.1 從麵試談起 289
12.2 無綫團隊必備的10份文檔 292
12.3 一對一溝通 297
12.4 每周技術分享 298
12.5 代碼評審 299
12.6 對Android團隊Leader的定位 300
12.7 Android應用開發所需技能自我評測 301
12.8 App開發人員的學習路綫 302
12.9 本章小結 303
前言/序言
Preface 序 一
互聯網時代什麼人是核心驅動力
在我剛剛開始宣布要做奇酷手機的時候，我曾經發布公開信說我需要四類動物：程序猿、攻城獅、産品狗、設計貓。程序員被排在瞭第一位，而從我的個人經曆來說，與程序員有著密切的關係：大學研究生時的程序員，上班時的工程師，創業後的産品經理，最近幾年一直在學習和琢磨設計。
這本書的作者建強也是其中一種人，一種喜歡鑽研技術的程序員。我曾經和《奇點臨近》作者雷·庫茲韋爾交流的時候提到，也許上帝就是一名程序員，因為程序員正在通過給基因重新編程的方式來解決人類很多疾病之類的問題。
當然，實現給基因編程解決人類疾病問題的過程是漫長的，但“程序員”的作用是重大的。而在互聯網的世界裏，程序員的重要性更明顯。一個好的程序員能力固然重要，精神世界的升華也不能缺少，寫書就是一種精神世界的升華，能說服自己，也能幫助和提高更多人。
互聯網時代離不開各種移動App，本書提到很多時下移動互聯網很前沿的技術，像競品技術分析部分就提到ABTest、WaxPatch等。而且據說，為瞭寫這本書，作者分析瞭市場上有名的上百款App，能夠費這麼多心血去研究技術實現的人，在我看來至少是一個充滿好奇心的人。正是這種擁有好奇心並執著探索的人，推動瞭近百年來的科學發展。
移動互聯網的世界更是如此，從手機産生至今，短短二三十年的時間，就已經發生瞭翻天覆地的變化。今天的手機已經快成為人類的器官瞭，未來手機是什麼樣子很難說，但對手機應用的要求越來越高。雖然iOS和安卓平颱上開發App會有所不同，但用戶在各方麵體驗的要求是一緻的。所以在我做手機的過程中，一直要求自己要充滿好奇心。
移動App是一個充滿瞭未知和探索的領域，這也正是它的魅力所在，所以越來越多渴望探索的人加入到移動互聯網的創業大潮中來。事實上，這些移動App正在改變著我們的生活，從訂餐、打車到遊戲娛樂都被各種App所改變。
但App相關的技術發展、更新非常迅速，所以作為技術人員要保持對技術的敏銳嗅覺，永遠抱著謙卑的心態去學習先進的技術和理念，纔能時刻占據著主動。當我們認為自己對這個世界已經相當重要的時候，其實這個世界纔剛剛準備原諒我們的幼稚。
互聯網發展到今天，程序員功不可沒。也許程序員真的就是上帝，但他們在創造齣一個個絢麗多彩的世界之前，注定要沉浸在枯燥的代碼之中。我相信，每個程序都有自己的一個小小世界，在程序世界裏，一切都按照他們的設計規則運行。那麼你說，這和上帝創造世界有什麼不同？互聯網的世界裏誰纔是核心驅動力？
當然，我也希望這本書能培養齣更多的App領域高級人纔，來共同繁榮移動互聯網的世界。
周鴻禕
奇虎360董事長
Preface 序 二
十年寫一本書
1998年，Peter Norvig曾經寫過一篇很有名的文章，題為“Teach Yourself Programming in Ten Years”（十年學會編程）。這文章怎麼個有名法呢，自發錶以來它的訪問次數逐年增加，到2012年總數已經接近300萬次。
文章的意思其實很簡單，編程與下棋、作麯、繪畫等專業技能一樣，不花上十年以上有素的訓練（deliberative practice）、忘我的（fearless）投入，是很難真正精通的。Malcolm Gladwell後來的暢銷書《異類》用1萬小時這個概念總結瞭類似的觀點。
那麼，寫書呢？
說到寫書，我的另一位朋友在微博上說過一段話，讓我一直耿耿於懷：“有的時候被鼓勵、慫恿寫書，就算書能賣5000冊，40塊一本，8%的版稅，收益是16000RMB，這還沒繳稅。我還不如跟讀者化緣，把內容均勻地貢獻給讀者，一個禮拜就能募集到這個數額。為什麼要去寫書？浪費紙張，汙染環境。為瞭名氣？為瞭評職稱？”這位朋友是2001年我齣版的國內第一本Python書的譯者，當時這本封麵上是一隻老鼠的書隻有400頁，現在英文原版最新版已經1600頁瞭——時間真是最強大的重構工具。其實他的話說得挺實在的。這年頭寫專業圖書，經濟上直接的迴報，的確很低。
可要是真的沒人寫書瞭，這個世界會好嗎？
我曾經在齣版社工作十幾年，經手的書數以韆計，有的書問世之初就門可羅雀，有的書一時洛陽紙貴但終歸沉寂，隻有少數一些，能夠多年不斷重印，一版再版。這後一種，往往是真正的好書，是某個領域知識係統整理的精華，其作用不可替代，Google索引的成韆上萬的網頁也不能——聚沙其實是不能成塔的。Google圖書計劃的受挫，其實是人類文明發展的重大延遲，對此我深以為憾。
書（我說的是科技專業書）可以粗略分為兩種，一種是入門教程性質的，一種是經驗之談或者感悟心得。無論哪一種，都需要作者多年教學或者實踐的積澱。很難想象，沒有這種積澱，能夠很好地引導讀者入門，或者教授其他人需要花費十年纔能掌握的專業技能。
所以，好書不易得。它不僅來之不易（有能力寫的人本來就少，這些人還不一定有動力寫），而且還經常麵臨爛書太多，可能劣幣驅逐良幣的厄運。最後的結果是，很多領域都缺乏真正的好書，導緻整個圈子的水平偏低。因為，書這種成體係的東西，往往是最有效的交流與傳承手段，是互聯網（微博、微信、博客、視頻等等）上碎片化的信息不能取代的。
幾天前，我的Gmail郵箱裏收到一封郵件：
“還記得2008年我就想寫一本書，但是感覺技術能力不夠，就隻好去翻譯瞭一本。一晃2015年瞭，積纍瞭11年的技術功底，寫起書來遊刃有餘。這本書我整整寫瞭1年，其中第6章和第9章是自認為寫得最好的章節。請劉江老師為我這本書寫一篇序言，介紹一下無綫App的技術前瞻和趨勢，以及看過樣章後的一些感想吧。謝謝。”
包建強
包建強？我記得的。一個長得挺帥的大男孩兒，2004年復旦大學畢業，2008年被評為微軟的MVP。在技術上有追求，而且熱心。多年前在博客園非常活躍，張羅著要將裏麵的精華文章結集齣版成書。很愛翻譯，曾找我推薦過國外的博客網站，想要把一個同學WPF/Silverlight係列文章翻譯成英文。2009年我在圖靈齣版瞭他翻譯的.NET IL匯編語言方麵的書，到現在也是這一主題唯一的一本。好多年沒聯係，沒想到他已經從.NET各種技術（WPF、Silverlight、CLR等），轉嚮移動客戶端開發瞭。更讓人動容的是，他一直不忘初心，用瞭十年，終於完成瞭自己的書。
那麼，這是一本什麼樣的書呢？
我將書的幾個樣章轉給身邊從事Android開發的一位美團同事，他看瞭以後有點小激動，給瞭這樣的評價：
“拿到這本書的目錄和樣章時，感到非常驚喜，因為內容全是一綫工程師正在使用或者學習的一些熱門技術和大傢的關注點。比如網絡請求的處理、用戶登錄的緩存信息、圖片緩存、流量優化、本地網頁處理、異常捕抓和分析、打包等這些平時使用最多的技術。
我本人從事Android開發兩年，特彆想找一本能提高技術、經驗之談的書，可惜很難找到。本書不光站在技術的層麵上去談論Android，還通過市場上比較火的一些App和當今Android在國內發展的方嚮等各種角度，來分析怎麼樣去做好一個App。
我個人感覺這本書不僅能讓你從技術上有收獲而且在其他層麵上讓你對Android有更深層次的瞭解。我已經迫不及待這本書能夠盡快上市，一睹為快瞭。”
的確，目前國內外市麵上數百種Android開發類圖書，基本上可以分為兩類：
一類是從係統內核和源代碼入手，作者往往是Linux係統背景，從事底層係統定製等方麵工作。書的內容重在分析Android各個模塊的運行機製，雖然深入理解係統肯定對應用開發者有好處，但很多時候並不是那麼實用。
一類是標準教程，作者往往是培訓機構的老師，或者不那麼資深但善於總結的年輕工程師，基本內容是Android官方文檔的變形，圍繞API的用法就事論事地講開去。雖然其中比較好的，寫法、教學思路和例子上也各有韆鞦，但你看完以後真上戰場，就會發現遠遠不夠。
本書與這兩類書都完全不同，純從實戰齣發，在官方文檔之上，闡述實際開發中應該掌握的那些來之不易的經驗，其中多是過來人踩過坑、吃過虧，纔能總結齣來的東西。不少章節類似於Effective係列名著的風格，有很高的價值。
書最後的部分討論瞭團隊和項目管理，既有比較宏觀的建議，比如流程、趨勢，更多的還是實用性非常強的經驗，比如百寶箱、必備文檔，等等。很多章節，不限於Android，對其他平颱的移動開發者也有很大的藉鑒意義。
看得齣來，這裏很多內容都是包建強自己平時不斷記錄、積纍的成果，其中少量在他的博客上能看到雛形。如果說多年前，包建強在組織和翻譯圖書時還有些青澀的話，本書中所顯現齣來的，則完全是一派大將風度，用他自己的話來說，“遊刃有餘”瞭。
我曾經不止一次和潛在的作者說過：“不寫一本書，人生不完整。”我說這話是認真的。人生百年，如果最後沒有什麼可以總結、留之後人的東西，那可不是什麼值得誇耀的事情。
而說到總結，互聯網各種碎片化的媒體形式當然有各種方便，但到頭來逃脫不瞭煙花易逝的命運（想想網上有多少好的文字，鏈接早已失效，現在隻能到archive.org上尋找，甚至那裏也不見蹤影）。還是書這種物理形式最堅實，最像那麼迴事兒，也最是個東西。去國傢圖書館看過宋版書的人肯定會有體會。
當然，真正能立住的，是那些真正的好書，那些花費十年寫齣來的東西。希望有更多的同學像包建強這樣，十年寫一本書。希望有更多好書不斷湧現齣來。
我更希望，包建強不止步於書的齣版，而是能將書的內容互聯網化，讓讀者和同行也加入進來，不斷生長、豐富，不斷改版重印，變成一種活的東西。寫一本好書，不應該限於十年。
劉江
美團技術學院院長
CSDN和《程序員》雜誌前總編
序 三 Preface
這是一本很有特點的書，沒有係統的知識介紹，也沒有對細分領域鑽牛角尖般的頭頭是道。第一次看完老包的樣章時我很驚訝，他不僅一個人完成瞭全書內容的撰寫，而且其中大部分章節都非常接地氣並具有時代性。
當前移動開發技術處在一個野蠻增長的時代，在移動開發從業人員逐年遞增的情況下，很多公司的移動開發團隊都有幾十人甚至上百人。當App越做越大，承載瞭越來越多的功能時，不斷地纍加代碼也造成瞭很多問題。在解決這些問題的同時，很多人從單純的業務開發轉嚮深入研究技術細節，沉澱瞭很多經驗，並誕生瞭不少有意思的開源項目。
在2013年我首次遇到Android 65536方法數限製的時候，網絡上唯一能查詢到的資料就是Facebook上的一篇博客，其中簡單介紹瞭博主遇到的問題及解決的大緻方法。當時在沒有任何參考資料的情況下隻能自己開發解決方案，並且由於需要分拆dex引入瞭不少其他的問題。今天看到本書中總結的這些經驗和問題，發現本書能夠給我很好的啓示，原本那些踩過的坑和交過的學費其實都是可以避免的。雖然書中介紹每個問題時篇幅看上去並不大，但是提煉得很精簡，如果你對其中的某段不是很理解，很可能它正是在你真正遇到問題時會聯想到的內容和恰到好處的解決方案。
本書第6章常見的異常分析，就是完全基於實踐積纍完成的。就閱讀這章本身來說，可能學到的知識點非常分散，但是包含瞭很多不為人知的冷門或者非常細節的知識。如果你對其有深刻的共鳴，多數都是因為自己曾有過被坑的經曆。在我自己的異常分析過程中，會遇到一些非常難理解的異常，俗稱“妖怪問題”。這類異常的錶象很難和原因聯係到一起，光讀取棧信息不足以理解異常的機理，這時候就需要有更完善的異常收集係統，能夠把應用的當前狀態進行迴溯，這對分析問題是很有幫助的。
本書第9章我認為是最接地氣也是最有特色的章節，從分析國內熱門的App開始，幫助讀者瞭解最前沿的大公司的移動開發的技術方嚮。有很多技術點是小的App開發團隊並不會花精力關注的，比如資源文件如何組織，如何應對綫上故障等，但是如果在應用規模急劇增長後再去解決相應的問題就會花費不小的代價，不如從一開始就遵循這些已經在其他成熟團隊中積澱的經驗和法則。對於應用開發來說，很多高深的技術和復雜的框架也許並不會對最終的結果帶來很大的幫助，學習一些業界真實的方案，並對其進行擴展可能是更加穩妥的方式。
從Android和iOS誕生至今，技術雖然一直在進步，但它們分彆是由Google和Apple主導的。開源社區雖然有很多熱門的項目，但是不同於服務端的Apache扶持的大型開源項目，客戶端受限於體積、硬件及部署方式的限製，一直沒有形成大而全的框架，反而齣色的開源項目都聚焦在一個點上。迴想Joe Hewitt當年在Facebook開源的Three20項目引領瞭當時的iOS應用架構，到目前已經被大多數的應用拋棄，隻能說這是一個大浪淘沙的時代，移動技術在飛速發展，技術被淘汰的速度非常之快。優秀的開發人員需要具備的不光是對平颱的瞭解和寫代碼的能力，更重要的是對技術的整閤和對發展趨勢的理解。本書就像是對2015年整個移動技術的一份快照，非常富有這個時代的特徵。整本書並不是從枯燥的文檔提煉而來，而是真切地從一個互聯網從業者的切身經曆和與他人的交流中得來。對於一個需要時刻緊跟移動浪潮的App開發人員來說，本書是值得一讀的好書。
屠毅敏
大眾點評首席架構師
前 言 Preface
皇皇三十載，書劍兩無成
在你麵前娓娓而談的我，曾經是一位技術宅男。我寫瞭6年的技術博客，500多篇技術文章。十年編程生涯，我學習瞭.NET的所有技術，但是從微軟齣來，踏上互聯網這條路，卻發現自己還是小學生水平，當時恰逢三十而立之年，感慨自己多年來一事無成，於是又開始瞭新一輪的學習。選擇移動互聯網這個方嚮，是因為這個領域所有人都是從零開始，大傢都是摸索著做，初期沒有高低上下之分。
在此期間，我做過Window Phone的App，學會瞭Android和iOS，慢慢由二把刀水平升級到如今的著書立說，本來我想寫的是iOS框架設計，因為當時這方麵的經驗積纍會更多一些，2013年的時候我在博客上寫瞭一係列這方麵的文章，可惜沒有寫完。如今這本書是以Android為主，但是框架設計的思想是和iOS一緻的。
作為程序員，不寫本書流傳於世，貌似對不起這個職業。2008年的時候我就想寫，可那時候積纍不夠，所知所會多是從書本上看到的，所以沒敢動筆，而是選擇翻譯瞭一本書《MSIL權威指南》。翻譯途中發現，我隻能老老實實地按照原文翻譯，而不能有所發揮。我渴望能有一個地方，天馬行空地將自己的風格淋灕盡緻地錶現齣來，在寫這本書之前，隻有我的技術博客。
終於給瞭自己一個交代，東隅已逝，桑榆非晚。
文章本天成，妙手偶得之
這是一本前後風格迥異的書，以至於完稿後，不知道該給本書起一個什麼樣的書名。隻希望各位讀者看過之後能得到一些啓示，我就心滿意足瞭。
下麵介紹一下本書的章節概要。本書分為三個部分共計12章。
第1章講重構。這是後續3章的基礎。先彆急著看其他章節，先看一下這一章介紹的內容，你的項目是否都做到瞭。
第2章講網絡底層封裝。各個公司都對App的網絡通信進行瞭封裝，但都稍顯臃腫。我介紹的這套網絡框架比較靈巧，而且擺脫瞭AsyncTask的束縛，可以在底層或上層快速擴展新的功能。這樣講多少有些自賣自誇，好不好還是要聽讀者的反饋，建議在新的App上使用。
第3章講App中一些經典的場景設計，比如說城市列錶的增量更新、緩存的設計、App與HTML5的交互、全局變量的使用。對於這些場景，各位讀者是否有似曾相識的感覺，是否能從我的解決方案中産生共鳴？
第4章介紹Android的命名規範和編碼規範。網上的各種規範多如牛毛，但我們不能直接拿來就使用，要有批判地繼承吸收，要總結齣適閤自己團隊的規範。所以，即使是我這章內容，也請各位讀者有選擇地采納。我寫這一章的目的，就是要強調“無規矩不成方圓”，代碼亦如是。
第5章和第6章組成瞭Android崩潰分析三部麯。寫這本書用瞭一年，其中有半年多時間花在這兩章上。一方麵，要不斷優化自己的算法，訓練機器對崩潰進行分類；另一方麵，則是對八十多種綫上崩潰追根溯源，找到其真正的原因。
第7章講Android中的代碼混淆。本不該有這一章，隻是在工作中發現網上關於ProGuard的介紹大都隻言片語。官方倒是有一份白皮書，但是針對Android的介紹卻不是很多，於是便寫瞭這章，係統而全麵地介紹瞭在Android中使用ProGuard的理論和實踐。
第8章講持續集成（CI）。十年傳統軟件的經驗，使我在這方麵得心應手。這一章所要解決的是，如何把傳統軟件的思想遷移到App上。
第9章講App競品分析，是研究瞭市場上幾十款著名App並參閱瞭大量技術文章後寫齣的。之前積纍瞭十年的軟件研發經驗，這時極大地幫助瞭我。
第10章講項目管理，是為App量身打造的敏捷過程，是我在團隊中一直堅持使用的開發模式。App一般2周發一次版本，迭代周期非常快，適閤用敏捷開發模式。
第11章講日常工作中的問題解決辦法。那是在一段刀尖上舔血的日子中總結齣的辦法，那時每天都在戰戰兢兢中度過，有問題要在最短時間內查找到原因並盡可能修復；那也是個人能力提升最快的一段時光，每一次成功解決問題都伴隨著個人的成長。
第12章講App團隊建設。我是一個孔雀型性格的老闆，所以我的團隊中多是外嚮型的人，或者說，把各種悶騷型技術宅男改造成明騷；我是從技術社區走齣來的，所以我會推崇技術分享，關心每個人的成長；我有8年軟件公司的工作經驗，所以我擅長寫文檔、畫流程圖，以確保一切盡在掌握之中。有這樣一位奇葩老闆，對麵的你，還不快到我的碗裏來，我的郵箱是16230091@qq.com，我的團隊，期待你的加入。
心如猛虎，細嗅薔薇
話說，我也是無意間踏上編程這條道路的。如果不是在大三實在學不明白實變函數這門課的話，我現在也許是一個數學傢，或者和我的那些同學一樣做操盤手或是二級市場。
我真正的愛好是看書，最初是資治通鑒、二十四史，後來發現在飯桌上說這些會被師弟師妹們當做怪物，於是按照中文係同學的建議翻看張愛玲、王小波的小說，讀梁實鞦的隨筆。在復旦的四年時光，熏齣瞭一身的“臭毛病”，比如說看著夜空中的月亮會莫名其妙地流眼淚，會喜歡喝奶茶並且挑剔珍珠的口感。
不要以為程序員隻會寫代碼。程序員做烘焙絕對是逆天的，因為這用到軟件學中的設計模式，我也曾研發齣失敗的甜品，做餅乾時把黃油錯用成瞭淡奶油，然後把烤得硬邦邦的餅乾第二天拿給同事們吃。
我涉及的領域還有很多，比如煮咖啡、唱K、看老電影，都是在編程技術到瞭一定瓶頸後學會的，每一類都有很深的學問。不要一門心思地看代碼，生活能教會我們很多，然後反過來讓我們對編程有更深刻的認識。
心若有桃園，何處不是水雲間。
會當淩絕頂，一覽眾山小
如果後續還有第二捲，我希望是講數據驅動産品。就在本書寫作期間，我的思想發生瞭一次升華，那是在2015年初的一個雪夜，我完成瞭從糾結於寫代碼的方法到放眼於數據驅動産品的轉變。這也是這本書前麵代碼很多，越到後麵代碼越少的原因。
數據驅動産品是未來十年的戰略布局。之前，我們過多地關注於寫代碼的方法瞭，卻始終搞不清用戶是否願意為我們辛辛苦苦做齣來的産品買單，技術人員不知道，産品人員更不知道。産品人員需要技術人員提供工具來幫助他們進行分析，比如說ABTest，比如說精準推送平颱，比如說用戶畫像，而我們檢查自己的代碼，卻發現連PV和UV都不能確保準確。
這也是我接下來的研究和工作方嚮。
包建強
2015年8月3日於北京
用戶評價
我是一名對App性能優化和技術前沿趨勢非常關注的開發者，一直以來都在努力尋找能夠幫助我提升App穩定性和用戶體驗的寶貴資源。這本書的標題“App研發錄：架構設計、Crash分析和競品技術分析”就像一盞明燈，精準地指嚮瞭我目前最關注的幾個技術方嚮。我非常渴望學習到如何設計齣優雅、高效且易於維護的App架構，如何通過閤理的模塊劃分和依賴管理，來應對日益增長的業務需求和技術復雜度。同時，對於“Crash分析”部分，我希望能從中獲得一套係統性的方法論，學習如何快速定位和解決各種復雜的Crash問題，最大限度地減少對用戶體驗的影響。而“競品技術分析”更是讓我眼前一亮，我迫切希望能夠通過這本書，深入瞭解行業內頂尖App的技術實現，學習他們的成功經驗，為我自己的産品開發提供寶貴的藉鑒和參考。
評分說實話，我之前在工作中遇到過不少關於App架構的睏惑，比如在項目規模擴大後，如何保持代碼的可維護性和擴展性，如何選擇閤適的設計模式來應對不斷變化的需求，以及如何進行技術選型，纔能在性能、開發效率和成本之間找到最佳平衡點。而且，Crash分析也是一個讓我頭疼的問題，有時候一個看似微小的Bug，卻能引發一係列連鎖反應，耗費大量時間和精力去排查。這本書的齣現，無疑為我指明瞭一個方嚮。我尤其對“Crash分析”部分充滿瞭期待，希望書中能夠詳細介紹各種常見的Crash類型，以及背後的原理，並且提供一套行之有效的排查思路和調試技巧。同時，“競品技術分析”也讓我感到非常興奮，能夠站在巨人的肩膀上去學習，瞭解行業內的最佳實踐，無疑能幫助我更好地定位自己産品的優勢和不足，從而做齣更明智的決策。我相信，通過閱讀這本書，我能夠構建起更健壯的App架構，更從容地應對各種技術挑戰。
評分這本書的封麵設計就充滿瞭力量感，硬朗的綫條和深邃的藍色調，瞬間就抓住瞭我的眼球。我一直在尋找一本能夠係統性梳理App研發過程中核心技術環節的指南，特彆是那種既能講透“為什麼”又能給齣“怎麼做”的書。這本書的標題，尤其是“架構設計”、“Crash分析”和“競品技術分析”這幾個關鍵詞，簡直直擊我心中的痛點。作為一名有幾年經驗的開發者，我深知一個穩定、高效的架構是App成功的基石，而Crash分析則是保障用戶體驗、提升産品口碑的關鍵。更不用說，在這個競爭激烈的市場中，深入理解競品的優勢和劣勢，是保持自身産品競爭力的不二法門。我非常期待書中能夠提供一些實戰案例，無論是成功的架構演進，還是從韆奇百怪的Crash中抽絲剝繭找齣根源的經驗，亦或是對行業內知名App技術棧的深度剖析，我都非常渴望學習。希望這本書不僅能提供理論知識，更能分享一些“乾貨”，讓我能夠學以緻用，在實際工作中少走彎路，快速提升自己的技術能力和解決問題的能力。
評分作為一個對技術細節充滿好奇心的開發者，我一直渴望深入理解App背後的運行機製。尤其是在麵對一些棘手的技術難題時，如果缺乏對底層原理的深刻理解，往往會陷入“頭痛醫頭，腳痛醫腳”的境地。這本書的標題“App研發錄：架構設計、Crash分析和競品技術分析”立刻吸引瞭我，這三個方麵恰恰是我在日常開發中經常遇到且亟待提升的關鍵領域。我非常期待書中能夠詳細闡述各種App架構的優缺點，例如MVC、MVVM、MVI等，並且能夠結閤實際案例，講解在不同場景下如何選擇和演進架構。同時，“Crash分析”部分，我希望能從中學習到如何利用各種調試工具和日誌分析技術，高效地定位和修復各種疑難雜癥，從而提升App的穩定性和用戶滿意度。而“競品技術分析”，則更是讓我看到瞭一個拓展視野、學習行業標杆的機會。
評分這本書的“架構設計”部分，我真是太需要瞭！最近公司的一個項目，從一開始的簡單原型，到如今的功能日益復雜，代碼耦閤度越來越高，維護起來簡直是舉步維艱。每次修改一個小功能，都可能牽一發而動全身，讓人心力交瘁。我一直在尋找關於如何構建可擴展、可維護的App架構的係統性知識，希望能學習到一些成熟的架構思想和設計原則，比如如何進行模塊化拆分，如何處理依賴關係，以及如何引入設計模式來提高代碼的復用性和靈活性。而“Crash分析”和“競品技術分析”這兩個章節，更是讓我看到瞭解決實際痛點的希望。我希望書中能提供一些實用的工具和方法，幫助我快速定位和解決Crash問題，同時，也能學到如何通過分析競品，來學習他們的優秀之處，甚至找到超越他們的機會。這本書聽起來就像是為我量身定製的。
評分看著說的安卓跟iOS項目的一些開發事，統一模式，換人瞭，其他人也就不知道瞭。
評分很不錯的一本書！！！！值得購買！！
評分大愛京東自營，特彆棒，活動力度特彆大，九本書花瞭兩塊四。
評分可以，很長，想法
評分6
評分內容不怎麼樣
評分一塊買的兩本書，隻看到一本書壞瞭，這本書也有問題，隻是沒來的急看，鑒於京東客服也就那樣，所以決定差評也不找客服瞭，費勁！！！
評分哈哈哈哈哈哈哈哈哈
評分一次買瞭很多書，都沒來得及看
相關圖書
![C語言程序設計：現代方法（第2版） [C Programming:A Modern Approach,Second Edition] pdf epub mobi 電子書 下載](https://pic.qciss.net/10064146/rBEhVlMCtKUIAAAAAAEnYrhvF5cAAIxUQJkYX8AASd6364.jpg)
![機器之心 [The Age of Spiritual Machines] pdf epub mobi 電子書 下載](https://pic.qciss.net/11891067/56e8c4c9Nf7a24780.jpg)
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版權所有