以下內(nèi)容學(xué)習(xí)、摘錄自《技術(shù)管理之巔》
8.1 移動(dòng)產(chǎn)品開(kāi)發(fā)那些事
8.1.1 移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)的組織架構(gòu)
對(duì)于初創(chuàng)型移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)（人數(shù)少于30人），只要配齊產(chǎn)品設(shè)計(jì)、架構(gòu)設(shè)計(jì)、用戶體驗(yàn)設(shè)計(jì)、技術(shù)開(kāi)發(fā)、移動(dòng)開(kāi)發(fā)、測(cè)試、運(yùn)維等角色，進(jìn)行簡(jiǎn)單分工就可以了。
到了中等規(guī)模的開(kāi)發(fā)團(tuán)隊(duì)（人數(shù)超過(guò)30人），移動(dòng)開(kāi)發(fā)就要設(shè)置獨(dú)立的機(jī)構(gòu)，跟技術(shù)開(kāi)發(fā)團(tuán)隊(duì)是平行關(guān)系。移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)分成iOS、Android兩個(gè)技術(shù)小組。這樣的好處是，移動(dòng)開(kāi)發(fā)資源比較集中，有利于高效利用。這種設(shè)置符合該階段的特點(diǎn)，即：移動(dòng)業(yè)務(wù)整體占比不高、開(kāi)發(fā)需求量不大，用戶對(duì)移動(dòng)體驗(yàn)要求不高。
隨著移動(dòng)業(yè)務(wù)的普及發(fā)展，比如在整體業(yè)務(wù)中的占比超過(guò)30%的時(shí)候，上面的組織架構(gòu)就面臨挑戰(zhàn)了。因?yàn)闃I(yè)務(wù)需求越來(lái)越多，用戶對(duì)移動(dòng)應(yīng)用體驗(yàn)要求越來(lái)越高，獨(dú)立的移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)在人手和對(duì)業(yè)務(wù)的熟悉度上都是受到限制的。所以，應(yīng)該把移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)拆散到技術(shù)開(kāi)發(fā)團(tuán)隊(duì)中去，每個(gè)開(kāi)發(fā)小組直接負(fù)責(zé)各自業(yè)務(wù)的移動(dòng)化。但要保留一個(gè)小型精干的“移動(dòng)架構(gòu)”團(tuán)隊(duì)，它不參與具體業(yè)務(wù)應(yīng)用的開(kāi)發(fā)，而是負(fù)責(zé)更加抽象的移動(dòng)技術(shù)框架的設(shè)計(jì)和維護(hù)工作。
8.1.2 移動(dòng)應(yīng)用的技術(shù)架構(gòu)
移動(dòng)互聯(lián)官網(wǎng)的一個(gè)特點(diǎn)是“多屏”，即終端設(shè)備除了PC的各種瀏覽器，還有各種廠家各種型號(hào)的平板、手機(jī)。為此，提出了如下的要求：
1.在軟件開(kāi)發(fā)過(guò)程中，底層要穩(wěn)固、健壯、具備高可用性；
2.接口層要豐富、兼容、保持相對(duì)穩(wěn)定；
3.業(yè)務(wù)邏輯層要兼顧靈活性、可擴(kuò)展性，以支持靈活多變業(yè)務(wù)的發(fā)展；
4.展示層要能適應(yīng)各個(gè)終端的特點(diǎn)，擁有良好的用戶體驗(yàn)。
為支撐以上要求，書(shū)中提到了3個(gè)需要特別重視的技術(shù)框架：
1.SOA架構(gòu)
SOA（Service-Oriented Architecture，面向服務(wù)架構(gòu)）。SOA可以根據(jù)需求通過(guò)網(wǎng)絡(luò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)層是SOA的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。SOA將能夠幫助軟件工程師們站在一個(gè)新的高度理解企業(yè)級(jí)架構(gòu)中的各種組件的開(kāi)發(fā)、部署形式，它將幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。較之以往，以SOA架構(gòu)的系統(tǒng)能夠更加從容地面對(duì)業(yè)務(wù)的急劇變化。
關(guān)于SOA，有很多資料、很多細(xì)節(jié)，就不贅述了。另外近年來(lái)提倡的“微服務(wù)”也是可選的技術(shù)框架。
2.MVVM框架
MVVM（Model-View-ViewModel，模型-視圖-視圖模型）。View層專注展示，ViewModel層專注業(yè)務(wù)，優(yōu)點(diǎn)是業(yè)務(wù)邏輯集中、模塊結(jié)構(gòu)相對(duì)統(tǒng)一、好維護(hù)、容易做單元測(cè)試。跟傳統(tǒng)的MVC模式相比，MVC中的C不可避免把視圖邏輯和業(yè)務(wù)邏輯混雜，導(dǎo)致越來(lái)越“胖”、維護(hù)成本高、單元測(cè)試不好做。
MVVM的誕生
MVC（Model-View-Controller）是這樣合理分配工作的：我們需要數(shù)據(jù)所以有了M，我們需要界面所以有了V，而我們需要找一個(gè)地方把M賦值給V來(lái)顯示，所以有了C。然而我們忽略了一個(gè)很重要的操作：數(shù)據(jù)解析。在MVC出生的年代，手機(jī)APP的數(shù)據(jù)往往都比較簡(jiǎn)單，沒(méi)有現(xiàn)在那么復(fù)雜，所以那時(shí)的數(shù)據(jù)解析很可能一步就解決了，所以既然有這樣一個(gè)問(wèn)題要處理，而面向?qū)ο蟮乃枷刖褪怯妙惡蛯?duì)象來(lái)解決問(wèn)題，顯然V和M早就被定義死了，它們都不應(yīng)該處理“解析數(shù)據(jù)”的問(wèn)題，理所應(yīng)當(dāng)?shù)模敖馕鰯?shù)據(jù)”這個(gè)問(wèn)題就交給C來(lái)完成了。
而現(xiàn)在的手機(jī)App功能越來(lái)越復(fù)雜，數(shù)據(jù)結(jié)構(gòu)也越來(lái)越復(fù)雜，所以數(shù)據(jù)解析也就沒(méi)那么簡(jiǎn)單了。如果我們繼續(xù)按照MVC的設(shè)計(jì)思路，將數(shù)據(jù)解析的部分放到了Controller里面，那么Controller就將變得相當(dāng)臃腫。
還有相當(dāng)重要的一點(diǎn)：Controller被設(shè)計(jì)出來(lái)并不是處理數(shù)據(jù)解析的，它的職責(zé)是：1、管理自己的生命周期；2、處理Controller之間的跳轉(zhuǎn)；3、實(shí)現(xiàn)Controller容器。這里面根本沒(méi)有“數(shù)據(jù)解析”這一項(xiàng)，所以顯然，數(shù)據(jù)解析也不應(yīng)該由Controller來(lái)完成。
那么我們的MVC中，M、V、C都不應(yīng)該處理數(shù)據(jù)解析，那么由誰(shuí)來(lái)呢？這個(gè)問(wèn)題實(shí)際上在面向?qū)ο蟮臅r(shí)候相當(dāng)好回答：既然目前沒(méi)有類能夠處理這個(gè)問(wèn)題，那么就創(chuàng)建一個(gè)新的類出來(lái)解決不就好了？所以我們聰明的開(kāi)發(fā)者們就專門為數(shù)據(jù)解析創(chuàng)建出了一個(gè)新的類：ViewModel。這就是MVVM的誕生。
3.跨平臺(tái)移動(dòng)開(kāi)發(fā)框架
移動(dòng)平臺(tái)的主流操作系統(tǒng)雖然只有iOS、Android兩個(gè)，但已經(jīng)使開(kāi)發(fā)資源、開(kāi)發(fā)工作量翻倍了。因?yàn)橥环菪枨髱缀醵家鰞纱?，以適應(yīng)兩個(gè)平臺(tái)。
所以，選擇一款合適的“跨平臺(tái)移動(dòng)開(kāi)發(fā)框架”是非常有必要的。書(shū)中提到的技術(shù)框架是“React Native”，一款Facebook推出的基于JavaScript的開(kāi)源框架。據(jù)了解，近年還有類似的優(yōu)秀框架出現(xiàn)。跨平臺(tái)移動(dòng)開(kāi)發(fā)框架的建設(shè)目標(biāo)是“Learning once， write anywhere.”。
8.1.3 移動(dòng)應(yīng)用怎么測(cè)試
有別于PC端應(yīng)用測(cè)試的是，移動(dòng)端應(yīng)用有著更復(fù)雜的客戶環(huán)境，因?yàn)橛脩舻氖謾C(jī)型號(hào)種類繁多。把移動(dòng)應(yīng)用特有的測(cè)試要點(diǎn)摘要如下：
1.界面測(cè)試
首先，檢查界面顯示內(nèi)容。要關(guān)注完整性（數(shù)據(jù)長(zhǎng)度自適應(yīng)）、一致性（同一數(shù)據(jù)源時(shí)，保證一致）、準(zhǔn)確性（所有字段都有其明確意義）。
其次，檢查提示信息。某些重要信息在輸入、修改、刪除時(shí)應(yīng)有“確認(rèn)”提示，同時(shí)有“取消”來(lái)撤銷誤操作；無(wú)網(wǎng)絡(luò)時(shí)給出友好提示；提示語(yǔ)言易懂、具有指導(dǎo)性；界面切換、加載數(shù)據(jù)時(shí)有動(dòng)畫(huà)提示。
再次，檢查界面應(yīng)用性。編輯界面，保證鍵盤的展開(kāi)、收起，以及鍵盤上的字符符合編輯要求；按鈕可點(diǎn)擊、不可點(diǎn)擊狀態(tài)；用戶可點(diǎn)擊的觸控區(qū)域合理性。
最后，檢查界面處理。屏幕旋轉(zhuǎn)是否影響界面布局，界面切換和跳轉(zhuǎn)符合交互設(shè)計(jì)原則。
2.功能測(cè)試
首先，檢查APP運(yùn)行正常。在殺進(jìn)程后重啟、前后臺(tái)切換、鎖屏與解鎖后、網(wǎng)絡(luò)中斷恢復(fù)、有來(lái)電或消息推送時(shí)、變更時(shí)區(qū)、變更日期、變更語(yǔ)言環(huán)境等情況下均無(wú)異常。
其次，檢查授權(quán)。用到系統(tǒng)定位、相機(jī)、通訊錄時(shí)，有授權(quán)提示；用戶在不主動(dòng)退出賬戶的情況下，支持自動(dòng)登錄。
最后，檢查數(shù)據(jù)操作。根據(jù)業(yè)務(wù)規(guī)則和數(shù)據(jù)交換情況，有些地方實(shí)時(shí)更新數(shù)據(jù)、有些可以緩存數(shù)據(jù)，并支持手動(dòng)刷新數(shù)據(jù)；在請(qǐng)求數(shù)據(jù)期間，允許/禁止用戶做某些操作。
3.聯(lián)合測(cè)試
由于客戶端、接口和H5之間的依賴關(guān)系，應(yīng)注意以下情況：
> 接口/H5主動(dòng)上線，與客戶端聯(lián)測(cè)。驗(yàn)證已發(fā)布的客戶端，客戶端驗(yàn)證通過(guò)后上線；客戶端驗(yàn)證不通過(guò)時(shí)，必須修改接口/H5來(lái)保證已發(fā)布客戶端的質(zhì)量。
>客戶端上線。接口/H5應(yīng)保證客戶端質(zhì)量，所以接口/H5需要在新版本客戶端發(fā)布之前上線。
4.兼容測(cè)試
兼容性測(cè)試開(kāi)展前，應(yīng)調(diào)研用戶的設(shè)備型號(hào)。兼容性測(cè)試除了關(guān)注iOS、Android的各種版本外，還應(yīng)關(guān)注屏幕分辨率尺寸。
5.客戶端崩潰
常見(jiàn)崩潰場(chǎng)景：客戶端未對(duì)接口返回的異常數(shù)據(jù)做處理；數(shù)據(jù)量加載過(guò)大，內(nèi)存溢出；未對(duì)客戶端邏輯錯(cuò)誤做異常捕獲及處理。
必現(xiàn)的崩潰在測(cè)試覆蓋較全的情況下，可以被發(fā)現(xiàn)、解決。然而還是有些特定場(chǎng)景下的崩潰不容易發(fā)現(xiàn)，此時(shí)可通過(guò)第三方產(chǎn)品，記錄崩潰日志以便定位分析、解決問(wèn)題。
8.1.4 移動(dòng)應(yīng)用的安全保障
移動(dòng)應(yīng)用的安全問(wèn)題，主要分為三類：
1.應(yīng)用自身的安全漏洞
主要是在應(yīng)用開(kāi)發(fā)過(guò)程中，沒(méi)有重視安全問(wèn)題，沒(méi)有在設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、發(fā)布環(huán)節(jié)做好安全性檢測(cè)工作。必須建立代碼安全審計(jì)規(guī)則，如：平行權(quán)限、注入漏洞等，常見(jiàn)的安全問(wèn)題都應(yīng)該加入安全測(cè)試用例庫(kù)中。還應(yīng)關(guān)注客戶端與服務(wù)器端之間數(shù)據(jù)傳輸?shù)陌踩珕?wèn)題，敏感數(shù)據(jù)禁止明碼傳輸，使用HTTPS協(xié)議進(jìn)行加密傳輸。
2.應(yīng)用被篡改
指的是應(yīng)用被反編譯后加入廣告、木馬等惡意代碼，并發(fā)布給用戶、誘騙用戶上當(dāng)。解決辦法是，在應(yīng)用發(fā)布之前做一些必要的“應(yīng)用加固”處理，如：應(yīng)用加殼、加密，但這只能對(duì)抗一般的靜態(tài)分析和簡(jiǎn)單的逆向工程?？梢哉业谌降囊苿?dòng)安全加固公司，購(gòu)買專業(yè)應(yīng)用加固服務(wù)。
3.木馬威脅
當(dāng)用戶的手機(jī)被植入了木馬后，用戶的任何操作對(duì)于木馬來(lái)說(shuō)都是透明的，小到用戶訪問(wèn)了什么應(yīng)用，大到用戶的網(wǎng)銀帳號(hào)密碼都可以被木馬輕易獲取。針對(duì)這類情況，應(yīng)用程序必須有自己的輸入模塊，替代系統(tǒng)自帶的輸入模塊。另外，還要防止木馬程序從本地存儲(chǔ)、網(wǎng)絡(luò)通信上輕易獲得用戶數(shù)據(jù)，解決辦法是加密后存儲(chǔ)、傳輸。
當(dāng)今的移動(dòng)安全問(wèn)題形勢(shì)嚴(yán)峻，某應(yīng)用安全調(diào)查報(bào)告顯示，40%的移動(dòng)應(yīng)用存在嚴(yán)重安全問(wèn)題。隨著大家安全意識(shí)的培養(yǎng)，移動(dòng)安全服務(wù)業(yè)務(wù)的興起，會(huì)改善移動(dòng)應(yīng)用的安全性。
