??因為所接觸的業(yè)務(wù)復(fù)雜度高、技術(shù)難度大，不能像之前開發(fā)APP那樣拿到需求后畫畫流程圖、定一下各領(lǐng)域的時間節(jié)點和項目里程碑就開干，因為不對技術(shù)做抽象并輸出技術(shù)方案設(shè)計文檔是講不清楚項目的整體實現(xiàn)方案的，即使做出了功能，只要技術(shù)指標(biāo)不達標(biāo)（比如準(zhǔn)確率低、耗時長等），就很難達到和產(chǎn)品預(yù)期相符的用戶體驗。所以需要有和類似于大型項目的服務(wù)端技術(shù)方案設(shè)計一樣，對客戶端APP做技術(shù)方案設(shè)計的環(huán)節(jié)，設(shè)計出高性能和高擴展性的技術(shù)方案，避免項目風(fēng)險大、項目目標(biāo)難達預(yù)期、技術(shù)債務(wù)堆積等問題。
??移動端的技術(shù)方案設(shè)計，同樣要遵循合適（合適優(yōu)于業(yè)界領(lǐng)先）、簡單（簡單優(yōu)于復(fù)雜）、演化（演化優(yōu)于一步到位）的原則，以高可用、高性能和高擴展性為目標(biāo)。相比于服務(wù)端的技術(shù)方案設(shè)計，做事的思路和方法都差不多，只是側(cè)重點不一樣而已。
??在做技術(shù)方案設(shè)計時，我對自己的要求是需要遵循如下幾大原則：
1、成事心態(tài)：作為架構(gòu)師，在設(shè)計技術(shù)方案時要想方設(shè)法達成產(chǎn)品需求和目標(biāo)。即使產(chǎn)品需求實現(xiàn)難度大、目標(biāo)不切實際、技術(shù)上存在瓶頸，經(jīng)過嚴謹?shù)姆治鲵炞C后，在客觀陳述技術(shù)瓶頸的同時還要基于對用戶需求的洞察給出自己對產(chǎn)品方案的建議，推動其它領(lǐng)域一起去促成項目目標(biāo)的達成；
2、全球視野：對于技術(shù)難度大或沒有頭緒的事情，多看看同行頭部企業(yè)是怎么做的，尤其是自己不了解、認為有難度的地方，要通過查閱資料、深入交流等方式，去開闊自己的視野，切忌成了井底之蛙在坐井觀天；
3、說到做到：方案設(shè)計出來不是架構(gòu)師工作的終點，而是工作的起點，架構(gòu)師的厲害之處在于不僅能設(shè)計出合適的技術(shù)方案，還能將技術(shù)方案落地，達成預(yù)期目標(biāo)。要通過在落地過程中遇到的問題去反思復(fù)盤，優(yōu)化自己做技術(shù)方案設(shè)計的方法、加深對技術(shù)的理解。
??下面講講我對移動端技術(shù)方案設(shè)計流程的理解：
一、需求分析：
??需求分析包括產(chǎn)品需求分析和技術(shù)需求分析，產(chǎn)品需求主要為功能性需求，技術(shù)需求主要為非功能需求，比如性能、穩(wěn)定性、安全性等，技術(shù)需求往往是設(shè)計技術(shù)方案時的約束。
??對產(chǎn)品的需求分析，最基本的是要了解做什么？解決用戶什么問題？什么時候做完？需要做成什么樣子？即要弄清楚產(chǎn)品功能、用戶需求、時間節(jié)點和產(chǎn)品規(guī)格。除了弄清楚這幾點之外，還要基于對用戶需求的洞察，去挖掘文字背后的隱藏信息，這些你洞察到但產(chǎn)品需求中沒有呈現(xiàn)出來的信息，往往就是潛在的需求變更點，即使你將洞察到的需求和疑慮告知產(chǎn)品，產(chǎn)品回復(fù)暫時不做考慮，在設(shè)計技術(shù)方案時也要將這些可能的需求考慮進去增強技術(shù)方案的拓展性。具體做法是假想自己就是用戶，去模擬用戶在特定場景下可能的行為。
??對技術(shù)的需求分析，主要是要識別出如果要保障產(chǎn)品在生命周期內(nèi)持續(xù)安全穩(wěn)定的運行，需要做些什么，這通常都屬于非功能性需求，比如：
1、安全性問題：被劫持、被逆向、被抓包等；
2、兼容性問題：在不同設(shè)備上運行可能存在的兼容性風(fēng)險；
3、性能問題：內(nèi)存泄漏、卡頓、高CPU占用等可能導(dǎo)致整機流暢度和功耗等問題；
4、 合規(guī)問題：技術(shù)上可能存在的法律風(fēng)險，比如使用第三方開源庫等。
二、方案設(shè)計：
??需求分析的主要工作是知道做什么？要做成什么樣？什么時候做完？做什么、做成什么樣是目標(biāo)，什么時候做完是約束。技術(shù)方案設(shè)計的主要工作是在產(chǎn)品和技術(shù)的約束下，設(shè)計技術(shù)方案實現(xiàn)項目目標(biāo)。其實技術(shù)方案的設(shè)計就是一個工作拆解的過程，現(xiàn)在的項目通常都很復(fù)雜、涉及領(lǐng)域眾多，只有拆成一個一個地模塊，然后由團隊相互協(xié)作，才能更好的達成項目目標(biāo)。架構(gòu)師要做的就是抽象問題、拆解模塊、串聯(lián)各模塊搭建方案以及明確每個模塊的實現(xiàn)方案，具體到工作上就是三個方面的工作：輸出技術(shù)架構(gòu)圖、輸出核心流程圖、明確各模塊的技術(shù)實現(xiàn)方案。
??技術(shù)架構(gòu)圖就是抽象問題和拆解模塊的工具，架構(gòu)圖分很多種，其中分層、分模塊的架構(gòu)圖最為流行，做技術(shù)方案設(shè)計的首要任務(wù)就是畫出基于項目的技術(shù)架構(gòu)圖，通過劃分為多個抽象的層級實現(xiàn)邏輯上的拆分、通過對單個層級下劃分為多個模塊實現(xiàn)物理上的拆分。Android平臺架構(gòu)圖就是典型的分層、分模塊架構(gòu)，具體如下圖所示：
??通過架構(gòu)圖能夠清晰明了地知道整個項目有哪些技術(shù)領(lǐng)域和哪些技術(shù)點組成，如果要讓整個項目運作，就需要通過流程將技術(shù)架構(gòu)中的各模塊串聯(lián)起來，技術(shù)架構(gòu)中的每一層和每個模塊就像一個一個的齒輪，流程圖就像是潤滑油，讓齒輪之間聯(lián)動運行起來。在技術(shù)方案設(shè)計階段，只需要畫出項目的主流程和核心流程就可以了，其它子流程可以在詳細設(shè)計的時候再畫。
??明確整個項目的方案后，還需要明確技術(shù)架構(gòu)中每個子模塊的實現(xiàn)方案，在能夠滿足功能和指標(biāo)需求的前提下，子模塊盡量復(fù)用公司或社會現(xiàn)成資源，其中社會資源包括開源的項目以及通過商務(wù)合作的資源，因為快速低成本交付是項目的首要目標(biāo)。如果沒有現(xiàn)成的方案，就需要根據(jù)公司的技術(shù)能力和項目的約束，確定是自研還是尋找技術(shù)合作。如果是自研需要走預(yù)研流程，在有預(yù)研成果對項目有一定的把握后才能進入工程化。如果是尋找技術(shù)合作，需要做技術(shù)方案選型，技術(shù)方案選型要基于項目的各維度關(guān)注點來選出最合適而非最厲害的方案（合適優(yōu)于業(yè)界領(lǐng)先），在方案選型中呈現(xiàn)的信息必須是經(jīng)過實際驗證得出的，切忌只是做信息的收集，避免因為信息不準(zhǔn)確而誤判導(dǎo)致潛在的項目風(fēng)險。
三、方案總結(jié)：
??技術(shù)方案設(shè)計完成后，需要給出總結(jié)性的結(jié)論，答復(fù)團隊和領(lǐng)導(dǎo)的疑慮。因為團隊中領(lǐng)域眾多，大家對技術(shù)的理解和認知各有不同，關(guān)注的重點也各不相同。所以在給出結(jié)論時要用直白簡練而非技術(shù)性的語言，解答各干系人的關(guān)注點。
結(jié)論通常包含如下幾個方面的內(nèi)容：
1、 技術(shù)上能否實現(xiàn)？
2、 技術(shù)上能做到什么程度？
3、 項目上存在哪些風(fēng)險？有何應(yīng)對方案？
4、 整個項目的投入情況如何？
??用一句話描述技術(shù)上能否實現(xiàn)即可，技術(shù)上可行/不可行。前提是要基于項目的約束，包括產(chǎn)品上和技術(shù)上的。
??如果可行，需要輸出整個項目以及各技術(shù)子模塊的技術(shù)規(guī)格，講清楚衡量技術(shù)能力的指標(biāo)以及能做到什么程度。
??接下來需要闡述清楚在項目過程中存在的潛在風(fēng)險，風(fēng)險包括：
1、 進度風(fēng)險：進度上存在的風(fēng)險；
2、 資源風(fēng)險：人力等資源上存在的風(fēng)險；
3、 涌現(xiàn)風(fēng)險：多個技術(shù)組合、并行存在的風(fēng)險，比如功耗、系統(tǒng)資源瓶頸等問題；
4、 體驗風(fēng)險：比如耗時長、操作繁瑣等和產(chǎn)品預(yù)期不一致的風(fēng)險問題；
5、 指標(biāo)風(fēng)險：受限于項目約束和技術(shù)瓶頸，無法達成產(chǎn)品規(guī)格的風(fēng)險。
??風(fēng)險的應(yīng)對方案包括：
1、 消除風(fēng)險：風(fēng)險可以消除且對項目沒有影響，這種通常不用寫出來；
2、 規(guī)避風(fēng)險：無法正面解決，但可以曲線救國的方案，這種情況可能對用戶體驗或其它方面有影響，必須寫出來講清楚，要在項目上達成一致；
3、 減小風(fēng)險：風(fēng)險無法消除但可以降低風(fēng)險對項目的影響。
??最后需要講清楚項目在人力、資金方面的投入成本，便于領(lǐng)導(dǎo)決策項目的價值。是否值得投入，或調(diào)整項目策略。
四、方案落地：
??在方案設(shè)計完成，且通過項目內(nèi)、領(lǐng)導(dǎo)的決策后，接下來需要按照設(shè)計的方案落地達成技術(shù)規(guī)格，在落地的過程中需要重點關(guān)注如下幾個方面：
1、 分里程碑拆解目標(biāo)，類似于敏捷開發(fā)小步快跑的方式及時交付、遇到問題能快速調(diào)整，降低風(fēng)險，避免一條路走到黑、遲遲看不到效果。
2、 分點專項驗證各技術(shù)點的達成情況，各個關(guān)鍵的技術(shù)點都需要針對性驗證和驗收，齒輪的質(zhì)量有保障，多個齒輪組成的系統(tǒng)聯(lián)動才會有保障。
3、 遇到異常時優(yōu)先嘗試去解決，如果在一段時間內(nèi)沒有進展需及時調(diào)整方案；只要是在方案設(shè)計階段經(jīng)過嚴格的驗證，遇到異常時首先不應(yīng)否定自己的方案，要想辦法嘗試解決遇到的問題。如果實在解決不了，要及時調(diào)整避免對項目進度造成影響。
4、 工程化的優(yōu)化是錦上添花的操作，但要正確理解工程化的優(yōu)化，不是打補丁，而是方案層面的優(yōu)化，比如多個技術(shù)并行減少運行時的耗時；
5、 項目結(jié)束后及時復(fù)盤總結(jié)，優(yōu)化后續(xù)的技術(shù)方案設(shè)計流程和方法。
??下面是對整篇文章的總結(jié)：
1、 技術(shù)方案的設(shè)計要以全球視野去想方設(shè)法做成項目，并且方案設(shè)計出來后要能親自落地，達成項目目標(biāo)；
2、 技術(shù)方案設(shè)計要充分洞察產(chǎn)品和技術(shù)需求，基于需求通過架構(gòu)圖拆解模塊，并通過流程將各模塊中的技術(shù)點串聯(lián)起來使整個項目運行起來。對于關(guān)鍵的技術(shù)點，要基于嚴謹?shù)尿炞C分析做出方案選型；
3、 技術(shù)方案的評審要給出明確的結(jié)論，以各領(lǐng)域都能懂的語言表達清楚技術(shù)的可行性、技術(shù)規(guī)格、風(fēng)險和應(yīng)對方案以及項目投入情況；
4、 技術(shù)方案設(shè)計評審?fù)ㄟ^不是架構(gòu)師工作的終點，把技術(shù)方案落地達成項目目標(biāo)才是終點。
