AiPublish

提供一个 token 鉴权的发布接口：POST /api/publish（兼容 POST /action/ai-publish）。

安装

1. 将插件目录放到：usr/plugins/AiPublish
2. 在 Typecho 后台启用 AiPublish

3. 在插件设置中配置：

   • API Token：接口鉴权密钥
   • 默认作者 ID：草稿作者（通常为管理员 ID）

接口

• 方法：POST
• 路径：/api/publish
• 兼容路径：/action/ai-publish

• Header（二选一）：

  • Authorization: Bearer <token>
  • X-API-Token: <token>

可用 GET 做健康检查（不需要 token）：

curl 'https://your-site.com/index.php/action/ai-publish'

正常会返回：

{"ok":true,"plugin":"AiPublish","route":"alive"}

请求体（JSON）

{
  "title": "文章标题",
  "content": "正文内容（支持 Markdown）"
}

也支持在请求体里额外传 token 字段。

成功响应

{
  "ok": true,
  "cid": 123,
  "status": "draft",
  "title": "文章标题"
}

调用示例

curl -X POST 'http://115.190.110.58/api/publish' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer ' \
  -d '{
    "title": "AI 自动写作草稿",
    "content": "这是一篇由 AI 通过 API 创建的草稿。"
  }'

未开启伪静态时请使用：

curl -X POST 'http://115.190.110.58/index.php/action/ai-publish' \
  -H 'Content-Type: application/json' \
  -d '{
    "token": "",
    "title": "AI 自动写作草稿",
    "content": "这是一篇由 AI 通过 API 创建的草稿。"
  }'

或继续使用 Header 传 token：

curl -X POST 'http://115.190.110.58/index.php/action/ai-publish' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer ' \
  -d '{
    "title": "AI 自动写作草稿",
    "content": "这是一篇由 AI 通过 API 创建的草稿。"
  }'

常见问题

1. 返回 Sorry but the page you are trying to view does not exist.
   停用并重新启用插件后再测试 https://your-site.com/index.php/action/ai-publish。
2. 返回 Unauthorized
   通常是 token 不一致，或请求头缺少 Bearer 前缀。

Android 中的内存泄漏（Memory Leak）本质上是：长生命周期的对象持有了短生命周期对象（如 Activity/Fragment）的引用，导致短生命周期对象无法被垃圾回收器（GC）回收。

以下是 Android 开发中常见的内存泄漏类型、原理、示例以及检测和解决方法的系统性整理。

一、 Android 常见内存泄漏类型

1. 静态变量导致的泄漏 (Static Variable)

• 原理：静态变量存储在方法区，其生命周期与 ClassLoader（通常等同于应用进程）一致。如果静态变量持有了 Activity 或 View 的引用，该对象将永远无法释放。

• 例子：

  public class MyUtils {
      // 错误：静态变量持有了 Activity 的 Context
      private static Context sContext;
  
      public static void setContext(Context context) {
          sContext = context;
      }
  }
  // 在 Activity 中调用 MyUtils.setContext(this); 导致 Activity 泄漏

• 修正：尽量不存 Context。如果必须存，使用 context.getApplicationContext()，或使用 WeakReference。

2. 单例模式导致的泄漏 (Singleton)

• 原理：单例的生命周期贯穿整个应用。如果单例初始化时传入了 Activity 的 Context 并一直持有，该 Activity 就无法销毁。

• 例子：

  public class AppManager {
      private static AppManager instance;
      private Context context;
  
      private AppManager(Context context) {
          this.context = context; // 如果传入 Activity，泄漏发生
      }
  }

• 修正：构造函数中强制转换：this.context = context.getApplicationContext();。

3. 非静态内部类 / 匿名内部类 (Inner/Anonymous Class)

• 核心原理：在 Java 中，非静态内部类和匿名内部类会隐式持有外部类（如 Activity）的强引用。如果这些内部类对象的生命周期比外部类长，外部类就无法回收。

