Overall
總的來說湃缎，2016年的綜合場（第一天上午）感覺講的一般，身邊的人吐槽也比較多蠢壹。不過相比之下嗓违，iOS場干貨就比較多了，演講者基本都是圈內(nèi)大V图贸，包括喵神蹂季，Sunny等等冕广。兩天停下來有兩個(gè)最大的感受，一是提到iOS大家很少提OC了偿洁，言必稱Swift佳窑，看來Swift趨勢勢不可擋；另一個(gè)是RN演講的比重很高父能，社區(qū)活躍度也很高神凑，看來也是時(shí)候要跟進(jìn)新技術(shù)了。
參加開發(fā)者大會一是開闊眼界何吝，二是來朝朝圣溉委，三是讓自己清楚的意識到自己跟臺上演講嘉賓的差距在哪里，回去該怎么學(xué)還怎么學(xué)去爱榕。瓣喊。。
VR的未來爆發(fā)
據(jù)估計(jì)黔酥，2020年會有20億的移動VR設(shè)備藻三，500萬的VR Game
京東的移動布局
京東的移動電商大數(shù)據(jù)價(jià)值觀：
- 洞察： 數(shù)據(jù)包容豐富的趨勢和變化
- 挖掘 ：分析和學(xué)習(xí)趨勢，洞察變化原因
- 決策 ：將數(shù)據(jù)智能賦給客戶與供應(yīng)商
- 開放 ：分享對數(shù)據(jù)的洞察與商機(jī)給第三方
京東的移動應(yīng)用覆蓋率已經(jīng)達(dá)到了80%
京東的大數(shù)據(jù)定價(jià)：
演講中跪者，京東顯然是通過大數(shù)據(jù)來進(jìn)行輔助定價(jià)棵帽，具體示意如下圖：
其中GMV指的是Gross Merchandise Volume，GMV=銷售額+取消訂單金額+拒收訂單金額+退貨訂單金額渣玲。GMV是流水逗概，只要你下了訂單，生成訂單號忘衍，就算了GMV
消費(fèi)者畫像
京東給了這么一個(gè)公式：精準(zhǔn)的用戶畫像+精準(zhǔn)的算法=成倍提高的效益
所謂精準(zhǔn)的用戶畫像逾苫，不是傳統(tǒng)的給用戶打靜態(tài)Tag的行為，而是根據(jù)用戶的購買行為建立起一個(gè)具體的枚钓，變化的铅搓，精準(zhǔn)的畫像。比如用戶買了母嬰用品搀捷，京東就有可能在半年之后給你推薦相應(yīng)段數(shù)的嬰兒奶粉星掰，試圖在最短的時(shí)間內(nèi)讓用戶買到最合適的商品。
React Native
跨平臺方案選型
- Hybrid方案：Cordova性能和用戶體驗(yàn)差
- Code轉(zhuǎn)換型方案：j2objc可移植性與可讀性都很差
- 編譯型方案： Xamarin指煎，C#解決方案蹋偏，社區(qū)活躍度差便斥，學(xué)習(xí)成本高
- 混合型方案：React Native至壤，社區(qū)活躍，RealTime Compiling
一種基于RN的程序架構(gòu)方法：
在傳統(tǒng)MVC之上枢纠，V層演化為React Native像街，這樣就擁有了UI上的跨平臺能力黎棠；C層為引擎，鏈接通過Configure來切換UI镰绎，以及通過RPC來切換Model以及對應(yīng)能力脓斩；M完全靠SDK來做動態(tài)變化。
React Native 熱部署平臺：
一款微軟出品的熱更新平臺：codePush
React Native JS導(dǎo)航欄目前的問題
- 隱藏導(dǎo)航欄時(shí)有閃動畴栖，體現(xiàn)在Push和Pop的時(shí)候
- iOS和安卓樣式不統(tǒng)一
- 動畫卡頓随静，由于在動畫過程中重新Render所致，通過延時(shí)或者InteractionManager解決
- Native打開的RN頁面中吗讶，通過Bridge返回Native
替代RN的Navigation的方案
- NavigationExperimental
- 動畫效果和使用方式接近于Native
Native APP + RN的優(yōu)化方案
- 所有功能放在一個(gè)Bundle中燎猛，使用統(tǒng)一導(dǎo)航；
- 啟動時(shí)創(chuàng)建一個(gè)RN Root照皆，加載Bundle重绷；
- RN中按功能添加路由；
- 點(diǎn)擊功能時(shí)路由相應(yīng)功能膜毁；
- 返回Native時(shí)如果路由為空清空緩存釋放內(nèi)存昭卓；
- 運(yùn)行期間內(nèi)存泄漏檢測可能會誤報(bào)，需要加白名單瘟滨；
- 功能越來越多時(shí)Bundle越來越大候醒；
RN下的開發(fā)人員組成參考
面向協(xié)議編程
產(chǎn)生原因：
- 面向?qū)ο蟛⒉荒芎芎玫姆磻?yīng)客觀世界
- Cross-Cutting Concern :（定義來自于Wikipedia）
In aspect-oriented software development, cross-cutting concerns are aspects of a program that affect other concerns. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering (code duplication), tangling (significant dependencies between systems), or both.
(簡單來說，Cross-Cutting Concern指的是一些由于設(shè)計(jì)和實(shí)現(xiàn)的問題導(dǎo)致的在功能分解時(shí)造成的代碼冗余及函數(shù)依賴)
針對以上問題杂瘸，傳統(tǒng)解決方法分為：
- Copy & Paste： 不推薦火焰，初級程序員的做法；
- BaseViewController： 不推薦胧沫，會將層級變的越來越多昌简；
- 依賴注入：一定程度上解決了這個(gè)問題，但是會增強(qiáng)了函數(shù)之間的耦合性绒怨；
- 多繼承：OC沒有此特性纯赎，而且容易造成二義性問題；
因此推薦使用面向協(xié)議來編程南蹂。對于協(xié)議犬金，需要注意的是：
- 協(xié)議定義
- 提供實(shí)現(xiàn)的入口
- 遵循協(xié)議的類型需要對其進(jìn)行實(shí)現(xiàn)
- 協(xié)議擴(kuò)展
- 為入口提供默認(rèn)實(shí)現(xiàn)
- 根據(jù)入口提供額外實(shí)現(xiàn)
為什么優(yōu)先考慮面向協(xié)議來編程：
高度協(xié)議化有助于解耦，測試以及擴(kuò)展
IM通信協(xié)議分享
排名前三的Socket協(xié)議分別為
- XMPP：協(xié)議開源六剥，可擴(kuò)展性強(qiáng)晚顷，有各種實(shí)現(xiàn)，接入方便疗疟；但是冗余多该默，耗費(fèi)流量
- MQTT：協(xié)議簡單，流量少策彤，訂閱+發(fā)送模式栓袖。比較適合于推送匣摘，并不是太適合IM
- WebSocket：Web原生支持，有很多第三方語言實(shí)現(xiàn)裹刮∫舭瘢可以適配XMPP，MQTT捧弃。
雙向Ping Pong機(jī)制
Server通過向Client直接發(fā)數(shù)據(jù)以及通過APNS來向Client發(fā)數(shù)據(jù)赠叼，來保證數(shù)據(jù)的到達(dá)率。
APNS的優(yōu)缺點(diǎn)
- 優(yōu)點(diǎn)：解決了iOS假在線等問題
- 缺點(diǎn)：
- 無法保證信息的及時(shí)性违霞。
- 無法保證信息的準(zhǔn)確性梅割。
- 服務(wù)端壓力太大。
因此APNS不適合需要及時(shí)響應(yīng)的應(yīng)用場景葛家。
Protobuff為最優(yōu)格式選擇
不論是序列化户辞，反序列化，字節(jié)大小來講癞谒，protobuf表現(xiàn)最好
移動端的性能調(diào)優(yōu)
- 優(yōu)化重連機(jī)制
- 精簡心跳包
- 減少心跳次數(shù)
- 重連冷卻（按照斐波切納數(shù)列進(jìn)行重連）在APP端進(jìn)行重連
選擇原因：
- 省流量
- 高效
- 省電
- 成熟可靠
- 易于使用
搜狗輸入法優(yōu)化實(shí)踐
鍵盤調(diào)起速度優(yōu)化步驟
- 懶加載底燎，也就是依賴加載；
- 盡量不阻塞主線程弹砚，不用解釋双仍；
- 盡量避免額外操作，不用解釋桌吃；
- 慎用AutoLayout
- autoLayout有簡單朱沃，易用，可讀性強(qiáng)的特點(diǎn)
- updateConstraint的調(diào)用時(shí)機(jī)會影響程序的性能
- 慎用NSDateFormatter茅诱，性能很差
- 慎用 [NSStrnig sizeWithAttributes:]此方法性能很差逗物，可以考慮通過估算每個(gè)字符寬度的方法來估算整體的String長度
所有應(yīng)用組件都應(yīng)該實(shí)現(xiàn)的方法（MemoryWarning）
- 普通應(yīng)用(UIApplicationDelegate)
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application - 鍵盤應(yīng)用(KeyboardViewController)
-(void)didReceiveMemoryWarning - 所有應(yīng)用都應(yīng)該實(shí)現(xiàn)，以在內(nèi)存告警的時(shí)候盡量釋放無用的變量保證程序的順利運(yùn)行
內(nèi)存優(yōu)化建議
- autorelease Pool要利用好
- 避免循環(huán)引用
- 讀圖方式要選擇好
- [UIImage imageNamed:@"xxx"] 圖片會緩存
- [UIImage imageWithContentOfFile:path] 圖片不會緩存
- 選擇正確的緩存策略
- 降低內(nèi)存占用峰值（自己估計(jì)瑟俭，盡量減少使用）
- 內(nèi)存文件的映射使用（解決大文件會刷爆內(nèi)存的問題）
- FastImageCache
- Path
- Mapped Memory
- Uncompressed Image Data
- Byte Alignment
測試
自動化測試推薦流程：
- 打包:ShenZhen
- 重簽名:ota-tools/ipa-sign:
unzip spa -> remove signature -> copy mobile provision -> code sign -> zip to new ipa
請保持環(huán)境為UTF-8 - 安裝
- Instruments
- 測試報(bào)告
自動化測試建議
- 自動化用例腳本不用太多翎卓，保證主流程即可
- 自動化用例也不用太長，防止鏈路過長而產(chǎn)生的問題
- 避免用例互相依賴
- 使用異步等待
- 避免執(zhí)行環(huán)境的差異
- 提高用例編寫水平
第三方內(nèi)存泄露檢測工具
- FBRetainCycleDetector
- FBAllocationTracker
- FBMemoryProfiler
安全
- Key不要直接存到客戶端
- 標(biāo)識用戶通過UIN來進(jìn)行摆寄，相對安全
- AFNetWorking要升級到3.0版本失暴，不然HTTPS也不安全
- AES中強(qiáng)烈建議使用AES_GCM
- 密碼如果一定要存的話，應(yīng)當(dāng)用Bcrypt／PBKDF2方式來進(jìn)行存儲
設(shè)計(jì)場
- 一項(xiàng)真正的設(shè)計(jì)必須有一種感覺上的漂移微饥，它必須能轉(zhuǎn)換情感逗扒，喚醒記憶，讓人尖叫欠橘，充滿反叛矩肩。讓我們感覺好像過著一種只屬于自己的生活，它必須是充滿詩意的简软。
- 設(shè)計(jì)的ATF原則：
- Art：藝術(shù)蛮拔，美學(xué)
- Tech：技術(shù)革新
- Fun：充滿樂趣
各種工具推薦
- 各種有用的越獄工具
- openSSH 是ssh的開源實(shí)現(xiàn)，一種保證遠(yuǎn)程登錄到系統(tǒng)的協(xié)議
- IPA Installer Console 通過命令行方式安裝痹升，卸載應(yīng)用
- Simulate Touch 模擬點(diǎn)擊建炫，滑動事件
- Simulate Key Events 模擬發(fā)送物理按鍵事件的插件
- iOS下Crash日志的收集
- Crash Reporter
- ITC
- Bugly
- Crashlytics
- 友盟等
- iOS下崩潰日志解析
- symboliticrash
- xcrun atos
- dwarfdump
- CLI工具：shenzhen
shenzhen - iOS 自動化測試工具：ui-auto-monkey iOS上的uitest工具
- 自動化測試平臺： appium
