本文由鸟哥笔记春羽计划出品
本文2766字，阅读时间约7分钟
想必大部分同学在运营APP的时候都会涉及到拉新的问题，而对于APP用户拉新，又不得不说到ASO优化。
什么是ASO优化？
ASO是“应用商店优化”的简称。ASO(App Store Optimization)就是提升你的APP在各类APP应用商店/市场排行榜和搜索结果排名的过程。
一款APP想要在搜索平台里面获得高的排名，提高应用下载量，提高品牌知名度，就离不开ASO优化。
ASO优化的主要影响因素
1. 应用名称
应用名称是由主标题和副标题组成的，显而易见，这是对应用排名影响最大的因素之一。
但是对于应用名称，却不像网站的title标签那么容易修改，很多时候名称是早就定好的，很难修改，尤其是主标题。但是副标题其实可以植入关键词，如哒哒英语APP：
可以看见哒哒英语的副标题是：少儿英语外教一对一学英语口语，那为什么选择这样一串字符作为副标题呢？
其实是跟产品的定位和关键词有关系的，哒哒英语本身就是线上少儿英语外教一对一教育，而且少儿英语、外教都是该行业的主要关键词，所以这样的副标题是可以很好的给APP提高排名。
如果你搜“少儿英语”“外教”，哒哒英语都是排名前三的，这样就能很好的给APP带来下载量。当然这也跟关键词有很大关系，后面关键词优化再说。
2. 关键词
上传应用时填写的关键词，目前应该是支持4个版本：简体中文、英文(英国)、英文(澳大利亚)、英文(加拿大)，关键字的要求是每一种语言提供100字符，这个是很重要的，详细的后面再讲。
3. 应用描述
APP的描述对于应用的推广也是极其重要的，因为用户在搜索结果列表页看到你的应用时，吸引他们点击进入详情页的就是应用的描述。
而且这个因素还将直接跟你应用的搜索结果点击率有关，而搜索结果点击率也很可能影响你的应用在该搜索结果的排名。
应用描述最好突出产品的特点，优势，一下子让用户知道你们的产品功能，吸引住用户。
像VIPKID英语，应用描述就十分详细，突出自己的品牌优势，突出自己的特点，表现产品的功能，这样用户一看就明白了，很有可能就吸引到用户从而导致下载。
4. Icon(图标)
Icon对于一款应用就好比长相对于一个人。如果想让别人对你的应用有个良好的第一印象，首先就要从设计一个漂亮的Icon开始。
图标一定要清晰、直观，突出品牌，图标设计也是感化用户的一种有效方式。而且美观漂亮的图标可能还会带来其他意想不到的好处。
如哒哒英语，图标以红色为背景，白色字体突出品牌，简洁容易记住，很好的向用户展现了产品。
5. 应用截图
毫无疑问的是，应用详情页里的截图真的会影响应用在排行榜的表现。
当用户看到你的应用截图时，能否直观的通过图片吸引用户就特别重要，往往这就可能会导致用户是否下载你的APP。
图片不宜过多也不易过少，正常3-5张就好，最好选择的图片能突出重点且容易抓住用户内心，这样的的图片作为截图会提高你的排名。
如阿卡索少儿英语，一共放了5张图片，其中第一张就是代言人：佟大为，有明星效应。
第二张图和第三张图分别表现了“情景学习”“亲子口语”的产品特点，而且连接起来则是一幅完整的图，图片展现的也是少儿英语口语交流的场景。
每一张图片突显出重点，用户一看就能明白。
6. 用户评价
这点想必大家也知道，好评对APP的推荐会起到一定作用。
我记得在之前一段时间里，苹果还提高了评论里面含有关键词的权重，导致一时间刷评论的量增多，这一点也留到后面说。
总之，好评是很重要的，侧面也反应了真实用户对产品的真实反馈。
7. 应用安装量
APP应用安装量是非常重要的因素，基本上排名靠前的APP都是下载安装量排名里数一数二的。
正因为如此，市面上才有了各种提高下载安装量的方法，而这些方法的存在说明应用安装量对于ASO优化的重要性。
上图是叽里呱啦的一个实时排名，这样的排名已经很不错了，自然而然会带来更多的下载量。
ASO优化的主要方法
1.优化.关键词
在最初上传关键词100个字符的时候，一定要根据自己产品的定位以及最热的关键词选择最适合的100个字符。
可以从品牌词、行业词、竞品词、热点词里面去选择，最前面也说了，每种语言可以组一套关键词，所以建议产品上线前最好提供的关键词弄4套，这样对关键词的覆盖量以及搜索指数>=4605的关键词有很好的提高。
这个关键词优化可能有个过程，当你每次上新版的时候，都可以适当的更新关键词，在不断的优化中，找到一套稳定的可以带来下载量的关键词。
可以借助鸟哥笔记里面的优化助手检查自己的关键词是否合理，优化助手会自动筛选一些你重复的词，提醒你替换掉提高覆盖量，这个根据你的关键词情况和经验来定。
鸟哥笔记-ASO优化助手：
http://aso.niaogebiji.com/trends/optimization 
2.积分墙
可以说积分墙在ASO优化中有着举足轻重的作用，而积分墙用的好，是可以迅速提高应用安装量，当然也会出现苹果警告甚至下架的情况，这样就得不偿失了。
补充：什么是积分墙？积分墙是在一个应用内展示各种积分任务(下载安装推荐的优质应用、注册、填表等)，以供用户完成任务获得积分的页面。
其实这时候就要特别关注关键词，尤其是能提高下载量的关键词。这里提到的是关键词其实也就是用户平时在应用商店里所搜索的词。
你每天都要去关注关键词的变化，像品牌词、行业词、竞品词、热点词你都要特别关注，更要关注的是前10名，前3名搜索指数>=4605的词，这些对你有用的。包括竞品的关键词你也要去了解，这是个慢慢积累的过程，慢慢优化出一些能给产品带来下载量的词。
比如哒哒英语，“英语口语”“vipkid”“少儿英语”等一些词，目前都是排名第二的，是很好能够带来量的。
你知道吗？排名前三名的关键词是能带来很多的量，尤其是第一名，基本是按照7-2-1的比例来分配的。所以关注排名靠前热度高的词很有必要。
3.评论
大家都知道好评对产品的重要性，不仅是用户对产品的认可，也是可以提高产品的排名。
如果在评论中有高热度的关键词也会对排名有一定的帮助，下面是VIPKID英语的部分评论，其中不乏有高热度关键词“少儿英语”“英语学习”等。
对于如何提高用户的评论以及高质量的评论，有以下三个小的建议：
一是做好产品，让用户有好的体验自然而然会有好评；
二是产品内增加评论的引导，很多产品都有评论的功能，但是没有加强引导，所以这里大家可以想想是否可以结合活动引导用户进行反馈评论；
三是刷评论，苹果有提高评论的权重，尤其评论里含有关键词的权重，所以评论里最好是有关键词的，这样是可以提高应用搜索量的。
APP推广找鸟哥笔记！
你的APP是否也面临流量困境？鸟哥笔记整合ASO积分墙、信息流、SEM等优质渠道资源，为您提供一站式APP推广解决方案，助您抢夺海量用户。详情请加微信：ngbjxms5

