Category Archives: 杂谈

Android共享热点IP问题引发的“血案”

今天一朋友问Android手机的Wi-Fi共享热点IP能不能修改,他那边一直是192.168.43.*,自己记得在设置里面没有这个选项,便回复了他不能修改。后来猜测Android源码可能为了刻意避开常用局域网路由器192.168.0/1/2.*段,特意设置的其他网段,但会不会存在与基站代理在一个网段后冲突自我协调的机制呢?(当然这个可能性很低,一般基站的代理服务器分配的都是10.*段的内网地址),既然有了这个问题,那索性看看源码怎么设置的。

  • 涉水

首先想到的是到StackOverFlow上看看有没有相关问题,搜索得之,

http://stackoverflow.com/a/31238229/4865380

确实有人提到修改Hotspot网关的问题,给出的具体源码是在WiFiStateMachine.java中硬编码了192.168.43.1这个网关地址,这就解释了为什么共享出去的IP地址都是192.168.43.*了。手机用户想修改它,duang然是不可能了。

  • 挣扎

从AOSP的master中去查找上文提到的platform/framework/base/wifi/java/android/net/WiFiStateMachine.java却消失了踪影,寻寻觅觅发现已经被移到platform/framework/opt/net/wifi/service/java/com/android/server/wifi/WiFiStateMachine.java。一看就对源码分析不熟悉,这些模块搬家的消息都不知道,其实从5.0之后opt/net/wifi之后就有了,部分代码被迁移到这里。

但是,但是,这个文件里面再也没有发现startTethering()方法,而且硬编码的代码也被移除了,难道5.0之后热点网关IP的配置又被更改了?继续跟踪文件diff发现有一次提交提到AP:

https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/d4f347f7de30834317dd1561dc806eccb1c4f277

这次提交说明有关于AP热点配置在WiFiStateMachine.java中的代码被迁移到SoftAPManager,然后通过SoftAPManager来集成,同时也提到了AP这块代码放在WiFiStateMachine代码不够清晰。

  • 继续挣扎

既然知道了代码迁移过程,那就需要跟着去寻找SoftAPManager。这个文件和WiFiStateMachine.java在同一包下,打开文件一看还是没有发现对于IP地址的硬编码部分,只能再次寻求log,这个文件的修改历史记录比较少,其中最老的一条对应于上文提到的AP状态管理通过SoftAPManager。通过历史查看这次修改发现了从WiFiStateMachine.java迁移过来的硬编码IP地址的代码。既然在创建时代码还存在,那么次新一条的历史记录就更加让人着迷了:

时隔上次迁移到SoftAPManager.java的三个月后,这块逻辑又要被搬家了,归宿就是Tether模块,这么一波三折到底是Android源码,修改的简直是猝不及防。

  • 上岸

上面提交记录中,提到的Tethering&TetherInterfaceStateMachine在platform/frameworks/base/services/core/java/com/android/server/connectivity/下面,关于硬编码的部分被迁移到TetherInterfaceStateMachine.java

硬编码IP的方式并没有改变,至此终于将代码的变化追踪完了,结果还是一套硬编码方式。当然乐在于真正找到了答案。

Android 物联网初探

Android OS作为现今智能手机操作系统的老大,对智能设备的流行起到重要作用,从手机、平板到TV、手表、汽车等等,无处不在,无所不包,已然是现实意义的便携式设备OS的代表,虽然不同的设备厂商各怀鬼胎、高度定制,但不可否认Android OS确实推动了产业的迅速发展。随着智能设备的微型化和物联网的发展,Android团队也为我们带来了在物联网领域的又一力作-Android Things。与Android Wear、Android Auto一样,Android Things同样承袭了不开源的路子,预计后续开源的可能性也比较低。

Google在物联网领域主要有两方面:Android ThingsWeave

Android Things(原名为“Brillo”)是基于Android OS面向终端设备的一套定制化OS,旨在为了解决异构SoC物联网设备、不同传感器的数据处理等提出的一套解决方案,开发者只需要关注上层应用级别的数据传输和处理,同时还支持自定义传感器等元件的驱动。

Weave主要解决物联网对于后端数据传输和设备交互的需求,通过Google 的基础设施来采集、传输、交换、分析物联网的海量数据,同时联合其他厂商定义了一系列操纵设备指令使得设备可以通过Google Assistant这样的语音交互助手来完成对物联网设备的操控。

Android Things基于Android OS,在软件架构上没有太大的改动。

Android OS Architecture

Linux KernelHALNative C/C++ LibrariesAPI Framework沿袭了原有的架构和代码。在Framework同一层级上增加了Google Services(Google Mobile Services),这一模块是Google对Android设备提供完整移动服务的核心,在国内的Android手机上由于不可抗拒的原因无法提供服务,如果有幸能够买到Nexus、Pixel系列的手机,其实这些手机ROM的软件架构于此基本一致。除此之外还包含有一套IoT设备专有的支持库,它扩展了Android核心Framework API,以此来支持更多的传感器或者其他手机上不存在的硬件设备。

