獨立開發 一個社交 APP 的架構分享 (已實現)

（本博客爲原創：http://www.cnblogs.com/linguanh/）

 

My BananaCloud Android Application

前言:

　　  這算是個人第一個 完徹底全 由本身開發的社交類安卓APP，截止2016-7-15，第二版本的優化完善已順利完成，能夠正常使用。下面我將一 一講述各個點，往後若是不上線，那麼將考慮全面開源，含移動端代碼、服務器接口代碼，留意個人 GitHub。

　　因爲內容十分地多，我盡我本身的能力將各個功能模塊的作法儘量地去講清楚，歡迎留言，有問必復，文章會不斷更新，下面全部談及的功能皆已實現。

 

目錄：(點擊可跳轉)

一 、功能架構

• 公共部分
• 用戶管理
• 帖子模塊
• 文章模塊
• 個人模塊
• 搜索模塊

二 、移動端架構概述

• 框架層
• 線程層
• 緩存層
• 網絡層
• 實現層

3、服務端架構概述

• 服務器
• 數據庫引擎
• 數據庫設計
• 接口

---

1、功能架構

公共部分

• 全部用戶頭像顯示圓形，點擊即跳轉到詳情頁面
• 詳情頁面能夠看到該用戶的全部帖子操做記錄，頭像和背景圖片
• 帖子、文章圖片點擊是看大圖的效果，支持雙指縮放，多圖側滑切換，無限循環

用戶管理

• 註冊
  
  • 只能手機號，有短信驗證
  • 可選擇同時上傳頭像
  • 忘記密碼
• 登陸
  
  • 公共部分
    
    • 登陸設置緩存，一次登陸後，不退出的話，那麼之後的不用重複輸入
  • 登陸方式
    
    • 手機號碼登陸
    • 第三方登陸，含微信、新浪微博

帖子模塊

• 發佈
  
  • 文字輸入，包含敏感詞檢索，例如髒話
  • 圖片選擇，含相冊或拍照，能夠移出
  • 視頻錄製，自定義時間長度、斷點錄製，支持預覽
  • 共享位置
• 瀏覽：
  
  • 公共部分
    
    • 都會顯示出用戶頭像、發帖或評論的時間和評論的數目
  • 按編輯
    
    • 圖文混排類型
    • 圖文加視頻錄製類型
  • 按類型(內容佈局各不相同)
    
    • 圈子，能夠發佈視頻，顯示位置
    • 個人做品，圖文混排，瀑布流顯示
    • 創業，不開啓評論與點贊
• 操做：
  
  • 帖子評論與評論的回覆，包含表情的插入
  • 帖子與評論的點贊與撤銷點贊
  • 分享、收藏、舉報、信息分享到微信等平臺、刪除(帖主)等功能

文章模塊

• 瀏覽：
  
  • 內容頁純html，網頁瀏覽
• 發佈：
  
  • 由管理員經過網頁後臺編輯發佈，造成html標籤流
• 兼容：
  
  • 使用x5瀏覽器內核顯示，效果和微信類似，包括視頻播放
• 權限
  
  • 除了不能被帖子點贊，其餘同帖子操做

個人模塊(用戶信息)

• 個人背景圖片
  
  • 顯示在我的信息頁面
  • 點擊能夠修改，含剪輯
• 個人消息模塊
  
  • 推送
  • 點贊提醒
  • 評論與回覆提醒
  • 顯示效果爲小紅點和消息數目的提示
• 資料管理模塊
  
  • 頭像圖片修改，含剪輯
  • 暱稱修改
  • 密碼修改
  • 性別修改
  • 簽名、手機、郵箱、微信、興趣愛好等我的資料的顯示修改
• 帖子管理
  
  • 公共部分，點擊某一條，都會跳轉進入對應帖子或文章
  • 個人帖子模塊，顯示全部發過的帖子
  • 個人評論，顯示全部發過的評論，包含回覆
  • 我喜歡的模塊，顯示全部點過讚的帖子或評論
  • 個人收藏模塊，顯示全部收藏過的帖子或文章
• 個人設置模塊
  
  • 操做記錄私有，開啓了，別的用戶沒法查看你的操做記錄
  • 推送設置的開啓與否
  • 緩存清理
  • 檢測更新
  • 意見反饋
  • 分享給朋友
  • 關於咱們以及評分

搜索模塊

• 功能
  
  • 支持模糊搜索
  • 具有搜索的歷史緩存
• 類型
  
  • 搜索各種帖子
  • 搜索歷史記錄
  • 搜索用戶
  • 搜索文章

       說實話，這個項目的文件夾已達1.5G，安裝包混淆編譯後27M，我在寫以前，就在想要怎麼把它攤開來說，想一想真的很複雜，腦子東西東西太多。

 

