《2016中国移动开发者大会》参会笔记

Overall

总的来说,2016年的综合场(第一天上午)感觉讲的一般,身边的人吐槽也比较多。不过相比之下,iOS场干货就比较多了,演讲者基本都是圈内大V,包括喵神,Sunny等等。两天停下来有两个最大的感受,一是提到iOS大家很少提OC了,言必称Swift,看来Swift趋势势不可挡;另一个是RN演讲的比重很高,社区活跃度也很高,看来也是时候要跟进新技术了。
参加开发者大会一是开阔眼界,二是来朝朝圣,三是让自己清楚的意识到自己跟台上演讲嘉宾的差距在哪里,回去该怎么学还怎么学去。。。

VR的未来爆发

据估计,2020年会有20亿的移动VR设备,500万的VR Game

京东的移动布局

京东的移动电商大数据价值观:
  • 洞察: 数据包容丰富的趋势和变化
  • 挖掘 :分析和学习趋势,洞察变化原因
  • 决策 :将数据智能赋给客户与供应商
  • 开放 :分享对数据的洞察与商机给第三方
京东的移动应用覆盖率已经达到了80%
京东的大数据定价:

演讲中,京东显然是通过大数据来进行辅助定价,具体示意如下图:


大数据定价

其中GMV指的是Gross Merchandise Volume,GMV=销售额+取消订单金额+拒收订单金额+退货订单金额。GMV是流水,只要你下了订单,生成订单号,就算了GMV

消费者画像

京东给了这么一个公式:精准的用户画像+精准的算法=成倍提高的效益
所谓精准的用户画像,不是传统的给用户打静态Tag的行为,而是根据用户的购买行为建立起一个具体的,变化的,精准的画像。比如用户买了母婴用品,京东就有可能在半年之后给你推荐相应段数的婴儿奶粉,试图在最短的时间内让用户买到最合适的商品。

React Native

跨平台方案选型
  • Hybrid方案:Cordova性能和用户体验差
  • Code转换型方案:j2objc可移植性与可读性都很差
  • 编译型方案: Xamarin,C#解决方案,社区活跃度差,学习成本高
  • 混合型方案:React Native,社区活跃,RealTime Compiling
一种基于RN的程序架构方法:
一种基于RN的程序架构方法

在传统MVC之上,V层演化为React Native,这样就拥有了UI上的跨平台能力;C层为引擎,链接通过Configure来切换UI,以及通过RPC来切换Model以及对应能力;M完全靠SDK来做动态变化。

React Native 热部署平台:

一款微软出品的热更新平台:codePush

React Native JS导航栏目前的问题
  • 隐藏导航栏时有闪动,体现在Push和Pop的时候
  • iOS和安卓样式不统一
  • 动画卡顿,由于在动画过程中重新Render所致,通过延时或者InteractionManager解决
  • Native打开的RN页面中,通过Bridge返回Native
替代RN的Navigation的方案
Native APP + RN的优化方案
优化方案的架构
  • 所有功能放在一个Bundle中,使用统一导航;
  • 启动时创建一个RN Root,加载Bundle;
  • RN中按功能添加路由;
  • 点击功能时路由相应功能;
  • 返回Native时如果路由为空清空缓存释放内存;
  • 运行期间内存泄漏检测可能会误报,需要加白名单;
  • 功能越来越多时Bundle越来越大;
RN下的开发人员组成参考
开发人员组成参考

面向协议编程

产生原因:
  • 面向对象并不能很好的反应客观世界
  • 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指的是一些由于设计和实现的问题导致的在功能分解时造成的代码冗余及函数依赖)

针对以上问题,传统解决方法分为:

  • Copy & Paste: 不推荐,初级程序员的做法;
  • BaseViewController: 不推荐,会将层级变的越来越多;
  • 依赖注入:一定程度上解决了这个问题,但是会增强了函数之间的耦合性;
  • 多继承:OC没有此特性,而且容易造成二义性问题;

因此推荐使用面向协议来编程。对于协议,需要注意的是:

  • 协议定义
  • 提供实现的入口
  • 遵循协议的类型需要对其进行实现
  • 协议扩展
  • 为入口提供默认实现
  • 根据入口提供额外实现

为什么优先考虑面向协议来编程:
高度协议化有助于解耦,测试以及扩展

IM通信协议分享

