【MDCC 2015】平台与技术-Android专场（上）：剖析Android应用架构与设备体验

【CSDN现场报道】10月14日-16日，“2015移动开发者大会 ·中国”（Mobile
Developer Conference China 2015，简称MDCC 2015）在北京新云南皇冠假日酒店隆重举行。本次大会由全球最大中文IT社区 CSDN和中国最具关注度的全方位创业平台创新工场联合主办，以“万物互联，移动为先"为主题，邀请国内外业界领袖与技术专家公论移动开发的热点，在实践中剖析技术方案与趋势。

10月15日上午，在平台与技术-Android专场中，百度资深研发工程师、百度手机卫士Android客户端技术负责人 涂勇策 ，出门问问CTO 雷欣，友盟数据平台负责人 吴磊，绿色守护（Greenify）作者
冯森林从Android应用开发的经验、手腕上人工智能、大数据平台的架构及实践、Android App设备体验优化四个方面分享了各自在Android世界的精彩经历，本次平台与技术-Android专场由LeanCloud运营经理袁艺（袁滚滚）主持。



LeanCloud运营经理袁艺（袁滚滚）

百度资深研发工程师、百度手机卫士Android客户端技术负责人 涂勇策：Android应用开发浅谈——技术架构视角（PPT下载地址）

第一位出场的百度资深研发工程师、百度手机卫士Android客户端技术负责人涂勇策分享Android应用开发的经验，他从Android发展历程，主要问题及技术方案，新产品开发和技术演进四个方面进行阐述。



百度资深研发工程师、百度手机卫士Android客户端技术负责人 涂勇策

涂勇策介绍，Android开发的主要问题包括五个方面：1.性能；2.产品质量；3.产品迭代；4.多进程架构；5.其它典型问题。在性能方面，运行速度依赖于性能分析、优化UI布局，优化算法和数据结构和业务逻辑调整。

涂勇策强调，防止内存泄露是一个需要特别注意的问题。当然，占用内存占用的因素还包括不够优化的数据结构、图片，所以能少用图片就尽量少用，而对于多进程架构，要注意Android是基于Linux的内存管理的，即使Java内存释放，内存占用可能仍然很高。多进程设计的技术方案，包括四个方面：1.常驻进程；2.UI进程；3.特殊任务进程；4.IPC。数据库操作方面，单进程引用计数方式打开/关闭数据库，多进程可以用ContentProvider。他还提到，Android系统有一些安全问题，例如，广播发送/接收、Intent
extra参数提取，也会影响到应用的开发。



最后涂勇策谈到技术演进——技术跟踪时，要有专业人员对Android版本及SDK进行跟踪，发现其新特性和技术的价值挖掘，及时发现并解决产品的兼容性问题。对于Android Support库，当一些新的API的补充，大家也可以去关注。Android
Studio和Android Plugin for Gradle，开发人员应关注新特性，适时引入项目，优化构建流程。在性能优化和质量工具方面，开发者一定要注意优化产品的各性能指标（运行速度、内存占用、流量消耗、电量消耗）并引入适当的质量工具如Android Lint等，提高代码质量。

出门问问CTO 雷欣：Ticwatch——打造手腕上的人工智能（PPT下载地址）

第二位出场的是出门问问CTO 雷欣，他给大家带来的分享是一款手腕上人工智能：Ticwatch，详细介绍了智能手表软件体系构建及软硬件结合。



出门问问CTO 雷欣

雷欣首先讲到的是独立研发五大核心技术：语音识别、语音合成、语义理解、垂直搜索、智能推送。有了这些技术我们便可以实现Ticwatch。语义分析有查询分类和语义标签识别。其中在智能手表里，语音交互是灵魂。Ticwatch软件方面采用的是Ticwear中文智能手表操作系统，在后端人工作智能服务定制上，由Ticwear收集数据然后通过蓝牙将数据传到手机再上传到Ticoud上，最后在云端将数据整合处理。接下来他讲到了机器学习和创业公司的关系，在机器学习中，数据是血液，算法是大脑，工程师骨骼。在数据采集的方向，方式，量的方面都提出了自己的见解。



系统定制方面，基于Android的手表操作系统定制是主要是四个层面：应用层、Framework层、HAL层、蓝牙协议（自主开发Mobvoi Mobile Service (MMS)）。

应用层：桌面（Launcher）； 系统级应用，如日历、电话、健康、定时器、设置等。
Framework层： 独有硬件功能（挠挠）；服务精简、省电优化；系统 级功能实现及优化：双击截图、双击亮屏等；Android
Wear兼容。
蓝牙协议定制：基于蓝牙RFCOMM协议开发； 兼容Google GMS。

在UI的设计上，采用Cubic UI设计，桌面滑动使用Quick-Cards快捷卡片，快速地进行一些基本的设置，调整飞行模式，找手机、音乐控制等等。根据Timeline进行信息推送流，使得用户能更清晰、更高效的浏览与处理各类事物，更好的服务中文人群。该款智能手表还有大量的软件生态合作伙伴诸如京东、新浪、去哪儿等。在智能硬件方面，Tiwatch采用高屏占比360°完美纯圆设计，屏占比达到72.3%，嵌入扬声器使得手表更加人性化、采用磁吸式无线充电，并通过语音、触摸、挠挠、手势等软硬结合重新定义手表交互。

友盟数据平台负责人吴磊：移动大数据平台的架构及实践（PPT下载地址）

第三位出场的演讲嘉宾是来自友盟数据平台的负责人吴磊，他带来的分享主题是“移动大数据平台的架构及实践”。



