开发日记-20190424 关键词 阶段性开发心得和小结

Android开发学习小结

…图片因为是以前下下来的,所以出处真的记不太清楚了,如果有清楚出处的欢迎指正,我加上去,另外,这只是我的个人学习小结,并不是特地用于分享的,如果观赏有任何的不悦,还请谅解.

从我以前遇到过的囧境说起吧，我仍记得，那时候我还在读大二，我的老师鼓励我和我的小伙伴们好好努力，话是这么说的：“在这些项目上，你们可以尽情发挥，如果做的足够优秀的话，我可以分配学弟来给你们帮忙（没错，没有学妹，这里我记得特别清楚），完全可以你们搭框架，让学弟来往里面填东西”。

当时包括老师在内总共有5个人，一点声音都没有，寂静的可怕，那时候我真的不知道框架是什么，但是看别人都很清楚的样子，所以在老师讲话的时候，我只能面带微笑，不住地点头。在老师讲完的时候，我实在忍不住，我就这性子，我问了一句，“框架到底是什么？”，问到最后我才发现竟然除了我之外的同学也不知道这到底是什么东西。

我常常感觉高级语言以及一层又一层的框架的出现的确是一件好事情，因为后人可以站在巨人的肩膀上，可以绕开前人已经反复遭遇过的陷阱。但是另外一方面，每个人也因此变成了这巨大机器上的一颗螺丝钉，每个人只需要知道自己该被拧到哪个洞里面，而对这颗螺丝到底在整个机器上面到底起到了什么样的作用一无所知。发一句感慨，“知其然知其所以然”，这句话好像很久没听人提起过了。

通过今天的叙述和表达，我并不打算将任何一个具体的Android相关的概念的实现细节，任何一个android开发过程中的名词，因为在场的所有人都是在不同的方向从事着截然不同开发的工作，如果我直接抛出来一堆概念，就好比在完全没有地基的地皮上造房子，既浪费时间，又毫无意义。思想往往要比具体的技术实现更加重要，因为技术实现往往是片面的，针对特定的平台和特定的语言的，然而思想却是相通的。

OK,瞎扯了一堆东西，聊聊正事吧。我将主要从两个大块展开我的讲述，android项目演进规律和混合开发优势。

Android项目演进规律

很多事情看似并不存在规律，实际上却存在着必然性。

在全世界千千万万码农的艰苦卓绝的不懈努力下，android从最开始的开荒时期，经历了模块化，组件化，插件化这三个阶段，最后演变到如今的混合开发。

项目的结构也从最开始的一团乱麻到现在如同艺术品一般的代码结构。

演进看似不存在规律，实际上始终在往同一个方向演进，降低耦合度，提高复用性。其中降低耦合度体现在从模块内强耦合强引用，到模块间强耦合强引用，到模块间弱耦合弱引用，到项目间弱耦合弱引用。

而提高复用性体现在从模块间复用性，上升到项目间的复用性，最后到平台间的复用性，即所谓的java思想，“code once,run everywhere”,一次编码,满世界瞎跑。最开始的项目就是一整个包，一团乱麻。

最开始的项目就是一整个包，一团乱麻。

在项目还小，代码量还小的时候，几乎所有的项目都是这样，绝不会有人会去考虑分层什么的，就好比没有人在写hello world和demo的时候，会去特地思考解耦，还有复用这些问题。

直到项目的功能逐渐变多，整个项目逐渐臃肿，最后臃肿到所有人都受不了，新建项目的时候，程序员需要手动去拷贝大量代码并测试的时候。比如说，一个新的项目需要实现文件上传功能，因为项目组成的基本单位不是模块而是方法级的，所以开发人员不得不从一堆类中分别提取方法。

模块化的思想应运而生。

模块化的主要目的是为了将通用组件抽离，如果在别的项目中需要使用这些组件，直接复用，免去了重复拷贝的麻烦。

但是模块之间的强引用导致的强耦合依然存在，牵一发动全身的烦恼依然没有解决。

这时候不免让人思索，有没有这样一种方法，可以通过弱引用的方式来访问其他模块中的对象，调用其方法，这就是组件化的思想，

组件化的想法就是将模块之间的强耦合变为弱耦合，组件之间的替换成本比以往更低。还附加了一个小技巧，就是通过修改配置文件，可以让每个模块作为一个独立的app运行，也就是图上的子工程。

但是人总是贪婪的，一旦得到了，就想要更多，一旦解决了问题，就又马上自寻烦恼，陷入新的问题。

和国外不同，国内的app更新迭代速度极快，app出现的问题往往会直接变成经济上的损失，如果每次问题都等到下个大版本来修复，这对于开发测试人员是一个极大的挑战，容错率极低（比如说现在临近交包的时候，开发人员突然测出有什么问题，能直接让测试人员哭出来，这时候就是考验同事情谊的时候了，一起加班吧~）。

所以不需要重新安装app 直接在线修复bug的需求逐渐呼之欲出，这便是插件化的思想。

插件化技术其实是处于灰色地带的一种技术。实现插件化意味着对象的跨app访问。这项技术的核心关键字是“欺骗”,利用反射和代理这两种工具创建android框架一些类的代理，然后在代理中加入自己的私货，从而实现“欺瞒的目的”。介于项目整体的结构层次和组件化类似，而且在未来，随着谷歌的限制继续加强，插件化的实际应用场景会转换到应用多开技术，这里就不特别上图了。

混合开发优势

最后的最后，是混合开发技术，总感觉所有写框架或者发明概念的人都有一种通病，发布的时候，给自己的框架或技术起一个特别霸气或者玄妙的名字，好能光凭名字把别人唬住，给人一种虽然不知道你在说什么，但是总感觉很历害的感觉。

混合开发技术就是采用原生和web两者结合的方式来构建移动应用，因为页面是基于html写的，所以在一定程度上是跨平台的。

如上图，混合开发的其中一种思路是利用各个平台都一定会提供视图用以显示网页的原理。如果需要显示页面，可以直接加载储存在本地的html文件也可以直接通过url加载服务器端网页界面，如果填充的内容的内容需要通过平台本地的接口进行定义，内容可通过在android或者ios平台定义原生接口并转化成js注入到html，然后在html中调用即可。

对于混合开发，按照我翻阅书籍，阅读博客所了解到的，这项技术毫无疑问是未来的大势所趋，因为其所独有的优势，即上手难度低，应用安装包体积小，项目更新迭代速度快等。

虽然现在依然存在一些缺陷，但是凭借千千万万程序员的不屑努力，这些缺陷的客服也是早晚的事情。

混合开发常见思路之一还是基于webview的实现，所有的界面都在html界面中加以展现，说到底只是缺乏一个载体而已，选择网页显示终归只是一种面为其难的手段罢了，当然这个仅仅是我的想法，也有被打脸的可能性。

去年开始火起来的flutter就是对应的替代品，基于dart语言定义界面视图以及功能逻辑，而具体的实现通过在android和ios平台上编写插件的方式予以实现，虽然当前一堆极客大佬都在纷纷贡献开源库，阿里也为flutter专门写了学习demo和成品项目，跟随聪明人的脚步可以在一定程度上降低自己的成本，还是很有道理的。

但是这终归还是处于发展期的技术，我之前尝试参照开源项目写了一个demo，光是ide的坑都踩了很久，就是上面这个项目，实现本身其实真的挺有趣的整个项目400行代码不到，右边是这个项目的源码地址，在github站内有这个项目的实现步骤，这个项目虽然很小，但是相当高大上，记得好像是去年东京开展的flutter交流会上，官方给出的demo就是这个，有兴趣也可以去看看。