一名架構(gòu)師的職責(zé)是解放公司第一生產(chǎn)力(程序員們)脫離制造輪子的繁復(fù)工作包归。好的架構(gòu)設(shè)計(jì)是要經(jīng)得起檢驗(yàn)的哄褒，但是它未必經(jīng)得住時(shí)間的考驗(yàn)，任何框架和架構(gòu)都會(huì)在熊熊的社區(qū)烈火考驗(yàn)中被逐步淘汰敲茄。在這篇文章會(huì)詳細(xì)介紹APP的設(shè)計(jì)充包，APP的框架選型副签，以及APP后臺(tái)服務(wù)的交互通信安全方面的問(wèn)題。
互聯(lián)網(wǎng)時(shí)間的指針已經(jīng)指向了2017年基矮，我們手機(jī)的空間越來(lái)越大淆储，手機(jī)中的APP應(yīng)用也越來(lái)越多，每一個(gè)應(yīng)用所占用的內(nèi)存也是越來(lái)越多家浇，似乎現(xiàn)在的我們已經(jīng)不太在乎每一個(gè)APP應(yīng)用的大小了本砰，那么我們?cè)谑褂煤腕w驗(yàn)這些APP的時(shí)候，我們?cè)诤醯氖鞘裁茨兀?/p>
在13年到15年的時(shí)候钢悲，app 在UI設(shè)計(jì)上充斥了很多同質(zhì)化的產(chǎn)品点额，手機(jī)銀行舔株，直銷銀行這兩類APP，更是在內(nèi)容上存在同質(zhì)化咖楣，當(dāng)然這與其行業(yè)特性分不開(kāi)督笆。但是，現(xiàn)在到了2017年诱贿，UI設(shè)計(jì)師們?cè)赿ribbble和behance的風(fēng)格影響下娃肿，有了更多的發(fā)展空間，不得不說(shuō)的是珠十，現(xiàn)在的app比之前越來(lái)越好看和越來(lái)越好用了料扰。
這里有一個(gè)關(guān)鍵的問(wèn)題就出現(xiàn)了，為什么有些app焙蹭，普通用戶一打開(kāi)就自然而然地覺(jué)得它很美晒杈？用戶這種“覺(jué)得它很美”的意識(shí)到底是從哪兒來(lái)的？為了闡述用戶這種“覺(jué)得他很美”的意識(shí)的來(lái)源孔厉，就必須要了解app中“內(nèi)容”和“形式”之間的關(guān)系拯钻。
那我們不妨來(lái)了解一下內(nèi)容和形式的關(guān)系。內(nèi)容是集成在app中所有可被感知的圖片撰豺、文字粪般、聲音的合集。之所以說(shuō)是可被感知污桦，主要是從用戶層面上看亩歹，忽略用戶不可感知的”代碼”層面。那么我們必要搞要清楚的是凡橱，一個(gè)app的內(nèi)容到底是如何產(chǎn)生的小作？
假如有一天，一家銀行找到我們說(shuō)稼钩，做一個(gè)手機(jī)銀行APP顾稀，我們這里參考招商銀行。打開(kāi)招商APP变抽，參考他的UI設(shè)計(jì)和功能設(shè)計(jì)础拨。這個(gè)時(shí)候開(kāi)始思考這款app的MVP狀態(tài)應(yīng)該需要什么功能：
MVP=Minimum Viable product（最小可行產(chǎn)品）是《精益創(chuàng)業(yè)》的作者埃里克·萊斯提出提出的一個(gè)概念，意思就是可保證產(chǎn)品正常使用（主邏輯閉環(huán)）的最小產(chǎn)品單元绍载。MVP又分為Validating MVP和Invalidating MVP诡宗，《精益創(chuàng)業(yè)》是一本特別贊的書，推薦大家閱讀击儡。
▲********內(nèi)容設(shè)計(jì)APP內(nèi)容設(shè)計(jì)需要包含：“首頁(yè)”是核心塔沃，主要提現(xiàn)手機(jī)銀行的核心功能，賬戶阳谍，轉(zhuǎn)賬蛀柴，信用卡還款等螃概， “理財(cái)”將銀行的各類理財(cái)產(chǎn)品以分類列表的形式展現(xiàn)，生活類的類似于電商APP提現(xiàn)各類活動(dòng)和生活應(yīng)用鸽疾，“我的”里面會(huì)有賬戶總覽吊洼，收支記錄等一堆東西。其實(shí)這個(gè)時(shí)候制肮，產(chǎn)品設(shè)計(jì)師已經(jīng)在定義產(chǎn)品的信息架構(gòu)了冒窍。內(nèi)容就是這樣產(chǎn)生了。
▲********形式設(shè)計(jì)如果說(shuō)把所有集成在app中豺鼻，可感知的圖文聲的集合都可以稱作app的內(nèi)容的話综液，那app的形式就是“承載內(nèi)容，使內(nèi)容更好被感知的方式”儒飒。
人有五感谬莹，視覺(jué)、聽(tīng)覺(jué)桩了、嗅覺(jué)附帽、味覺(jué)、觸覺(jué)井誉。而人去和一款手機(jī)應(yīng)用進(jìn)行交互的時(shí)候只會(huì)從視覺(jué)士葫，聽(tīng)覺(jué)，觸覺(jué)（反饋）三個(gè)方面去感知送悔，而觸覺(jué)涉及到交互層面， 關(guān)于聽(tīng)覺(jué)其實(shí)也不是本文重點(diǎn)爪模。
舉個(gè)例子欠啤，比如大家都用過(guò)滴滴，滴滴有一個(gè)“內(nèi)容（功能）”是司機(jī)送一個(gè)乘客的過(guò)程中屋灌，當(dāng)判斷距離目的地很近的時(shí)候會(huì)默認(rèn)進(jìn)行一個(gè)“下一單的匹配”的功能洁段。我們用滴滴的這個(gè)功能來(lái)對(duì)比手機(jī)游戲里面的“匹配下一局”，我們會(huì)發(fā)現(xiàn)這是幾乎相同的“內(nèi)容”共郭，但是承載形式不一樣祠丝，手游是視覺(jué)展現(xiàn)，你必須點(diǎn)擊手機(jī)上的“匹配”按鈕除嘹，而滴滴因?yàn)榭紤]到司機(jī)在開(kāi)車很難解放雙手去點(diǎn)擊匹配写半，所以從產(chǎn)品邏輯上設(shè)計(jì)的是“語(yǔ)音提示+主動(dòng)匹配+手動(dòng)接單”的方式，所以我們總能在快下出租車的時(shí)候聽(tīng)到司機(jī)手機(jī)上傳出響亮的“開(kāi)始接單啦”語(yǔ)音提示尉咕。
一款A(yù)PP的設(shè)計(jì)過(guò)程叠蝇，從無(wú)到有，大概就是如此年缎。
【前端工具介紹】
大多做APP的是從WEB開(kāi)發(fā)轉(zhuǎn)化而來(lái)的悔捶，如果要在這里說(shuō)說(shuō)前端的發(fā)展之路铃慷，這可能又要開(kāi)始一篇新的文章了。這些年來(lái)蜕该，前端的框架如同雨后春筍犁柜，層出不窮。一直以來(lái)堂淡，許多軟件公司都希望開(kāi)發(fā)一套框架來(lái)統(tǒng)一處理前端的所有問(wèn)題馋缅，例如Facebook開(kāi)發(fā)和維護(hù)的React，用于支持起WhatsApp和Instagram產(chǎn)品淤齐，它目前是GitHub上最受歡迎的項(xiàng)目之一股囊，再如Google推出的Angular系列框架用于其Adwords,Fiber項(xiàng)目，還有號(hào)稱輕量級(jí)低門檻的Vue更啄，等等稚疹。
各家公司封裝的前端框架都有各自的側(cè)重點(diǎn)，并不能全部的解決所有問(wèn)題祭务，當(dāng)然内狗，他們也都解決了前端需要共同面對(duì)的問(wèn)題：組件化，數(shù)據(jù)綁定以及平臺(tái)無(wú)關(guān)的Render機(jī)制义锥，我第一次聽(tīng)說(shuō)Render這個(gè)詞柳沙，是在學(xué)習(xí)ExtJs(其在前端實(shí)現(xiàn)類似后端服務(wù)的MVC模式給我及其深刻的印象)。
2007年到2009年拌倍，對(duì)于前端開(kāi)發(fā)來(lái)說(shuō)赂鲤，這是一個(gè)極其重要的時(shí)間段。因?yàn)?007年Apple發(fā)布了IPhone1（IPhone在中國(guó)的大爆發(fā)是從4和4S開(kāi)始的柱恤，123這3代在國(guó)內(nèi)基本上沒(méi)有人知道）数初，而2009年誕生了NodeJS。兩個(gè)缺一不可的主角終于登場(chǎng)了梗顺！
IPhone把人類帶入了移動(dòng)互聯(lián)網(wǎng)時(shí)代泡孩，而NodeJS把前端開(kāi)發(fā)帶入了工業(yè)化時(shí)代！所以寺谤，以2009年為界仑鸥，你會(huì)發(fā)現(xiàn)，2009年之后出現(xiàn)的所有前端框架（包括CSS和JS標(biāo)準(zhǔn)）变屁，都會(huì)做一件事：那就是必須要兼容移動(dòng)端的小屏幕眼俊！于是，老一代桌面端框架的光環(huán)開(kāi)始褪色粟关，2009年首先出現(xiàn)了AngularJS泵琳、2014年底誕生了React、2015年初誕生了Vue，移動(dòng)互聯(lián)時(shí)代的前端技術(shù)開(kāi)始大爆炸啦获列！
目前來(lái)看谷市，React、Angular击孩、Vue基本上處于三足鼎立的態(tài)勢(shì)迫悠。
Angular是一個(gè)功能豐富的框架，React是一個(gè)豐富的UI組建庫(kù)巩梢，Vue是一個(gè)號(hào)稱最易入門创泄，最輕量級(jí)的框架，從這三者的對(duì)比上來(lái)看括蝠，解決前端的思路主要有：
一是鞠抑，高效的渲染技術(shù)加豐富的組件庫(kù)，開(kāi)發(fā)人員只需要拖拽來(lái)用即可忌警。
二是搁拙，是給開(kāi)發(fā)后端服務(wù)的程序員們一個(gè)進(jìn)入前端開(kāi)發(fā)的學(xué)習(xí)機(jī)會(huì)，例如后臺(tái)服務(wù)的MVC思想引入前端法绵，出現(xiàn)了ExtJs（針對(duì)4以上的版本）箕速，例如Angular中引入的TypeScript,這對(duì)原來(lái)有.NET語(yǔ)言和Java語(yǔ)言基礎(chǔ)的同學(xué)來(lái)說(shuō)非常容易。
【APP后臺(tái)服務(wù)架構(gòu)】
當(dāng)設(shè)計(jì)APP后臺(tái)架構(gòu)的時(shí)候朋譬，根據(jù)架構(gòu)框架盐茎，采用以下4點(diǎn)設(shè)計(jì)APP架構(gòu)：? 根據(jù)APP的設(shè)計(jì)，梳理出APP的業(yè)務(wù)流程徙赢，把每個(gè)業(yè)務(wù)流程列出字柠；? 把每個(gè)業(yè)務(wù)流程可能會(huì)遇到的問(wèn)題整理出來(lái)；? 根據(jù)整理出的問(wèn)題狡赐，探討可行的技術(shù)解決方案募谎；? 把第三點(diǎn)中的所有技術(shù)解決方案有機(jī)融合，就是一個(gè)APP后臺(tái)的初步架構(gòu)阴汇。
每個(gè)APP都有獨(dú)自的業(yè)務(wù)邏輯，遇到的問(wèn)題會(huì)不一樣节槐，解決方案也不一樣搀庶，因此架構(gòu)也不盡相同。APP的架構(gòu)演變是由業(yè)務(wù)驅(qū)動(dòng)的铜异，架構(gòu)是為了滿足業(yè)務(wù)的需求而設(shè)計(jì)的哥倔，技術(shù)人員不該過(guò)度設(shè)計(jì)，學(xué)了一堆最新揍庄，最炫的技術(shù)并將其放進(jìn)架構(gòu)咆蒿，這是不合適的。技術(shù)是為了滿足業(yè)務(wù)而存在。
APP和APP后臺(tái)的通信是用HTTP協(xié)議還是私有協(xié)議沃测，是用長(zhǎng)連接還是短連接缭黔？使用通用語(yǔ)言通信還是使用暗語(yǔ)通信？
▲****HTPP協(xié)議OR私有協(xié)議
協(xié)議就相當(dāng)于一套語(yǔ)言蒂破，雙方都知道每個(gè)字節(jié)的具體含義馏谨，網(wǎng)絡(luò)通信中有很多通用協(xié)議，其中HTTP協(xié)議就是使用最廣泛的一種附迷。大多數(shù)開(kāi)發(fā)語(yǔ)言都支持通用協(xié)議惧互，有大量成熟的模塊供程序員調(diào)用，方便程序員解析這些通用協(xié)議的內(nèi)容喇伯，使用私有協(xié)議就相當(dāng)于使用暗語(yǔ)通信喊儡，其類似于開(kāi)發(fā)一套新的語(yǔ)言。
私有協(xié)議對(duì)協(xié)議的封裝和拆解工作量大稻据，App程序員和后臺(tái)程序員都要增加額外的工作量艾猜，而且私有協(xié)議對(duì)程序員的設(shè)計(jì)能力要求高，從WEB網(wǎng)站轉(zhuǎn)向移動(dòng)開(kāi)發(fā)的開(kāi)發(fā)者上手有一定的困難攀甚，除非開(kāi)發(fā)者對(duì)App的安全性和性能要求高箩朴，不然選擇HTTP協(xié)議就足夠了。
▲長(zhǎng)****連接OR短連接
長(zhǎng)連接短連接的選擇問(wèn)題秋度。我想作為一名成熟的開(kāi)發(fā)者來(lái)說(shuō)炸庞，應(yīng)該是非常明白的。我們的服務(wù)器資源是有限的荚斯，所以長(zhǎng)連接并不太合適埠居，但是，在一些場(chǎng)景下事期，我們又不得不用長(zhǎng)連接滥壕，例如我們的消息推送，還有手游兽泣，這些場(chǎng)景為了做到數(shù)據(jù)的及時(shí)性绎橘，長(zhǎng)連接又是必然的選擇。
▲通信****安全
安全唠倦，是在做APP時(shí)最應(yīng)該關(guān)心的領(lǐng)域称鳞。提到安全，回到我們?cè)?jīng)熟悉的領(lǐng)域稠鼻，WEB前端冈止。做WEB的時(shí)候，為了做到安全候齿，一些核心的數(shù)據(jù)和內(nèi)容熙暴，往往是放在后端session中的闺属，傳統(tǒng)的WEB網(wǎng)站使用Cookie+Session保持用戶的登錄狀態(tài)，那么在App后臺(tái)怎么實(shí)現(xiàn)類似的功能呢周霉？在App后臺(tái)怎么避免每次驗(yàn)證用戶身份都需要傳輸用戶名和密碼呢掂器？
假設(shè)如下場(chǎng)景：把App后臺(tái)想象為一個(gè)房間，里面有個(gè)房間管理員诗眨，同時(shí)房間門有一把鎖唉匾，這把鎖有兩種打開(kāi)方式：(1)輸入了這把鎖上注冊(cè)的用戶名和密碼；(2)用房間管理員提供的鑰匙匠楚。
用戶進(jìn)入這個(gè)房間的流程如下：用戶第一次輸入鎖上注冊(cè)的用戶名和密碼打開(kāi)這把鎖后進(jìn)入房間巍膘，找到房間管理員讓其提供一把鑰匙。以后用戶每次需要進(jìn)入這個(gè)房間用這把鑰匙就行芋簿，不用擔(dān)心旁邊有人偷看到自己的用戶名和密碼峡懈，從而導(dǎo)致用戶名和密碼泄漏。(3)用戶決定一段時(shí)間內(nèi)不再進(jìn)入這個(gè)房間了与斤，又怕鑰匙被偷肪康，進(jìn)入房間后把鑰匙歸還給管理員，讓管理員把鑰匙銷毀撩穿。這里對(duì)應(yīng)上我們的APP登錄過(guò)程磷支，用下圖來(lái)表示
生成token的流程如下：
注意，這個(gè)方案是不安全的食寡，身份驗(yàn)證依賴token字符串雾狈，如果用戶泄漏了URL，那token也就泄漏了抵皱。這相當(dāng)于鑰匙被黑客復(fù)制了一份善榛。那么我們?nèi)绾蝸?lái)保障App的通信安全呢？
身份驗(yàn)證依賴于token呻畸，token被我們拿著滿大街的跑移盆，生怕黑客不知道我們的token可以來(lái)校驗(yàn)用戶信息。所以伤为，不能拿著鑰匙滿大街的跑咒循。
因此不在網(wǎng)絡(luò)上傳輸token就能很大程度上防止token泄漏。那么不在網(wǎng)絡(luò)上傳輸token的方案呼之欲出了绞愚，這個(gè)方案被叫做URL簽名叙甸，方案如下：在上一個(gè)方案版本中，Redis中除了維護(hù)token字符串和用戶信息的對(duì)應(yīng)關(guān)系爽醋，還要維護(hù)用戶id和token的對(duì)應(yīng)關(guān)系，以方便后面APP后臺(tái)驗(yàn)證URL簽名時(shí)快速查找便脊。
假設(shè)API請(qǐng)求為”test.com/user/info”,APP用token字符串” daf32asd12w”和URL的md5值作為URL簽名
APP后臺(tái)接收到這個(gè)URL后，用和APP前端相同的簽名算法生成簽名和sign參數(shù)對(duì)比，如果發(fā)現(xiàn)相等就表示驗(yàn)證通過(guò)遂赠，繼續(xù)執(zhí)行這個(gè)API的其他邏輯久妆。
但是，這個(gè)URL前面方法還有一個(gè)問(wèn)題：假設(shè)在API請(qǐng)求
沒(méi)有過(guò)期期間跷睦，黑客截獲了這個(gè)API請(qǐng)求的URL,就能反復(fù)調(diào)用這個(gè)URL.那怎么解決呢筷弦？可能有的小伙伴想到一個(gè)辦法了，我們的信息不是保存在Redis中的嗎抑诸，如果驗(yàn)證完一次烂琴，我的token值就刪掉一次重新生成一個(gè)，不就解決了嗎蜕乡？但事實(shí)證明奸绷，這不是一個(gè)很好的解決方案，為何呢层玲？
因?yàn)槿绻诳徒孬@了這個(gè)url号醉，可以反復(fù)不停地pin你的服務(wù)器，給你的服務(wù)器帶來(lái)很大的壓力辛块，并且畔派，這樣做了之后，對(duì)于那些手里有鑰匙的真正的客戶來(lái)說(shuō)润绵，他也用不了线椰，因?yàn)樗掷锏膖oken已經(jīng)被之前黑客攻擊使用的url給改變了。
那么這里有一個(gè)改進(jìn)的方案授药，就是在傳遞參數(shù)中增加時(shí)間戳士嚎，當(dāng)App后臺(tái)發(fā)現(xiàn)這個(gè)時(shí)間戳相隔當(dāng)前時(shí)間很久的，就判斷這個(gè)URL已經(jīng)失效悔叽。但是莱衩，APP端使用時(shí)間戳存在一個(gè)問(wèn)題是：App端的時(shí)間有可能和APP后臺(tái)服務(wù)的時(shí)間不一致。
保證APP端和APP后臺(tái)時(shí)間同步的方法為：APP每次啟動(dòng)時(shí)通過(guò)API獲取APP后臺(tái)時(shí)間娇澎，保存APP端時(shí)間和App后臺(tái)的時(shí)間差笨蚁，以后APP端用這個(gè)時(shí)間戳調(diào)整其生成的時(shí)間戳。例如趟庄，某一刻API獲取的APP后臺(tái)時(shí)間是1115922778括细，APP端的時(shí)間應(yīng)該是111592775，兩者的時(shí)間差是3戚啥。當(dāng)APP在本地時(shí)間應(yīng)該是213984751準(zhǔn)備向APP后臺(tái)發(fā)送API請(qǐng)求時(shí)奋单，加上時(shí)間差3，即可得到APP后臺(tái)的時(shí)間為213984754. 213984754即為參數(shù)傳遞中的時(shí)間戳猫十。
改進(jìn)方案的流程如下：
上面這個(gè)方案就完美了嗎览濒？很遺憾呆盖，它也不完美。
在今年(2017年)的1月份贷笛，蘋果App Store中的所有App都必須啟用ATS(App Transport Security)安全功能应又。蘋果公司在該公司的全球開(kāi)發(fā)者會(huì)議（WWDC）上宣布稱，公司希望官方應(yīng)用商店中的所有iOSapp都使用安全的HTTPS鏈接與服務(wù)器進(jìn)行通信乏苦。
啟用ATS后株扛，它會(huì)屏蔽明文HTTP資源加載，強(qiáng)制App通過(guò)HTTPS連接網(wǎng)絡(luò)服務(wù)汇荐，不滿足以下條件洞就，ATS都會(huì)拒絕連接。
▲********ATS客戶端支持https走域名方式請(qǐng)求的拢驾，無(wú)需更改奖磁。https走IP直連方式，使用私有證書走442端口的繁疤，將不再可行咖为；需要端口改成443端口，客戶端預(yù)埋證書改為CA證書稠腊，并且需要設(shè)置域名白名單躁染。
▲********服務(wù)端支持要求服務(wù)器必須支持傳輸層安全(TLS)協(xié)議1.2以上版本;證書必須使用SHA256或更高的哈希算法簽名;必須使用2048位以上RSA密鑰或256位以上ECC算法等。
在網(wǎng)絡(luò)環(huán)境日趨復(fù)雜的今天架忌，個(gè)人信息的保護(hù)已經(jīng)顯得非常重要了前文的例子中吞彤，我們的API即使使用了HTTPS協(xié)議也不能保證信息的絕對(duì)安全，萬(wàn)一基于HTTPS的API請(qǐng)求被黑客截獲叹放，使用URL簽名會(huì)有如下3個(gè)問(wèn)題：
● 當(dāng)用戶登錄后饰恕，APP后臺(tái)返回給APP的信息(包括個(gè)人信息)沒(méi)加密，有被截取的風(fēng)險(xiǎn)● URL簽名只能保護(hù)token值不泄漏井仰，但沒(méi)法保護(hù)其他敏感數(shù)據(jù)埋嵌，例如當(dāng)用戶更新自己的個(gè)人信息時(shí)，所有的信息在傳輸過(guò)程中應(yīng)該被加密● URL被黑客截獲后還是能在一段時(shí)間內(nèi)調(diào)用（假設(shè)APP后臺(tái)認(rèn)為有效的時(shí)間間隔是30S）俱恶。
怎么解決雹嗦，總會(huì)有辦法的，這就是AES對(duì)稱加密合是。這里了罪，對(duì)稱加密的原理就不在贅述了，直接講過(guò)程：后臺(tái)返回給APP用戶個(gè)人信息的流程如下：(1)用戶在APP后臺(tái)登錄后得到”個(gè)人信息”{"token":"daf32asd12w","userId":1,"name":"jack"}(2)App后臺(tái)的當(dāng)前時(shí)間戳為1427871234聪全，用這個(gè)時(shí)間戳生成HTTP請(qǐng)求頭Toke-ParamToke-Param:1427871234(3)取請(qǐng)求頭Toke-Param的22位長(zhǎng)度作為密鑰secretKey(4)用AES算法把個(gè)人信息用密鑰secretKey加密泊藕，再進(jìn)行base64編碼，最后用HTTPS協(xié)議返回給App难礼。
HTTPS協(xié)議內(nèi)容如下：
客戶端解密APP后臺(tái)返回的內(nèi)容流程如下：
（1）取HTTPS協(xié)議中HTTP請(qǐng)求頭Token-Param的值的22位長(zhǎng)度作為密鑰secretKey
（2）把Http body的數(shù)據(jù)先用base64算法解碼娃圆，用AES算法把解碼后的數(shù)據(jù)用密鑰secretKey解密汽久，得到用戶的個(gè)人信息。
AES算法中的密鑰不是固定不變的踊餐，可以根據(jù)項(xiàng)目的需要和實(shí)際情況，設(shè)計(jì)其他的密鑰方式臀稚。
App和App后臺(tái)服務(wù)的通信安全大體上就說(shuō)完了吝岭，那么我們最終版的AES對(duì)稱加密方法就是安全的，萬(wàn)能的嗎吧寺？非常遺憾窜管，這并不是終極的解決方案。如果APP被黑客反編譯了稚机，黑客就知道了整個(gè)通信的加密過(guò)程(知道使用的加密算法和如何獲取密鑰)幕帆，如果又同時(shí)截取了API的請(qǐng)求數(shù)據(jù)，那么整個(gè)安全措施就無(wú)效赖条。更進(jìn)一步的加密措施：
★使用自定義的通信協(xié)議傳輸敏感數(shù)據(jù)(例如納美語(yǔ)言)
★使用DES（非對(duì)稱加密算法）加強(qiáng)通信的安全性
★使用第三方加固方案對(duì)APP進(jìn)行加密
★涉及到特別敏感的信息(支付密碼)失乾，每次都需要用戶輸入，支付密碼永遠(yuǎn)不要在APP端保存
★使用自主開(kāi)發(fā)的安全控件輸入敏感信息纬乍。