2、移動端架構概述

1，框架層

• 圖片部分
        在說使用的框架以前，先說說，APP安裝包的大小的影響，包的大小能夠算進去用戶體驗的一部分，過多地使用框架只會加大APK體積和內存消耗，例如 static final int/String 或 65535限制，在使用框架的時不少時候，都是隻使用其中的一個功能。
        如今我只保留了一個，不包括第三方SDK，例如OneKeyShare，保留的是 imageLoader，保留它的緣由是，它的功能就是顯示圖片，而對於圖片這類數據，能夠說是佔內存最大的大頭，我能力有限，暫時還不能利用系統庫封裝好個比imageLoader更好的庫，同類的庫還有 picasso、fresco、volley等，曾經也引入過 fresco，比imageLoader多了不少API，考慮到框架的成熟性最後沒使用，volley就不只僅是顯示個圖片那麼簡單了，還有網絡請求，上傳等，網絡請求和上傳的代碼這部分由於我本身可以寫出還不錯的幾個函數，因此爲了減小沒必要要的消耗，沒使用volley。

• 網絡部分
         上面說到volley具有網絡的大部分需求，例如get、post請求操做，除了這個，還有 android-async-http、okHttp 等，這些我都有了解過，也在別的項目裏面使用過，但我沒使用到BananaCloud，緣由就是上面談到的網絡請求和上傳的代碼這部分，若是本身封裝好，且封裝得不錯，就不須要再去使用框架。

• 富文本編輯器
         這個在一個月前還有使用，基於gitHub 安卓開源項目-richEditor二次開發而來，原做者的項目，bug比較多，且兼容性很是差，在我修改完以後，最後一次發現bug是在紅米手機上面，編輯框徹底失效，逐棄之。修改的教程請轉移到個人博文：點我

• 視頻播放器

  • 原生

    • Ijkplayer(輕量級)
      它是Blibli技術團隊開源的一個視頻播放框架，原框架須要本身編譯.so，我當時在他們的基礎上編譯和封裝好了一個，詳情移至我 github 的 ijkplayerDemo
      
    • Vlc(重量級)
      國外的一個視頻播放框架，體積比較大，同樣須要本身動手編譯.so，相比ijk，它功能強大一點，詳情移至我 github 的 VlcDemo

  • 網頁

    • 基於javaScript播放器
      這個是我最初的嘗試，在使用原生播放器的時候，經過正則替換文章內容的video標籤，提取 src，而後組合 js 的播放器裏面，可以自定義不少功能，例如：調節亮度和聲音。
      
    • 直接使用騰訊x5瀏覽器內核
      其實，我一直想作一個像微信打開公衆平臺文章那樣的網頁 webView，兼容性強，速度快且對視頻的兼容十分好。這也是我最終的選擇

2，線程層

       因爲我網絡請求這塊沒使用框架，因此線程的選用時 Thread + Handler 組合或 AsyncTask ，須要明確一點，AsyncTask 比 Thread + Handler 更耗資源，不過使用起來比較方便。

• 數據列表類型的頁面數據加載採用自定義的 AsyncTask 繼承類來進行網絡線程
• 相似收藏、舉報這類低數據流的網絡請求採用 Thread + Handler 組合
• 圖片併發上傳的類型，採用線程池進行

3，緩存層

       Android 的數據存儲方式有5種，分別是 SharedPrefrences、File、SQLite、ContentProvider、NetWork。我採用的是 SharedPrefrences 和 File便是文件存儲，其中

• 標記性數據採用 SharedPrefrences，例如是否隱藏操做記錄，用戶名稱等
• 帖子列表、評論列表類大批量數據採用了File文件存儲或sqlLite，緣由是操做方便，只須要序列化和反序列化操做就能很方便地讀出緩存並顯示，這裏要注意下你的bean類須要 imp 序列化接口。

4，網絡層

• 加載
       所有是本身基於 HttpUrlConnection 封裝的工具類。

• 邏輯

  • 廣播監聽網絡狀態的變化以作對應操做
  • 加載前進行網絡鏈接是否可達判斷
  • 斷網狀況啓用緩存

5，實現層

       帖子分享，我採用的 OneKeyShare SDK，之因此使用它，是由於它把絕大部分的平臺的SDK分享接口都集成了，例如微信、QQ、QQ空間、新浪微博、知乎等等等等。

   1) 註冊與登陸

