Architecture of I19tSDK AIDLs

摘要

在深度学习的过程中，数据的采集和标注是非常头疼和重要的一个部分。通过纯工人的方式来做费时费力，因此，如果在条件允许的情况下，我们可以通过市面上一些已经存在的识别软件来尝试对数据做标注（可以通过调整置信率来提高标注的准确度），甚至可以采取不同识别软件/模型做交叉验证，进一步确保标注的准确度。
但是，收集数据本身也是一个资源受限的问题，在实际过程中，我们想到了通过使用DCGAN来学习以标注的数据，然后生成出一些具有相同标签（分布）的伪数据，从而达到拓展标注数据集的目的。
最后，利用原始数据+伪数据再去进行模型训练，就可以获得一些“比较好”的预期了。
本文会基于数字识别这样一个场景，给出一个整套的工程化操作过程。

摘要

目的

如何利用已有模型，针对现有数据集进行retrain，在短时间内获得还不错的模型。
本文是从工程角度来阐述整个配置/运行/训练的过程，至于推导原理和模型介绍等会另外开文。
本文是一篇基于工程实作的流水科普文，看完这篇文章，你会：

• 明白tensorflow retrain的大概原理
• 知道了一个叫做inception（感知）模型
• 大概了解了retrain为什么可以生效
• retrain一个模型大概需要做哪些事情

同时，你仍旧不会知道：

View-Window-Surface

前言

本文打算从Root View的建立出发，呈现View，Window，Surface之间的联系。
从而厘清这三者之间的不同，加深对Android Graphic系统的理解

V-W-S简介

• View:android中最基本的UI组件，会占据屏幕上的一席之地并可以处理一些基本事件。

  This class represents the basic building block for user interface components. A View
  occupies a rectangular area on the screen and is responsible for drawing and
  event handling. View is the base class for widgets, which are
  used to create interactive UI components (buttons, text fields, etc.).

• Window:Window是top View的容器，这里的top view我们一般都是说ViewRoot。

  Window的概念在Android中比较抽象，广义上，被认为是一个App对应了一个window，狭义上，Window实际又对应了
  ViewRoot，对于WindowManagerService来说，如何呈现/管理App端的显示，都是通过Window来实现的

• Surface：Surface可以认为是一块提供绘制的buffer，所有View的修改，最终都会被统一反馈到Surface上。

  每个ViewRoot都会有一个真实的surface变量，View的所有操作会反馈到这块Surface。这块Surface也即SurfaceFlinger
  的某一个composer对象，因此只有操作到了ViewRoot中的Surface，屏幕上才会有变化
  注意：此处的Surface并不是SurfaceView，SurfaceView本质上还是一个View，注意区分

  阅读全文 »

AIDL简介

AIDL：AIDL=Android Interface definition language（Android 接口定义语言），与您可能使用过的其他 IDL 类似。 您可以利用它定义客户端与服务使用进程间通信 (IPC) 进行相互通信时都认可的编程接口。 在 Android 上，一个进程通常无法访问另一个进程的内存。 尽管如此，进程需要将其对象分解成操作系统能够识别的原语，并将对象编组成跨越边界的对象。 编写执行这一编组操作的代码是一项繁琐的工作，因此 Android 会使用 AIDL 来处理。

摘自google开发者文档：https://developer.android.com/guide/components/aidl.html?hl=zh-cn

前言

debug的时候我们有时候会使用shared uid，对于系统签名的应用来说，就需要重新sign

前言

Android Framework层的代码非常多，在进行frameworks开发＆Debug时，如果只能依靠log输出，效率比较低下，而假定可以像普通应用一样进行单步Trace的话，相信效率就会高不少。
本文基于Android Studio，给出了一种可以单步调试Android Framework的简便方法。
如果讲的更通俗一点：

本文提供了一种，“有源码，但是无法通过Android Studio编译”的工程的调试方法

比如原生的那些应用们，Launcher3，SystemUI，Email，XXXXX
比如ActivityManagerService，PackageManagerService，XXXXX

前言

