2016MDCC移动开发者大会总结_研发会议总结

由于编译器排版的不同，导致文章难以阅读，欢迎阅读原文：

MDCC移动开发者大会总结原文

月22日，凌晨。托stormzhang张哥的洪福，有幸去参加2016MDCC移动开发者大会。在此特别感谢张哥，不然怎么可能有这样的机会去参加如此高逼格的会议啊。

因为路途遥远，要提前一天踏上旅程。

9月23日，上午全体大会。

分别由CSDN&极客帮创始人——蒋涛、微软亚洲研究院院长——刘振、京东技术副总裁——赵一鸿、图灵机器人CEO——俞志晨、360智能家居总裁、360车联网CEO——邓邱伟演讲，有幸见到各大科技公司的领军人物甚是激动。下面大体讲解一下他们各自的议题，不做深入讨论，主要还是要讨论Android开发峰会。

从移动时代走向 AIR 智能时代——蒋涛

未来十年产业将进入 AIR 时代，即人工智能、IoT、AR时代。A时代的标志是AlphaGo，深度学习已彻底改变了图像识别领域；I时代的标志是软银收购ARM，2015年人均芯片拥有量为2颗，十年后将达到人均100颗；R时代的标志是PokeMon Go，且VR头显的销售会逐年呈指数式增长。

智能应用的普及化——刘震

介绍在大数据的时代，分析已经成为商业成功的一个关键推动点。深厚的数学知识是人工智能的基础，海量的数据是建立良好模型的关键，然而这些构建分析所必需的条件却是大多数开发者所缺乏的。基于机器学习的人工智能和基于语境的人机交互已变为可能，刘震也结合微软认知服务的实际案例，从计算机视觉API、人脸识别API、情绪识别API、语言理解智能服务等方面多方位角度进行解读。
详情请访问：微软亚洲工程院院长刘震：智能应用的普及化

移动时代的大数据电商技术探索与实践——赵一鸿

移动端的普及提升了碎片化时间的利用率，在家电、母婴、体育、超市方面京东移动的渗透率已近80%。这一背景下，数据的价值体现在洞察、决策、挖掘、开放，利用大数据去设计买点成为了重点。用户画像如何从静态变为动态，实现变化，是大数据的基本特点。他以“智能卖场”的例子从应用层面展示了动态数据的价值，通过京东大脑对用户行为、商品属性等大数据的挖掘，产生用户及商品画像，完成推荐预测，实现个性化选品和排序，能够有效地提升点击率和订单转化率，同时缩短用户购买路径。演讲主要围绕以下三个方面探讨：移动互联网对电商企业的挑战，移动电商的发展潜力，以及移动时代电商大数据的价值。
详情请访问：京东集团技术副总裁赵一鸿：移动时代的大数据电商技术探索与实践

智能机器人开发关键技术——俞志晨

他把智能机器人定义为：外在硬件载体＋人工智能系统和应用。他指出机器人操作层、感知层、认知层分别对应人的四肢、五官和大脑的概念。今天，智能机器人产业硬件所需要的投入要大于软件，只有产生优秀的硬件载体软件才能有意义，这涉及到各位传感器和控制单元，但这一天屏正在慢慢开始平衡。

智能硬件设计及关键实现技术——邓邱伟

他认为现在智能硬件行业整体呈高速增长状态，2015年达到300%，巨头从各个链条进入布局；而产品现状仍处于初期，缺乏联通，资本快速进入押宝智能家居；人工智能应用实用性大幅提升；在服务上，线上渠道仍为主要购买途径，而第三方服务尚却未大规模介入产业链。
详情请访问：360智能家居总裁、360车联网CEO邓邱伟：智能硬件设计及关键实现技术
以上就是全体大会的大体内容了。

下午的技术专场说起来就有点遗憾了。

本人对新鲜事物比较好奇，尤其是好玩的东西，听起来比较高大上的东西。比如人工智能、深度学习。由于上午各位大佬们的演讲太过于精彩，让我对人工智能提起来很大的兴趣，有一种想要立马研究一下的冲动。所以就决定先放弃预先安排的去跨平台专场，而去人工智能与机器人专场听听。因为之前没有接触过人工智能，所以听起来简直比上高数课还难受，根本不知道说的什么，因为比较感兴趣所以想继续试着听下去。听了很久之后觉悟到还是去跨平台吧，那时候离下午专场的结束还有不到一个小时的时间。真是蛮遗憾的。

