完成日期：2020年7月8日
版本：V1.0
作者：龔va
郵箱：shmily__vivi@163.com

目錄
第一章 總體思路
第二章 整體架構(gòu)
2.1 技術(shù)架構(gòu)
2.2 組件化
第三章 技術(shù)能力
3.1 NATIVE開發(fā)
3.1.1 統(tǒng)一架構(gòu)
3.1.2 開發(fā)語(yǔ)言
3.1.3 開發(fā)工具
3.1.4 構(gòu)建工具
3.1.5 代碼分支管理
3.1.6 代碼檢查
3.1.7 編碼規(guī)范
3.2 混合開發(fā)
3.3 系統(tǒng)測(cè)試
3.3.1 用例評(píng)審
3.3.2 冒煙測(cè)試
3.3.3 功能測(cè)試
3.3.4 自動(dòng)化測(cè)試
3.3.5 性能測(cè)試
3.3.6 安全測(cè)試
3.3.7 兼容性測(cè)試
3.4 運(yùn)維與發(fā)布
3.4.1 內(nèi)網(wǎng)辦公
3.4.2 發(fā)布部署
3.4.3 服務(wù)監(jiān)控
3.5 熱修復(fù)
3.6 日志收集與統(tǒng)計(jì)
第四章 流程管理與質(zhì)量體系
4.1 項(xiàng)目流程管理
4.2 安全管理
4.2.1 服務(wù)器物理安全
4.2.2 網(wǎng)絡(luò)安全
4.2.3 應(yīng)用安全
4.2.4 數(shù)據(jù)安全
4.3 文檔管理
第五章 落實(shí)步驟

第一章 總體思路

程序總體架構(gòu)滿足“高內(nèi)聚、低耦合”的建設(shè)思路，架構(gòu)模式采用MVVM，利用組件化思維解除模塊間不必要的依賴關(guān)系，組件可獨(dú)立開發(fā)、發(fā)布與管理，提高模塊開發(fā)的獨(dú)立性，提升協(xié)作效率。
利用持續(xù)集成工具提升發(fā)布效率，增加發(fā)布流程降低發(fā)布出錯(cuò)率。
利用監(jiān)控與統(tǒng)計(jì)工具及時(shí)發(fā)現(xiàn)服務(wù)器運(yùn)行狀態(tài)異常、App運(yùn)行異常與用戶行為收集，及時(shí)進(jìn)行問題溯源，重要問題可使用熱修復(fù)技術(shù)及時(shí)修復(fù)。
測(cè)試類型的完整引入，搭建全生命周期項(xiàng)目管理流程體系，清楚定義階段交付物，同時(shí)搭建從服務(wù)端到App端完整的安全體系，以提高送測(cè)與發(fā)布程序質(zhì)量。
統(tǒng)一開發(fā)工具與開發(fā)環(huán)境，統(tǒng)一編碼規(guī)范、代碼檢查規(guī)范與分支管理規(guī)范，持續(xù)維持健康的團(tuán)隊(duì)協(xié)作。

第二章 整體架構(gòu)

2.1 技術(shù)架構(gòu)

整體架構(gòu)模式采用MVVM，邏輯處理從業(yè)務(wù)層轉(zhuǎn)移至模型層與數(shù)據(jù)層，減小Controller的壓力與冗余，也更便于二次維護(hù)，數(shù)據(jù)倉(cāng)庫(kù)維護(hù)本地與遠(yuǎn)端數(shù)據(jù)源，程序使用組件加業(yè)務(wù)功能組裝的方式進(jìn)行構(gòu)建，同時(shí)提供線上用戶行為收集、程序運(yùn)行錯(cuò)誤日志上報(bào)及熱修復(fù)功能。

圖1 技術(shù)架構(gòu)

? MVVM架構(gòu)
MVVM是Model-View-ViewModel的簡(jiǎn)寫，是將其中View的狀態(tài)和行為抽象化，將視圖UI和業(yè)務(wù)邏輯分開。具有數(shù)據(jù)驅(qū)動(dòng)、低耦合、可復(fù)用性、團(tuán)隊(duì)協(xié)作等優(yōu)點(diǎn)。

? Retrofit+OKHttp3：http(s)通信
Retrofit是Square公司開發(fā)的一個(gè)類型安全的Java和Android 的REST客戶端庫(kù)，配合OKHttp完成是對(duì)網(wǎng)絡(luò)請(qǐng)求的封裝，可以處理各種類型的請(qǐng)求并具有眾多特性，使用簡(jiǎn)單，運(yùn)行穩(wěn)定。

? RxJava2/RxAndroid
一個(gè)在 Java VM 上使用可觀測(cè)的序列來(lái)組成異步的、基于事件的程序的庫(kù)。

? Glide圖片加載
Glide是一款由Bump Technologies開發(fā)的圖片加載框架，可以在Android平臺(tái)上以極度簡(jiǎn)單的方式加載和展示圖片，支持Gif，支持緩存。

? EventBus：通信總線
一種用于Android的事件發(fā)布-訂閱總線，簡(jiǎn)化了應(yīng)用程序內(nèi)各個(gè)組件之間進(jìn)行通信的復(fù)雜度，尤其是碎片之間進(jìn)行通信的問題，可以避免由于使用廣播通信而帶來(lái)的諸多不便。

