建站
咨詢
售后
建站咨詢
新聞中心
接下來要說的一個系列，是一個完整的App應(yīng)用所需要的企業(yè)級框架設(shè)計，是我這2年來在無線客戶端這個領(lǐng)域摸爬滾打的，總結(jié)沉淀的心得體會，中途吃 了很多虧，走過很多彎路，加了很多班，一次又一次的重構(gòu)，不斷的學(xué)習(xí)，才知道，哦，原來iOS要這么做，原來Android要那么做，然后回過頭來再看看 我最熟悉的wp，哦，原來WP還可以做的更好。
成都創(chuàng)新互聯(lián)基于成都重慶香港及美國等地區(qū)分布式IDC機(jī)房數(shù)據(jù)中心構(gòu)建的電信大帶寬，聯(lián)通大帶寬，移動大帶寬，多線BGP大帶寬租用,是為眾多客戶提供專業(yè)西部信息服務(wù)器租用報價，主機(jī)托管價格性價比高，為金融證券行業(yè)服務(wù)器托管，ai人工智能服務(wù)器托管提供bgp線路100M獨(dú)享，G口帶寬及機(jī)柜租用的專業(yè)成都idc公司。
2年間，我還接手了MobileAPI的維護(hù)，從而讓客戶端和服務(wù)器端的配合更順暢，中途還發(fā)明了幾個好用的工具，從服務(wù)器端到客戶端這條路我打通了。再然后，我還碰了碰tcp+protobuf，WP8的項(xiàng)目就是基于此開發(fā)的。
此外，我還打通了另一條路，那就是前端設(shè)計人員和客戶端開發(fā)人員的協(xié)作，為此，專門設(shè)計了iOS UI框架和WP UI框架，前端設(shè)計人員在拿到美工的設(shè)計稿后，不再提供標(biāo)注圖，而是基于UI 框架，直接提供xib或者xaml，客戶端開發(fā)人員可以直接拿去使用。對于Android，暫時我還沒有太好的解決方案。
也許有從事iOS開發(fā)的朋友會問，為什么要設(shè)計企業(yè)級框架呢？沒有它，我也可以很好的寫程序啊。也可以快速開發(fā)一個App啊。至少，我手下的iOS team都是這么認(rèn)為的。而Android team和WP team能比較容易接受這樣的框架。
說說我的想法，一家之言。我想是因?yàn)锳ndroid是基于Java的，經(jīng)過這么多年的沉淀，Java對設(shè)計模式、代碼規(guī)范這些概念已經(jīng)有了積累。而 且Android在設(shè)計的時候，就考慮到這些東西，所以它會有Activity、Intent、Adapter這些“積木”，搭建起一個完整的App。而 微軟出品的WP，是基于.NET framework體系的，而.NET本身就充斥著設(shè)計模式的思想。
對了，也許你得到那個點(diǎn)了——iOS在這方面顯得有些貧血。除了MVC和delegate和Notification，其它什么都沒有。所以，你可 以在一個ViewController里面寫3000行代碼，而沒有任何規(guī)定說你這樣做是錯的；不使用xib而在viewDidLoad中手動創(chuàng)建頁面所 有控件，當(dāng)然，我問過很多到我這里面試的人，他們以及他們的公司都認(rèn)為這樣做沒什么不好，甚至更靈活。大部分的iOS程序員，都已經(jīng)習(xí)慣于面向過程的編程 方式，而抵觸OOP。
我也見過一些到我這里來面試的Leader，他們來自大公司，這些公司都有一些框架設(shè)計，或者說，業(yè)界規(guī)范，比如說，數(shù)據(jù)緩存，圖片緩存、網(wǎng)絡(luò)請求的封裝。
其實(shí)，越是什么都沒有，才越好做框架。我們可以借鑒Android和WP的設(shè)計，甚至是網(wǎng)站開發(fā)、javascript開發(fā)、windows開發(fā)的經(jīng)驗(yàn)和模式，補(bǔ)充到iOS的框架中去。
2年來，我就在堅持不懈地做這件事，基本上可以認(rèn)為是做成了，由iOS、Android、WP三套框架組成，它們的設(shè)計思想是一樣的，包括以下18點(diǎn)，其中最重要的是前六點(diǎn)，稱之為框架設(shè)計的六大要素。
框架設(shè)計六大要素：
1.基類的設(shè)計
沒有基類，就不要說有框架。而且不僅僅是一個基類，對于一個企業(yè)級的App而言，框架層要有一個基類，里面只存放一些與框架有關(guān)的共用邏輯。App層也要有一個二級基類，繼承自框架級的那個基類，里面存放的是App相關(guān)的共用邏輯。
2.自定義App的生命周期。
對于一個頁面從初始化到消亡，每個客戶端系統(tǒng)各自有自己的生命周期。我們發(fā)現(xiàn)，在初始化的時候，要做過多的事情，代碼會很多很亂，因此有必要細(xì)分，重新規(guī)劃，定義新的生命周期。
3.發(fā)起網(wǎng)絡(luò)請求（以下簡稱MobileAPI）獲得數(shù)據(jù)。
很多書都在大講特講手機(jī)控件的使用、IO語法、酷炫動畫。卻對MobileAPI的介紹 語焉不詳。其實(shí)這才是最重要的一個環(huán)節(jié)，包括請求失敗后的自動重試、如何處理JSON、如何統(tǒng)一API的調(diào)用形式并使之最簡，對于多個API調(diào)用，是串行 調(diào)用還是并發(fā)調(diào)用及各自的處理方式。
此外，我們經(jīng)常面對的是HTTP+JSON形式的網(wǎng)絡(luò)請求，對于轉(zhuǎn)換為TCP+protobuf形式，則需要做的事情還有很多。
無論是HTTP+JSON，還是TCP+protobuf，都要考慮數(shù)據(jù)緩存，并且要讓上層使用者感受不到數(shù)據(jù)是來自網(wǎng)絡(luò)請求還是緩存。
4.圖片緩存
服務(wù)器端，有2種解決方案。
客戶端的解決方案，iOS、Android、WP實(shí)現(xiàn)思想相同，只是實(shí)現(xiàn)手法不太一樣。
5.導(dǎo)航器（僅適用于iOS和WP）
跳轉(zhuǎn)到一個頁面很簡單，但是要整個App都采用一種調(diào)整風(fēng)格，要求iOS、Android、WP都采用一種風(fēng)格，就不大容易了，尤其是傳遞參數(shù)，以及處理登錄后的回調(diào)。
6.適配器
Android在這一方面做的是最好的。對于iOS和WP，我們不妨學(xué)習(xí)一下Android，設(shè)計出各自的自動適配器。
接下來就是一些細(xì)節(jié)了：
7.登錄
別看一個小小的登錄框，里面的學(xué)問可大了。比如說，記住密碼要怎么實(shí)現(xiàn)，才能保證用戶下次打開App不需要登陸。比如Cookie的讀寫。比如登錄后要去往哪里？比如重復(fù)輸入3次錯誤后要求輸入驗(yàn)證碼的實(shí)現(xiàn)？比如最安全的登陸解決方案設(shè)計。
8.與JS的互操作
你可能會第一時間想到PhoneGap。但其實(shí)，對于一個原生的App框架，只要支持簡單的JS交互就夠了。
9.時間校準(zhǔn)
如何讓客戶端時間與服務(wù)器時間保持一致，這對于電子商務(wù)至關(guān)重要。
10.廣告處理器
廣告是目前App最賺錢的一個功能。如何設(shè)計一個通用的廣告機(jī)制，而且要脫離App整體的業(yè)務(wù)邏輯，實(shí)現(xiàn)松耦合，至關(guān)重要。
11.彈出框鏈
這是職責(zé)鏈模式在App中的典型應(yīng)用。
12.進(jìn)度條
進(jìn)度條經(jīng)常和網(wǎng)絡(luò)請求聯(lián)系在一起，分兩種，一種是調(diào)用MobileAPI時，鎖住當(dāng)前頁面不能動，知道請求返回結(jié)果；另一種是鎖住局部頁面，頁面其他地方可以操作。
13.日志工具
對于那些很難復(fù)現(xiàn)的bug，日志工具所記下的內(nèi)容，能告訴我們一切。日志分兩種，調(diào)試時直接打在控制臺上；直接寫入到在手機(jī)中。
14.單元測試
本文告訴你App上的單元測試要怎么寫？以及什么時候需要單元測試。
15.MVC還是MVVM
iOS和Android使用MVC，WP使用MVVM，本文告訴你，使用哪一種，不是絕對的，一切根據(jù)業(yè)務(wù)邏輯的復(fù)雜程度而定。以此來消除一個頁面3000行代碼的問題。
16.分頁
上拉分頁，下拉刷新。3個平臺的分頁各有不同，需要注意的細(xì)節(jié)都不能少，比如說，沒有數(shù)據(jù)時怎么辦？
17.低流量模式
在2G網(wǎng)絡(luò)下，網(wǎng)速賊慢，因此，我們要設(shè)計一種能認(rèn)用戶快速看到內(nèi)容的機(jī)制。這就是低流量模式。其實(shí)，這是App的一種需求，只是很多App并沒有考慮過。
18.UI框架設(shè)計
在分工越來越細(xì)的今天，我們可以把一部分工作分出去給其它Team。比如UI設(shè)計，完全可以讓前端人員（熟悉js和html）來做，這就需要我們?yōu)?前端Team提供一個好用的App UI的設(shè)計工具。這樣，我們能拿到的就不再是設(shè)計稿或者標(biāo)注圖，而是畫好的xib、xaml以及Android的xml布局文件。
分享題目：無線客戶端框架設(shè)計(1)：前言、目錄，以及一些念念碎
標(biāo)題來源：http://m.5511xx.com/article/cdhhgsi.html