附上跨平台技术专场的PPT及Demo，大家自行研究。
1

MDCC 2016跨平台开发专场的演讲 PPT 以及 Demo

9月24日，终于到了拭目以待的Android开发峰会了，此次峰会可谓大神云集，往届肯定也是，不过我没有参加也没有关注，毕竟是才走入正途。

先附上一张议题和演讲嘉宾的表格：

有必要重点说明的是这次Android会场的主持人是秋百万（廖祜秋）前辈。 他在主持的同时也讲解了不少东西，实在佩服秋百万前辈

滴滴国际化Android端演进——吴更新

1.国家化技术上的特殊性

• 地图
  地图选型、地图切换。国内用户使用国外地图服务的限制。
• 网络
  网络的限制。由于大家众所周知的原因，国外的很多服务国内用户是不可用的，墙的原因导致漫游网络不可用， 所以 国际化面临的技术问题还是很多的。
• 运力来源
  运力的来源问题。需要与其他国家合作来提供司机，在国内只需要司机注册就可以使用，而在国外需要和其他国家的合作伙伴做接入。

2.地图（地图选型、地图切换）

• 地图选型
  考虑的方面很全面。主要在功能与需求，数据源，技术支持力度，性能，用户，包大小，demo和文档等方面。选取了Bing、Tomtom、Here、Nutiteq、Mapbox作为研究对象。综合分析来看Mapbox是最合适的。
  分析如下图：
  
  
  • 地图切换
    选型可能无法通用，随意切换。对地图切换来说，关键是要有一套自己的抽象，再对应具体的实现搞一个Adapter就行。
    好处：解耦、通用、学习成本低
    
    
    问题：Api规范、适配所有的Api、标尺（如：缩放尺度、经纬度）、未支持API
    解决方案：
    1.主要按照Google Map的API为标准来做标准的API、对用到Mapbox的API做完全的适配
    2.先对初始版本的API做完整的适配，后面再对其他版本做竞争
    3.要保持地图的缩放级别是保持不变的，以国际的标尺为准。
    4.debug 版本抛出异常 crash，release 版本打 log。

3.漫游网络

滴滴主要服务的是国内用户去国外的情况。地图服务器是 不在AWS上面的。所以主要有海外运营商、用户依然使用国内版本的app在海外漫游的情况。主要讨论用户在海外漫游的情况。
国内用户在国外漫游访问国外服务器慢。
漫游网络，运营商，aws……
用户在国外访问网络的简单流程：
先访问海外运营商，通过海外运营商访问国内运营商，再去访问web。由于墙的存在一般用户是访问不到网络的。

为了解决这个问题使用了通过国内运营商去访问公网，通过公网访问AWS上的服务器。这种访问方式是比较慢的。

为了解决访问慢的缺陷，做了网络优化。在去访问AWS的时候在中间加一个中转服务器来实现专线访问

对于客户端来说，访问专线网络时大概会有三步：
1.拉取中转服务器域名列表
2.对于漫游用户访问中转服务器
3.一定时机及推送更新域名列表
这样做速度大概会比之前快一倍。

4.项目演进

• 问题
  1.按照包名划分，仍会存在大量的耦合。
  2.由于不同国家业务不同的原因等，添加新业务不便。
  
  • 解决方案
    分SDK和业务模块，但都作为独立的Module，最后再整合成一个apk。
• 实现技术
  单项目依赖：按照SDK和业务模块拆分成单独的项目，单项目依赖单独的SDK。之后再整合到成一个SDK，聚合成整个的工程，再实现SDK分层。
  
  
  
  使用模块划分的原则：单一、开闭原则，依赖关系，拓展规范，避免重复依赖。
  好处：解耦，并行开发、测试，组件单独测试。
  
  

5.现场问答

