面试地点：深圳市南山区南山智园A5。
面试公司：深圳市智璟科技有限公司
面试时间：2016年06月02日 15:00
刚过完儿童节，发哥就出来“找工作”了。这不，一不小心接到一个做无人机的公司的面试邀约。看看无人机的android开发都有哪些要求吧。
====================
来到南入口，嗯，感谢头顶的乌云挡住了阳光。话说这儿还是挺偏的。

大厦门口

到了门口，吓得我赶紧拍了一张。跟前台妹子说明来意后，在旁边沙发少坐等一会，面试官马上就来了。效率不错。

======================
下面直接进入面试环节。（有些同学看到另外的同学发了各种笔试题啊，看得心方方，其实很多公司是没有笔试题的。）
======================
面试官：你好，请先自我介绍一下。
发    哥：您好。我叫杨x发，很荣幸能到贵司应聘Android开发的岗位。在上家公司工作了2年，觉得自己技术积累到了一定程度，而公司的发展也比较缓慢，觉得自己应该去另外一家更有发展前景的公司去挖掘自己的潜力，刚好在拉勾上看到了贵司的招聘信息，就投递了一份。面试官：（微笑）咱们公司是做无人机的，前景是比较不错。（顿了下）之前都做了哪些项目？
发    哥：之前公司项目基本都是应用层的产品，与硬件交互的还是没什么机会接触到。（举起手机）面试官，您看，这是我最近做的项目。图片欣赏和文章阅读这块是我来做的。这个项目以MVP作为架构基础进行开发的。
面试官：（接过手机）挺好看的，遵循了MaterialDesign风格的设计。
发    哥：对，这个项目基本遵循了MaterialDesign设计，侧滑出来的菜单中可以切换功能模块。
面试官：说说MVC和MVP的优缺点。
发   哥：印象中MVP早几年已经出现了，也是这两天才火起来的。MVC中，M和C的耦合是比较严重的，这在MVP中得到了很好的解决，就是P。P中有M和V的对象，两者的交互由P进行协调，这里将MVC中的耦合降至最低。MVP在单元测试中也有非常不错的体现，M这块不需要V。但是要注意，MVP容易“类爆炸”，产生过多的接口类，如果面向对象的六大原则没有掌握好，项目反而更加难以维护。MVP也更加适合大型项目。
面试官：（微微点头）好，那这个项目中有没有用上热更新技术。我看你简历上写了这个点。
发    哥：这个项目还是没用这个的。热更新这个词也是最近才比较火的，记得是阿里发布了个是叫AndFix的开源项目。原理好像是通过在native层直接进行方法替换。而在我之前项目中，是使用DexClassLoader进行热更新的。当初这个需求是要实现动态地升级外部的jar包的，由于我们公司的产品SDK是提供给中小游戏使用的，他们的包不更新的话，我们也就没办法给它升级，后来我通过这个DexClassLoader去加载这个包，分为主程序和插件程序，主程序嵌入游戏，负责调用插件程序。插件程序可存在sd卡中，所以也可以存在服务器中进行检测更新以实现自动升级jar。但这样去加载有一个问题——外部jar包无法加载四大组件。这就意味着需要将activity和service等组件放在主程序中加载。于是我定义了一个ProxyActivty和ProxyService来代理外部包中的Activity。我记得微信中的游戏也是通过这么一种方式去实现插件化的。那会网上并没有太多的插件升级方案，所以这些都是自己结合网上的一些资料摸索出来的。
面试官：不错啊，可以说得上是热更新的先驱了。
发    哥：过奖了，这个技术在现在看来是比较低级的（憨笑）。做其他项目后也没有深入去研究了。
面试官：这项目中图片挺多挺清晰的，这块如何优化的？发    哥：嗯，这项目中图片处理着实是个大头。常规处理方式自然少不了三级缓存+LRUCache，在内存这块使用这个LRUCache类，中文全称就是“最近最少使用原则”，缓存到LruCache中维护的LinkedHashMap存储的图片，在达到阈值后，将最近较少使用的图片从内存中移除的做法。这在我项目中用的Glide（Google的图片开源框架）中也是如此一种缓存策略。图片处理这块在Android开发中太重要，所以有不少优秀的开源框架。Picasso及Glide，以及Facebook的Fresco都是非常优秀的。而我这项目中的图片，在显示是按照原比例显示的，所以宽高是不确定的。在一开始，通过监听ImageView的Bitmap设置后，得到宽高再去重新设置ImageView的大小，但在ListView或RecycleView中显示时会不断计算不断重绘。为了避免这个问题，我在图片上传时将宽高保存为元信息，下次
请求json时得到宽高，计算比例，直接设置ImageView的宽高，等图片加载好之后，便可以完美贴合显示。
面试官：对开源框架挺了解的。刚刚说那三个框架，为什么你选择Glide？
发    哥：以前一直用UniversalImageLoader的，后来看到一些技术群里对Picasso和Glide的讨论，说谁好。我就找了些文章。文章里说到Picasso和Glide的一些对比测试，前者默认加载的图片比较清晰，是RGB_565我记得，而后者是RGB_444，这块是Glide比较省内存，通过工具看到Glide比Picasso省了好多，具体是多少给忘了。后来我也测试了一下，果真如此。然后重新配置了Picasso的图片清晰度，也是可以将内存剩下来并且不影响用户观看效果的。这里两者都是一个链式调用，使用方便。Glide还支持动图，而且图片加载与Activity与Fragment的生命周期绑定了，所以我选择了它。
面试官：嗯。咱们公司做的是无人机，图片不会很多，可能没有Glide的用武之地了。（笑）发    哥：那也是。（笑）
。。。。。。
闲聊了一些公司的产品后，基本结束本次面试。
======================
后面即跟hr谈薪资，给我开了个11k。我笑着说这个薪资还是比较低的。hr说跟主管说下，争取网上提，也希望我再多考虑，比较无人机这块的发展还是挺不错的。
以上。