? AliPush：推送服務(wù)
集成阿里云推送，完成App的推送服務(wù)功能，根據(jù)業(yè)務(wù)場(chǎng)景可選。

? ARouter：頁(yè)面路由
阿里開源的一款android路由框架。通過路由進(jìn)行界面跳轉(zhuǎn)，區(qū)別于Intent的顯隱式跳轉(zhuǎn)。在模塊化的項(xiàng)目中，友好的解決了因模塊互相依賴沖突，而界面互相跳轉(zhuǎn)不了的問題，使用ARouter進(jìn)行跳轉(zhuǎn)，兩個(gè)模塊互相不依賴，也可以相互跳轉(zhuǎn)。

? Tinker：熱修復(fù)
Tinker是微信官方的Android熱補(bǔ)丁解決方案，它支持動(dòng)態(tài)下發(fā)代碼、So庫(kù)以及資源，原理基于dex分包機(jī)制，讓應(yīng)用能夠在不需要重新安裝的情況下實(shí)現(xiàn)更新。

? Walle：多渠道打包
瓦力通過在Apk中的APK Signature Block區(qū)塊添加自定義的渠道信息來(lái)生成渠道包，從而提高了渠道包生成效率。

? JsBridge：與H5交互
Js與Native之間進(jìn)行通信的橋梁， 可實(shí)現(xiàn)H5和Native的雙向通信，在H5和Native之間搭建一個(gè)橋梁（Bridge），給兩端留好更友好、更合理的接口。

? Ali/WeiXin Pay：支付
支付業(yè)務(wù)集成：微信支付、支付寶支付，可對(duì)接官方SDK，也可對(duì)接工行、中金等三方平臺(tái)，根據(jù)業(yè)務(wù)場(chǎng)景可選。

? Umeng：分享與統(tǒng)計(jì)
友盟社會(huì)化分享集成框架，還可以附帶其友盟強(qiáng)大的統(tǒng)計(jì)功能，提供分享結(jié)果數(shù)據(jù)，根據(jù)業(yè)務(wù)場(chǎng)景可選。

? Gson：數(shù)據(jù)解析與格式化
Gson是Google提供的用來(lái)在Java對(duì)象和Json數(shù)據(jù)之間進(jìn)行映射的Java類庫(kù)，快速高效、代碼量少、且面向?qū)ο蟆?/p>

? Bugly：日志收集
在線的錯(cuò)誤日志收集，便于穩(wěn)定性分析。

? BaiduSDKs：百度(地圖/語(yǔ)音/人臉/文字識(shí)別)
地圖SDK：該套 SDK開發(fā)適用于Android系統(tǒng)移動(dòng)設(shè)備的地圖應(yīng)用，通過調(diào)用地圖SDK接口，可以訪問百度地圖服務(wù)和數(shù)據(jù)，構(gòu)建功能豐富、交互性強(qiáng)的地圖類應(yīng)用程序，根據(jù)業(yè)務(wù)場(chǎng)景可選。

語(yǔ)音SDK：百度語(yǔ)音識(shí)別服務(wù)，語(yǔ)音識(shí)別可將語(yǔ)音識(shí)別為文字，適用于手機(jī)應(yīng)用語(yǔ)音交互、語(yǔ)音內(nèi)容分析、智能硬件、呼叫中心智能客服等多種場(chǎng)景，根據(jù)業(yè)務(wù)場(chǎng)景可選。

人臉SDK：百度人臉識(shí)別SDK，用于對(duì)活體人臉的識(shí)別，人臉比對(duì)，人臉?biāo)阉鞯葓?chǎng)景下的應(yīng)用。
文字識(shí)別：百度文字識(shí)別（OCR）服務(wù)，用于對(duì)如身份證件，駕照等紙質(zhì)文字證件文字識(shí)別，根據(jù)業(yè)務(wù)場(chǎng)景可選。

? 版本說(shuō)明
最低兼容版本Android4.4（據(jù)2020年4月谷歌統(tǒng)計(jì)，4.4以下版本手機(jī)的市場(chǎng)占有率不到2%）
編譯版本Android9.0，目標(biāo)運(yùn)行版本Android9.0（目前市場(chǎng)占比最高的穩(wěn)定版本）

2.2 組件化

組件化是將復(fù)雜的功能模塊的邏輯、數(shù)據(jù)、UI等元素積木式的進(jìn)行拆分、重組的過程，形成單個(gè)可以獨(dú)立開發(fā)和測(cè)試的組件。
組件化可以極大程度的提高協(xié)作效率，將不同模塊間的開發(fā)完全解耦，配合路由框架，做到不同模塊間的代碼管理、編譯、測(cè)試、發(fā)布等獨(dú)立，可通過Maven倉(cāng)庫(kù)進(jìn)行管理，模塊間的邊界清晰，也為問題溯源提供了足夠的思路與歷史記錄。
單個(gè)組件的構(gòu)建思路應(yīng)遵循邏輯能力與UI展示解耦，當(dāng)UI展示不滿足組件使用者的要求時(shí)，允許只使用組件能力，以此來(lái)滿足復(fù)雜多變不可控的眾多業(yè)務(wù)場(chǎng)景。

圖2 組件架構(gòu)