问题：Integrated Project怎么个打包法？Lyft、GradTaxi这些合并吗？还是它们会被打包成独立的apk？
回答：所有的module都是输出aar，最后一个整合成滴滴app
我讲解的可能是比较乱，同时可能也不怎么清晰，因为我自身理解的也是不怎么深刻。Piasy的视频连接：滴滴国际化 Android 端演进（包括冯老师分享的开头） 有时间可以自行观看。

回归初心，从容器化到组件化——冯森林

近年来插件化，module化的原因，已经不再像过去那样，庞大的软件，改一行代码，测试，耗费开发人员较长时间（虽然我没有亲身体验过以前开发的难度，但是可想而知）。组件化作为独立模块，协同开发时，可以提供release版本进行集成。平时，只须在自己的dev分支上进行开发。大大提高开发效率。各模块之间解耦，当然这其中也面临相关的问题，如大量的反射方式。各rom厂商对系统的改动，就很容易产生各种问题。何俊林在会上请教了apk与apk数据之间如何共享的问题。冯老师建议可用contentprovider。建议在项目的早期做拆分，避免后期组件化的抽离困难。

以我现在的能力是很难听懂冯老师这个分享的，或者说我完全听不懂这个分享。是的，完全没有听懂。
还是分享一下别人的理解吧。

Piasy

原文链接：MDCC 参会纪要
【大公司的方案，不一定符合小公司
模块化，从硬件，系统到软件
APP 的模块化
- 隔离各个模块
- 特性：独立，可替换，可互操作
- 代价：解耦，契约，兼容性
- 从第一天开始坚持解耦，为中长期打好基础
- 独立并行开发测试，高效，快速
- 灵活的集成，发布，升级
- 64k问题
- 选择性安装，非常轻量
- hybrid友好，web native 可切换
- 高度可扩展
- 包隔离，最简单，太宽松
- gradle library module 隔离，有很好的工具链，构建效率低
- 多 apk，构建、安装更高效，用户体验差
- multidex，工具链支持，弱
- 容器 droid plugin，hook 和代理，兼容性问题
- 半容器，直接合并，但需要类加载支持，轻量，兼容性好
- activity 作为入口，提前准备好，后续开发都是 fragment。
- activity 用 url 启动
- 禁止状态共享
……】这是Piasy大神的分享。

我自己的理解是把一个项目隔离出各个模块，使分离出的模块成为独立的、可替换的、维护性强的小项目。这样做的带来好处是解耦、兼容性、可维护性。从一开始项目就做好项目的分离工作，使其解耦，为以后打好基础。

组件化

• 特性
  1.独立性
  2.可替换性
  3.互操作性
• 成本
  1.解耦
  2.契约
  3.兼容性
• 收益
  1.强制建立一个解耦
  2.模块的独立性
  3.组件粒度的测试
  4.灵活的测试
  5.组件粒度的升级
  6.混合开发性平滑地过渡
• 基础解决方案
  1.Java package name
  2.Gradle Library modules
  3.multiple App
  
• 进一步解决方案
  1.multi-Dex
  2.Container
  3.semi-Container
  
  由于我自己能力的限制，不能讲解清楚，所以附上Piasy的视频连接：回归初心，从容器化到组件化

云信 IM 推送保障及网络优化实践——周江华

现在IM应用范围很广泛，人与人要通过网络交流就离不开IM，可以说现在大多数的应用都有IM。
比如：社交、电商、教育、医疗等…

IM是什么

Instant：有新消息能立即收到，消息推送无延迟
Messaging：稳定可靠，安全，消息不丢，不乱，不重复

怎么推

后台运行。答案就是后台运行。

LMK

需解决的问题：内存占用、进程优先级
方案：
1.Sticky Service、Alarm、Receiver、JobSchedule
2.建立多进程、双进程。避免使用单进程。

SDK架构的设计

方案

云信IM SDK使用的连接类型有：TCP，UDP，HTTP。
TCP实现长连接，UDP实现一个需要加密处理的连接，HTTP实现收发文件等。
在复杂的Android生态环境下，多种因素都会造成消息推送不能及时达到客户端。另外，不稳定的移动网络也给数据传输的速率和可靠性增加了障碍。演讲从这两个方面出发，讲述了云信IM SDK如何实现不影响用户体验的后台保活，改善的长连接加推送组合方案，以及在弱网环境大数据传输的优化实践。
关于进程怎么在后台活，目前较好的解决方案包括：长连接+推送，系统推送（MIUI、华为为代表）。




