工做隨筆

工做日誌  時間：兩週內完成

 

1，即時通訊 （接入環信）

2，推送 （個推、極光）

3，頁面緩存 和  混合開發框架的集成 

4，將1，2，3 集成到一個demo 裏 

 

 

第一天     3-14

 

目標： 瞭解  環信 、 極光 、混合開發框架  

 

環信： 支持離線推送  單聊  羣聊  實時音視頻 

 

基礎訂價方案： 1個 2個 坐席 免費 

             3個坐席  4500/年 

             4個坐席  6000/年 

       註冊後一個月內 不限坐席，不限功能 免費       

 

極光： 推送  IM 聊天  

 

基礎訂價方案：     免費用戶        VIP用戶  

  共享          獨享

    API開放部分      API所有開放 

   

推送消息/通知

推送歷史

推送API

最大併發數 高峯期有資源瓶頸 無限制 

推送速度 二十萬條/秒（共享） 二十萬條/秒（獨享）

推送條數 無限制 無限制

按標籤推送

用戶分羣推送

富媒體（預加載）

專享高速推送通道

子帳號管理

更多Push API調用次數

離線保存消息條數 5條 最高50條

數據統計與報表

推送數量

用戶打開次數

用戶使用時長

新增用戶

在線用戶

活躍用戶

消息送達統計API

Device API

在線設備查詢API

數據報表統計API

通知是否打開

技術支持

網站問答

郵件支持

VIP技術支持

解決方案諮詢

400電話支持

1對1在線支持

 

頁面緩存  混合開發框架 

 

http://www.cnblogs.com/wendingding/p/3950198.html

 

混合開發框架 

 

1，hybrid 框架 

 

Native 

js調用Native中的代碼

Schema：WebView攔截頁面跳轉

 

2，Cordova

 

3，PhoneGap

 

調查結果  通常用PhoneGap  

 

影響及注意點： 

 

沒法經過審覈的緣由

 

首先，蘋果不會由於App使用的用戶界面基於HTML而去拒絕一個應用。實際上，許多蘋果本身的App或者廣告平臺都基於HTML、CSS和JavaScript，好比Apple Store裏的iAd廣告平臺就是其中一個。除了蘋果本身的應用外，還有LinkedIn，Wikipedia等等。固然，當中不是全部App都用PhoneGap，但其用戶界面都基於HTML，因此就排除HTML爲罪魁禍首這一說。

 

1）蘋果會拒絕沒有以下特徵的應用：

 

能給用戶帶來應用體驗而非網頁體驗；

在iOS生態系統中，使用起來輕鬆自如；

能與移動端Web體驗區分開。

這幾條對全部應用都適用，並不只僅是UI基於HTML開發的應用，若是不知道蘋果的具體審覈標準是什麼，記住一點就能夠，全部標準都和用戶體驗有關。在蘋果的「iOS User Interface Guidelines」（iOS UI設計說明）中就有大量關於哪些能經過哪些沒法經過的詳細信息，在UI guidelines中，蘋果尤爲強調「基於Web的設計」這個部分：

 

若是應用是基於Web的設計，建議三思而行

若是基於Web，建議你確保App帶給用戶的是iOS應用體驗，而不是Web體驗。記住，用戶能夠經過Safari訪問你的網站。

 

 

圖片來源：lukor

 

在利用HTML及與之相關的技術開發應用時，必定要仔細閱讀完整的「iOS User Interface Guidelines」。除了iOS User Interface Guidelines，蘋果的「App Store Review Guidelines」對於如何經過App審查也有相關說明，當中就有許多有關基於HTML開發的App可能被拒絕的狀況，值得注意的是以下幾條：

 

2.12：不是特別有用的，獨特的應用，只是簡單與網站捆綁後做爲App的應用，沒法提供持續娛樂價值的應用可能會被拒絕。