• 类型 A：Handler

  • 例子：

    // 匿名内部类 Handler 持有 Activity 引用
    private final Handler mHandler = new Handler() { ... };
    // 发送延时消息，消息未处理完，Activity 关闭也无法回收
    mHandler.sendEmptyMessageDelayed(0, 10000);

  • 修正：使用 静态内部类 + WeakReference，且在 onDestroy 中调用 mHandler.removeCallbacksAndMessages(null)。

• 类型 B：Thread / AsyncTask

  • 例子：

    new Thread(new Runnable() { // 匿名内部类 Runnable 持有 Activity
        @Override
        public void run() { SystemClock.sleep(20000); }
    }).start();

  • 修正：定义为静态内部类，或在 Activity 销毁时中断线程。

• 类型 C：双括号初始化 (Double Brace Initialization)

  • 原理：new HashMap() {{ ... }} 实际上创建了一个 HashMap 的匿名子类。这个子类会隐式持有外部类（Activity）的引用 this$0。如果这个 Map 被传递到 Activity 外部（如静态缓存、单例配置），Activity 就会泄漏。

  • 例子：

    // 看起来是语法糖，实际是隐形炸弹
    public void initData() {
        Map<String, Object> map = new HashMap<String, Object>() {{
            put("key", "value"); // 这是一个匿名内部类的实例初始化块
        }};
        // 如果这个 map 被传给单例或静态变量，Activity 泄漏
        GlobalCache.getInstance().save(map);
    }

  • 修正：

    • 使用普通写法：Map<String, Object> map = new HashMap<>(); map.put(...);
    • 使用 Kotlin：val map = mapOf("key" to "value")
    • 使用静态工具方法：Map.of(...) (Java 9+)

4. 资源未关闭 / 未注销 (Resource Not Closed)

• 原理：使用了系统资源或注册了监听器，使用完毕后未关闭或注销。

• 常见场景：

  • BroadcastReceiver：忘记 unregisterReceiver。
  • IO 流 / Cursor：数据库查询或文件读写后未 close()。
  • EventBus / RxJava：onDestroy 中未取消订阅。
  • 属性动画：无限循环动画未调用 cancel()，View 被持有，导致 Activity 无法释放。

5. WebView 泄漏

• 原理：WebView 系统实现复杂，会在 native 层持有 Context，且往往不随 Activity 销毁而立即彻底释放。

• 修正：

  • 不在 XML 中定义，改为代码动态 new WebView(getApplicationContext())。
  • 销毁时：先从父容器 removeView，加载空内容 loadUrl("about:blank")，最后 destroy()。
  • 多进程方案：将 WebView 放在独立进程，销毁时 System.exit(0)。

二、 如何发现内存泄漏

1. LeakCanary (最推荐)

• 介绍：Square 开源的检测库。
• 原理：自动监测 Activity/Fragment 的销毁。若销毁后对象仍驻留堆内存，触发 GC 并分析引用链，通知开发者。
• 优点：集成简单，实时报警，无需手动分析。

2. Android Studio Profiler (Memory Profiler)

• 操作：

  1. 运行 App，打开 Profiler -> Memory。
  2. 操作 App 后手动触发 GC。
  3. 点击 "Dump Java Heap"。
  4. 在结果中筛选 Activity 类，查看 Count（实例数）。若 Activity 已关闭但 Count > 0 且有关联引用，即为泄漏。

3. Lint 静态检查

• Android Studio 自带的代码检查工具，能在编写代码时提示（例如：提示 "This Handler class should be static or leaks might occur"）。

三、 总结：解决之道

解决的核心在于切断长生命周期对象对短生命周期对象的引用。

1. Context 敏感度：

   • 原则：凡是跟 UI 渲染无关的（工具类、单例、全局配置），一律使用 Application Context。
   • 警惕：严禁静态变量直接持有 Activity 或 View。

2. 内部类规范：

   • 强制：Activity 中定义的 Handler、Thread、Runnable 尽量使用 静态内部类 (static class)。
   • 引用：如果静态内部类需要引用 Activity，必须通过 WeakReference。
   • 拒绝：禁止在 Activity 中随意使用 new ArrayList() {{ ... }} 这种双括号写法传递数据给外部。