• 註冊
  
  • 號碼
    
    • 對只能是數字的檢測
    • 手機號碼 11 位的限制
    • 是否以前註冊過的檢查，這塊要和服務器對接
  • 密碼
    
    • 位數的限制，例如最少 6 位
    • 加密傳輸
  • 短信驗證
    
    • 使用阿里大魚服務商，服務端寫好接口，移動端經過get或post手機號碼過去，而後接口調用API發送
    • 重複發送的倒計時

• 手機登陸

• 第三方登陸

  • 微信登陸
    使用的是微信開放平臺的 SDK，注意要先判斷用戶是否有安裝微信
  • 新浪微博登錄
    使用新浪開放平臺的 SDK，新浪SDK會自動判斷用戶是否有安裝新浪APP

   2) 發表帖子功能的實現

• 編輯

  • 文字部分

    • 字數的限制
      必定要限制用戶帖子的輸入字數的限制，一來減小服務器負擔，二來避免惡意刷帖。

    • 內容過濾
      要過濾掉某些敏感詞，防止色情或其餘內容出現

    • 用戶位置獲取
      使用百度地圖API
      

  • 圖片部分

    • 選擇
      
      • 張數的限制
      • 模仿了微信的圖片選擇器，採用GirdView加載，能夠多張一塊兒選擇
      • 拍照
    • 顯示
      
      • 命名採用：用戶賬號+帖子id+圖片下標，這樣的好處是，徹底可以惟一標識，且在看帖頁面加載方便，組合連接簡單。
      • 在發帖頁面顯示縮略圖，提供有點擊看大圖和移除的功能
        
    • 圖片服務器採用騰訊雲- - -萬象優圖
      1，具有縮放功能，方便生成、加載縮略圖
      2，能夠自定義添加水印
      3，鑑黃圖，這是最重要的！

  • 視頻錄製

    • 封裝系統的 Camera + surface 錄製，返回路徑
    • 預覽的時候直接用mediaPlayer + surface 播放

• 上傳

  • 注意大小，我是壓縮控制在450K左右
    
    • 好處：
      1， 加速上傳速度
      2， 加快用戶在加載圖片時的速度
      3， 減小流量消耗
  • 先上傳圖片，在圖片上傳成功後，再開始上傳文字內容，若是出錯，圖片能夠直接覆蓋，文字成功，圖片失敗時，帖子避免數據混亂
  • 採用線程池上傳，一來方便控制併發數，二來方便回收內存

   3) 帖子列表的顯示

• 控件選取

       選用了安卓5.0 的 SwipeRefreshLayout + RecyclerView，緣由是 SwipeRefreshLayout 自身帶有下拉刷新，最先的時候使用的是 PullToRefresh 開源項目。RecyclerView 重寫onScroll() 就能夠搞定加載更多，還有一個緣由，RecyclerView 自帶有瀑布流佈局屬性。
       早以前我使用的是 LinearLayout 實現的，不斷地 addView 再 remove，致命的缺點是內存消耗不合理。

• 加載限制
  
  • 數據加載採用分批加載的方式進行，減輕服務器的併發請求負擔和達到移動端的合理顯示效果。
  • 帖子主要內容的加載應該只加載摘要，不然內容過多，會形成數據處理時間過長，顯示慢。

   4) 帖子詳情頁的顯示

• 代碼結構

  • 因爲帖子的類型有三種，這三種帖子除了內容部分佈局不同，評論佈局是同樣的，分享、刪除等按鈕也是同樣的，固然，也能夠本身經過接口改變評論佈局。因此在類的集成方面，我採用了三個抽象類父類，子類只須要傳進入本身佈局、實現評論數據適配器 Adapter 便可。
    
    • 數據請求抽象類，含有請求方面的方法與屬性
    • 數據組合抽象類，含有獲取數據後進行組合的方法與屬性
    • 數據顯示抽象類，處理大部分的公共操做，例如評論列表的顯示，分享等功能按鈕，同時留有自定義佈局的接口

• 邏輯

  • 數據請求，根據點擊跳轉過來的帖子 id 來進行服務器數據請求。
  • 樓層評論
    
    • 判斷是否已登陸
    • 判斷內容是否有表情
    • 判斷是不是回覆，回覆就須要把被回覆者的名稱改顏色，而且添加點擊事件
    • 採用 post 上傳，由於採用get會有字節限制和中文亂碼的問題，還一個是數據安全
    • 評論成功後再作應的UI更新，防止失敗頁面顯示錯亂
  • 點贊
    
    • 判斷是否已經登陸
    • 判斷以前是否點過贊，不然就是撤銷贊，這個操做須要在加載點贊帳號的時候，保存到一個列表裏面，例如 List 以做後續的判斷。
    • 點同意功後再作對應的UI更新，例如點贊圖標變顏色等等