10.3：沒有正確使用系統所提供的選項（如按鈕，圖標）的應用以及與Apple iOS Human Interface Guidelines的規定描述不符的應用可能會被拒絕。

12.3：只是簡單的web剪接，內容聚合或者連接蒐集，這類應用可能會被拒絕。

2）出現這些跡象，應用也有可能被拒絕

 

若是你的應用只是PhoneGap包裝下的網站，可能被拒絕。固然也有例外，但千萬不要抱僥倖心理。

若是你的應用須要用戶縮放頁面才能查閱內容，就有可能被拒絕。應用要有應用的感受，要給人直觀性，不要讓用戶去找功能，不要讓用戶返回上一個導航去尋找有用的東西。

若是應用看上去就像加了超連接的文版，沒有本地化風格，也會被拒絕。

注意你應用的反應時間，這些時間與用戶操做處理時間以及與對服務器的反應時間都相關，蘋果不喜歡慢的應用或者沒有反應的App。一樣，若是用戶按了某個按鈕，結果等了好幾秒鐘纔有反應，也有可能被拒絕。

蘋果的判斷界限不少時候很模糊，尤爲是對那些已經通過評估的獨立開發者開發的應用更是如此。他們對每一個應用都會進行優勢，功能，用戶體驗評估。另外iOS User Interface Guidelines以及App Store Review Guidelines是動態文件，可能會隨操做系統的變化而變化，或根據新的應用設計帶來的新問題而改變，因此要記住按期閱讀這些文件。

 

被拒絕了該怎麼作？

 

前面提到PhoneGap有這麼多功能，但它沒法使你免於應用審覈。因爲PhoneGap的用戶界面是基於web技術，不太可能當即被接受。在開發過程當中，設計師或開發者必定要注意，UI/UX設計必定要與操做平臺或生態系統的要求相符。當你在設計或開發一個PhoneGap應用的時候，要思考的是如何讓應用看上去更加本地化，如何更有移動應用的感受而不是網頁感受，核心問題就是「用戶體驗」是否好。

 

1）作應用的時候，要思考下面幾個問題：

 

應用的UI界面範例與平臺相符嗎？

應用給人的視覺效果如何？

應用看上去像一個網頁嗎？界面有利於觸屏操做嗎？

下面以Fresh Food Finder（App Store裏的PhoneGap應用）爲例，咱們將檢驗兩個視覺效果。下面兩張圖是同一個應用，均由PhoneGap模擬器捕捉。

 

 

 

圖片來源：Adobe

 

左圖有HTML內容但沒有CSS風格，若是比較視覺效果，左邊界面看起來就像網頁，而右邊的看上去則很是有應用的感受，頂部有導航元素，經過右邊箭頭還能繼續查看下一級內容，每一條都有UI元素，促使用戶繼續瀏覽內容。

 

 

 

圖片來源：Adobe

 

看上圖，有什麼問題呢？

 

首先，上圖是一個通過包裝的網站，蘋果討厭的就是把網站用本地化的外殼假裝起來，這個外殼是空的，沒有任何邏輯可言，若是掉線，假裝就會失敗，與移動端的Web體驗沒什麼差異，也沒有增長任何價值。

 

其二，用戶界面沒有優化移動體驗，用戶須要縮放等操做來閱讀內容，而且，導航不只與內容沒有明確的區分開，也不利於觸屏操做。開發應用的時候，要讓用戶操做起來有熟悉的感受，固然，你無須模仿每一個本地應用的UI風格，但用戶互動範例應該類似，UI要夠直觀，清爽。想要理解什麼叫「有App感受的應用」，就多看看其它公諸於衆的應用或者已經經過蘋果審覈的設計。

 

如今國外有許多比較應用UI的網站，進去看看對UI設計會有很大幫助。例如：

 

Mobile partners

Inspired UI

Pttrns

許多工具及框架都能幫助你將HTML體驗打造得更加本地化，點擊連接可進入下載。例如：

 

Twitter Bootstrap