而关于如何活好（主要问题是慢、断、贵），解决办法包括协议选择；
协议选择使用二进制的协议，牺牲了可读性换来的是包非常非常的小，同时拓展性也是比较好的。

登录加速（长连接中经常使用，步骤包括Lbs、Connect、Handshake、Login，Sync；优化思路为：尽量减少交互步骤，尽可能并行步骤）；
使用TCP的连接方式。
通过减少交互的步骤，尽可能的使用并行步骤来实现登录的加速。连接和LBS并行、捂手和登录并行。

UDP优化（常用于音视频服务，对弱网环境更敏感，优化包括：FEC，自适应初始化包频，动态包频和码率调整，数据缓冲Buffer，音频PLC丢包补偿，Temporal Scalability视频编码，以及视频关键帧多重保障）；

HTTP优化（断点续传，图片预加载，pipeline，边录边传）。



周江华老师讲的还是比较清晰，内容比较丰富的，基本涵盖了IM开发所要主要的问题。由于我自身能力的限制，理解的还是比较浅显的。附上Piasy的视频连接：【云信 IM 推送保障及网络优化实践上】【云信 IM 推送保障及网络优化实践下】

微信Tinker热补丁实践演进之路——张绍文

总体说明：

• 这场分享听的还是比较激动的，因为亲眼见证了大腾讯开源的第一个项目。真的是很激动，开源标志着我们可以阅读源码，可以清楚的理解其框架的内部实现，真的太帮了。Tinker的开源标志着腾讯走上了开源之路，各大BAT都在走向开源。真的是拥抱开源拥抱未来啊。
• 近半年很热的hot fix技术，走过坑是在art平台，dalvik平台的差异，让全量合成技术面临挑战，最后借鉴studio install run的原理及市场实际情况，发展到目前的阶段。
• Tinker是微信Android团队推出的开源热补丁框架，在MDCC现场，张绍文点击GitHub上的项目“公开”按钮——Tinker宣布开源！ 它可以帮助应用快速获得动态更新能力。演讲首先介绍Tinker项目的演进历程，重点分析在开发过程中遇到的问题（曾经遇到了启动耗时警报，Dex格式异常复杂）以及解决方案。然后剖析Tinker框架的核心架构设计，讲述Tinker是如何保证一致性、安全性、稳定性、高性能等关键问题。最后结合热补丁在微信的应用与实践，分享如何使用Tinker快速动态部署。目前热补丁有两大流派，Native（AndFix、KKFix）和Java。微信设计的目标是：稳定性于兼容性、性能、易用。1.0版三天成功率达到96.3%，启动耗时下降31%，补丁包大小为500KB。2.0版本（2016年2月）基于全量合并方式，Diff算法（设计目标为Diff结果小，占用内存小，合成速度快），其他技术挑战还包括Android N、Xposed、Classloader、DexDiff等。张绍文说，也许有人觉得Tinker过于臃肿，过于复杂。这是因为热补丁并不是仅仅加载一个dex或so文件，事实上它要关心的细节有很多。进程的一致性，控制可修改类的范围，版本的管理，扩展性等等。微信未来的开源计划，都以高可用为核心，除了Tinker，还有Mars和MMDB。
• 减小安装大小，对特定有问题的用户推送补丁包，获取调试信息。技术是用来解决问题的，明确需求：稳定兼容，性能，易用。

• 什么是热补丁：可以让应用无需重新安装下能够自动更新。

  具体说明：

• 热补丁两大流派：
  1.Native：AndFix、KKFix
  2.Java： Qzone、nuwa、rocooFix、Tinker、amigo、 robust
• 微信的设计目标
  “高可用”的补丁框架：
  1.稳定性与兼容性：微信数亿用户的设备上稳定运行；
  2.性能：非补丁版本影响补丁大小；
  3.易用性：简单易用，完整支持。

1.0 小试牛刀