• 佈局

       採用的佈局是 HeaderView + CommentView，HeaderView 用於顯示帖子的全部內容含帖子點贊，CommentView 用來顯示用戶的評論

• 加載順序
  1，請求服務器數據，判斷該帖子是否有被刪除
  2，沒被刪除，那麼先加載帖子的內容
  3，最後再加載帖子的評論

   5) 消息提醒

       消息提醒採用了極光推送的SDK實現

• 以用戶帳號註冊推送
• 在服務端評論、點讚的接口代碼處觸發推送API
• 經過廣播的形式獲取推送，顯示消息提醒

   6) 表情模塊

• 匹配
  
  • 以圖片的名字組合其餘標記符組合爲 key，例如 [ ]，資源id爲value，放至常量區
  • 以正則匹配 key 的方式來判斷是否有表情輸入
• 顯示
  
  • 使用Spannable來將文字替換成drawable
  • 選擇頁面的顯示採用 GirdView + viewPager 顯示

   7) 其餘部分

       收藏、刪除、舉報，這些操做進行一次get操做，傳遞帖子的id給服務器，服務器處理完畢後，就作對應操做

• 收藏，不能重複收藏，服務器作判斷，返回信息
• 刪除，只能是帖主操做，刪除成功後，返回主頁刷新頁面數據

       其餘功能能的實現基本同上述。

   8) 優化

• 安裝包
  
  • .so 動態庫的添加，如今絕大部分手機已經支持 armeabi cpu 架構，因此只須要編譯這種進去就夠了，不是越多越好，越多，安裝包會跟着變大！
  • 減小沒必要要的庫引用
• 內存
• 參照我以前的博文 內存優化

 

   9) 使用的庫

　第三方

• PhotoView
• DickLruCache
• ImageLoader
• MultiImageSelector

　本身派生

• lghLoopViewPager
  
• SlowlyProgressBar
• ListGirdView

 

3、服務端架構概述

 

       第二部分結束得有點匆忙，我真的很想把全部的東西都寫下來，若是加上我一路遇到過的 bug 及其解決方法，估計還要寫兩天。主要緣由是，有不少我記得已經不是太清楚了。

 

1，服務器

• 集羣 
  • 阿里雲 Linux centos 6.5 操做系統，以ngnix 解析
  • 騰訊雲- - - 萬象優圖，只用來存放圖片
• MySQL 數據庫，MyISAM 與 InnoDB 引擎
• php 語言開發接口

2，數據庫引擎

       最初的我並無採用 InnoDB，而是全部表都是所有是 MyISAM 。改用的緣由是MyISAM 不支持事務InnoDB支持事務，並且社交類APP的數據庫操做過多偏向於insert、update、delete 這種操做若是涉及多表或單表互聯操做的狀況，爲了不數據寫髒，因此使用事務。由於整個過程當中若一條錯誤，即可以回滾到開始時的狀態。

• MyISAM 的查詢速度比InnoDB快
• 查詢高發的表採用 MyISAM 引擎
• 數據比較重要或多寫操做的表採用InnoDB引擎

3，數據庫設計

       對於數據庫設計，不該該過多依賴範式，適度的冗餘能夠加快搜索速度，在服務器的配置還能夠的狀況下，能夠採用冗餘來解決查找慢的問題。

       常被 update 的字段，不該該出如今多張表，應該使用一張表，例如用戶的名稱，userName 這個確定是會被常常改變的。不然在update數據的時候你要多張表更新！

• 帖子有三種類型，對應三張表，文章獨立一張表
• 點贊一張表
• 評論一張表
• 收藏一張表
• 信息提醒一張表
  
  • 用戶消息的查看與否以及數目在移動端的顯示，須要在消息表設置加上是否查看了的字段，能夠解決如下幾個問題：
    
    • 用戶在卸載APP再安裝時，不會形成查看混亂，例如以前看過的，又顯示出來
    • 在每次用戶進入APP的時候，能夠很好地顯示出新的消息，不會形成過於複雜的邏輯代碼判斷
• 用戶信息兩張表
  
  • 帳號信息一張，存帳號、密碼、註冊時間、ip等
  • 基本信息一張，存簽名、頭像連接、背景圖片連接等

4，接口

• 數據傳輸格式
  json array 或 字符串
• 訪問頻繁的數據
  架多一層 Redis，必定程度緩解高併發，須要服務器的內存支持，配置博能夠參照我以前的博文點我
• 代碼
  
  • 封裝一個自定義的 Redis 操做類
  • 封裝一個基於事務的數據庫鏈接類，方便使用
  • 封裝一個用戶信息類，專門用來處理用戶的信息插入與獲取

未完待續……