iUI

jQuery Mobile

Sencha Touch

Kendo UI

app-UI

Zurb Foundation

Moobile

Chocolate Chip UI

Dojo Toolkit

jqMobi

 

 

圖片來源：Mobile-Patterns

 

2）交互性與性能注意事項

 

（1）優化視覺脫節環節：若是用戶必須經過HTML連接來下載一個單獨的頁面，會帶來視覺上的脫節，在這個環節須要進行優化。蘋果貌似更青睞那些給人感受比較統一的應用，能爲用戶帶來無縫體驗的應用。在異步下載數據或者動態更新內容的時候能夠採用單頁面架構，總的來講就是要讓頁面之間的銜接更快更不容易讓人察覺。

 

（2）優化數據獲取過程：你還須要在應用內及應用外優化數據獲取過程。數據交換儘可能最小化，只有在須要的時候才傳輸數據，最好採用輕量級數據交換格式，這樣就會緩解數據傳輸延遲現象，讓你的應用變得更快。

 

（3）應用內操做過渡要連貫：尤爲要注意這條，若是你的應用出現閃爍，不連貫的狀況，那你就須要從新訪問應用，試試本身是如何在屏幕上移動應用內的按鈕或者設置的。去查找一些技術，讓GPU爲只是使用CSS的HTML DOM元素服務，許多狀況下，這些技術能改變整個應用性能。

 

（4）進度條與旋轉指針：另外在處理一些須要時間的事情時，好比與服務器交換數據，能夠增長一些簡單標誌，好比進度條或者旋轉指針，可讓你的應用感受更快更加本地化。

 

總的來說，注意你的用戶體驗設計，蘋果的審覈程序也並不是一成不變的，還得看你是什麼應用。千萬不要認爲用了PhoneGap跨平臺開發工具就能免除審覈這一步。蘋果至關注重應用的品質及用戶體驗，若是表現很差，出現漏洞，或者審美達不到他們標準，也會被拒絕，蘋果對本身的生態系統要求比較高，但記住一點，越注重用戶體驗，經過的概率就越高。

 

 

 

http://www.csdn.net/article/2012-11-04/2811382-phonegap-rejection-apple

 

 

問題： 

  蘋果的根證書  2016-2-14 更新了  須要更新  不然 開發者證書  無效  

 

 

 

 

 

 

次日 3-15

 

目標： 集成極光推送  瞭解環信  

 

問題：  0/0  消息發不出去 

 

緣由： 開發者證書的問題？ 接收不到消息 

 

解決： 仍是證書的問題 

 

作了 本地通知 測試 可用  第三方的問題  須要解決  

 

瞭解環信 

 

 

問題待解決：  極光推送  和  環信 都須要開發者證書和推送證書  須要儘快解決  可是能夠先作着

 

問題待解決:  極光推送 的  開發者證書的問題   開發證書  和 生產證書  

 

 

3-16 

證書配置完成  開發環境（調試模式）須要聯機 

            生產模式 裝好應用 便可離線推送 （後臺發送，手機有網）

 

今日計劃： 環信的集成開發  

 

1，仍須要配置推送證書 

2，按照開發文檔 一步一步集成 

 

Bundle Identtifier 是統一的 

推送證書  能夠是  一個 

 

 

問題：

可是 作app 的Bundle Identtifier 只有一個  再造環境須要 從新申請 

 

 

環信裏  嵌套 極光推送 失敗 Bundle Identtifier 不可用 

 

措施：  反向嵌套   及  先極光推送  後封裝環信 

 

 

 

3-17  

 

選擇環信  2.2.0  版本  從新集成  

緣由：3.1.0最新版 集成文檔沒有推出 一直報錯 

 

決定集成2.2.0 版本  

 

將第三方調用 

 

功能： 註冊

      登陸

      自動登陸

      自動鏈接

      

 