? Core核心組件
提供基于java、android語(yǔ)言級(jí)的工具方法集合。如：加解密、時(shí)間工具、數(shù)字運(yùn)算、進(jìn)程/線程工具、鍵盤、屏幕、網(wǎng)絡(luò)監(jiān)聽工具等。

? 基礎(chǔ)功能組件
提供Base的Application、Activity、Fragment、Custom View、Manager、Loading Controller、Configuration、Lifecycle等的基準(zhǔn)類庫(kù)；
同時(shí)提供功能插件，如：網(wǎng)絡(luò)請(qǐng)求Retrofit、Android動(dòng)畫、IO相關(guān)操作、總線通信EventBus、圖片加載glide、圖片/文件加載庫(kù)、權(quán)限管理等。

? 基礎(chǔ)業(yè)務(wù)組件
提供通用又可選的一些能力的封裝，如：地圖能力、掃碼能力、推送能力、數(shù)據(jù)庫(kù)管理能力、分享能力、熱修復(fù)、人臉/圖像識(shí)別、一鍵打包、語(yǔ)音能力、統(tǒng)計(jì)能力、圖表繪制能力等。

? 常規(guī)業(yè)務(wù)組件
這一層和業(yè)務(wù)功能掛鉤，通常會(huì)有一個(gè)對(duì)業(yè)務(wù)功能的分析和提煉的過程，將具有相同特性的功能封裝成常規(guī)業(yè)務(wù)組件，此類組件通常會(huì)持續(xù)的新增和維護(hù)。如：登錄/注冊(cè)、App版本更新、廣告、訂單與支付、引導(dǎo)、內(nèi)嵌H5等。

? App殼工程
主App工程，選擇性的對(duì)各類組件進(jìn)行特性定義或組裝，結(jié)合非組件功能，構(gòu)建完整的Application。

第三章 技術(shù)能力

3.1 Native開發(fā)

無(wú)論是同一個(gè)線下團(tuán)隊(duì)還是多地協(xié)作的多團(tuán)隊(duì)，都需要統(tǒng)一的一套技術(shù)棧，加上規(guī)范與流程的約束，即可避免很多環(huán)境差異、認(rèn)知差異、習(xí)慣差異、能力水平差異等帶來(lái)的問題。

3.1.1 統(tǒng)一架構(gòu)

開發(fā)語(yǔ)言可采用Java、Kotlin混用模式，框架級(jí)代碼為了適應(yīng)更多技術(shù)層次的團(tuán)隊(duì)成員建議采用Java編寫，業(yè)務(wù)功能模塊的開發(fā)允許使用Java或Kotlin中任意一種。

3.1.3 開發(fā)工具

開發(fā)工具使用Android Studio，參考版本3.6.1，并使用相同的Code Template，規(guī)范團(tuán)隊(duì)的注釋、換行等規(guī)范。

3.1.4 構(gòu)建工具

采用Gradle作為自動(dòng)化構(gòu)建工具，工程變量的配置、CPU架構(gòu)配置、編譯配置、Maven上傳、三方庫(kù)版本管理等均在Gradle中統(tǒng)一配置，并通過自定義Task來(lái)完成特定的項(xiàng)目常用任務(wù)，如：Clean Project，Build Release，Make Channel等。

3.1.5 代碼分支管理

采用Git統(tǒng)一管理項(xiàng)目代碼，可在團(tuán)隊(duì)均可以訪問且安全的網(wǎng)絡(luò)環(huán)境中搭建一套GitLab，并遵循團(tuán)隊(duì)共用的分支管理規(guī)范，參考：

圖3 Git分支管理規(guī)范

3.1.6 代碼檢查

形成定期的Code Review制度，并在Review中檢查代碼的完整性、一致性、健壯性、重用性、擴(kuò)展性、性能、安全性、注釋等。

3.1.7 編碼規(guī)范

團(tuán)隊(duì)采用統(tǒng)一的編碼，保證代碼風(fēng)格一致。（參考文檔不在此處另附）

3.2 混合開發(fā)

針對(duì)Native與H5混合開發(fā)的情況，需要提供一套完整且統(tǒng)一的Native與JavaScript的通信規(guī)范，同時(shí)Native需要提供Js可喚起和跳轉(zhuǎn)的Scheme路由地址。
通常可以分為Js->Native的數(shù)據(jù)類與動(dòng)作類Handler和Native->Js的數(shù)據(jù)類與動(dòng)作類Handler，傳輸數(shù)據(jù)類型與格式根據(jù)業(yè)務(wù)自定義，Handler Name參考：
Js->Native數(shù)據(jù)類：com.company_name.native_echo.data
Js->Native動(dòng)作類：com.company_name.native_echo.action
Native-> Js數(shù)據(jù)類：com.company_name.javascript_echo.data
Native-> Js動(dòng)作類：com.company_name.javascript_echo.action

3.3 系統(tǒng)測(cè)試

測(cè)試的設(shè)計(jì)與執(zhí)行過程需要完整有序，對(duì)產(chǎn)品性能、質(zhì)量、安全、兼容性要做到全方位兼并，通知借助工具與測(cè)試技術(shù)，提高效率。

3.3.1 用例評(píng)審

測(cè)試用例的設(shè)計(jì)需要內(nèi)部評(píng)審與外部評(píng)審，內(nèi)部評(píng)審以校驗(yàn)功能覆蓋率，外部評(píng)審以校驗(yàn)邏輯正確性，管理工具可使用TestLink。

