近幾個月的技術總結

      很久沒有上博客園了，也很久沒有寫博客了。爲何呢？最主要本身近段時間比較懶，在公司的項目裏面徹底找不到之前的那種成就感了。

      好了，讓咱們回到正題上面來吧！說到本身近幾個月的技術收穫，我想最大的即是本身由以前的純粹native android客戶端的開發，轉型到服務端了。說也奇怪，本身轉型以前一直對後端的東西是比較的好奇的，一直認爲native的客戶端開發，其實所用的技術點都是比較侷限的，沒有什麼高深的東西。你想一想一個app真正成型起來以後，他應該包括哪些東西呢？首先也許最直觀的認識就是UI界面了，確認UI起到一個承載用戶直觀體驗的重要性。假如如今有一款app擺在你的面前，當前滿懷着期待的心情打開app的時候，卻...字體大的可怕，而後整個界面佈局亂七八糟，甚至有的時候，某些按鈕卻點不了。當你剛剛靜下心來，想一想忍一忍，再點點試試吧。卻發現連個最基本的註冊、登陸功能都麻煩的要死，而後各類彈窗提示。若是是這種狀況下，我想好多用戶已經不可以在忍了，立刻卸載掉吧！因此一款好的app最起碼的條件就是要有一個牛逼的設計。

      說到app設計，我仍是想憑藉着本身的一些開發經驗、還有一些書籍上面的要點，讓咱們擺一下例子，對比對比。首先，app設計的首要原則：1.就是極簡原則。也許你知道吧，當初微信爲何會起來呢？就是憑藉着提供着及時聊天功能，同時綁定着qq大面積的穩定用戶，拿下來最開始的一些用戶。慢慢地微信纔在核心功能下來，開發了更多的用戶粘性功能，漸漸地有了朋友圈、有了微信公衆號。而後就有如今的微信，一個完整的微信生態圈。2.細節照顧，蘋果爲何可以每出一款產品就可以大賣，甚至如今已經出現了穩定的腦殘粉，每一款產品都會去定時更新、推動。讓咱們來看一下另外一款你們都比較熟悉的app-陌陌，說實話，最初陌陌剛出來的時候，用戶體驗仍是很是的糟糕的。整個界面字體太大了，而後呢？用戶好友添加過程、或者聊天、朋友動態查看都是比較麻煩的。如今的陌陌呢？產品設計已經到了必定的級別了。今天我又從新下了一款app，從新體驗了一把，發現極簡、細節都已經作的很好了。3.作到上面兩個原則以後，後面纔有可能會留在你這個app裏面。而後你要作什麼呢？也許你會想到我須要加什麼新的功能，纔可以將用戶黏在個人app裏面呢？這個時候，你就須要作好充分的用戶調研工做了，用戶須要的纔是最重要的。提及來彷佛這點在app開發之處就應該作好的，而後你看我提及來彷佛很簡單的樣子是嗎？其實，這個纔是最核心的東西，用戶的需求老是不斷的變化着，並且有的時候就連用戶本身他也不知道本身想要什麼。這個纔是如今企業最應該關注，可是好多企業都不太關注的事情。

      當咱們的設計作好以後，也許你就會想這個時候，咱們應該可以開始功能的開發工做了吧！我想這個應該放到第三步，第二步咱們應該好好的想一想到底咱們的app架構的時候，應該包括哪些功能模塊呢？讓咱們來理一理，到底app裏面一個簡單的登陸/註冊功能，應該怎麼作呢？首先登陸功能，當咱們點擊登陸按鈕的時候，後臺到底作了什麼呢？後臺代碼確定會先拿到UI界面裏，你輸入的用戶、密碼吧，而後作相關的校驗工做。當你輸入的帳號信息知足條件以後，後臺代碼會將你的帳號、密碼調用相關的api封裝成請求報文，發送到服務器。服務器收到你的報文以後，它又會怎麼作呢？解析報文拿出帳號信息，而後查找數據庫進行帳號對比，無論成功、失敗都會給客戶端返回相應的響應報文。你想一想、報文到達客戶端以後，客戶端應該怎麼作呢？須要有一個同時兼容不一樣數據格式的解析模塊吧！好比支持同時解析xml/json格式，拿出裏面的msg字段，給出響應的提示信息（這裏面可能就牽涉到一個體驗細節問題，儘可能不要用彈出框的方式提醒用戶，可能在登陸頁面用不一樣的字體輸入信息，由於彈出框的方式會打斷用戶的直觀體驗）。經過這些步驟之後一個完整的登陸流程才完成了吧。因此經過這樣的分析，咱們發現一個app後臺代碼裏面，最起碼、必不可少的功能模塊就是：Http/Https請求發送模塊、數據解析模塊、必要的時候，咱們可能還須要加上安全加密、條件校驗模塊、動畫模塊等。

      因此經過上面的分析過程，咱們能夠發現客戶端實際上所作的事情仍是比較少，甚至如今流行什麼？瘦客戶端的概念，移動端的東西越少越好，若是要達到這種要求，咱們應該怎麼作呢？H5技術就能夠很好的知足這種需求，這個時候客戶端只要提供一個外殼就能夠了，全部的H5頁面，後臺代碼邏輯都放在了服務端。這個時候，理論上咱們只須要上線一次客戶端app就能夠了，並且能夠實現高可配置性。可是這對服務端的要求就比較高了。

      說到服務端的架構就比較麻煩了，由於服務端須要考慮的事情太多了。一個請求到了以後，我首先應該丟給哪一個模塊進行處理，該模塊處理以後，拿到請求裏面的數據。這個時候我又應該怎麼進行處理呢？數據是否是須要保存到數據庫，仍是說我只須要簡單的用個臨時變量保存就能夠了。或者其餘頁面又須要使用這個請求裏面的數據，我是否是就應該保存到session裏面呢？這仍是說只有一筆請求的時候，若是這個時候同時有多筆請求的併發狀況下呢？我同時去保存數據庫是否是有可能會發生錯誤呢？數據保存過程當中是否是有可能由於多筆操做，致使流程比較慢呢？用戶體驗很是差的狀況，這種狀況下，我是否是就應該考慮使用一個穩定/成熟的框架呢？針對數據庫讀寫慢的這種狀況，我是否是又應該考慮使用一些分佈式存儲的技術框架呢？內存數據也是不錯的選擇，最終後端系統好不容易開發完成以後，這個時候我又應該考慮部署上線的相關事情了。

       好了，上面說了這麼多。讓咱們在後面的章節拆開細講吧！