第三方實現的思想： 

    使用環信的思想

    全部的網絡請求 [EaseMob sharedInstance].chatManager "聊天管理器"

    結果（自動登陸、自動鏈接）- 經過代理來回調

    調用chatManager 「聊天管理器」的 

【- (void)addDelegate:(id<EMChatManagerDelegate>)delegate delegateQueue:(dispatch_queue_t)queue;】

 

     [[EaseMob sharedInstance].chatManager addDelegate:self delegateQueue:nil];

 

下午：

功能： 添加好友

      自動獲取好友列表 

      好友贊成後刷新通信錄

      接收好友的請求

      刪除好友

      監聽被好友刪除

      退出登陸 

 

 

 

 

 

 

 

 

自動登陸 方法的代理  調用： 所有調用  只要實現了這個方法 就調用 

 

環信要求代理 用過以後  dealloc 代理方法 

 

總結： 添加聊天管理器的代理時，在控制器被dealloc的時候是，應該移除代理

     添加好友的代理方法，最好放在Conversation的控制器實現 

即便沒有聯網 也有好友 說明 環信 將好友列表 保存到本地db數據庫

 

 

數據庫： SQlite

// 獲取好友列表數據

/* 注意

* 1.好友列表buddyList須要在自動登陸成功後纔有值

* 2.buddyList的數據是從 本地數據庫獲取

* 3.若是要從服務器獲取好友列表 調用chatManger下面的方法

【-(void *)asyncFetchBuddyListWithCompletion:onQueue:】;

* 4.若是當前有添加好友請求，環信的SDK內部會往數據庫的buddy表添加好友記錄

* 5.若是程序刪除或者用戶第一次登陸，buddyList表是沒記錄，

解決方案

1》要從服務器獲取好友列表記錄

2》用戶第一次登陸後，自動從服務器獲取好友列表

*/

 

 

3-18 

 

 

問題： 1，pch 文件 鏈接錯誤  

      2，點擊發送崩潰 ？ 

      3.點擊好友崩潰 

      4.語音發送不出 （發不出，收不到 未解決）

 

解決： 1，重置 建立後 重寫路徑

      2，沒有向通信錄控制器 傳遞一個 buddy的值  找不到好友屬性因此崩潰

      3，返回tableView 數據源方法時 崩潰  修改了indexPath.row 方法

      4，監聽點擊方法 調試 

 

環信的集成繼續 

 

功能 ：

上午： 

      聊天界面工具條排版

      聊天接收方的cell排版

      聊天發送方的cell的排版

      發送聊天信息

下午：

      加載本地聊天記錄 

      監聽消息回覆 

      調整輸入框

      發送語音

      播放語音

      

3-19

 

    推送demo  已完成

    集成環信demo 已完成 

 

    頁面緩存 和 混合開發框架  

 

#pragma mark  測試時衍生出來的問題  待解決

推送證書的時效性  和 bundle ID 的時效性  

 

Please verify that your device’s clock is properly set, and that your signing certificate is not expired. (0xE8008018).

The identity used to sign the executable is no longer valid.

 

請確認您的設備的時鐘設置正確，而且您的簽名證書未過時。（0xE8008018）。

用來簽署可執行的身份再也不有效。

 

 

 

頁面緩存機制：  能夠用第三方AFNnetworking 網絡處理框架  進行頁面緩存

NSURLConnection/AFN 緩存機制  

NSURLConnection  蘋果自帶的緩存機制 

 

 

 

NSURLCache * cache = [[NSURLCachealloc] initWithMemoryCapacity:5 * 1024 * 1024

diskCapacity:25 * 1024 * 1024

diskPath:nil];

[NSURLCachesetSharedURLCache:cache];

 

1. URL緩存基本概念

NSURLCache 提供了內存與磁盤的緩存機制。

任何經過NSURLConnection 加載的請求都會 NSURLCache 處理，由於 AFNetworking 使用了NSURLConnection ，因此也會被處理。