基于 classloader 的方案
preverify 问题，内存地址错乱，性能差，补丁包大

2.0 自创功法

1. 基于全量合并方式：
   Gradle Instant run
   Buck exopackage
2. Diff算法：
   BsDiff
   DexMerge
   DexDiff
3. Diff设计目标：
   Diff结果小
   占用内存小、合成速度快
   支持新增、删除、修改class

Dex格式：直接上图。

Diff方案：

anr，dex 太大，分平台合成 dex，art 上合成小 dex

illegal access。
性能好，兼容性和稳定性差

3.0 修炼内功

主要在异常熔断、监控回调、安全、一致性、合成、加载方面进行优化。比较不容易理解，上图。

• 异常熔断
  
• 监控回调
  
• 一致性
  
• 加载与合成
  

结果：

4.0 内外兼修

提升易用性和稳定性

Library处理

核心问题：
1.多API获取不准确，反射出问题
2.32位与64位问题

尽量少的hook：
1.LoadLibraryFromTinker(“assets/86”，“stloprt_shared”)；
2.LoadLibrary(“stlport_shared”);

资源处理

预埋entry count：
1.编译强耦合
2.影响基础版本
3.无法随心所欲

全量替换
1.Atlas或者携程的插件化框架
2.Gradle-instant run

异常情况

Transition动画：ResID无法新增、删除，可能出现Res not found
Notification：ResID无法新增、删除，可能出现Res not found
ShortcutResID无法新增、删除，可能会变成默认图标
Assets：读取 source apk方式无法修改

资源问题

直接上图

编译目标

简单易用：
1.只要输入一个旧的基础包，即可生成补丁包
2.proguard
3.mainDex
4.日志与校验

灵活控制
1.可通过pattern灵活控制需要的内容
2.版本控制

减少补丁包
1.applyMapping
2.appyResourceMapping
3.force jumbo
4.7zip

V4.0结果

微信开源计划：Tinker开源地址
同样附上Piasy视频网址：微信Tinker热补丁实践演进之路
YouTube上Jacks录制的网址：微信 Tinker 热补丁实践演进之路——张绍文
微信开发团队公号：微信开发团队公号 (详细介绍可点击链接，非常详细的介绍，基本是按照演讲的时候介绍思路进行的)

方案选择，最重要的依据还是我们的需求，回到初心。

Fresco - loading images fast——王洁（Jie Wang）

• 我对这个框架所知甚少，在参加MDCC之前没有听说过，更别说用了。打算近期对这个Fresco图片处理框架研究一番。
• Fresco一个目前为止非常好用的或者说是最好用的加载图片、显示图片的框架。Fresco（单词的中文含义是湿壁画）是运用于Android设备的图片加载组件，使用了Fresco就可以不必烦恼图片的加载、显示这种繁琐的问题。Fresco中设计有Image Pipeline模块。它负责从网络、从本地文件系统、本地资源加载图片。为了最大限度节省空间和CPU时间，它含有3级缓存设计（2级内存，1级磁盘）。Fresco中的Drawees模块，会在图片加载完成前显示占位图，加载成功后自动替换为目标图片。当图片不再显示在屏幕上时，会及时释放内存和空间占用。解压后的图片，即Android中的Bitmap，占用大量的内存。大的内存占用势必引发更加频繁的GC。在5.0以下，GC将会显著地引发界面卡顿。在5.0以下系统，Fresco将图片放到一个特别的内存区域。当然，在图片不显示的时候，占用的内存会自动被释放。这会使得APP更加流畅，减少因图片内存占用而引发的OOM。Fresco在低端机器上表现一样出色，再也不用因图片内存占用而思前想后。未来Fresco的目标包括：更小的库和.so，令Image Pipeline插件化等
• 这里引用一段秋百万前辈的一点简单点评
  【王洁同学中文已经没有她的英文流利了，:)。作为 Fresco 文档的译者，也反复看了源码，以为对 Fresco 已 经足够了解了。还是补了好多知识。
  对于不能 wrap_content 的事情，如何做到提前知道图片的宽高，我现在的做法是把宽高信息放到 uri 中。】
