Android面试一天一题(Day 31:Android技术难题
最近在看一些认知、脑科学和学习相关的书籍,看似和面试不相关,其实一想关系非常大。面试,特别是软件开发的面试,其实最重要的是区分出面试者的认知能力,而且最好能判断对方是否具备理工科(较理性客观)的思维能力。
所以我也多次提过,除了太基础的题目(原则)之外,面试者答错题并不算是严重的问题,严重的是面试者思路让别人难以理解,或者说面试者没有很好的表达能力让别人更容易理解他的思路。工作过几年的人都有感受吧:“不怕神一样的对手,就怕猪一样的队友”,这个“猪一样”大多数时候都是用来描述思维奇葩的同事吧。
那么,在Android开发中,如何结合技术点和思维认知方面一起考查呢?请看今天的主题。
面试题:你在Android开发中遇到的技术难题是什么,你是怎么解决的?
一个工作过几年的程序员肯定会有工作中遇到技术难点问题,虽然这个问题有可能对于别人不是技术难点,但只要对于当时的你是技术难点,只要让你抓耳挠腮毫无头绪就往往会在你的大脑中留下深刻的印象。
这个问题,我也比较难教大家怎么回答,我只能给大家做一个示范,如果问到我,我怎么回答。
因为我这两年主要的工作是给一家公司做Android插件框架的开发,所以我的第一反应就是刚做插件时遇到的茫然无助。先给大家说一下插件是什么以及为什么要做插件,估计面试官不太了解的话,也会这样问你的。
如上图所示,随着应用的业务和功能代码的无节操增大,技术上代码方法数到达了一个DEX文件(那时Google还没有推出MultiDex)的上限(65536),业务上太多的模块和业务逻辑混在一个应用中,部署和升级都遇到很麻烦的问题,不能快速响应业务的发展。
基于这些痛点,我们想到了“动态插件”方面,把各个业务模块独立出来成为一个个可以动态加载、独立升级的插件,而原来的应用做为一个平台承载这些插件。思路是很不错的,可是当时(2014年底)关于Android插件的资源和开源项目都很有限,并没有那么多现成的开源框架让我们借鉴。如果你现在做插件你的烦恼是选择的开源框架太多了,不知道该选那个,正如我在一篇文章所写的那样:
2015年Android的插件开发热情空前高涨,开源的插件框架也如雨后春笋,初步了解对比了一下各个开源框架,感觉各有千秋。因为面对不同的业务需求,所以在针对性和实现方式上都略有不同。
在没有开源框架的时候,世界很安静,大家只能低头研究android机制和framework的代码自己闭门造车,一直怨恨无人同行且不能踩在前辈的肩膀向上。而今面对扑面而来的开源插件时,大家又陷入选择的泥潭而不能自拔,这真是幸福的烦恼。每个插件框架都各有各的优缺点,当你花时间去熟悉对比完各个插件框架后,你也不一定能百分百确定某某框架一定适合你用。你终于在绕了一圈后又回到起点,是自己写一个框架呢还是用开源框架呢?因为你始终不能确认开源的框架是否能经得起实际项目的检测,害怕还有N多不知道的坑在等着你。
不过问题总是要解决的,我的解决方案如下:
- 当时有一家叫ApkPlug的小公司做出了一套插件框架,我打电话和他联系看能否交流(回答当然是买产品可以,技术就免了),如果对方能提供优质的服务是可以考虑花钱使用他们的框架。
- 试用ApkPlug的产品把它能做到的功能点记录下来,对比一下是否完全符合我们的业务需求。这一步至少给我一个意识:“只要ApkPlug能实现的就证明技术上是行得通的”, 对于还在起步阶段的我们信心很重要。
- 收集其他相关的信息以评估自己实现插件框架的可行性,如Apache flex的OSGI模块化开发框架也进入我们的尝试提案。
最终我们决定自己来实现插件框架,当时遇到过很多技术“难点”,如“如何实现在插件中不改变开发者的习惯正常调用startActivity”,“自定义View的在插件Activity切换时的类加载有问题”,“插件升级时so不能正常加载的问题”等等。问题很多,解决这些问题,基本上都是靠先理一遍正常的一个APK应用在Android系统上是个怎么样的流程,详细的查看Framework层代码的调用过程,最后找到问题的解决点。
小结
其实很多人的问题在于“他没有问题”!很多工作了多年的程序员,你问他有什么印象深刻的问题困扰过自己吗?没有!有在参与过的项目中有提供什么非常关键的解决方案吗?没有!有发现过测试没测出来但很严重的问题吗?没有!
太多的“没有”了,这样的人不在少数,包括工作很多年的资深程序员。那么真的是我们没有遇到过问题吗?答案显然不是,问题是我们遇到问题时没有对问题进行过深入的思考,没有把它记录或者当成案例分享给别人,渐渐地你自然会遗忘它们,然后你还有可能遇到同一个(或相似的)问题又被它再次弄得焦头烂额。
努力吧,做个有“问题”的程序员。