當完成數據的請求後，緩存的相應被保存在本地（沙盒目錄爲Library/Cache/<boundleId>目錄下，每個不一樣的請求會生成一個文件夾，保存的文件爲NSData文件。）當下一次一樣的請求時，直接從緩存中獲取便可。

所以網絡緩存減小了與服務器的負擔，並提升應用程序更好的體驗。

 

二 ：設置NSURLCache

1. 使用URL緩存首先要使NSURLCache進行初始化。URL 緩存默認大小爲Memory 4 * 1024 * 1024 btye Disk 20 * 1024 * 1024byts

2. 在首次使用URL換粗以前就初始化NSURLCache，這樣才能使用URL緩存，所以一般狀況下在application： didFinishLaunchingWithOptions--- 初始化，這樣這個程序全部的NSMutableRequest 都能使用URL緩存。固然，你也寫在本身網絡請求的 單例初始化裏

 

NSURLCache * cache = [[NSURLCachealloc] initWithMemoryCapacity:5 * 1024 * 1024

diskCapacity:25 * 1024 * 1024

diskPath:nil];

[NSURLCachesetSharedURLCache:cache];

 

三 ： 設置NSMutableURLRequest的requestsetCachePolicy即緩存策略

 

NSURLRequestUseProtocolCachePolicy= 0,默認緩存策略。具體工做：若是一個NSCachedURLResponse對於請求並不存在，數據將會從源端獲取。若是請求擁有一個緩存的響應，那麼URL加載系統會檢查這個響應來決定，若是它指定內容必須從新生效的話，將創建一個連向源端的鏈接來查看內容是否發生變化。假如內容沒有變化，那麼響應就從本地緩存返回數據。若是內容變化了，那麼數據將從源端獲取。

NSURLRequestReloadIgnoringLocalCacheData = 1,URL應該加載源端數據，不使用本地緩存數據

NSURLRequestReloadIgnoringLocalAndRemoteCacheData =4,本地緩存數據、代理和其餘中介都要忽視他們的緩存，直接加載源數據

NSURLRequestReloadIgnoringCacheData =NSURLRequestReloadIgnoringLocalCacheData, 兩個的設置相同

NSURLRequestReturnCacheDataElseLoad = 2,指定已存的緩存數據應該用來響應請求，無論它的生命時長和過時時間。若是在緩存中沒有已存數據來響應請求的話，數據從源端加載。

NSURLRequestReturnCacheDataDontLoad = 3,指定已存的緩存數據用來知足請求，無論生命時長和過時時間。若是在緩存中沒有已存數據來響應URL加載請求的話，不去嘗試從源段加載數據，此時認爲加載請求失敗。這個常量指定了一個相似於離線模式的行爲

NSURLRequestReloadRevalidatingCacheData = 5指定若是已存的緩存數據被提供它的源段確認爲有效則容許使用緩存數據響應請求，不然從源段加載數據。

只有響應http和https的請求會被緩存。ftp和文件協議當被緩存策略容許的時候嘗試接入源段。自定義的NSURLProtocol類可以保護緩存，若是它們被選擇使用的話。

 

示例：

NSMutableURLRequest * request =[NSMutableURLRequest requestWithURL:[NSURLURLWithString:@"http://www.sina.com"]];

[requestsetCachePolicy:NSURLRequestReturnCacheDataDontLoad];

 

 

四 ：URL緩存的使用

1  獲取緩存

 

NSCachedURLResponse * response =[cache cachedResponseForRequest:request];

 

if (response != nil) {

 

NSLog(@"有緩存");

[requestsetCachePolicy:NSURLRequestReturnCacheDataDontLoad];

 

}else{

NSLog(@"沒有緩存");

}

 

2. 得到緩存就能夠賦值更新UI了。

 

 

根據內存分析 

打開36M  打開網頁 內存 上升  64 

返回  還有 45

 

佔用內存分析  已經完成 