3.3.2 冒煙測(cè)試

冒煙測(cè)試是開發(fā)過程中的一種快速的基本功能的驗(yàn)證策略，是對(duì)軟件基本功能進(jìn)行確認(rèn)驗(yàn)證的手段與過程。
開發(fā)版本達(dá)到送測(cè)標(biāo)準(zhǔn)的前提是冒煙測(cè)試通過，測(cè)試團(tuán)隊(duì)負(fù)責(zé)冒煙測(cè)試用例的設(shè)計(jì)與維護(hù)，研發(fā)團(tuán)隊(duì)負(fù)責(zé)參與評(píng)審與執(zhí)行，以保證送測(cè)的主功能與流程通暢，若冒煙測(cè)試不通過，測(cè)試團(tuán)隊(duì)有權(quán)將送測(cè)流程打回。

3.3.3 功能測(cè)試

功能測(cè)試是根據(jù)產(chǎn)品設(shè)計(jì)、交互體驗(yàn)、數(shù)據(jù)邏輯等要求，對(duì)產(chǎn)品各功能進(jìn)行驗(yàn)證，以檢查產(chǎn)品達(dá)到既定的要求，是最常見的且必要的測(cè)試過程。參考：
? 測(cè)試用例完整執(zhí)行
? 測(cè)試問題完整回歸
? 邊界值
? 覆蓋率
? 不允許Reopen
? 測(cè)試報(bào)告

3.3.4 自動(dòng)化測(cè)試

對(duì)系統(tǒng)中很重要且不經(jīng)常變更設(shè)計(jì)的功能進(jìn)行自動(dòng)化測(cè)試，以提高測(cè)試效率與程序穩(wěn)定性，如：注冊(cè)/登錄、版本更新等。

3.3.5 性能測(cè)試

使用Android Studio的Profile工具進(jìn)行性能測(cè)試，關(guān)注的性能問題包括但不僅限：
? 應(yīng)用耗電量過大
? 設(shè)備發(fā)熱
? 程序啟動(dòng)較慢
? CPU告警/內(nèi)存泄漏
? 頁(yè)面卡頓、幀率低
設(shè)定性能目標(biāo)，根據(jù)性能測(cè)試結(jié)果持續(xù)進(jìn)行程序優(yōu)化。

3.3.6 安全測(cè)試

安全測(cè)試通常是一個(gè)很大的課題，因?yàn)锳ndroid系統(tǒng)開源，因此在Android領(lǐng)域中需要做的安全檢查項(xiàng)較多，根據(jù)項(xiàng)目與客戶的安全等級(jí)不同，可選擇性的執(zhí)行以下的部分或全部安全檢查項(xiàng)。

程序安全

? 安裝包簽名和證書
檢測(cè) App安裝包是否正確簽名，通過簽名，可以檢測(cè)出安裝包在簽名后是否被修改過。
? 數(shù)據(jù)可備份
AndroidMainfest.xml 文件中的 allowBackup 屬性值默認(rèn)為 true。當(dāng)該屬性沒有顯式設(shè)置為 false 時(shí),攻擊者可通過adb backup和adb restore 對(duì) App 的應(yīng)用數(shù)據(jù)進(jìn)行備份和恢復(fù),從而可能獲取明文存儲(chǔ)的用戶敏感信息。
? 程序保護(hù)
App未提供防反編譯的手段，則可能面臨被反編譯的風(fēng)險(xiǎn)。
? Debug模式
AndroidManifest.xml中的 android:debuggable="true" 標(biāo)記如果開啟，可被 Java 調(diào)試工具例如 jdb 進(jìn)行調(diào)試，獲取和篡改用戶敏感信息，甚至分析并且修改代碼實(shí)現(xiàn)的業(yè)務(wù)邏輯。
? 完整性校驗(yàn)
程序如果沒有自校驗(yàn)機(jī)制，攻擊者可能會(huì)通過篡改客戶端程序，植入木馬以竊取手機(jī)用戶的隱私信息。

組件安全

? Content Provider
若沒有對(duì)Content Provider 組件的訪問進(jìn)行權(quán)限控制和對(duì)訪問的目標(biāo)文件的Content Query Uri 進(jìn)行有效判斷，則openFile()接口可進(jìn)行文件目錄遍歷以訪問任意可讀文件。
? WebView代碼執(zhí)行檢測(cè)
Android系統(tǒng)通過addJavascriptInterface 方法注冊(cè)可供 JavaScript 調(diào)用的 Java 對(duì)象，以用于增強(qiáng) JavaScript 的功能，但是系統(tǒng)并沒有對(duì)注冊(cè)Java類的方法調(diào)用進(jìn)行限制，攻擊者可以利用反射機(jī)制調(diào)用未注冊(cè)的其它任何Java類，最終導(dǎo)致JavaScript能力的無(wú)限增強(qiáng)，利用該漏洞可以利用Js執(zhí)行客戶端任意代碼。
? WebView校驗(yàn)證書
調(diào)用了android/webkit/SslErrorHandler類的 proceed方法,可能導(dǎo)致WebView忽略校驗(yàn)證書的步驟。
? WebView密碼明文保存
在使用WebView的過程中忽略了 WebView setSavePasswor，當(dāng)用戶選擇保存在 WebView 中輸入的用戶名和密碼，則會(huì)被明文保存到應(yīng)用數(shù)據(jù)databases/webview.db中。如果手機(jī)被 root就可以獲取明文保存的密碼，造成用戶的個(gè)人敏感數(shù)據(jù)泄露。