• 这里再次引用别人的点评和理解——何俊林前辈
  【分想了fresco一些思想及实现，主要用到了匿名共享内存Ashmem ，在native层处理，减少在java层内存的处理问题。现场有人提问，如果都来申请这样一个匿名共享内存，会不会导致机器很卡，等。这个Ashmem实际上是直接站在巨人的肩膀（Linux 共享内存机制）上的，对于Android基于Linux系统，各个app都是一个process，当然一个app也有可能多个process,共享内存的创建（open）、映射（mmap）、读写（read/write）以及锁定和解锁（pin/unpin）四个使用情景.详细了解Ashmem可以参考：http://blog.chinaunix.net/uid-20321537-id-3482938.html。另一个问题是说fresco用Drawee的问题，提问的小伙伴说他们之前都是用ImageView，现在切fresco，发现Drawee不是继承ImageView，王洁告知在起初定用Drawee,就不会把Drawee继承ImageView，我觉得应该有相应的解决方案吧，毕竟那么多人都在用fresco。哈哈】
• 附上几张图，我本人英文惨不忍睹，基本翻译不出来。所以直接上图。（当然为了更好的理解王洁前辈所分析的干货，我私下会想办法翻译理解的，各位自行解决，有利无害）
  
  
  
  
  
  
  
• 抱歉，别找了，没视频。官方视频没出来之前别指望找到了，静等官方视频吧，不过官方也不一定会放出来。
• 我只有PPT，05-Fresco-loading-image-faster.pdf
  其余的全部会在文末放上。
  其中包括：
  [01-滴滴国际化 Android 端演进.pdf]
  [02-From.Containerization.To.Modularity.pdf]
  [03-云信 IM 推送保障及网络优化实践.pptx]
  [04-微信 Tinker 热补丁实践演进之路.pdf]
  [05-Fresco-loading-image-faster.pdf]
  [06-如何开发一款优雅的 SDK.pptx]
  [09-Android应用性能优化经验分享-张明云.pdf]

如何开发一款优雅的 SDK？——吕观祥

• 吕观祥前辈的分享是完全围绕着其公司的SDK产品来讲的。从SDK的设计到内核架构，讲解的比较全面。不过个人觉得，讲的有点高大上了，都是去寻求干货的，讲点技术比较实际。内核就没有必要拿出这么长的时间来讲解了，毕竟内部的东西不是一两句就能讲清楚的。
• 用当下的MVC,MVP等设计一个SDK。现场提问，是说这么多渠道和客户，如何管理分支问题。SDK打包及升级不同客户，确实都是很实在的问题。这个实际上是可以做一些渠道的标识的。不同的客户和厂商。在发版可以记录。build不同的sdk，脚本也是可以做到的。
• 个推推送数亿SDK独立设备上稳定运行多年的经验为切口，从SDK的开发、集成、发布等多方面深挖SDK与APP开发的不同之处，从架构、接口设计、兼容性等多维度来阐述如何开发一款优雅的SDK，使其满足易用、稳定、灵活等特点。吕观祥认为SDK的设计要点包括：开发方面需要接入简单，可自解释，可定制，防止误用；接口设计要周全考虑生命周期和异常处理；兼容性则考虑Android API、ROM版本，so版本，SDK版本；安全性要考虑本地和通信数据安全（HTTPS ECDHE-AES-GCM）；性能指标（电量、流量、内存、包大小）。发布方面，则需要实现灰度发布，补货Crash趋势和详情。发布包管理方面，需要包含日志更新，Sample工程代码等。其他还需要关注的有：第三方jar包，低污染（及时清理运行过程中创建的临时文件），以及全平台支持（Cocos2dx、Unity3D等）。
• 秋百万前辈的简单点评：开发，CI，测试三个方面，尤其 CI 方面的介绍，如果目前还没 CI 的团队，可以立刻按照这个配备搭建一个了。
• 还是说以我目前的能力理解的不怎么样，或者说根本没怎么听懂。所以大家自行学习，我也会继续学习。
• 附几张图，体会一下。
  
  
  
  
  
• 继续学习才能深入理解

打造可信赖的 Android 设备 ID ——杨玉奇