測試網絡關閉  頁面能夠打開  緩存完成 

 

頁面能夠緩存  緩存完成  

 

經過抓包技術  獲取 網頁數據  

 

 

3-21 星期一  晴 

本週任務 將三個Demo 合併到一款 demo裏 並使用第三方混合開發框架 

 

facebook/react-native 框架

 

Cordova 是驅動PhoneGap的核心引擎

提供了一組設備相關的API，經過這組API，移動應用可以以JavaScript訪問原生的設備功能，如攝像頭、麥克風等。

 

須要用終端安裝

 

國內的：

 

JSPatch框架  

 

apiclound 

 

Wex5 

 

風險

 

JSPatch讓腳本語言得到調用全部原生OC方法的能力，不像web前端把能力侷限在瀏覽器，使用上會有一些安全風險：

 

1.若在網絡傳輸過程當中下發明文JS，可能會被中間人篡改JS腳本，執行任意方法，盜取APP裏的相關信息。能夠對傳輸過程進行加密，或用直接使用https解決。

 

2.若下載完後的JS保存在本地沒有加密，在未越獄的機器上用戶也能夠手動替換或篡改腳本。這點危害沒有第一點大，由於操做者是手機擁有者，不存在APP內相關信息被盜用的風險。若要避免用戶修改代碼影響APP運行，能夠選擇簡單的加密存儲。

 

 

 

試用三種 框架 

React 的核心思想是： 封裝組件

 

各個組件維護本身的狀態和UI ，當狀態變動，自動從新渲染整個組件

 

react-native

 

解決:終端—> npm install react-native  Xcode  添加依賴Link Binary with Library —>Add Other —> node_modules__>react-native —> React—>Base—>RCTRootView.m

 

brew uninstall --force watchman

brew install --HEAD watchman

從新安裝watchman  試試

 

Node.js

 

 

Node.js was installed at

 

/usr/local/bin/node

 

npm was installed at

 

/usr/local/bin/npm

 

Make sure that /usr/local/bin is in your $PATH.

 

 

下載測試demo  開始使用 學習 

 

 

 

3-22  新建一個react-native 應用

 

緣由： 建立完成後  有安卓程序  沒有ios程序 

 

 

解決： 須要升級 node。js  最新版 

 

bad external relocation length 

 

解決：  不用命令行  官網下載最新 安裝覆蓋 

 

 

Node.js was installed at

 

/usr/local/bin/node

 

npm was installed at

 

/usr/local/bin/npm

 

Make sure that /usr/local/bin is in your $PATH.

 

 

 

下載測試 （OK）

建立測試  （OK）

 

cd 項目 

npm install 

 

 

運行後出現紅色屏幕 JSC profiler is not supported.

解決： 

 

$工程目錄/node_modules/react-deep-force-update/

1

目錄下面刪除

 

.babelrc

1

注意:該文件是隱藏文件，若是你已經運行工程，請先關閉 React Packager，不然無效。

 

 

在原生app中 添加RN  

 

 

將四個demo 結合起來  

 

 

3-23 

 

目標 將四個demo 集成

 

問題： RN 報錯  每次鏈接WiFi 地址都會變  8081端口服務器問題 

 

解決： 須要服務器（電腦） 一直打開 並確保聯網狀態下  

 

 

極光推送： bundle  ID  只能惟一  

可放在 最後集成 

 

RN報錯問題。。。 也須要最後集成  

 

RN  ： 一種用純RN 作app  須要用  js  

 

       另外一種 原生加RN  （須要保證RN後臺服務器 一直開着 並安裝配置環境）

 

 

RN  解決：

 

brew uninstall --force watchman

brew install --HEAD watchman

從新安裝watchman  試試

 

 

Connection to localhost port 8081 [tcp/sunproxyadmin] succeeded!

Port 8081 already in use, packager is either not running or not running correctly

Command /bin/sh failed with exit code 2  (待解決)

 

 

