3G Eden
RSS近期一名新星在国内Android开发社区冉冉升起，他就是目前正在读高二的罗迪（Lody），前段时间他开源的Legend、TurboDex等项目受到业界的肯定。InfoQ也对他进行了采访，了解他的技术成长历程以及对技术的理解。
技术学习与成长
InfoQ：请你先介绍一下自己。你是从什么时候开始学习编程，什么时候接触Android开发？
罗迪：大家好，我是罗迪，英文名是Lody。我热爱编程，专注移动开发领域。目前我在国内某高中读高二，作为一个高中生，我平日里跟代码接触的时间不是很多，但是我对技术有较高的追求。我不会去考虑一个技术的应用价值，只要我对它有兴趣，就会去研究它、攻克它。
我学习编程是一个意外，最初我喜欢为一些设备定制ROM包，发到一些渠道上面，但是时间一长，感到没有意思，我发现定制ROM就像是搬砖的工作，没有太大的挑战性和激情，便很向往做一个Android工程师。于是初二那段时间，我买了第一本编程书籍：《C++从入门到精通》。当时连C++是什么都不知道，只知道它可以做很厉害的事情，很逗。但是学得时间一长，对编程的理解逐渐深入，看法也就慢慢改变了。我在初三时期把Java基础给拿下来，然后就开始朝着Android奋斗。
我学习Android没有像一般的人那样去看《Android从入门到精通》这样的书籍，我直接clone了Android的源码下来慢慢啃。 Android源码博大精深，绝非我一个little boy能够看懂，幸亏有邓凡平老师的大作《深入理解Android》，为我理解源码起到了很好的导向作用。看源码看到激情澎湃的时候，我会有很多奇思妙想，之后我所写的项目，大多是建立在对源码理解的基础上的。
InfoQ：你是如何如何快速学习提高技术水平的？
罗迪：有句话说的好: Read the f**k source code。在一项语言基础扎实的情况下，去学习具体平台的开发，绝佳的方式就是阅读优秀的源码。无论代码做得是什么，优秀的代码都会在不经意间让你有所感悟。现在，网上各种文章介绍着各种各样的设计模式。尽管你可能看懂了它的组织形式，却不一定能够融会贯通。阅读源码的过程，你能够真切的体会到一个设计模式的妙处。Google开源了Android这个珍贵的宝藏，阅读它的源码成为了我提高技术水平的方式。Android虽然为开发者提供了详细的文档，但是如果仅仅止步于SDK层，很多的问题你都会有"知道怎么处理，但是不知道原因"的感觉。
InfoQ：能否介绍一下你的几个有代表性的开源项目。
罗迪：我最早开源的项目是“Direct-load-apk”，它是国内较早实现无约束运行APK的一个开源插件化框架。可以说，动态化加载技术一直在伴随着我成长，Direct-load-apk则是我努力后的结晶。作为我高一时期我所写的第一个开源项目，它的背后充满了许许多多的故事以及插曲。当然，最让我高兴的是，它让我结交了许许多多的朋友。开源过后，许多朋友吸收了它的思想，为公司做出了适应需求的插件化框架。后来，我又实现了更完美的插件化方案(可以运行QQ&微信)，但是由于一些原因，我无法将其开源。张勇（叔叔）开源的DroidPlugin也很棒，许多的思想跟我志同道合。我敬佩思想的创造人，因为有了思想，轮子可以再造，但是如果没有思想，轮子是不可能造出来的。
与此同时，我也在探索虚拟机的Hook技术，在我探索Android平台的Hook技术前，Dalvik下的Java Hook就已经趋于完美。但是很遗憾的是，Google在Android 4.4以后就使用了ART虚拟机替代了Dalvik虚拟机。ART虚拟机的运行机制相对于Dalvik虚拟机而已复杂了很多，其中还掺杂了许多平台相关的因素，这为研究ART下的Java Hook造成了极大的困扰。不过由于兴趣的缘故，我没有放弃这块难啃的骨头，我经常会在车上和地铁上看有关的文章以及源码，在家里尝试着验证已有的想法，之后我开发了一个新的Art Hook方案，我将它命名为Legend。项目地址：https://github.com/asLody/legend。
再后来，有一天我偶然看到很多朋友在讨论Dex加载速度过慢的问题，对于这个问题，很多朋友都想到了异步的方案来避免ANR，但是这样的办法会降低用户体验，于是我想到了在我的一个项目中使用的“跳过Dex优化”的方案，将它抽离出来并开放了源代码：https://github.com/asLody/TurboDex。
Android插件化与双开技术
InfoQ：听包建强老师说，你对Android插件化的理解很深刻，能向我们介绍一下吗？
罗迪：插件化发展到目前，总结一下，有两种实现方式，一是基于SDK层组件Delegate(委托&代理）的方式，这种方式不用关心系统底层源码，框架实现成本较低，但插件开发成本较高；二是Framework hook，这种方式是对运行时环境做很多的hook和patch，使得插件的约束很小，随着这种方式的成熟，渐渐就发展成了双开，从而诞生了一系列双开APP。当然，对于Weex、React Native这些，他们的发展可能更局限在界面层，对于内容丰富的app，例如天猫、淘宝，就很适合，但是绝对做不到双开那种程度。
InfoQ：什么是App双开技术，它的难点在哪里？
罗迪：App沙盒/双开技术是现在仍处于发育时期的未成熟技术，它的目标是使一个未安装的APK直接运行在一个容器当中，与外部环境部分隔离（或完全隔离），处于沙盒之中的App无法觉察到自己的环境与普通运行时的环境有所不同，并能够与沙盒之中的其它App进行交互。概念上来讲，它类似Docker。
现阶段，已有许多安全公司研发出了较早时期的App双开技术：LBE平行空间、卓盟双开助手、金山开小号，但是它们的原理无一例外的是插件化。
App沙盒的难点主要有：
欺骗 App，让其认为自己运行在正常的环境中。
完整得驱动四大组件。
让组件的进程分布与实际完全一致。
随时与处在沙盒外部的容器和宿主(Host)进行同步的远程通信。
兼容不同系统API版本的设备。
SD卡隔离(Native IO Redirect)。
每一个难点，都需要花费很多的精力去研究，时不时还会陷入到一个坑里面去。要去从头设计并完成一套这样的App双开引擎，绝非几天就能完成的。在桌面平台，早已有了沙盒环境的概念，随着移动端开始崛起，我相信移动端的沙盒机制在未来几年内必然会诞生的，插件化技术将会得到空前的发展。
InfoQ：有人认为插件化会被React Native或类似技术代替，对此你有什么看法？
罗迪：对于这个观点，我不是很赞同。React Native的稳定，决不意味着插件化的落幕，怎么说呢？
React Native这类的技术，为实现UI层的跨平台而生，它能够在多端渲染出一样的界面，降低开发成本，但是它却仍然依赖已有的系统组件。它的跨平台特征都是建立在一个内置的JavaScript引擎上面的，你能够利用它已有的组件，但无法对组件进行更新和升级。就好比搭积木，无论你要搭成什么东西，积木就这么几块，形状固定，颜色固定，你不可能再把单个的积木细分成更小的东西。
但是插件化就不一样了，在插件化之下，你能根据需要动态的加载、升级和卸载组件，甚至是整个React Native框架。不仅如此，React Native还能和插件化优雅的结合，如果让React Native为UI提供渲染支持，而下层所支持的UI组件通过插件化来提供，那么React Native的缺陷就得到了克服。
插件化技术的成熟程度虽然在最近几年呈上升趋势，但是总体而言仍然处于初、中级阶段。App沙盒技术的出现就是插件化发展的创新和第一阶段的产物。在未来，我相信很多插件化技术会被更多的应用，如果插件化稳定到了一定的程度，甚至可以颠覆App开发的方式。