面试地点：深圳市南山区南山智园A5。
面试公司：深圳市智璟科技有限公司
面试时间：2016年06月02日 15:00
刚过完儿童节，发哥就出来“找工作”了。这不，一不小心接到一个做无人机的公司的面试邀约。看看无人机的android开发都有哪些要求吧。
====================
来到南入口，嗯，感谢头顶的乌云挡住了阳光。话说这儿还是挺偏的。

大厦门口

到了门口，吓得我赶紧拍了一张。跟前台妹子说明来意后，在旁边沙发少坐等一会，面试官马上就来了。效率不错。

======================
下面直接进入面试环节。（有些同学看到另外的同学发了各种笔试题啊，看得心方方，其实很多公司是没有笔试题的。）
======================
面试官：你好，请先自我介绍一下。
发    哥：您好。我叫杨x发，很荣幸能到贵司应聘Android开发的岗位。在上家公司工作了2年，觉得自己技术积累到了一定程度，而公司的发展也比较缓慢，觉得自己应该去另外一家更有发展前景的公司去挖掘自己的潜力，刚好在拉勾上看到了贵司的招聘信息，就投递了一份。面试官：（微笑）咱们公司是做无人机的，前景是比较不错。（顿了下）之前都做了哪些项目？
发    哥：之前公司项目基本都是应用层的产品，与硬件交互的还是没什么机会接触到。（举起手机）面试官，您看，这是我最近做的项目。图片欣赏和文章阅读这块是我来做的。这个项目以MVP作为架构基础进行开发的。
面试官：（接过手机）挺好看的，遵循了MaterialDesign风格的设计。
发    哥：对，这个项目基本遵循了MaterialDesign设计，侧滑出来的菜单中可以切换功能模块。
面试官：说说MVC和MVP的优缺点。
发   哥：印象中MVP早几年已经出现了，也是这两天才火起来的。MVC中，M和C的耦合是比较严重的，这在MVP中得到了很好的解决，就是P。P中有M和V的对象，两者的交互由P进行协调，这里将MVC中的耦合降至最低。MVP在单元测试中也有非常不错的体现，M这块不需要V。但是要注意，MVP容易“类爆炸”，产生过多的接口类，如果面向对象的六大原则没有掌握好，项目反而更加难以维护。MVP也更加适合大型项目。
面试官：（微微点头）好，那这个项目中有没有用上热更新技术。我看你简历上写了这个点。
发    哥：这个项目还是没用这个的。热更新这个词也是最近才比较火的，记得是阿里发布了个是叫AndFix的开源项目。原理好像是通过在native层直接进行方法替换。而在我之前项目中，是使用DexClassLoader进行热更新的。当初这个需求是要实现动态地升级外部的jar包的，由于我们公司的产品SDK是提供给中小游戏使用的，他们的包不更新的话，我们也就没办法给它升级，后来我通过这个DexClassLoader去加载这个包，分为主程序和插件程序，主程序嵌入游戏，负责调用插件程序。插件程序可存在sd卡中，所以也可以存在服务器中进行检测更新以实现自动升级jar。但这样去加载有一个问题——外部jar包无法加载四大组件。这就意味着需要将activity和service等组件放在主程序中加载。于是我定义了一个ProxyActivty和ProxyService来代理外部包中的Activity。我记得微信中的游戏也是通过这么一种方式去实现插件化的。那会网上并没有太多的插件升级方案，所以这些都是自己结合网上的一些资料摸索出来的。
面试官：不错啊，可以说得上是热更新的先驱了。
发    哥：过奖了，这个技术在现在看来是比较低级的（憨笑）。做其他项目后也没有深入去研究了。
面试官：这项目中图片挺多挺清晰的，这块如何优化的？发    哥：嗯，这项目中图片处理着实是个大头。常规处理方式自然少不了三级缓存+LRUCache，在内存这块使用这个LRUCache类，中文全称就是“最近最少使用原则”，缓存到LruCache中维护的LinkedHashMap存储的图片，在达到阈值后，将最近较少使用的图片从内存中移除的做法。这在我项目中用的Glide（Google的图片开源框架）中也是如此一种缓存策略。图片处理这块在Android开发中太重要，所以有不少优秀的开源框架。Picasso及Glide，以及Facebook的Fresco都是非常优秀的。而我这项目中的图片，在显示是按照原比例显示的，所以宽高是不确定的。在一开始，通过监听ImageView的Bitmap设置后，得到宽高再去重新设置ImageView的大小，但在ListView或RecycleView中显示时会不断计算不断重绘。为了避免这个问题，我在图片上传时将宽高保存为元信息，下次
请求json时得到宽高，计算比例，直接设置ImageView的宽高，等图片加载好之后，便可以完美贴合显示。
面试官：对开源框架挺了解的。刚刚说那三个框架，为什么你选择Glide？
发    哥：以前一直用UniversalImageLoader的，后来看到一些技术群里对Picasso和Glide的讨论，说谁好。我就找了些文章。文章里说到Picasso和Glide的一些对比测试，前者默认加载的图片比较清晰，是RGB_565我记得，而后者是RGB_444，这块是Glide比较省内存，通过工具看到Glide比Picasso省了好多，具体是多少给忘了。后来我也测试了一下，果真如此。然后重新配置了Picasso的图片清晰度，也是可以将内存剩下来并且不影响用户观看效果的。这里两者都是一个链式调用，使用方便。Glide还支持动图，而且图片加载与Activity与Fragment的生命周期绑定了，所以我选择了它。
面试官：嗯。咱们公司做的是无人机，图片不会很多，可能没有Glide的用武之地了。（笑）发    哥：那也是。（笑）
。。。。。。
闲聊了一些公司的产品后，基本结束本次面试。
======================
后面即跟hr谈薪资，给我开了个11k。我笑着说这个薪资还是比较低的。hr说跟主管说下，争取网上提，也希望我再多考虑，比较无人机这块的发展还是挺不错的。
以上。