去年冬天，源码我在一个安卓开发群里看到有人发了个截图：一个不到200KB的源码APK，界面简陋得像是源码2013年的产物，但功能却出奇地完整——自动签到、源码数据抓取、源码本地存储，源码甚至还有个简单的源码图表展示。底下有人问：“这用什么写的源码？”发图的人回了两个字：“iapp。”
那是源码我第一次认真去翻iapp的源码。说实话，源码打开它的源码项目文件夹时，我有点恍惚。源码没有gradle，源码没有AndroidManifest.xml里那一长串权限声明，源码取而代之的源码是一堆后缀为.iyu和.mjava的文件。目录结构简单到近乎粗暴：一个main.iyu管界面，一个mjava文件夹放逻辑，资源文件直接扔在res里，连assets都省了。
iapp的源码本质上是一套“翻译层”。你写的iyu代码，最终会被它自己的编译器转成Java，再调用Android原生API。但有意思的是，它把很多繁琐的东西藏起来了。比如你要在界面上放个按钮，原生写法得先定义Button类，再findViewById，再setOnClickListener。iapp里就三行：button b = new button()，b.setText("点我")，b.setOnClickListener(...)。语法像Java，但少了泛型、注解、匿名内部类的完整写法，甚至允许你直接写toast("hello")这种连上下文都不用管的调用。
这种设计带来的直接后果是：源码可读性极高，但可维护性极差。我见过一个用iapp写的天气查询工具，main.iyu里塞了将近800行代码，所有逻辑——网络请求、JSON解析、UI更新——全挤在一个文件里。没有函数封装，没有模块拆分，变量命名清一色是a1、a2、str、str2。你改一个功能，得先花十分钟找到对应的那几行。可偏偏就是这种“一坨”式的代码，跑起来一点问题没有，编译出来的APK只有150KB，启动速度比很多用Kotlin写的现代App还快。
iapp的源码还有个特点：它大量依赖“事件驱动”的隐式写法。比如你写onClick，不需要声明接口，直接写个function onClick()，iapp会自动把它绑到当前组件的点击事件上。这种约定优于配置的思路，让新手能在一小时内做出一个能跑的App。但代价是，你很难追踪事件的完整调用链。源码里到处都是call和goto，像极了早期BASIC的GOSUB。我甚至见过有人用goto实现循环，代码跳来跳去，读起来像在走迷宫。
不过话说回来，iapp源码的“土”恰恰是它的生命力。我在一个二手交易平台上看到过，有人专门卖iapp写的自动化脚本，5块钱一个，销量上千。买家不在乎代码结构，只在乎能不能用。有个卖家跟我说，他写了个自动刷视频的脚本，核心逻辑就20行mjava代码，用了两年都没被封。我问他不担心维护吗？他说：“维护啥？需求不变，代码就不动。真出问题了，重写一遍比读旧代码快。”
这让我想起早期Web开发时的jQuery。你当然可以用React、Vue把项目拆得清清楚楚，但有时候一个$(document).ready()加上几个click回调，就能解决所有问题。iapp源码就是安卓自动化领域的jQuery——不优雅，不现代，但足够直接。它的iyu文件里，你能看到作者边写边试的痕迹：注释掉的旧代码、临时加的toast调试、甚至直接写死的if (1==1)。这些“脏”东西，反而让源码有了种手工作坊的实感。
当然，iapp的局限也很明显。它不支持多线程，网络请求必须放在子线程里手动切换，稍不注意就ANR。它的UI组件库停留在Android 5.0时代的审美，想做个圆角按钮都得自己画XML。更麻烦的是，iapp的源码几乎无法迁移——你想转成Kotlin？基本等于重写。但换个角度想，那些用iapp写脚本的人，本来也没打算做个“产品”。他们要的是“今天下午能跑起来的东西”。
我电脑里现在还存着那个200KB的APK源码。偶尔翻一翻，看到main.iyu里那些直白的if...else和toast("成功了")，会觉得挺亲切。它不跟你谈架构，不跟你讲设计模式，就是把想法直接翻译成能点的按钮和能跑的代码。这种粗糙，在越来越复杂的开发生态里，反而成了一种稀缺品。