Android用户常遇见的一个问题就是应用程序在后台被无故禁用，当用户在几个应用程序之间进行多任务处理时，突然一个应用程序重新加载，就会丢失位置，或者后台运行的应用程序就会停止工作。这一问题存在于很多Android设备上，近日，Pixel 3就这一问题进行了更新修复。
此前，Pixel 3系列最多保持3个APP挂后台时不重新加载，每次启动相机，其它的程序就会被清理。12月3日，谷歌推送了内存修复更新。在补丁说明中，谷歌标注了此次更新将会“在某些情况下提高Pixel 2/3系列机型但内存性能”。经过外媒测试，在使用Pixel 3 XL后台音乐播放时，同时开启8-10个APP，查杀后台的问题被成功解决。
用户受这类问题困扰，应用开发人员也必须处理这个问题。但在手机杀死后台应用时，开发者并没有用武之地。如果用户没有通过“电池优化”将应用程序列入白名单，应用程序还是无法正常运行，并且用户可能还会对这些应用程序差评。一些开发人员试图联合起来，并试图通过Do not Kill My App网站解决这个问题。
这个网站由Urbandroid团队创建，这个团队同时也是热门应用Twilight和Sleep的开发者。Urbandroid团队的一些应用程序是在后台工作的，所以他们非常熟悉这个问题。该网站对制造商的应用程序查杀行为进行排名，并告诉用户如何解决这个问题，比如如何将应用程序从制造商的电池“优化”中删除。
在Do not Kill My App网站中，评级按照很有特色的大便标记，点量越多表示评级越低。诺基亚的评级最低，足足点亮了五个标志。Urbandroid团队表示，搭载Android Pie系统的诺基亚设备在屏幕关闭30分钟后，会杀死包括睡眠跟踪(或任何其他运动跟踪)在内的所有后台进程。OnePlus的评级也很差，HTC 和 Stock Android 表现稍好，但在手机处于睡眠模式时启用Wi-Fi等连接设置，某些应用可能仍会继续使用电池。。
针对用户的解决方案是：转到手机设置—应用—查看所有应用，点击右上角菜单—显示系统。在列表中找到电池保护应用程序，选择它并强制关闭。直到下次重启，它会一直停止。
精通技术的用户可以通过以下adb命令卸载com.evenwell.powersaving.g3包：
针对应用开发者只有唯一的解决方案，那就是在进程运行时始终保持屏幕打开。但这非常耗电，通常情况下，试图保护电池的供应商会在这种解决方法上导致更大的电池消耗，另一种方法是20分钟内再次打开屏幕。

