參加了2天的MDCC2016，趁着10.1有空，回顧一下。
2天的會議主要參加了2個專場，跨平臺開發專場和iOS開發峯會。
ppt地址
跨平臺開發專場
跨平臺主要關注了ReactNative和Weex。
Weex目前看來還是阿里內部在用，ReactNative屬於主流。
從RN的使用情況來看，都是在App中部分頁面使用RN。對於RN使用中遇到的問題，美團點評的演講介紹得比較詳細，主要還是性能相關的優化。
從React到ReactNative漸進強化應用體驗
主要講了從Web應用改造爲native應用的3種方式：
1. WebView嵌入(Hybrid)，通過WebViewBridge實現部分native增強
2. 將Web的ReactDOM改成ReactNative的組件，也就是現在的ReactNative的標準使用方式
3. 展望了一下ReactNative for Web的跨平臺。由ReactNative直接提供iOS/Android/Web三個端複用的能力 比較來看，還是第二種方案更成熟，性能也更好
Mobile可配置化的跨平臺實踐
沒有從客戶端角度講跨平臺。而是利用服務端可配置化的控制平臺，實現服務端快速上線和客戶端產品的快速更新展現。
驅動原生型移動應用的跨平臺實踐
普元因爲在Eclipse和組件化模型方面有很多積累，所以他們自己實現了一個類似ReactNative的技術，稱爲驅動原生型移動應用。
同時配合他們的IDE，可以有很好的調試體驗。 但是因爲這是普元的商業產品，這個主題一半可以當做他們的產品宣傳。
Weex移動應用架構設計和實戰
這個主題是跨平臺開發專場中的亮點，開講之前就在現場微信羣裏倍受期待，這也是這次大會上首次現場show code的嘉賓。
鄭蔚(克爽)講了Weex的分層架構，Native和Javascript的交互模型以及組件的渲染過程。
從架構和原理上，Weex和ReactNative差別並不大。 所以聽衆問了2個問題，Weex的開始和將來。
Weex的產生是因爲原來淘寶的一套魔改Json加入腳本的方式難以維護，重構的時候正好Web技術比較成熟。實際Weex開始開發的時間比ReactNative還早，所以不存在有了ReactNative爲什麼還要造Weex的問題。
Weex的未來，首先會把接口層做得更薄，以後不只是可以用Vue.js來寫Weex，甚至React.js也可以作爲Weex的DSL。
同時有個不太好的消息是，淘寶在Weex的投入取決於淘寶自身業務的需要，所以Weex的未來還是看社區的推動情況。這個會讓選擇Weex變得很糾結，目前Weex的社區相對ReactNative還是相差太多。
美團點評 ReactNative 設計和實踐
這個主題基本就是美團使用ReactNative的一些乾貨了，各種遇到的坑。
美團使用RN的目標是提升開發效率，縮短髮布週期，解決版本不一致，資源不一致的問題。 然後張宇開始各種乾貨。
1. RN和native各自適用的場景 主要是性能相關的。 長列表(~1000條)，或者強交互的場景適合native，因爲RN會產生深層的嵌套，以及列表本身的性能有問題。
而對於一些View數量比較少的UI，詳情頁，和交互較少的UI適合RN實現。 RN的熱更新，美團採用了自己實現的一套。
2. 熱更新 美團採用自己實現的一套
3. Navigator 踩了各種坑(事件穿透，原生表現不一致等)之後，推薦NavigationExperimental
4. ios和android樣式自定義 用F8StyleSheet封裝Platform.OS===
5. ListView優化 主要是對沒有顯示的Cell的部分做一些優化，減少內存佔用
6. bundle加載速度 放到一個bundle裏面，內部路由
7. RN版本升級 升級需謹慎，api變化，採用階段性升級，不追求最新版 把平臺差異性代碼放到組件裏，業務代碼保持平臺獨立性
iOS開發峯會
iOS峯會彷彿Swift開發峯會，OC已經沒人講了。但是對於Swift，臺下問嘉賓，Swift3升級遇到問題怎麼辦，嘉賓說我們不升3，升2.3，哈哈哈。
Swift面向協議編程與Cocoa框架的邂逅
喵神講了一下Swift裏面新增加的協議擴展特性。 整個演講主要是講面向接口的設計方法。
Swift增加了協議擴展之後，能力已經跟多繼承沒有太大區別了。
展望 Isomorphic Swift
主持人都沒太明白Isomorphic Swift是什麼意思。 聽完大概就是前後端都用Swift來實現。
主要介紹幾個後端Swift框架，Kitura，Vapor，Perfect，Zewo。
從benchmark看，swift的性能表現比nodejs要好，僅次於go。
把玩編譯器，Clang有意思
這個主題有點難。 孫源科普了一下llvm，clang的概念。 同時演示了一下clang與xcode結合使用的三種方式，實現code
lint，以及利用AST做一些hack的事情。
IM 即時通訊技術在多應用場景下的技術實現，以及性能調優
leancloud的陳宜龍詳細講了IM的協議選擇與性能優化，但是時間沒安排好，導致部分內容沒講完。
乾貨也很多，基本涉及了IM中常遇到的一些問題。
1. 連接問題 輪詢，長輪詢，長連接 從流量上看，當然Websocket的長連接花費更少
2. 通訊協議 XMPP，MQTT，私有協議 XMPP協議成熟，可利用的開源實現很多，但是耗流量，不是爲移動場景設計。 MQTT協議簡單，流量少，適合訂閱+推送模式。針對IM場景需要做很多擴展。適合打車，朋友圈狀態更新等場景。
私有協議是主流IM採用的方式，要求有設計良好協議的能力，對設計者要求高。
3. 假在線 雙向ping pong機制
4. 序列化 PB的序列化比json和xml更省流量和省電
5. DNS污染 ip直連，http DNS
6. 重連機制 精簡心跳包，減少心跳次數，重連冷卻
58同城App在React Native上的開發實踐-iOS視角
彭飛主要分享了58同城在使用RN上的一些經驗，有細節的，也有工程性的。
1. RCT_EXPORT_MODULE(js_name)，RCT_REMAP_METHOD 設置別名，解決android和iOS類名的問題
2. 覆蓋methodQueue,實現自定義queue
3. 載體頁初始化參數解耦處理
4. 單次回調用Callback，多次回調用EventListener
5. js端和native端的異常處理策略
6. 熱更新採用基於common的diff。相當於除了common之外的全量更新
搜狗輸入法性能優化實踐
因爲系統對輸入法佔用資源的限制，李騰傑的分享也是乾貨滿滿，從與android峯會的微信羣對比，iOS峯會一直保持了很高的質量。
搜狗主要分享了鍵盤調起速度和內存佔用的優化，可操作性很強。
1. 鍵盤調起速度 懶加載，不要阻塞主線程，避免額外操作，慎用autolayout，慎用NSDateFormatter，慎用[NSString sizeWithAttributes:]
2. 內存佔用 autoreleasepool使用，避免循環引用，讀圖方式優化，正確的緩存策略，降低內存峯值，內存文件映射，FastImageCache
Deep in iOS Testing
這個主題沒聽完整，主要講了一下iOS的自動化測試，monkey，以及中間會用到的一些工具。
最後有個Q&A，問xcode8裏面對UIAutomation的支持去掉了，自動化怎麼做，回答是不升級xcode8.跟不升級swift3的回答同樣簡單粗暴，哈哈。
安全那點事兒
本來想聽點黑客的事情，但那是不可能在大會上講的。
微信的馬鬆鬆首先科普了一下信息安全的演進，從原始社會一直講到薩德導彈，中間各種圖片梗好像聽衆都沒接上，嘉賓估計很無奈，講安全不能講太細，簡單的梗也沒人懂，只能順便黑一下csdn。
結論是安全的最大問題在於人的意識問題，對於開發者：安全能力是每一位開發者的基本能力，沒有“銀彈”!架構上最關健的一點是層層設防。
然後舉了幾個通常我們認爲的防禦，普通開發者認爲的安全在安全人員眼裏都是很容易攻擊的，甚至安全人員認爲的安全也不一定是安全的，沒有絕對的安全，最好代碼有專業的安全人員審計。
不過問嘉賓怎麼在客戶端存密碼的時候，keychain依然是優先安全的方案。
聽完感覺開發者首先要更新自己的一些知識庫，特別是有些傳統加密算法因爲發現有漏洞，已經被一些安全性更高的算法替代了，然後要有一些安全的常識，因爲安全上有些問題如果你不知道，那就真的不知道。