摘要：請求下來數(shù)據(jù)之后，我們使用了提供的進(jìn)行解析，類化。示例代碼本篇我們將提供以及示例代碼來闡述我們上文中提到的用法。下一節(jié)下一節(jié)中我們將針對初創(chuàng)公司端技術(shù)團(tuán)隊構(gòu)建的一些問題來闡述我們的團(tuán)隊如何構(gòu)建以及運(yùn)作的。

“網(wǎng)絡(luò)請求 - 解析數(shù)據(jù) - 寫入緩存 - 讀取緩存”

在上篇的文章中我們說明了我們在是在 MVC 層面的 M 層共享了代碼，不過對于只是“有可能”需要 OpenSDK 的團(tuán)隊來說，更重要的還是保證 M 層的代碼能夠支撐 VC 層的調(diào)用方式。我們在編寫界面的時候，通常情況下是先從緩存(SQLite，下同)中查詢該界面已經(jīng)緩存的數(shù)據(jù)用于顯示一屏預(yù)覽數(shù)據(jù)，此時在界面上某個角落顯示 HUD，然后發(fā)起網(wǎng)絡(luò)請求，請求到數(shù)據(jù)之后解析數(shù)據(jù)(JSON,XML,Protol Buffers)，然后將數(shù)據(jù)類化寫入緩存——YES，就這么倆事(兒)，too 易姿 too 森破。

“l(fā)ibcurl & json11”

我們團(tuán)隊在 Web 上用的是 MEAN Stack，對于 Client 來說，就是發(fā)起一個請求，然后獲得一個以 JSON 形式表示的結(jié)果，Client 將其解析為類，然后將結(jié)果同步到 SQLite 中，方便下一次緩存頁面的使用，在具體的使用中，我們參考 cocos2d-x 對 libcurl 的封裝，并結(jié)合 C++ 11，封裝了一個 HttpClient 用于普通的 GET/POST/PUT/DELETE 請求，對于 iOS 和 Android 的上傳和下載部分，我們?nèi)匀皇褂昧嗽姆椒ǎ驗橛行r候上傳和下載需要在“后臺”進(jìn)行，這意味著需要提供能訪問 framework API 的能力，對于 Windows 和 Mac，則可以繼續(xù)使用 HttpClient 中提供的 C++ 方法來進(jìn)行操作 (因為并沒有“后臺”一說)。請求下來數(shù)據(jù)之后，我們使用了 dropbox team 提供的 json11 進(jìn)行解析，類化。

“easySqlite”

在數(shù)據(jù)緩存方面，我們選用了大家都說好的 SQLite，在 SQLite 的方案上我們其實做過一些探討——我們可以選擇 CoreData 作為 iOS/Mac 的方案，Android 也有原生的 Helper，Windows 則只能使用 C/C++ 的原生方案。經(jīng)過實踐我們發(fā)現(xiàn)其實在客戶端幾乎只有讀取緩存的需求——因為寫入緩存的操作可以在 C++ 層面完成——緊接在 HTTP 請求之后，所以我們就選用了所有平臺都使用 C/C++ 的方式進(jìn)行數(shù)據(jù)庫操作，查了幾個可選的 C/C++ 庫之后，我們覺得 easySqlite 是比較容易使用和維護(hù)的。(輕量是我們評估方案的一個重要參考指標(biāo)，輕量不僅意味著小，而且意味著 fork 之后我們可以自己進(jìn)行修改而不用在弄懂里面的工作原理上花過分多的時間)

在緩存策略上，我們就是簡單的將 JSON 解析后類的表存儲到數(shù)據(jù)庫中。這里有個小插曲，之前有看到有策略是將每個頁面的 JSON 直接存儲到數(shù)據(jù)庫中，然后取出的時候解析呈現(xiàn)，不過我們的移動端和桌面端有可能調(diào)用不同的 API 接口，而且如果按照頁面緩存，就不是一個適合放在 Core 層的方案了，故最終該方案還是沒有敵過我們一顆面向?qū)ο蟮男摹?/p> Prebuilt & Future

“Sakura”

由于我們在 Worktile Pro 版與 Worktile協(xié)同版中使用了同一套的底層工具庫，而 build 過 C++ library 的同學(xué)也應(yīng)該會覺得其實每個平臺看著對應(yīng)庫的文檔去 build 也是挺蛋疼的一件事情，所以我們將我們用到的 C++ 庫 fork 一份并且編譯出來，連我們一起的弄出一個 prebuilts 作為我們 C++ 的核心庫的工具庫，用 git submodule 形式管理使用。(為了體現(xiàn)一點情懷，我們?nèi)∶麨?Sakura>>)

“人生苦短，我用 Python”

上文介紹的 C++ 跨平臺的目的，是在創(chuàng)業(yè)公司初期人少的時候提供一個可以很快出產(chǎn)品的技術(shù)方案，在我們編寫一個又一個的模塊時，我們發(fā)現(xiàn)我們在做一個比較重復(fù)性的事情 ——寫一個 User，寫一個 UserManager 用于管理 User 相關(guān)的 API，為 UserManager 編寫一個 FetchUsersFromCache， 用于從 SQLite 從讀取用戶的信息，然后編寫對應(yīng)的 Objective-C++ Wrapper 以及 Java Wrapper，然后我們編寫一個任務(wù)的模塊的時候，我們又重復(fù)了同樣的一個過程——當(dāng)然，細(xì)想一下，我們重復(fù)做的事情并不能通過在 C++ 設(shè)計 Super Class 或者 Template 抽象出來，但是我們的的確確在用一套重復(fù)的思維方式，于是，我們將應(yīng)該由 Contributor 消費(fèi)腦力完成的設(shè)計過程提煉成 module.xml，然后編寫了一個 Python 腳本用于生成 C++, Objective-C++ 以及 Java 部分的代碼>> 。

使用 Model Builder 構(gòu)建代碼的好處一方面是可以保證全部門的代碼風(fēng)格統(tǒng)一并且符合規(guī)范，另外也可以解決一些由于傳參太多或者重構(gòu)的時候順序亂了造成的一些低級錯誤。不過需要特別提一句的是，即使使用了 Model Builder，我們?nèi)匀徽J(rèn)為只有 Unit Test 能保證你的代碼質(zhì)量，我們僅將 Model Builder 視為代碼構(gòu)建的輔助工具。另外，因為在我們公司我們無法獲取 Web 端的代碼，如果你所在的公司處在剛起步的階段，你完全可以考慮將 Model Builder 自行擴(kuò)展下使其能夠生成你們的樣式的 Web 端代碼以及文檔，這樣更讓聯(lián)調(diào)這一過程變得 smooth (因為返回的 JSON 的 Key 聲明在了 module.xml 中，這樣就可以保證服務(wù)端所使用的 path 和客戶端的相同)。

本篇我們將提供 iOS 以及 Android 示例代碼 來闡述我們上文中提到的用法。

下一節(jié)

下一節(jié)中我們將針對初創(chuàng)公司端技術(shù)團(tuán)隊構(gòu)建的一些問題來闡述我們的團(tuán)隊如何構(gòu)建以及運(yùn)作的。