在使用Flutter发现一个问题，在Android 手机/ios手机设置成深色模式时，UI显示不完整（深色模式中有些颜色和字体设置的颜色一致或者相近），由于还没有适配深色模式，现在先将深色模式禁用。

方法1：在主题中直接添加brightness

return MaterialApp(
   ThemeData(
       brightness: Brightness.light,
      )

    );

设置之后，发现有些UI还是没有效果，检查后发现这些UI是使用的IOS风格的Widget，比如CupertinoAlertDialog，CupertinoDialogAction等。

而我使用的是MaterialApp而不是CupertinoApp，这时直接在ThemeData中设置brightness是没有效果的。

方法2:在主题中添加 cupertinoOverrideTheme

return MaterialApp(
   ThemeData(
       brightness: Brightness.light,
       cupertinoOverrideTheme: CupertinoThemeData(
          brightness: Brightness.light
        ),
      )

    );

OK，现在已经完全禁用了深色模式

上篇文章最后留了一个问题：就是如果禁用app的时刻，被禁用的APP是打开的或者是最近应用视图正在显示，该怎么处理？

我的解决方案是模拟一个HOME键的事件。这样，就能退出的状态，回到主页，同时给出提示，告知用户APP已被禁用。
这里就有两个问题了：1、如何模拟HOME按键。2、如何判断哪个APP在前台。
模拟按键
我们知道，用adb可以模拟按键，那么，我们就从input命令的实现入手。input的实现是在framework/base/cmds/input/src/com/android/commands/input/input.java。
public static void main(String[] args) {
	(new Input()).run(args);
}

private void run(String[] args) {

	...

	try {
		if (command.equals("text")) {
			
			...
			
		} else if (command.equals("keyevent")) {
			if (length >= 2) {
				final boolean longpress = "--longpress".equals(args[index + 1]);
				final int start = longpress ? index + 2 : index + 1;
				inputSource = getSource(inputSource, InputDevice.SOURCE_KEYBOARD);
				if (length > start) {
					for (int i = start; i < length; i++) {
						int keyCode = KeyEvent.keyCodeFromString(args[i]);
						if (keyCode == KeyEvent.KEYCODE_UNKNOWN) {
							keyCode = KeyEvent.keyCodeFromString("KEYCODE_" + args[i]);
						}
						sendKeyEvent(inputSource, keyCode, longpress);
					}
					return;
				}
			}
		}
		
		...
		
	} catch (NumberFormatException ex) {
	}

	...
	
}

这里，通过getSource()函数获取inputSource，然后获取int类型的keyCode，再调用sendKeyEvent函数：
private void sendKeyEvent(int inputSource, int keyCode, boolean longpress) {
    long now = SystemClock.uptimeMillis();
    injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_DOWN, keyCode, 0, 0,
            KeyCharacterMap.VIRTUAL_KEYBOARD, 0, 0, inputSource));
    if (longpress) {
        injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_DOWN, keyCode, 1, 0,
                KeyCharacterMap.VIRTUAL_KEYBOARD, 0, KeyEvent.FLAG_LONG_PRESS,
                inputSource));
    }
    injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_UP, keyCode, 0, 0,
            KeyCharacterMap.VIRTUAL_KEYBOARD, 0, 0, inputSource));
}

这里调用injectKeyEvent()函数生成按下、长按和抬起事件：
private void injectKeyEvent(KeyEvent event) {
    Log.i(TAG, "injectKeyEvent: " + event);
    InputManager.getInstance().injectInputEvent(event,
            InputManager.INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH);
}

这里就是调用InputManager的injectInputEvent方法插入相应的事件了。所以，我们在APP里面也可以这么做。
InputManager中的injectInputEvent方法是hide的，所以想要在APP里调用，要么用反射，要么就用定制的android.jar。这里我使用反射来调用。
sendKeyEvent(InputDevice.SOURCE_KEYBOARD, KeyEvent.KEYCODE_HOME, false);

