內容共計6300字，預計閱讀時間需要花費10分鐘，您也可收藏後再進行閱讀
本文不是一篇純技術文章，想與IT、電商、互金、網金以及負責數字化運營的部門同儕們一起探討一下App的數字化建設。
你們家的App是不是越來越“重”？
銀行、證券業機構在智能手機上發展App，到今年應該說有十年時間了。
這十年來，相信很多機構的App都經歷過數次的“傷筋動骨”的大改造。開始的時候外購了一些技術，然後讓開發商在上面訂製、修修補補，但是發現無法響應市場變化、業務創新需求、監管規則變化，於是要麼是購買源代碼、組建自己的研發團隊接手徹底自研，要麼是另起爐竈採用新的技術框架重新開發。相信很多機構都經歷過維持舊的App還是自建新App的困擾、以及同時運營和維護兩個甚至更多歷史遺留App的痛苦。
即便是好不容易穩定在一個比較乾淨利索的架構上，隨着功能的不斷堆疊、不同階段的開發人員的不斷接手改造，很有可能越來越複雜、越來越笨重，例如個別工程師的技術水平導致了App裏的模塊劃分不清晰、功能高度耦合，最後導致改什麼東西都可能“牽一髮而動全身”；更糟糕的是，有些部分的代碼在負責人員離開後，可能誰都不願意或者不敢碰，逐漸變成App裏的一個黑箱所在。
App功能隨着時間的積累而越堆越多，開發團隊人員也進進出出，App變得越來越“脆弱”，每次發版的時間更長、需要回歸測試的功能點更多。隨之而來的是“敏捷迭代”名存實亡。開發團隊在開發新功能、填補安全漏洞、實現監管機構所需的一些合規要求、救火被客戶投訴的應用功能之間疲於奔命。
創新變得越來越難。
現有的技術能讓App變“輕”嗎？
先稍稍回顧一下App技術歷史的軌跡。
古時候，開發App大家要養兩個團隊 – 一支負責iPhone版本、一支負責Android版本。這兩撥人具備的知識結構、採用的編程語言、掌握的技術概念都是不兼容的。產品經理想實現同一個業務功能，必須跟這兩撥人都說一次。並且，兩個陣營的版本功能經常性不同步。這種類型的App叫做Native App（原生應用）
後來，開始有人琢磨，我能不能讓業務邏輯代碼只開發一次而無縫跑在iPhone和Android兩個世界呢？於是開始發明出用HTML5開發應用頁面，通過“反向代理、遠程加載、本地渲染”的辦法進行運行，並通過一種叫JS Bridge的“橋接”技術對接到手機上的原生代碼，這種類型的App叫做Hybrid App（混合型應用）。開始的時候這類應用性能不大好，但經過多年的優化（尤其是在Android上對瀏覽器內核的優化）以及手機硬件的升級，性能也總體得到提高。到今天爲止，大部分的金融類應用估計屬於這個類型。但是採用這種方案，我們還是得養着iOS和Android“兩套班子”，分別負責各自平臺上的一些原生部分的工作。
再後來，Facebook也開始琢磨這事情 。“要讓開發人員用類似JavaScript的語法，寫出接近原生的性能效果”、“要讓企業只養一套班子” - 於是Facebook發明了一種技術叫React Native，簡稱RN。市場上有越來越多的企業採用，開始的時候坑不少，經過多年的磨練，現在的RN也填了不少的坑。在金融領域，也有一些採用者。
近年來，Google也在琢磨這事情。“要讓開發人員學習Dart這種更牛逼的語言，寫出高性能的App”、“要讓企業只養一套班子”、“要讓同樣的代碼牛逼到不僅僅跑在iPhone和Android上，還可以跑在個人電腦上” – 於是Google發明了一種技術叫Flutter。市場上也開始有越來越多的企業採用，當然，作爲新生事物，坑還不少。在金融業，有沒有機構在開始採用？可能還沒有，或者有也是極少數。
無論如何，開發App的技術是在進步的，起碼在這三個方面：
1）越來越不需要養“兩套班子”了，節省人力成本
2）開發門檻低了些，起碼在iOS上，掌握Objective-C這種古代語言不是一種那麼令人愉快的事情。同樣的功能用Objective-C和Java分別在iOS和Android上實現一次，還無法保障它們運行起來是否表現一致。現在業務邏輯用JavaScript或者語法與JavaScript有相似性的Dart，開發一次，在兩種移動端都可以運行，確實便利
3）業務邏輯可以“熱更新”了。想一想每次修個小bug也要對整個App重新編譯、打包、迴歸測試、向各應用商店申請上架、等上幾天才獲得批准，甚至有被駁回的危險，這個過程多痛苦？繞開應用市場（尤其是蘋果商店）讓一些業務邏輯的代碼能被App自身進行遠程加載更新，對於經常有業務或監管需求不得不緊急迭代升級的金融機構來說，是非常必要的
可是，上述這些技術，有讓我們的App變“輕”嗎？恐怕不見得。
無論手機銀行還是手機證券類App，實質上都是銀行、券商放在用戶手裏的移動門戶，一個App後面對接着很多的業務、很多的部門、很多的場景、很多的金融產品類別，這些東西只要耦合在App上，無法由不同的團隊、按不同的時間節奏相對自由的發佈到App中，這個App就無法真正的“輕”起來。
就會導致牽一髮動全身、就需要整個App的迴歸測試；開發模式上，就需要有項目經理、產品經理去協調企業內各部門的需求，排優先級，把功能實現排個優先級，進入App開發團隊那資源有限的管道中排隊。
領導說，App是我們的“金融科技”（雖然並不是），必須全面投入，給你100個工程師… 可是這100號人估計大部分坐冷板凳，因爲現有的技術架構沒辦法讓你把人並行的用起來。
金融類App的特點
很多金融機構都有1到多個所謂的“C端”，以及1到多個所謂的“B”端。前者是在移動互聯網發展早期導致的，可能是不同的業務部門各有想法、各自發展，逐漸形成了多個承載不同業務線的App；有些情況下，也出現不同廠家爲其提供的、商業目的一樣的、內部競爭的App – 券商裏存在這種情況的不在少數。
後者則往往是因爲缺乏企業級的統籌，一會兒是建設一個賦能零售人員的移動應用，一會兒是採購一個解決遠程辦公問題的移動OA，一會兒是公司引入了某個CRM的移動版… 總之到了後來，出現五花八門的各種App，讓員工們裝上一堆，這些App在同一個手機裏卻涇渭分明互不相通，堅決形成信息孤島，讓使用者不得不來回切換，最終大部分的App都玩不起來。例如某大型銀行提供給員工的App就不下十數個，佔據其一個手機屏幕，光是從大同小異的圖標來判斷該用哪個幹什麼事情，就面臨選擇困難症。
金融類App，其實天然有以下的特點：
-
都是“賦能型”的，不是向客戶提供各種功能供其在App裏針對不同的業務進行自助服務，就是向員工提供各種工具供其進行營銷展業、辦公、彙報、查看報表等等。無論是C端還是B端，本質上都是一個前端集成的“移動端門戶”- 鑲嵌着各種工具、服務入口。工具之間從業務角度、功能角度看，並沒有太多的耦合關係，它們爲了處理不同的事情、面向不同的場景、由不同的部門負責。大家不過是在移動端分別埋些“模塊”、“入口”而已
-
迭代升級的訴求明顯。對於C端來說，它需要的是一個靈活多變、有強烈的“可運營性”、便於創新的能力，並且因爲金融市場本身的敏感性，任何時候在App端出現技術缺陷、信息安全問題、技術穩定性問題、資訊內容問題，金融機構必須有能力“實時”的進行處理，否則面臨監管問責、客戶投訴、經濟損失。對於B端來說，它需要的是一個可以持續不斷髮布新賦能工具的能力，快速響應企業內部領導、業務部門、經營管理人員及一線員工的各種訴求 – 想到就做、做好就上、有反饋就優化。通常在公司內部推廣一個新App並不容易，而廢棄失敗的可能性卻很高。要讓B端App有生命力，需要很多技巧，其中一個，必定是向全員展示不斷推出新功能、快速響應使用者反饋的能力，呈現出“論持久戰”的決心而不是給員工傳遞一個“玩票”性質的感覺
-
對是否採用所謂“原生”（Native）的技術來開發應用，並不是非常重要。和手機遊戲、辦公套件（例如Microsoft Office）、即時通訊工具等等相比，金融類App的界面其實都是表單爲主。其實用HTML5開發是合適的，至於RN、Flutter等技術，對於金融機構的開發人員，有新的學習成本，尤其是採用Flutter的學習曲線並不平滑（需要掌握一門新的語言，以及適應一個新的編程模型）
可以這麼說，很多銀行、證券、保險的App，都是碎片化功能的“集散地”，最理想的方案是，各個“碎片”單獨研發、測試、灰度發佈，有獨立的生命週期，運行在App這個“宿主”上但是無法影響“宿主”的穩定性、安全性。
大道至簡
“碎片化”和“宿主”- 有沒有這樣的應用架構可以借鑑？當然有，而且是大家都熟悉的，就是微信。
微信App，本身較爲純粹，功能設計非常剋制，遵循着較爲簡約主義的設計邏輯（當然，這要看跟誰比，在海外市場裏，Whatsapp可能是一個更加純粹、功能聚焦、目標單一的IM），但是在它上面運行着數以百萬計的小程序。這些小程序就是場景化、功能化的“碎片”，使用者隨需隨用、用完即走。而微信本身，就是支撐這些“碎片”運行的“宿主”（宿主這個比喻，也許不是最恰當，但是它就是讓小程序們寄生在其中，並且可以通過分享、轉發進行傳播）。
小程序的性能缺陷不能影響微信App本身、小程序的安全漏洞也理論上不能導致微信本身的信息安全問題，成千上萬小程序由不同的機構擁有、開發者開發，它們的升級迭代也從來不影響微信App自身的穩定性。微信App本身在應用市場的發版更新，也同樣不影響各種小程序的存在。微信App與運行在其中的小程序們，各自的生命週期獨立、彼此耦合關係非常鬆散。
在微信App內部，可以理解爲兩個基礎技術的結合，一個是即時通訊 – 提供了交流、通訊、社交的功能；一個是小程序的運行引擎，提供了遠程加載小程序代碼並把它運行在安全沙箱裏呈現給用戶的能力。
金融類App，能否整理出一個穩定的“內核”，作爲“宿主”去運行、分享、傳播各種變化頻繁、敏捷迭代的功能碎片？
金融類App是時候考慮新的架構
基於金融類App的特點，“宿主”+ ”碎片”的架構是非常適合的：
首先，金融類App如手機證券軟件，非常強調穩定性，如果能保持一個已經在生產環境打磨過多年的App“內核”，則是最爲理想的。這個“內核”僅以原生（native）方式實現最關鍵、最需要穩定的行情與交易相關基礎功能，輕易不作改動。在當下的股市，能扛的住黑天鵝事件頻發的所引起的突發性客流量、交易量，需要一個穩定、可靠的交易核心，也就是說，把App本身也分成券商IT們喜歡說的“穩態”和“敏態”。
其次，大部分的業務功能，以“碎片”的方式實現，擁有完全獨立的生命週期，獨立於App之外進行開發、測試、灰度發佈。“碎片”最理想的技術載體，是類似“微信小程序”那樣的形式。想象業務功能點以小程序開發，經過IT內測、業務部門UAT、合規審覈、運維上架，整個發佈流程完全數字化、在線。發佈之後，依然通過灰度控制，讓該業務功能小程序在有限人羣範圍逐漸放開，這一切在App側是無感的，萬一有問題，可以瞬間下架。
第三，兼容微信小程序的“標準”。開發人員只要懂微信平臺上的小程序規範與框架，就能夠開發。這樣，在市場上能找到大量的技術人員，從大學畢業生到有經驗的工程師，人才資源更加豐富。當前百度、阿里、美團、京東、字節跳動等互聯網大廠均有類似於微信小程序的技術，但是無論哪家廠都不得不接受有巨大先發優勢的微信小程序作爲“既成事實”的開發標準。雖然我們可以基於Flutter、RN等技術重新發明“碎片化”的技術載體，可是市場上有無大量可駕馭這些技術且成本較低的人才也是我們在設計技術方案時需要關注的。
第四，金融機構（券商、銀行、保險、基金等）自己扮演了騰訊的角色，在自己的機房運行自己的小程序中心，讓內部的工程師、外部的外包商技術人員、合作伙伴的IT都可以申請獲得“開發者賬戶”，申請把自己開發的小程序進行上架和灰度發佈。這個能力一旦建立，金融機構各條業務線就有可能通過自己的IT團隊或者臨時招募的合同工程師，針對自己的業務場景開發小程序並申請上架到公司的App（也是面向所有客戶的移動門店）。
這有可能導致一種新的IT研發團隊組織結構（例如小程序開發人員可能由“業務IT”負責，與App研發團隊解耦）、一種更加DevOps友好的開發模式（結合PaaS和Serverless技術）。
App從信息化到數字化的跳躍
技術人員在評估選擇App開發技術的時候，往往只考慮解決跨平臺問題、熱更新問題、開發語言問題、開發框架問題，在RN、WeeX、Flutter或原生與Hybrid型技術的選型之間糾結。但就金融這個領域來看，這些技術都只是底層的實現手段，它們是戰術性、技巧性的、從信息化角度看的。着眼點還是提高內部開發效率、降低一點開發成本。這還是把App的實現看成是一個信息化過程，和20年前開發網站把企業內部的一些技術系統集成輸出以便於客戶在網上自服務，是一個思維。
移動互聯網改變了這個格局，帶來了數字化時代。移動端App是數字化的開端。新一代金融類App，起碼需要做到以下幾點。
具有傳播能力。傳播的不僅是信息，還有工具和場景。目前最普及、最容易爲大衆所接受的，就是小程序這種載體。想一下，現在連七八十歲的老人，都知道微信裏的小程序這麼個東西，知道用它打開健康碼出入小區。子女替父母購買電商產品，把一個小程序轉發過去，老人即可打開購物車看到是否自己要的東西。這種在終極用戶層面的感知，不是RN、Flutter純粹技術實現層面所能達到的。
具有連接能力。平臺型的App和純工具型的App不同之處在於，前者天然具有社交屬性，這也是移動互聯網給我們帶來的產物。當前無論銀行、證券還是保險類的App，絕大部分缺乏平臺思維，都是做成高度同質化的、客戶自服務爲導向的、工具型的東西，可是很多金融服務的性質天然決定它應該是平臺型的，是對接多方 – 外部的客戶、合作伙伴和內部的各種業務線及崗位職能。連接多方，讓他們以共同的場景、上下文進行交流互動，是數字化的另一個要素。而小程序，剛好是能以場景化促進連接的技術載體。
具有生態化能力。我們知道互聯網巨頭們逐漸形成了所謂的Super App（超級應用），它們手握公域流量，在自己的平臺上讓大量的第三方“進駐”，讓自己的客戶在一個Super App裏獲得所有的工具與服務，通過豐富的生態圈住了用戶，同時也把合作伙伴牢牢綁住。金融業能否出現Super App，有不同的觀點。但國內一些大型銀行的App，顯然是在嘗試成爲Super App，玩生態遊戲。那麼對中小型的金融機構是否就沒有參考價值呢？顯然不是，在數字化的世界，一切都是生態化的，無法想象這個時代我們哪家金融機構不需要外部的合作 – 資訊內容的提供商、新媒體的合作伙伴、理財產品的代銷機構、專業培訓機構… 通過一個強大的合規審覈後臺，把合作伙伴的小程序“上架”到自家的App，借力外部資源共同服務客戶，是未來的一種可能。以保險公司爲例，完全可以構建這麼一個數字化生態平臺，引入更多的合作伙伴服務客戶，把一個個靜態的“保險賬戶”變成“用戶”。
具有最簡最優的用戶體驗。很多金融業務其實是低頻的，不必期望所謂的用戶黏着度、活躍度，在App裏堆疊大量的功能，不見得有多好的投入產出比。通過推送高質量、個性化、爲客戶量身定製的資訊內容來吸引和轉化用戶，在他到來時則給他乾淨利落、簡單好用的自服務功能，是一個更好的方向。
越簡單的應用實質上越強大，結合On-Device AI（端側智能），App的操作界面是越來越簡單越來越迴歸人類感官本能的。正如很多父母輩的老人，不要說駕馭不了PC，連打字機都從不曾觸摸過；結果智能手機出現後卻能熟練掌握以即時通訊工具進行社交，閱讀分享新聞、進行電商購物。越來越結合人工智能的軟件，界面只能進一步的簡化，瞭解用戶的畫像、對用戶的行爲偏好有預測能力的AI，會把與App的人機交互複雜度降到最低。讓用戶通過一個極簡主義的App“宿主”，獲得智能算法推薦過來的各種“碎片化“功能（小程序），隨需隨用，用完即走，再也不需要在一個App的菜單和服務入口裏層層深入的去定位一些功能。
文章來源：凡泰極客