Android开发峰会
滴滴国际化之路
地图选型考虑全面：功能与需求，数据源，技术支持力度，性能，用户，包大小，demo及文档
地图切换：有一套自己的抽象，再对具体实现一个adapter
项目演进：
按包名划分，仍存在大量耦合，添加新业务不便
分sdk和业务模块，作为独立的module，最后集合成一个apk
国内地图：谷歌地图
海外地图：Mapbox、Natiteq
Mapbox大小为5M，全开源，DEMO及文档完整，用法基本与谷歌地图一致
Natiteq大小为7M，全开源，DEMO及文档完整，用法不寻常
其他：漫游网络，运营商，AWS...
容器化到组件化
组件化：
特性：独立性、可替换性、互操作性
成本：解耦、契约、兼容性
收益：低耦合、模块独立、组件独立测试、集成灵活、组件独立升级、混合开发平滑过渡
基础解决方案：JAVA PackageName、Gradle module、mutiple app
从第一天开始坚持解耦，为中长期打好基础
Tinker实践之路
热补丁两大流派。
减小安装大小，对特定有问题的用户推送补丁包，获取调试信息。
技术是用来解决问题的：稳定性和兼容性，性能，易用性。
1.0小试牛刀
基于classloader的方案
preverify问题，内存地址错乱，性能差，补丁包大
2.0自创功法
dex diff
anr，dex太大，分平台合成dex，art上合成小dex。
illegal access。
性能好，兼容性和稳定性差
3.0修炼内功
异常、调试信息收集
4.0内外兼修
提升易用性和稳定性
方案选择，最重要的依据还是我们的需求，回到初心
开源地址：https://github.com/Tencent/tinker
Android性能优化
检测工具
启动速度：
Hierarchy Viewer
StrictMode
TraceView
Hugo
流畅度：
Android Studio
开发者选项
StrictMode
TraceView
Hugo
内存：
Android Studio
Leakcanary
功耗：
Android Studio
开发者选项
跨平台专场
从React到ReactNative
由NHN Techorus的Web前端部门经理带来的RN发展历程
Web优势：
一次编写，几乎可以在所有平台运行
搜索引擎可爬性
版本控制简单
可分享性
Web应用的问题：
页面的载入时间，离线体验
无法利用主屏幕图标，推送通知等功能增强应用画面外的
互动
受限于浏览器的实现，用户体验难以匹敌Native应用
–相机，音频，视频，后台，振动，剪贴板，应用内支付……
Android的老旧机种上的性能问题
发展:ReactDOM to ReactNative
•弃用DOM，置换HTML元素成ReactNative组件
–画面排版活用View, Text, Image, ScrollView组件
–表单元素活用TextInput, Slider, Switch, Picker组件
–注意弃用DOM的同时也意味着将不能使用面向浏览器的库（比
如jQuery）
•弃用CSS，转用Inline
Style属性
–利用ReactNative组件的style属性来指定样式
–活用JavaScript特性以及StyleSheet
API进行样式管理
•ReactNative提供了3种和服务器通信的手段
–Fetch API
–XMLHttpRequest API
–WebSocket API
通信层可以根据各自情况进行重构
美团点评ReactNative
为什么用RN
框架模式：
Native APP+RN功能：
JS包小，不到1M
可以使用热更新
使用现有的Native资源
使用在已有一定规模的APP，尝试性地添加小功能
RN APP+Native功能
不需要多少Native技术
JS包将越来越大
热更新要重新启动
使用在新的App中
使用场景
Native：view数量很多（大于1000），强交互效果
RN：view少
RN升级应对：
有选择的阶段性升级
尽早确定代码风格和规范，协调好开发节奏
完善CI流程、单元测试
尽量把平台差异性代码放到组件中处理（而不是业务代码中）
RN预估：
将来必会有一次大的API跳转
1.0版本将在4年后发布
代码美观：F8StyleSheet
Weex Native Architecture
Weex是阿里巴巴团队研发并开源的项目，也能够跟RN一样提供跨平台功能，但是由于其开源时间比RN迟，并且同样没解决RN所遇到的问题，所以活跃程度远不及RN。目前只有一个理由能支持它，就是支持国产。