private void sendKeyEvent(int inputSource, int keyCode, boolean longpress) {
    long now = SystemClock.uptimeMillis();
    injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_DOWN, keyCode, 0, 0,
            KeyCharacterMap.VIRTUAL_KEYBOARD, 0, 0, inputSource));
    if (longpress) {
        injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_DOWN, keyCode, 1, 0,
                KeyCharacterMap.VIRTUAL_KEYBOARD, 0, KeyEvent.FLAG_LONG_PRESS,
                inputSource));
    }
    injectKeyEvent(new KeyEvent(now, now, KeyEvent.ACTION_UP, keyCode, 0, 0,
            KeyCharacterMap.VIRTUAL_KEYBOARD, 0, 0, inputSource));
}

private void injectKeyEvent(KeyEvent event) {
    Log.i(TAG, "injectKeyEvent: " + event);
    InputManager im = (InputManager) getSystemService(Context.INPUT_SERVICE);
    Method method;
    try {
        method = InputManager.class.getMethod("injectInputEvent", InputEvent.class, int.class);
        method.invoke(im, event, 2);
    } catch (NoSuchMethodException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (InvocationTargetException e) {
        e.printStackTrace();
    } catch (IllegalArgumentException e) {
        e.printStackTrace();
    }
}

据说，模拟HOME键必须是系统应用，也就是声明uid为system，且有system签名的应用。
判断前台应用
网上有很多判断应用是否在前台的方法，都不是很直接，不太符合我的需求。我这里通过在ActivityManagerService中增加代码，以提供给APP前台应用的信息。
以前我做过通过在Instrumention这个类里面的callActivityOnResume方法里面增加广播，来通知APP前台应用有切换。但是在我们的这个需求里面，如果用广播的方式，那么APP就无法做查询，只能是在收到广播之后自己记录当前的前台应用。这么做不是很优雅。如果在Instrumention里面写系统属性或者Settings里面的值，因为Instrumention里面的两个context并不是system，会导致经常无法写值。
在ActivityManagerService中搜索resume，我找到了这几个方法：
@Override
public final void activityResumed(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized(this) {
        ActivityRecord.activityResumedLocked(token);
        mWindowManager.notifyAppResumedFinished(token);
    }
    Binder.restoreCallingIdentity(origId);
}

@Override
public final void activityPaused(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized(this) {
        ActivityStack stack = ActivityRecord.getStackLocked(token);
        if (stack != null) {
            stack.activityPausedLocked(token, false);
        }
    }
    Binder.restoreCallingIdentity(origId);
}

@Override
public final void activityStopped(IBinder token, Bundle icicle,
        PersistableBundle persistentState, CharSequence description) {
    if (DEBUG_ALL) Slog.v(TAG, "Activity stopped: token=" + token);

    // Refuse possible leaked file descriptors
    if (icicle != null && icicle.hasFileDescriptors()) {
        throw new IllegalArgumentException("File descriptors passed in Bundle");
    }

    final long origId = Binder.clearCallingIdentity();

    synchronized (this) {
        final ActivityRecord r = ActivityRecord.isInStackLocked(token);
        if (r != null) {
            r.activityStoppedLocked(icicle, persistentState, description);
        }
    }

    trimApplications();

    Binder.restoreCallingIdentity(origId);
}

@Override
public final void activityDestroyed(IBinder token) {
    if (DEBUG_SWITCH) Slog.v(TAG_SWITCH, "ACTIVITY DESTROYED: " + token);
    synchronized (this) {
        ActivityStack stack = ActivityRecord.getStackLocked(token);
        if (stack != null) {
            stack.activityDestroyedLocked(token, "activityDestroyed");
        }
    }
}

@Override
public final void activityRelaunched(IBinder token) {
    final long origId = Binder.clearCallingIdentity();
    synchronized (this) {
        mStackSupervisor.activityRelaunchedLocked(token);
    }
    Binder.restoreCallingIdentity(origId);
}

从函数名来看，这几个函数应该与Activity声明周期对应的，所以，我在这里增加日志跑了一下，发现确实如此。而且，Service里面的context是system的，能用来写属性和Settings。那么，我们就在activityResumed()方法里面增加写系统属性或者Settings的代码。
但是，当我写Settings的时候，报了context为空。所以，最终我写的是系统属性。
activityResumed()方法的参数类型是IBinder，怎么通过IBinder获取到包名呢？在ActivityManagerService里面搜索一下是package，就找到了下面两个方法：
@Override
public ComponentName getActivityClassForToken(IBinder token) {
    synchronized(this) {
        ActivityRecord r = ActivityRecord.isInStackLocked(token);
        if (r == null) {
            return null;
        }
        return r.intent.getComponent();
    }
}

@Override
public String getPackageForToken(IBinder token) {
    synchronized(this) {
        ActivityRecord r = ActivityRecord.isInStackLocked(token);
        if (r == null) {
            return null;
        }
        return r.packageName;
    }
}

通过这两个方法，不光能获取到包名，连Activity的名字都能获取到。