在system ui的recents中有大量使用到EventBus的地方，这里会揭示EventBus到底是什么，以及EventBus是如何运作的。
从一个朴素的角度来说，EventBus其实是一个Subscriber-Event的机制，对于Sbuscriber来说，它们的回调函数会在适当的时候被Event所激活。

前言

Android N引入了分屏的概念，有两个入口：

• 单击多任务按键，通过长按拖动多任务界面中的task到顶部dock区域后释放。
• 进入到某个应用（非Launcher）后，长按多任务键

对应的，另外一个区域的应用，则是通过点击多任务中的图标来启动。

前言

作为一个插件框架，VirtualApp自然会使用到大量的hook。
本文会解析在VA中，那些hook是如何用的，用到了哪些技术，flow是怎样的。

技术储备

• java泛型
• java反射
• 接口编程
• java动态代理
• java注解编程

以上几个知识点希望大家可以在看文章之前先大概了解一下，不然后面看代码会比较累。
后面的文章部分不会对上述的知识点做二次展开，仅仅以理顺整个Hook flow为主。

前言

作为一个插件框架，VirtualApp自然会使用到大量的hook。
本文会解析在VA中，那些hook是如何用的，用到了哪些技术，flow是怎样的。

技术储备

• java泛型
• java反射
• 接口编程
• java动态代理
• java注解编程

Android Studio Instant Run

By Howie.Hxu

什么是InstantRun

Android Studio2.0推出的一项新功能，google的官方介绍：请看这里
可以实现apk快速部署（快速安装），还有什么冷启动，热插拔之类，简单来说就是代码修改完成了，targe设备马上就显示不同了。
这里还有一篇helloworld式的InstantRun中文介绍：传送门
顺带提一下，从InstantRun的技术角度出发，它也可以算的上是插件化开发的一种，热加载/热修复（动态加载了新的dex or dex拆分）。

研究的契机

最早是想写一个multi dex的项目demo，用来泡DroidPlugin的框架，想尝试看看能否加载起来。
而在各种机缘巧合下，android studio又升级到了2.2，然后就很悲催的发现demo fail。
从异常的log来看则是各种class找不到。而且一眼看过去都是一些非常明显的错误。

主activity居然都没有找到。而主activity则是在application构造的时候被创建的，所以..看起来问题很严重。

Begin Of Process

By Howie.Hxu

前言

在android的世界中，google为我们屏蔽掉了很多操作系统层面的细节。
以至于很多人都习惯性提到android系统，android架构，android程序。
“然鹅”，android其本身只是跑在linux上的一个进程而已，对于linux的世界而言：

android仅仅是一个跑在user space的进程罢了

只是它比起其他的hello world拥有了更多的变化，更多的封装以及更多的child process。
从init进程开始，经历zygote的演化，到各个service的建立，最终为service manager　
& system_server所统一。整个android构建了一个基于linux的神奇世界，而像activity，
service，content provider，boardcast通过intent这条纽带，把linux下process，user
等概念完美地保护了起来。

本文主要想通过分析“process在android中是如何启动”，从而看看android世界中的“process”

ClassLoader

By Howie.Hxu

前言

关于ClassLoader的介绍，可以参考之前提到的：
Android动态加载基础 ClassLoader工作机制
另外文章会提到，android中classloader都是采用了“双亲委派机制”，关于这一点可以参考：
Parents Delegation Model

简单总结一下：
对于android中的classloader是按照以下的flow：

loadClass方法在加载一个类的实例的时候:
会先查询当前ClassLoader实例是否加载过此类，有就返回；
如果没有。查询Parent是否已经加载过此类，如果已经加载过，就直接返回Parent加载的类；
如果继承路线上的ClassLoader都没有加载，才由Child执行类的加载工作；

这样做的好处：

首先是共享功能，一些Framework层级的类一旦被顶层的ClassLoader加载过就缓存在内存里面，以后任何地方用到都不需要重新加载。
除此之外还有隔离功能，不同继承路线上的ClassLoader加载的类肯定不是同一个类，这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。这也好理解，一些系统层级的类会在系统初始化的时候被加载，比如java.lang.String，如果在一个应用里面能够简单地用自定义的String类把这个系统的String类给替换掉，那将会有严重的安全问题。