敏感信息安全

? 敏感文件與字符檢查
檢查App私有目錄下的文件是否存在敏感信息泄露的情況。
? 程序目錄權(quán)限檢查
檢查App私有目錄下的文件權(quán)限是否設(shè)置正確，非root 賬戶是否可以讀、寫、執(zhí)行私有目錄下的文件。
? LogCat日志檢查
檢查是否關(guān)閉了調(diào)試日志的輸出。

密碼軟鍵盤安全

? 鍵盤劫持檢查
檢查App在密碼等輸入框是否使用自定義軟鍵盤。Android應(yīng)用中的輸入框默認(rèn)使用系統(tǒng)軟鍵盤，手機(jī)安裝木馬后，木馬可以通過替換 系統(tǒng)軟鍵盤，記錄應(yīng)用的密碼。

安全策略

? 密碼復(fù)雜度
檢查App的密碼復(fù)雜度要求設(shè)計(jì)是否過于簡(jiǎn)單。
? 會(huì)話安全
測(cè)試App在一定時(shí)間內(nèi)無(wú)操作后，是否會(huì)使會(huì)話超時(shí)并要求重新登錄。
? 界面切換保護(hù)
檢查App在切換到后臺(tái)或其他應(yīng)用時(shí)，是否能恰當(dāng)響應(yīng)（如清除表單或退出會(huì)話），防止用戶敏感信息泄露。
? 用戶敏感信息泄露
檢查App是否存在敏感信息泄露。
? 登錄安全
根據(jù)業(yè)務(wù)需求檢查程序是否需要單點(diǎn)登錄。
? 安全退出
驗(yàn)證App在用戶退出登錄狀態(tài)時(shí)是否會(huì)和服務(wù)器進(jìn)行通信以保證退出的及時(shí)性。
? 驗(yàn)證碼安全
驗(yàn)證移動(dòng)客戶端使用的驗(yàn)證碼的安全性，如圖形驗(yàn)證碼是否輕易被機(jī)器識(shí)別。

通信安全

? 通信加密檢測(cè)
驗(yàn)證App和服務(wù)器之間的通信是否使用加密信道。
? 關(guān)鍵數(shù)據(jù)加密檢測(cè)
驗(yàn)證通信過程中能否對(duì)關(guān)鍵數(shù)據(jù)進(jìn)行篡改。
? SSL證書有效性檢測(cè)
驗(yàn)證App和服務(wù)器之間是否存在雙向驗(yàn)證的機(jī)制，同時(shí)確認(rèn)此機(jī)制是否完善，服務(wù)器是否以白名單的方式對(duì)發(fā)包者的身份進(jìn)行驗(yàn)證。
? 訪問控制
測(cè)試App訪問的 URL 是否僅能由手機(jī)移動(dòng)客戶端訪問。是否可以繞過登錄限制直接訪問登錄后才能訪問的頁(yè)面，對(duì)需要二次驗(yàn)證的頁(yè) 面（如私密問題驗(yàn)證），能否繞過驗(yàn)證。

進(jìn)程安全

? 內(nèi)存訪問與修改檢測(cè)
通過對(duì)App內(nèi)存的訪問，有可能會(huì)得到保存在內(nèi)存中的敏感信息（如登錄密碼，帳號(hào)等）。測(cè)試App內(nèi)存中是否存在的敏感信息（卡號(hào)、明文密碼等）。
? 本地端口開放檢測(cè)
使用domain的socket來(lái)進(jìn)行本地 IPC 或者遠(yuǎn)程網(wǎng)絡(luò)通信，這些暴露的socket代表了潛在的本地或遠(yuǎn)程攻擊。
? 外部加載Dex安全風(fēng)險(xiǎn)
類加載器DexClassLoade可以加載外置目錄的DEX文件，如果沒有對(duì)外部所加載的DEX文件做完整性校驗(yàn)，則可能會(huì)被注入惡意代碼。

業(yè)務(wù)安全

? 存儲(chǔ)型XSS漏洞
Web應(yīng)用未對(duì)用戶提交的數(shù)據(jù)做充分的檢查過濾，允許用戶在提交的數(shù)據(jù)中摻入 HTML 代碼(最主要的是“>”、“<”)并將未經(jīng)轉(zhuǎn)義的惡意代碼輸出到第三方用戶的瀏覽器解釋執(zhí)行，從而導(dǎo)致 XSS 漏洞。
? 短信炸彈
務(wù)器端若沒有對(duì)短信發(fā)送接口做限制，則可能導(dǎo)致短信炸彈漏洞。

3.3.7 兼容性測(cè)試

團(tuán)隊(duì)?wèi)?yīng)該配備主流品牌的測(cè)試機(jī)型，但由于Android機(jī)型眾多，所以通常還會(huì)采用第三方云平臺(tái)輔助進(jìn)行兼容性測(cè)試，如：testin。
測(cè)試范圍包括：可安裝、安裝耗時(shí)、可卸載、可啟動(dòng)、啟動(dòng)耗時(shí)、monkey測(cè)試等。