環信的prch文件地址 導入問題 

 

問題：

/Users/zhangyuanhai/Desktop/HYDemo/<command line>:3:10: '/Users/zhangyuanhai/Desktop/HYDemo/HYDemo/PrefixHeader.pch' file not found

 

clang: error: linker command failed with exit code 1 (use -v to see invocation)

 

 

$(SRCROOT)/HYDemo/PrefixHeader.pch

 

3-24

 

組合 

 

問題： 推送  RN   集成  

 

 

RN  須要有固定的IP 及 服務器 最後添加 （須要討論）

 

IP  天天WIFI連上會 變動IP 地址 問題 

 

 

完成進度： 

 

環信+緩存框架+視頻 

 

3-25

 

添加推送  完善App測試demo  

 

視頻添加評論（須要後臺接口）先作聊天測試評論 

 

RN 框架須要討論  

 

 

讓人慾哭無淚的bug 

 

libopencore-amrnb.a(wrapper.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

 

解決： 第三方環信的功能不支持 bitcode  Xcode裏找到  關掉寫成NO 

 

Port 8081 already in use,packager is either note running or not running correctly

command /bin/sh failed with exit code 2 

 

解決： 從新電腦了 清空配置  

 

1，終端—> npm install react-native 

2，npm install -g react-native

 

 

3-26

 

繼續完善功能  繼續添加混合開發框架 

 

換一種方式 使用 

pod  init  

 

修改 Podfile 文件 CocoaPods 

 

pod 'React', '0.13.0-rc'  

pod "React/RCTText"  

pod "React/RCTActionSheet"  

pod "React/RCTGeolocation"  

pod "React/RCTImage"  

pod "React/RCTLinkingIOS"  

pod "React/RCTNetwork"  

pod "React/RCTSettings"  

pod "React/RCTVibration"  

pod "React/RCTWebSocket" 

 

 

安裝 pod install 

 

安裝完成後 出錯二個錯誤  

 

Undefined symbols for architecture x86_64:

"_OBJC_CLASS_$_RCTRootView", referenced from:

objc-class-ref in ViewController.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

 

沒法解決的問題 （待解決）

 

換一種思路 安裝 

 

3-28 

 

index.ios.jsbundle  該怎麼用？ 裏面寫什麼？ 

 

作評論: 

 

     向系統的一個ID 發消息 

     每一個用戶都在向系統發 

     評論是相互可見的 

     用戶之間的互動回覆  須要@  

 

 

初步方案： 

 

     在用戶評論的 右側 cell  添加回復 

     點擊回覆 就作@操做  

 

 

文字便可 

可移植性

 

3-29  討論

 

頁面優化---

 

混合開發 

 

頁面緩存 

 

UI方案  

 

MVC MVVM  

 

依賴注入 

 

代碼優化 

 

視頻  

 

第三方集成  登陸 支付  

 

 

----具體作App  

 

 

3-30

 

今日目標：

 

    設計模式 深刻了解 

    

    頁面優化

  

    UI方案

 

考慮： 

    在原先的基礎上  添加內容 

    

    添加視頻？ 

 

    發表文章？ 

    

    聊天？

    

    羣組？

    

    直播？

 

 

初版的設計方案：

 

    先把微信端的內容作出來  而後添加新內容

    

    

3-31 

 

    測試兩套H5 和  OC的 交互 

 

    標題 文字  排版測試  

 

    關於視頻  能夠參考 土豆視頻app 的設計 

 

 

    有沒有app 判斷手機聯網狀態 發送推送的 ， 好比剛連上wifi的狀況下  會推送

 

 

4-1  設計模式 考慮 

 

    MVC  Model-View-Controller 

 

MVC是將Model, View和Controller分離，讓彼此的職責(responsibility)可以明確的分開，這樣不管是改M, V仍是C，均可以確保另外兩層可不用作任何修改，同時這樣的分層也能夠增強程式的可測試性(testability)，View和Model基本上是相關的，但它們並不會有直接的相依關係，而是由Controller去決定Model產生的資料，而後丟給View去作呈現，也就是說，Controller是Model和View之間的協調者(coordinator)，View和Model不能直接溝通，以確保責任的分離。而Controller能夠只是一個繫結Model和View的小類別，也能夠是大到包含Workflow, Enterprise Services或是作爲外部系統的Proxy Services等的邏輯系統，MVC各元件是能夠分離的組件，也能夠是分離的系統(固然要設計一些機制在相互溝通)。

 

MVVM，MVVM的架構同樣是M, V分離，但中間是以VM (ViewModel)來串接，這個ViewModel比較像是View的一個代理程式，它負責直接對Model作溝通，而View能夠透過一些機制(ex: Events, Two-way Databindings, ...)來和ViewModel溝通以取得資料或將資料拋給Model作存取等工做，ViewModel也能夠做爲和外部系統的代理程式，例如Web Service或是REST Service或是Enterprise Services等等，不過它和MVC不一樣的地方，就是ViewModel和View的黏合度比較高，由於View必需要透過ViewModel才能夠取得Model，而ViewModel又必需要處理來自View的通知訊息，因此雖然職責同樣分明，可是卻不像MVC那樣能夠擴展到整個系統元件都能用。若是MVVM要和MVP比較的話，MVVM會比MVP更靈活一點。

    

MVP，MVP同樣也是職責分明，且Model與View分離的架構，可是這個P (Presenter)和ViewModel就很相似，不過就如同Presenter (主持人)這個字所表明的意義，全部主控View呈現的工做，都是由Presenter來作，而View自己只是Presenter所要使用的舞臺而已，因此View原則上會相依於Presenter，可是爲了要作到關注點分離(SoC原則)，因此在View和Presenter間都會加入一個介面(ex: IView)，而後以IoC的方式將View注射到Presenter中，而Presenter就使用介面所定義的方法去操控，而View就透過介面所定義的方法去呈現介面便可。但也由於受限於介面，因此Presenter只能依介面定義的動做去迴應與處理，而不能再作更多的延伸功能，除非更改View的介面。

 

上面各個架構的討論，咱們能夠獲得如下的結果：

 

MVC 架構適合於大型系統，它能夠分層且能夠在實體層面切割爲不一樣的機器或服務，只要彼此間具備適當的通信協定便可。

MVVM 架構適合像XAML 這種與程式碼無關(code ignorance) 的使用者介面設計，只要View 中下特定的指令與ViewModel 串接，就能夠享有ViewModel 溝通的功能，而ViewModel 只需作一些特別的介面實做，便可平順的和View 溝通。

MVP 架構適合集中由程式碼決定View 動做的應用程式，而View 只須要實做特定的介面便可，不須要太複雜的工做，但Presenter 則可能會受限於View 介面的動做，而沒法作更進一步對View 的控制。

 

最後我想提的是，MVC的包容度比MVVM和MVP要來的高，在MVC的V層，能夠再進一步的包含MVVM或MVP的實做，而C層也可使用MVP (V是輸出的資料)來進一步切割資料的流動與輸出，M層則能夠相似MVVM的架構，當V (元件)有資料的異動時，VM便可自動偵測到並更新Model (資料庫)。固然，要用什麼樣的架構去設計，端看當時的系統環境與需求來決定，而不是隻想着要用同一種架構去作全部的系統。

 

MVC 依然是主流  MVC中也能夠用MVVM  也包含MVP  

 

 

 

版本更新迭代 

 

產品設計，功能需求 下載其餘電影類app 體驗 

        片刻、豆瓣、影評劇透、影評視頻合集、四款參考方案 

進行總結：

        功能問題 功能少 花樣少 留不住用戶 

        

        須要社交 社區 文藝 圈子

        

        不要加廣告條 網絡資源加載要快