3. 生命周期对齐：

   • 成对出现：register 对应 unregister，bind 对应 unbind。
   • 清理战场：onDestroy 中必须移除 Handler 消息、取消 RxJava 订阅、停止动画。

4. 工具常驻：

   • 开发阶段集成 LeakCanary，将内存泄漏视为 Bug 处理，发现即修。

在线生成图网站

软件设计领域图表类型

1. 类图 (Class Diagram)

• 用途：展示系统的静态结构

• 展示内容：

  • 类及其属性、方法
  • 类之间的关系（继承、实现、组合、聚合、关联等）
  • 类的可见性和访问修饰符

• 适用场景：

  • 系统架构设计
  • 代码结构分析
  • 面向对象设计

2. 时序图 (Sequence Diagram)

• 用途：展示对象之间的交互顺序

• 展示内容：

  • 对象之间的消息传递
  • 方法调用顺序
  • 时间顺序
  • 同步/异步调用

• 适用场景：

  • 业务流程分析
  • 系统交互设计
  • 性能分析

3. 组件图 (Component Diagram)

• 用途：展示系统的物理结构

• 展示内容：

  • 系统组件
  • 组件间依赖
  • 接口定义
  • 部署关系

• 适用场景：

  • 系统架构设计
  • 模块划分
  • 部署规划

4. 活动图 (Activity Diagram)

• 用途：展示业务流程

• 展示内容：

  • 活动流程
  • 决策点
  • 并行活动
  • 条件分支

• 适用场景：

  • 业务流程设计
  • 工作流分析
  • 复杂逻辑梳理

5. 状态图 (State Diagram)

• 用途：展示对象状态变化

• 展示内容：

  • 对象状态
  • 状态转换
  • 触发条件
  • 状态行为

• 适用场景：

  • 状态机设计
  • 生命周期管理
  • 复杂状态分析

6. 用例图 (Use Case Diagram)

• 用途：展示系统功能需求

• 展示内容：

  • 系统功能
  • 用户角色
  • 功能关系
  • 系统边界

• 适用场景：

  • 需求分析
  • 功能规划
  • 用户交互设计

7. 部署图 (Deployment Diagram)

• 用途：展示系统部署结构

• 展示内容：

  • 物理节点
  • 部署组件
  • 网络关系
  • 硬件配置

• 适用场景：

  • 系统部署规划
  • 硬件配置设计
  • 网络架构设计

8. 包图 (Package Diagram)

• 用途：展示代码组织结构

• 展示内容：

  • 包结构
  • 包依赖
  • 模块划分
  • 代码组织

• 适用场景：

  • 代码架构设计
  • 模块划分
  • 依赖管理

9. 对象图 (Object Diagram)

• 用途：展示系统在特定时刻的对象状态

• 展示内容：

  • 对象实例
  • 对象关系
  • 属性值
  • 运行时状态

• 适用场景：

  • 系统快照分析
  • 对象关系验证
  • 运行时分析

10. 通信图 (Communication Diagram)

• 用途：展示对象间的消息传递

• 展示内容：

  • 对象关系
  • 消息传递
  • 交互顺序
  • 对象链接

• 适用场景：

  • 对象交互分析
  • 消息流设计
  • 系统行为分析

选择图表类型的考虑因素

1. 要表达的内容（结构、行为、关系等）
2. 目标受众（开发人员、业务人员、架构师等）
3. 设计阶段（需求分析、架构设计、详细设计等）
4. 具体场景（系统设计、业务流程、部署规划等）

项目建议

对于您的项目，建议使用：

1. 类图展示领域模型
2. 时序图展示业务流程
3. 组件图展示系统架构
4. 活动图展示复杂业务逻辑

参数root
当参数root为null时，attachToRoot参数无效。且生成的view会丢失布局文件中的LayoutParams
当参数root不为null时，生成的view会根据root类型来保留布局文件中对应的LayoutParams

参数attachToRoot
attachToRoot为true时，返回的view就是root
attachToRoot为false时，返回的view是跟布局生成的view

