订阅移动开发RSS CSDN首页> 移动开发

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

发表于2015-10-23 10:59| 次阅读| 来源CSDN| 0 条评论| 作者刘崇鑫

摘要:在平台与技术-Android专场(上),百度资深研发工程师涂勇策、出门问问CTO雷欣、友盟数据平台负责人吴磊、绿色守护作者冯森林从应用开发、智能手表、大数据平台、设备体验角度分享了各自在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移动开发者大会

0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章