• 什么都不想说了。
• 还是说一句吧。不然憋得慌。少一点广告多一点真诚啊。
• 技术人搞什么推销呢，打起广告来没玩啊，全场刮台风。根本找不到自我。
• 这里要有秋百万前辈的点评：Slide 做得不错，台风也不错。嗯。我觉得秋百万前辈也是比较无语啊。
• 还是要来点有用的。
• 改IEMI、MAC，刷浏览、留存广泛存在，传统Android设备ID标识已经无法应对无孔不入的造假手段，推广效果难以评估。他认为，Android设备需要一个新的、可信赖的ID，而这种ID需要有四种特性：唯一（有统一维护中心），可校验（确保ID可靠），安全防伪造（防伪策略需要多重动态可调整），高可用（处理能力强）。数盟这套系统的平台架构分为五部分：系统应用层，消息枢纽层（Kafka+ZooKeeper），数据统计层，数据存储层，以及监控管理层。

Android 中 Native 的内存泄露检测 ——德胜（季丹）

• ANMAT是阿里Android团队内部使用的一套检查C++的crash和内存泄露的框架。它可以帮助开发者快速找到Native中Crash和内存泄露的函数栈。演讲首先介绍是关于ANMAT的演进历程，重点分析在开发过程中遇到的问题以及方法的提炼，然后剖析ANMAT架构的核心架构设计，最后结合ANMAT的解决思路，分享项目过程中的最佳实践。
• 阿里这位前辈的演讲使我听过的最快的演讲了，我感觉还没开始就结束了。:).
• 内存泄露问题后面的明云前辈也有讲解，所以这里就不赘述了。
• 其实想要赘述也没得说，根本没听懂，也还没开始听就结束了。
• 当我没说。

Android应用性能优化经验分享——张明云

• 与普通开发者不同，张明云所在公司的产品优化是针对整个平台，而非单个应用。他从产品经理和开发人员的视角，分别就性能优化的必要性、性能优化的工具和方法以及性能问题的改善方案做详细介绍。张明云举了一个例子：他们团队发现手机在静置的情况下，一晚会掉电20%，研究发现原因包括：60%的应用，启动时间超过2秒，SDK使用不合理，在系统回调或频繁调用代码块中创建新的实例，几乎所有App都存在过度绘制，Activity和Window都设置了背景，json库使用不合理导致Launcher卡顿严重，近10个应用监听开启广播，应用内存占用不合理，系统SDK导致内存泄漏，非静态内部类导致内存泄漏，四大组件的Context和Application Contex使用不合理，I/O操作完成后没有关闭文件。关于性能优化，张明云给出了需要遵循的原则和指标，并推荐了几款强大的工具——ASinpectCode、ASPerfarmance Monitor。
• 应用性能状况
  
  1. 约60%应用冷启动时间超过2s
     对应用的启动速度进行优化，尤其是冷启动。控制应用的冷启动时间在一个合理的时间内
  2. SDK的不合理使用（基础类型和装箱类型、HashMap、SparseArray）
     SDK的不合理使用是造成应用性能欠佳很重要的原因。要注意合理使用基础类型和装箱类型、HashMap、SparseArray等
  3. 在系统回调或频繁调用的代码块中创建新的实例
     对应用的代码进行合理的解耦，减低应用的耦合性是避免在系统回调或频繁调用的代码块中创建新实例的关 键。频繁的创建新实例导致应用的包过大，同时在运行阶段导致应用大量占用系统内存。导致应用的性能下降
  4. 几乎所有APP都存在过度绘制问题，Activity和Window都设置了背景
     APP的过度绘制问题，同样会导致占用应用性能下降，对用户的体验造成很大的影响。例如Activity和Window都设置了背景。
  5. json库的不合理使用，导致 Launcher严重卡顿
     json库类的不合理使用，导致应用运行严重卡顿。要用好json库并不容易，要在合理的时机使用json，避免滥用json库
  6. 近10个应用监听开机广播，导致开机后一段时间内Launcher严重卡顿
     关闭不需要的应用开机广播。过多的应用同时监听开机广播，会导致开机后一段时间内的应用运行严重卡顿。尽可能的避免应用开机广播
  7. 应用内存占用不合理（适配不规范、缓存不合理、回收不及时）
     不合理的内存占用。对不用的实例及时回收，避免不合理的缓存，规范的适配api
  8. 系统SDK导致的内存泄露（InputMethodManager、WebView，AndroidExcludedRefs.java）
     合理设计SDK架构。避免SDK导致内存泄露
  9. 非静态内部类导致的内存泄漏（ Handler、Observer、 AsyncTask）
     合理使用Handle、AsyncTask等非静态内部类。避免导致内存泄露
  10. 四大组件的Context和Application Context的不合理使用
      四大组件的Context和Application Context的不合理使用。优先使用四大组件的Context。合理使用Application Context
  11. IO操作后没有关闭文件（ Cursor、TypedArray、File等）
      尤其注意Cursor。Cursor使用不合理导致文件重复读写。
  12. 功耗问题明显（循环动画、过度绘制、网络请求不合理、后台服务常驻等）
      循环动画、过度绘制、网络请求不合理、后台服务常驻问题是造成功耗大的主要原因。要注意。