3.4 運(yùn)維與發(fā)布

3.4.1 內(nèi)網(wǎng)辦公

文檔管理：SVN
代碼管理：Gitlab
項(xiàng)目管理（含BUG管理）：Jira
知識(shí)庫(kù)管理：Confluence
接口管理：Yapi
測(cè)試用例管理：Testlink

3.4.2 發(fā)布部署

配置中心：Apollo
持續(xù)集成（自動(dòng)化構(gòu)建）：Jenkins
發(fā)布流程：發(fā)布申請(qǐng)->發(fā)布準(zhǔn)備->Check List->發(fā)布執(zhí)行->發(fā)布驗(yàn)證

3.4.3 服務(wù)監(jiān)控

利用后端與運(yùn)維技術(shù)，以實(shí)現(xiàn)及時(shí)的服務(wù)監(jiān)控，監(jiān)控范圍與技術(shù)參考：
服務(wù)器監(jiān)控（包括硬件資源、數(shù)據(jù)庫(kù)、緩存、流量等）：Zabbix、Prometheus
應(yīng)用監(jiān)控：Springboot Admin
中間件管理：Rabbitmq admin、Kafka admin、ES Kibana
鏈路監(jiān)控：APM SkyWalking
日志跟蹤：ELK（Elasticsearch, Logstash, Kibana）

3.5 熱修復(fù)

由于Android機(jī)型碎片化，線上環(huán)境復(fù)雜多樣化，APP發(fā)布后總會(huì)遇到一些開發(fā)環(huán)境無(wú)法測(cè)試覆蓋的缺陷：崩潰、數(shù)據(jù)錯(cuò)誤、鏈接跳轉(zhuǎn)失敗、商品無(wú)法交易等。傳統(tǒng)處理方式需要發(fā)現(xiàn)問題、定位問題、修復(fù)問題、發(fā)布新的版本。這種方式一方面會(huì)讓APP頻繁更新，用戶體驗(yàn)不好，另外App Store也有一些審核的周期，修復(fù)問題時(shí)間成本高，最終導(dǎo)致客戶流失、資金損失等后果，因此熱修復(fù)技術(shù)應(yīng)運(yùn)而生。
Android平臺(tái)的熱修復(fù)技術(shù)，是通過下發(fā)補(bǔ)丁包，讓已安裝的客戶端動(dòng)態(tài)完成更新，讓用戶可以不用重新安裝APP，就能夠修復(fù)軟件缺陷的一種技術(shù)，同時(shí)還可以發(fā)布一些輕量級(jí)的新功能。
常見的熱修復(fù)技術(shù)框架如：Tinker、Robust、阿里百川等，也可自研。
附Tinker熱修復(fù)原理探究（作者：本人）：http://www.lxweimin.com/p/fd9ed8b720ef

3.6 日志收集與統(tǒng)計(jì)

App發(fā)布之后，我們通常都會(huì)有需要知道C端的下載、安裝、使用與錯(cuò)誤情況，業(yè)務(wù)部門也會(huì)提出數(shù)據(jù)采集、業(yè)務(wù)檢測(cè)、用戶行為分析、穩(wěn)定性監(jiān)控等多樣化的需求，因此App需要接入監(jiān)控與統(tǒng)計(jì)工具，通常能解決的需求包括：
? 新增用戶數(shù)、活躍用戶數(shù)、啟動(dòng)次數(shù)與其趨勢(shì)統(tǒng)計(jì)
? 版本分布與其趨勢(shì)統(tǒng)計(jì)
? 活躍時(shí)段與渠道分析
? 用戶使用時(shí)長(zhǎng)、頻率與頁(yè)面訪問路徑
? 事件埋點(diǎn)與轉(zhuǎn)化率統(tǒng)計(jì)
? 設(shè)備、網(wǎng)絡(luò)、地域分布與統(tǒng)計(jì)
? 崩潰錯(cuò)誤日志的收集與統(tǒng)計(jì)
常見的統(tǒng)計(jì)技術(shù)框架如：友盟、百度等，也可自研。

第四章 流程管理與質(zhì)量體系

4.1 項(xiàng)目流程管理(交付型)