与手机平板相比,在App层面上有一个重大的区别,那就是Android Things的单应用运行模式。这意味着IoT设备在开机启动后第一个运行的应用就是当前开发的应用,即刻提供服务,像手机的电话、通讯录、日历、相机、Launcher等系统应用在此平台下都不再存在,这对开发者来说可能是一大变化。

Android Things Architecture

Android Things提供了对于物联网设备无差异的支持,但对于不同设备制造商、不同类型的传感器的数据传输、交换还是存在着巨大的鸿沟,这就是Weave存在的意义。Weave被定义为一个物联网的通信平台。不同OEM生产的物联网设备嵌入Weave SDK,然后通过Google Cloud基础设施与Weave服务器之间进行数据交换和收集。Weave联合一部分厂商定义了许多设备可操纵参数,比如灯的开关亮度、插座的开关、空调通风量等等,同时约束了一系列的设备注册流程和安全协议,通过这一系列的操作,可以让OEM厂商只需要关注设备本身以及提供的特定服务而无需关注设备与服务器之间的交互和数据传输。说到底这是一套完整的物联网数据交换解决方案,Google的野心也并非仅此而已,Google Cloud的基础设施,人机交互的指令定义,Google Assistant的原生支持,通道与终端的完整控制使得Google不再像Android OS一样脱缰狂奔,而是牢牢把握在自己手中。

Weave虽好,OEM厂商对此的支持又如何?这还是一个疑问,当前的SDK只支持Linux、高通、Marvell的特定芯片,同样的疑问还有,无法访问Google Services的中国用户怎么办?联想到之前推出的Android Wear中国版,或许是一个选择。

Java WEB系统微服务化迁移

  1. Docker
  2. 微服务
  3. Spring-Boot

支撑互联网公司运行的庞大后端服务系统经历了原始的BS架构设计、前后端分离、模块化组件、系统分层设计的进化,从计算资源的虚拟化到今天容器技术的应用,互联网一直在朝着资源高效配置、分布式集群服务的方向进发。

Docker作为当下最流行的容器化技术,相比于运行在实体物理机上的虚拟机技术,它具有轻量级资源隔离、快速部署、持续交付、版本控制、 可移植、开放技术等特点。

如果采用虚拟机技术去部署一套系统,需要几个步骤:

1、分配物理资源(CPU\内存\网络)

2、开机启动运行

3、安装系统运行时支撑环境(模版)

4、发布生产系统

5、上线。

采用Docker需要如下几个步骤:

1、拉取Docker Image

2、发布生产系统

3、上线

相比来看可能就会发现,Docker相当于把最繁琐最耗时的工作帮助我们解决了。Docker运行在(特定)操作系统之上,只需要一条命令即刻启动;通过Docker Image将运行时配置、依赖管理、版本管理集成一个Dockerfile描述文件中标准化,快速解决原始虚拟机技术中的1、2、3步骤。如果再搭配Google出品的Kubernetes容器管理工具更加得心应手。

与Docker并行出现一个架构模式-微服务,它并不是一种全新的架构体系,更确切的说是一种架构的思考。在经历了模块化、组件化、服务化之后,系统的架构设计实现复杂、服务调用关联度高等问题困扰着一个系统的稳定性和开发难度。微服务是在原有的服务治理的基础上,将原有系统服务的粒度进行再切分使得服务之间的耦合性降至最低,同时不依赖于过多的外部运行时环境,对外暴露的输入输出可能只是一个JSON、XML数据集,可以实现大规模的快速部署运行。这些特点与Docker的容器化优势不谋而合,这也是当前微服务实践采用比较多的一种方式。

Spring Boot在微服务概念出现之前已经发布了有一段时间,但并没有大行其道,大家对于Java Web的项目更倾向于原有Servlet Container Server的部署模式。随着微服务的出现,Spring Boot再次引起了大家的注意,同时Spring在被收购后也在朝着云服务商的方向上进发,推出了自己的云服务平台。

相比一切全新的服务系统,遗留的Java WEB系统如何进行更好的迁移使用微服务,是需要考虑的一大问题。当前的项目中框架采用了Freemarker+Spring+Hibernate的方式,Spring的配置是原有的XML配置方式,与Spring-Boot推荐的注解配置相比,迁移难度较大。

Spring-Boot使用注解配置剥离了XML的配置方式,使用内嵌式Servlet Container(Jetty\Tomcat\Undertow)来实现服务的HTTP通信、监控、交互。与此相对照,能否维持XML配置不变,仅使用内嵌Servlet Container来提供服务呢?答案是:可以。

采用Tomcat Embed作为默认的Servlet Container,通过Tomcat Bootstrap中Host、Port配置来实现HTTP服务,指定WEB路径的方式来提供Spring XML配置部分和其他WEB资源,这样就基本实现了原有Java WEB系统的服务化迁移。

在迁移测试过程中,也遇到了几个坑。

1、Gradle编译工具对JAR包的支持度不够完善,需要额外的插件来实现Eclipse FatJar的功能。

2、如果自定义Jar合并时,一定要注意Spring Schema文件的合并。在不使用插件的情况下,会导致spring schema XSD文件的丢失。需要在插件支持下通过tramformer来合并。

如果单独使用Maven来打包之需要通过修改POM文件来实现。

相关资料     Docker Spring-Boot Gradle FatJar Plugin Tomcat Embed