性能优化

1. 性能优化流程
   发现问题（性能检测工具）——>定位问题（性能检测工具）——>改善问题（性能优化方法）——>验证问题（性能检测工具）
2. 性能优化原则
   
   • 不能凭感觉，要看数据说话，有足够多的测量
   • 尽量使用低配置设备进行测试
   • 权衡利弊，以保证进度、稳定为主
   • 改善后一定要验证，保证每一次改善都有效，不会导致其他的问题
3. 性能优化指标
   在指标、现象、原因、检测工具几个方面讨论，上图。
   
4. 性能优化工具
   
   • AS Inspect Code
     
   • AS Performance Monitor
     
   • AS Date Analysis
     
   • 开发者选项
     
     • 过度描绘
       
     • GPU呈现模式分析
       
   • StrictMode
     
   • TraceView
     
   • 方法耗时打印Hugo
     
   • 布局性能查看 Hierarcher Viewer
     
   • 内存泄露检测 Leakcanary
     

5. 性能优化实战

   • 启动速度优化

     • 三种启动模式

       1. 首次启动：
          耗时漫长，fork进程+生成数据+dex编译为本地代码+应用初始化
       2. 冷启动：
          fork进程+应用初始化
       3. 热启动：
          应用恢复

       应该以冷启动速度为优化指标，首次启动频次低，热启动耗时少，没多大意义。

     • 冷启动平均耗时统计
       
       详情扫码
       Google Play排名前100的非游戏类应用：39个冷启动时间在2秒内，73个冷启动时间在3秒内
       
     • Hugo大致定位耗时位置
       
     • TraceView精确定位
       
     • 改善后
       
       
       
   • 流畅度优化
     
     
     • 内存优化
       
   • 功耗优化
     

实际优化效果

1. 超过80%的应用冷启动时间速度基本都控制在了1.5s以内
2. 解决图文混排控件界面因为图片太多导致滑动卡顿的问题
3. 对大部分模块完成静态代码分析，解决了明显的性能问题（Handler内部类、IO操作导致的内存泄露）
4. 解决两个APP因为适配不合理（图片存放的Drawable文件夹不对）导致耗内存的问题
5. 超过80%的应用基本做到无内存泄露（除系统导致的内存泄露问题外）
6. 解决了两个系统导致的内存泄露问题（WebView、InputMethodManager）
7. 超过80%的应用过度绘制层数控制在3X以内（无红色）
8. 超过95%的应用安装包大小控制在10M以内
1
2
3
4
5
6
7
8

2016MDCC大会 Android开发峰会讲师PPT

https://github.com/MDCC2016/Android-Session-Slides

最后附上Android峰会结束后的合影

以上是我此次参加MDCC大会总结的全部内容。大多数材料来自于讲师PPT，秋百万前辈、Piasy前辈、何俊林前辈的总结等。欢迎大家提意见，共同进步。有不对的地方还请见谅，请指出我会加以改正。

再次感谢stormzhang张哥给的机会，非常感谢，我会继续努力。

转载请注明作者——王佳豪