設(shè)定項(xiàng)目管理或PMO崗，制定并執(zhí)行全生命周期項(xiàng)目管理流程，解決DoD（Definition OF Done）的問題，分清楚上下游流程的邊界，定義清交付物清單及模板標(biāo)準(zhǔn)，減少多余的溝通與返工的可能，關(guān)鍵流程與文檔需要正式的郵件留痕。
? 項(xiàng)目立項(xiàng)
項(xiàng)目可行性分析、立項(xiàng)評(píng)審。
交付物：可行性分析報(bào)告、立項(xiàng)申請(qǐng)書、項(xiàng)目預(yù)算等。
? 售前階段
建立客戶關(guān)系、分析挖掘客戶需求、技術(shù)可行性分析、成本評(píng)估、基線版本需求。
交付物：需求跟蹤表、合同、產(chǎn)品評(píng)估表等。
? 項(xiàng)目啟動(dòng)
刷新項(xiàng)目與客戶需求 、資源調(diào)配、里程碑劃分、項(xiàng)目啟動(dòng)會(huì)、關(guān)鍵角色任命。
交付物：關(guān)鍵角色任命書、整體交付計(jì)劃（粗）、成本與預(yù)算、項(xiàng)目啟動(dòng)報(bào)告等。
? 項(xiàng)目規(guī)劃
交付需求留痕、確定項(xiàng)目交付模型、制定并評(píng)審交付計(jì)劃。
交付物：需求交付清單、整體交付計(jì)劃（細(xì)）。
? 方案設(shè)計(jì)->需求評(píng)審->研發(fā)實(shí)現(xiàn)->發(fā)布上線
功能清單梳理，產(chǎn)品設(shè)計(jì)與評(píng)審，開發(fā)、測(cè)試、運(yùn)維等各職能端口按計(jì)劃執(zhí)行開發(fā)和交付，并符合質(zhì)量要求決策點(diǎn)。
交付物：PRD、版本功能清單、版本迭代開發(fā)計(jì)劃、系統(tǒng)架構(gòu)設(shè)計(jì)、接口設(shè)計(jì)、數(shù)據(jù)庫(kù)設(shè)計(jì)、代碼、項(xiàng)目周報(bào)、測(cè)試用例、測(cè)試報(bào)告等。
? 階段驗(yàn)收
驗(yàn)收各要素完成情況，截止驗(yàn)收前遺留的問題情況，驗(yàn)收前要決策的問題，階段性周期復(fù)盤，項(xiàng)目變更約束，階段客戶培訓(xùn)。
交付物：項(xiàng)目驗(yàn)收?qǐng)?bào)告，需求變更管理，階段交付物，階段復(fù)盤紀(jì)要等。
? 項(xiàng)目結(jié)項(xiàng)
內(nèi)部驗(yàn)收，提交初驗(yàn)申請(qǐng)，初驗(yàn)，試運(yùn)行，終驗(yàn)。
交付物：結(jié)項(xiàng)申請(qǐng)，初驗(yàn)申請(qǐng)，試運(yùn)行申請(qǐng)，試運(yùn)行報(bào)告，終驗(yàn)申請(qǐng)，終驗(yàn)報(bào)告。
? 項(xiàng)目維護(hù)
缺陷維護(hù)，日常維護(hù)，需求變更。
? 項(xiàng)目關(guān)閉
經(jīng)驗(yàn)總結(jié)，資源釋放，客戶滿意度調(diào)研。
交付物：總結(jié)報(bào)告、客戶滿意度報(bào)告、技術(shù)白皮書、解決方案文檔。

4.2 安全管理

安全技術(shù)體系主要包括物理安全、網(wǎng)絡(luò)安全、應(yīng)用安全、數(shù)據(jù)安全。

4.2.1 服務(wù)器物理安全

登錄服務(wù)器操作系統(tǒng)和數(shù)據(jù)庫(kù)系統(tǒng)的用戶都通過用戶名和口令進(jìn)行身份標(biāo)識(shí)和鑒別。服務(wù)器網(wǎng)絡(luò)部署在一個(gè)VPC網(wǎng)絡(luò)（Virtual Private Cloud），所有服務(wù)器無(wú)法直接SSH連接，需要通過跳板機(jī)跳轉(zhuǎn)，所有跳板機(jī)服務(wù)器設(shè)置IP白名單限制，對(duì)出網(wǎng)和入網(wǎng)端口進(jìn)行限制，并對(duì)主機(jī)做相應(yīng)的安全策略：

1. 設(shè)置SSH空閑退出時(shí)間600秒；
2. 用戶認(rèn)證最大失敗數(shù)為4；
3. 密碼最小長(zhǎng)度設(shè)置為8位，至少包含小寫字母、大寫字母、數(shù)字、特殊字符等4類字符中等3類；
4. 沒有密碼的用戶禁止登陸服務(wù)器；
5. 每個(gè)月對(duì)密碼進(jìn)行更新。

4.2.2 網(wǎng)絡(luò)安全

多個(gè)服務(wù)器與客戶端網(wǎng)絡(luò)之間通信全程采用數(shù)據(jù)加密方式進(jìn)行網(wǎng)絡(luò)傳輸，包括服務(wù)器間約定對(duì)稱加密密鑰、非對(duì)稱數(shù)據(jù)加密、雙向SSL認(rèn)證等，保證通信安全，防止中間人攻擊，傳輸?shù)拿舾袛?shù)據(jù)需要脫敏。

4.2.3 應(yīng)用安全

1. 發(fā)布包安全

(1) 采用v1，v2打包簽名機(jī)制，確保APK完整性，防止APK篡改，確保應(yīng)用程序和開發(fā)者的信任關(guān)系。
(2) 采用加固方案，提升APK破解難度。混淆僅僅針對(duì)源碼的閱讀難度上做處理，無(wú)法從根源防止反編譯，有暴露敏感代碼信息的可能，而加固可防止應(yīng)用被逆向分析、反編譯、二次打包，防止嵌入各類病毒、木馬等惡意代碼及低俗廣告，從源頭保護(hù)數(shù)據(jù)安全防止逆向破解。

2. 程序安全