友盟数据平台负责人 吴磊

友盟大数据平台的架构借鉴了Lambda架构，数据接入层让Kalfka集群承担，后面由Storm消费，存储在MongoDB里面，通过Kafka自带的Mirror功能同步，两个Kafka集群，可以分离负载；计算有离线和实时两部分，实时是Storm，离线是Hadoop，数据挖掘用Hive，分析任务，正在从Pig迁移到Spark平台，大量的数据通过计算之后，存储在HFDS上，最后存储在HBase里面，通过ES来提供多级索引，以弥补HBase二级索引的缺失。

数据采集方面，友盟面临的挑战包括大流量、高并发和扩展性，最开始用ROR，后台接Resque，现在改成Kafka，单台服务器处理并发能力得到提升，横向扩展，能够承担读写压力。数据清洗也踩了很多坑，得到的教训包括：唯一标识，数据标准化，数据格式。大数据的系统，价值最大的部分，数据增值在两个大的方向进行发力，首先在内部进行数据打通。目前我们是实现了个性化“微”推送，主要是基于用户的实践，还有数据挖掘，基于用户画像、设备评级、健康指数。例如对有无车辆的不同用户区别的进行产品推荐。通过个性化的定制，可以达到一些精度比较高的运营效果。

对于Android市场的IMEI、MAC和Android ID的混乱，友盟通过两种方式解决：1.统一计算，综合以上提到的三种设备ID，按一定的算法来计算出唯一的ID，对于重复的IMEI、MAC地址、Andriod ID等数据会进入我们的计算黑名单，在计算时不予采用。2.机器学习，通过基于图的分析方法，来讲计算设备标识。



最后吴磊介绍了友盟基于数据的一站式解决方案，在该解决方案中对于用户评级，采用基于友盟全量数据, 甄别渠道用户质量 ，进而给用户进行评分；在游戏统计分析，采用开箱即用的手游数据解决方案；建立与用户直接沟通的渠道来进行消息推送；采用一站式社会化服务SDK ；微社区方面，快速搭建APP内社区；通过精细的数据统计分析来读懂用户。

绿色守护（Greenify）作者冯森林：做一个安静的App（PPT下载地址）

绿色守护（Greenify）作者冯森林从Android App设备体验优化角度出发，带来一场与众不同的演讲——“做一个安静的App”。



绿色守护（Greenify）作者 冯森林

作为一个从Symbian到Android专注移动工具App开发十多年的资深技术专家，冯森林用封闭的监狱与开放的丛林比喻iOS和Android，两者各有弊端，因此绿色守护就变得不可或缺。

丛林的黎明，随着Android Marshmallow推出了Runtime Permission、Doze Mode、App Standby和Improved Battery/Memory Graph等强有力的工具。

他谈到了应用程序拖慢系统这个问题，如Broadcast receivers in AndroidManifest （可能远比你想象中慢）：在进程创建和初始化（在低端机型上可能需要约 1 秒）和Application.onCreate() （在很多大型App中往往开销非常大）。另外作为中低端手机的杀手的连环唤醒也是让用户深恶痛绝的。针对上述问题他提出了几点解决方案：

1.避免使用静态声明的Broadcast Receiver，尽可能动态注册； 2.不再需要时禁用静态 Receiver ，例如PackageManager.setComponentEnabledSetting()； 3.Lazy 初始化、分离的 UI 初始化（利用ActivityLifecycleCallbacks)4.采用SyncAdapter、JobScheduler或者GcmNetworkManager来解决不同的问题。

除此之外的后台服务也存在问题，典型表现为内存消耗、GC（Dalvik的最痛）、频繁被重启、Exception Spam in logcat等问题。他提到采用独立于UI的后台进程或者Object Pool以及改掉那些 IDE自动生的 catch(…)等等措施可以解决相应问题。此外IO 密集型任务（如Flash存储）和非唤醒型 Alarm问题也是App设计时必须要考虑到的问题。



另一个用户更为敏感的问题是：电量消耗。对耗电问题第一个要考虑的是Alarm，首先确保 Target SDK Version ≥ 19；第二务必使用可对齐的周期：15分钟、30分钟……；第三Wake up 与否，很有讲究（non-wakeup 并不总是最佳选择）；最后尽可能不要使用 Exact Alarm。同时WakeLock、后台持久服务，传感器和定位请求也应该纳入考虑范围。

最后，第三方Push服务往往是耗电大户，在对比测试时应该慎重选择，面向全球市场的App，优先使用Google Cloud Messaging，最后务必给用户关闭的机会。

接下来他讲了保护设备体验的若干最佳实践：对于后台持久服务而言很可能 SyncAdapter已经够用，所以可以考虑短生命周期的后台服务Broadcast / Alarm + IntentService，也可以选用一个不需要启动后台持久服务的Push通道（如GCM）。对于WakeLock服务来讲保持屏幕常亮并不需要WakeLock。小数据量下载/上传别惦记 WakeLock，而是加上必要的重试机制。大数据量下载用DownloadManager。大数据量上传需要的可能是 WifiLock。对于Push服务来讲，内容的实时性诉求要考虑用 Sync Adapter 代替 Push，内容的性质要的只是一个社交媒体账号（比如微信公众号）。当然实行自己自由的权利也可以选择卸载。
更多精彩内容，请关注新浪微博：@CSDN移动，图文直播专题：2015移动开发者大会。

原文地址：http://www.csdn.net/article/2015-10-23/2826014