问题：一个viewpager2使用了FragmentStateAdapter，当系统配置发生变化（切换横竖屏、切换深色模式、切换语言），会多出fragment实例，每切一次就会多一次。查看日志每次切换后获取fragment的时候，都会重新走FragmentStateAdapter的createFragment。而之前已经生成的fragment都会重建。所以造成上面的现象和问题。

原因：这个viewpager2是动态通过代码new创建的，改成直接写在xml布局中就正常了（一般写在xml中都会加一个id的）

根因：只有绑定id的viewpager2才能正常同步fragment。从xml加载的也需要加id才能。代码动态创建的，设置id后也能正确。

private void ensureFragment(int position) {
    long itemId = getItemId(position);
    if (!mFragments.containsKey(itemId)) {
        // TODO(133419201): check if a Fragment provided here is a new Fragment
        Fragment newFragment = createFragment(position);
        newFragment.setInitialSavedState(mSavedStates.get(itemId));
        mFragments.put(itemId, newFragment);
    }
}

FragmentStateAdapter源码显示，只有mFragments不包含的时候，才会从createFragment拿

@Override
public final void restoreState(@NonNull Parcelable savedState) {
    if (!mSavedStates.isEmpty() || !mFragments.isEmpty()) {
        throw new IllegalStateException(
                "Expected the adapter to be 'fresh' while restoring state.");
    }

    Bundle bundle = (Bundle) savedState;
    if (bundle.getClassLoader() == null) {
        /** TODO(b/133752041): pass the class loader from {@link ViewPager2.SavedState } */
        bundle.setClassLoader(getClass().getClassLoader());
    }

    for (String key : bundle.keySet()) {
        if (isValidKey(key, KEY_PREFIX_FRAGMENT)) {
            long itemId = parseIdFromKey(key, KEY_PREFIX_FRAGMENT);
            Fragment fragment = mFragmentManager.getFragment(bundle, key);
            mFragments.put(itemId, fragment);
            continue;
        }

        if (isValidKey(key, KEY_PREFIX_STATE)) {
            long itemId = parseIdFromKey(key, KEY_PREFIX_STATE);
            Fragment.SavedState state = bundle.getParcelable(key);
            if (containsItem(itemId)) {
                mSavedStates.put(itemId, state);
            }
            continue;
        }

        throw new IllegalArgumentException("Unexpected key in savedState: " + key);
    }

    if (!mFragments.isEmpty()) {
        mHasStaleFragments = true;
        mIsInGracePeriod = true;
        gcFragments();
        scheduleGracePeriodEnd();
    }
}

然后可以看见除了ensureFragment，只有在restoreState这个地方mFragments才会存fragment。关键是要从savedState拿到fragment。

继续跟源码可以发现adapter的restoreState方法是在viewpager2的restorePendingState方法中被调用的，其中传递的参数是mPendingAdapterState，继续看看mPendingAdapterState哪儿来的

@Override
protected void onRestoreInstanceState(Parcelable state) {
    if (!(state instanceof SavedState)) {
        super.onRestoreInstanceState(state);
        return;
    }

    SavedState ss = (SavedState) state;
    super.onRestoreInstanceState(ss.getSuperState());
    mPendingCurrentItem = ss.mCurrentItem;
    mPendingAdapterState = ss.mAdapterState;
}

mPendingAdapterState来自于viewpager2的onRestoreInstanceState。

protected void dispatchRestoreInstanceState(SparseArray<Parcelable> container) {
    if (mID != NO_ID) {
        Parcelable state = container.get(mID);
        if (state != null) {
            // Log.i("View", "Restoreing #" + Integer.toHexString(mID)
            // + ": " + state);
            mPrivateFlags &= ~PFLAG_SAVE_STATE_CALLED;
            onRestoreInstanceState(state);
            if ((mPrivateFlags & PFLAG_SAVE_STATE_CALLED) == 0) {
                throw new IllegalStateException(
                        "Derived class did not call super.onRestoreInstanceState()");
            }
        }
    }
}

可以看见只有当有id的时候才会执行onRestoreInstanceState