排名前三的Socket协议分别为
  • XMPP:协议开源,可扩展性强,有各种实现,接入方便;但是冗余多,耗费流量
  • MQTT:协议简单,流量少,订阅+发送模式。比较适合于推送,并不是太适合IM
  • WebSocket:Web原生支持,有很多第三方语言实现。可以适配XMPP,MQTT。
双向Ping Pong机制

Server通过向Client直接发数据以及通过APNS来向Client发数据,来保证数据的到达率

双向PingPong机制
APNS的优缺点
  • 优点:解决了iOS假在线等问题
  • 缺点:
  • 无法保证信息的及时性。
  • 无法保证信息的准确性。
  • 服务端压力太大。

因此APNS不适合需要及时响应的应用场景。

Protobuff为最优格式选择

不论是序列化,反序列化,字节大小来讲,protobuf表现最好


字节长度比较
移动端的性能调优
  • 优化重连机制
  • 精简心跳包
  • 减少心跳次数
  • 重连冷却(按照斐波切纳数列进行重连)在APP端进行重连

选择原因:

  • 省流量
  • 高效
  • 省电
  • 成熟可靠
  • 易于使用

搜狗输入法优化实践

键盘调起速度优化步骤
  • 懒加载,也就是依赖加载;
  • 尽量不阻塞主线程,不用解释;
  • 尽量避免额外操作,不用解释;
  • 慎用AutoLayout
  • autoLayout有简单,易用,可读性强的特点
  • updateConstraint的调用时机会影响程序的性能
  • 慎用NSDateFormatter,性能很差
  • 慎用 [NSStrnig sizeWithAttributes:]此方法性能很差,可以考虑通过估算每个字符宽度的方法来估算整体的String长度
所有应用组件都应该实现的方法(MemoryWarning)
  • 普通应用(UIApplicationDelegate)
    - (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
  • 键盘应用(KeyboardViewController)
    -(void)didReceiveMemoryWarning
  • 所有应用都应该实现,以在内存告警的时候尽量释放无用的变量保证程序的顺利运行
内存优化建议
  • autorelease Pool要利用好
  • 避免循环引用
  • 读图方式要选择好
  • [UIImage imageNamed:@"xxx"] 图片会缓存
  • [UIImage imageWithContentOfFile:path] 图片不会缓存
  • 选择正确的缓存策略
  • 降低内存占用峰值(自己估计,尽量减少使用)
  • 内存文件的映射使用(解决大文件会刷爆内存的问题)
  • 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
    请保持环境为UTF-8
  • 安装
  • Instruments
  • 测试报告
自动化测试建议
  • 自动化用例脚本不用太多,保证主流程即可
  • 自动化用例也不用太长,防止链路过长而产生的问题
  • 避免用例互相依赖
  • 使用异步等待
  • 避免执行环境的差异
  • 提高用例编写水平
第三方内存泄露检测工具
  • FBRetainCycleDetector
  • FBAllocationTracker
  • FBMemoryProfiler

安全

  • Key不要直接存到客户端
  • 标识用户通过UIN来进行,相对安全
  • AFNetWorking要升级到3.0版本,不然HTTPS也不安全
  • AES中强烈建议使用AES_GCM
  • 密码如果一定要存的话,应当用Bcrypt/PBKDF2方式来进行存储

设计场

  • 一项真正的设计必须有一种感觉上的漂移,它必须能转换情感,唤醒记忆,让人尖叫,充满反叛。让我们感觉好像过着一种只属于自己的生活,它必须是充满诗意的。
  • 设计的ATF原则:
  • Art:艺术,美学
  • Tech:技术革新
  • Fun:充满乐趣

各种工具推荐

  • 各种有用的越狱工具
  • openSSH 是ssh的开源实现,一种保证远程登录到系统的协议
  • IPA Installer Console 通过命令行方式安装,卸载应用
  • Simulate Touch 模拟点击,滑动事件
  • Simulate Key Events 模拟发送物理按键事件的插件
  • iOS下Crash日志的收集
  • Crash Reporter
  • ITC
  • Bugly
  • Crashlytics
  • 友盟等
  • iOS下崩溃日志解析
  • symboliticrash
  • xcrun atos
  • dwarfdump
  • CLI工具:shenzhen
    shenzhen
  • iOS 自动化测试工具:ui-auto-monkey iOS上的uitest工具
  • 自动化测试平台: appium
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342

推荐阅读更多精彩内容