(1) 正式版關(guān)閉debug模式，防止系統(tǒng)崩潰，獲取和篡改用戶敏感信息，甚至分析并且修改代碼實(shí)現(xiàn)的業(yè)務(wù)邏輯實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)和App數(shù)據(jù)。
(2) WebView安全：WebView js代碼執(zhí)行安全、請(qǐng)求證書不校驗(yàn)安全、本地?cái)?shù)據(jù)訪問安全、WebView 密碼明文不保存。
(3) 進(jìn)程安全：默認(rèn)關(guān)閉組件進(jìn)程訪問（android:exported="fasle"），廣播經(jīng)量使用本地廣播LocalBroadcastManager，通過廣播和接收器必須加權(quán)限。

3. 數(shù)據(jù)安全

(1) 關(guān)閉程序應(yīng)用數(shù)據(jù)備份權(quán)限（android:allowBackup="fasle"）。將該屬性顯式設(shè)置為false 時(shí)，防止攻擊者通過adb backup和 adb restore 對(duì)App 的應(yīng)用數(shù)據(jù)進(jìn)行備份和恢復(fù)，從而獲取明文存儲(chǔ)的用戶敏感信息。
(2) 正式版關(guān)閉log開關(guān)，防止敏感數(shù)據(jù)通過log打印泄露。
(3) 密鑰文件信息通過so庫(kù)保存。

4. 本地文件數(shù)據(jù)，緩存數(shù)據(jù)，數(shù)據(jù)庫(kù)數(shù)據(jù)目錄安全

(1) SharePreference保存敏感配置數(shù)據(jù)采用AES加密。
(2) 本地?cái)?shù)據(jù)庫(kù)敏感消息數(shù)據(jù)采用AES加密。
敏感文件數(shù)據(jù)，緩存數(shù)據(jù)存放在應(yīng)用目錄權(quán)限內(nèi)，敏感對(duì)外文件統(tǒng)一通過Provider方式對(duì)外暴露。

4.2.4 數(shù)據(jù)安全

建立完整的備份策略，能夠?qū)?shù)據(jù)庫(kù)和文件系統(tǒng)進(jìn)行備份及恢復(fù)。

1. APP本地?cái)?shù)據(jù)庫(kù)數(shù)據(jù)加密策略

對(duì)用戶信息數(shù)據(jù)或者其他需要緩存到本地的敏感數(shù)據(jù)進(jìn)行加密處理后再存儲(chǔ)，主要通過AES對(duì)稱加密，密鑰應(yīng)存儲(chǔ)在動(dòng)態(tài)鏈接庫(kù)中。

2. 服務(wù)器備份策略

(1) 對(duì)系統(tǒng)每月進(jìn)行一次快照，備份數(shù)據(jù)保存三個(gè)月；
(2) 系統(tǒng)升級(jí)、打補(bǔ)丁等操作，要在操作之前進(jìn)行一次快照，操作完成后進(jìn)行一次快照，備份數(shù)據(jù)保存三個(gè)月。

3. 數(shù)據(jù)庫(kù)備份策略

(1) 數(shù)據(jù)庫(kù)備份策略采用全量+增量的模式備份，保證能夠快速的恢復(fù)數(shù)據(jù)。如：每周星期日進(jìn)行一次全量備份，周一至周六依據(jù)周日的全量進(jìn)行增量備份，備份數(shù)據(jù)保存三個(gè)月；
(2) 系統(tǒng)升級(jí)不允許修改字段名稱，不允許刪除字段，如果對(duì)數(shù)據(jù)庫(kù)有修改操作，在修改前先對(duì)修改的表做一次全量備份。

4. 日常巡檢策略

(1) 操作系統(tǒng)巡檢。操作系統(tǒng)巡檢內(nèi)容：CPU監(jiān)控，內(nèi)存監(jiān)控，I/O監(jiān)控（硬盤使用率），系統(tǒng)SWAP監(jiān)控等。
(2) 數(shù)據(jù)庫(kù)本身巡檢。包含重點(diǎn)參數(shù)的檢查，數(shù)據(jù)庫(kù)狀態(tài)的檢查，自增ID的使用情況，以及主從狀態(tài)的巡檢，檢查數(shù)據(jù)庫(kù)本地備份的完整性。

4.3 文檔管理

項(xiàng)目中所有文檔需要清晰有效的分類管理與控制，實(shí)現(xiàn)項(xiàng)目文檔有序的保管與規(guī)范流動(dòng)，文檔管理在線化。
包含但不僅限：全生命周期項(xiàng)目管理流程中的交付物文檔、規(guī)范、資料庫(kù)、路由表、組件說(shuō)明、技術(shù)調(diào)研、分享材料、工作記錄等。

第五章 落實(shí)步驟

方案的落地需要根據(jù)重要程度與依賴關(guān)系逐步落實(shí)，參考以下優(yōu)先級(jí)順序：
1 統(tǒng)一的工具與環(huán)境
2 編碼規(guī)范、Code Review規(guī)范、分支管理規(guī)范
3 系統(tǒng)架構(gòu)搭建
4 組件化框架搭建
5 安全體系的搭建
6 監(jiān)控體系搭建
7 業(yè)務(wù)開發(fā)
8 其他
9 貫穿全程：文檔管理、項(xiàng)目管理流程的逐步落實(shí)、持續(xù)重構(gòu)、技術(shù)演進(jìn)、團(tuán)隊(duì)開發(fā)能力提升、團(tuán)隊(duì)測(cè)試能力提升