• 设备。
• Benchmark 工作流程。 如图3。看不懂。
• 功耗测量。 通过Monsoon power monitor。为了防止安卓电池省电机制杀后台，评测期间通过安卓电量管理服务保持屏幕常亮，屏幕的功耗也被测量了。

对RQ1的回答。

• 两个版本，20200214和20210404的Google Play

• 模型都是分布在主APK里的（就是没有通过扩展包之类的方法下载）
• 没有发现开发者选择使用某个设备专用的模型，开发人员更喜欢解决方案的通用性

• 这里的模型不是表2中的全部，剩下的是被加密和混淆的
• caffe已经被停止更新了，还能被用这么多，零人吃惊
• 这些结果说明，前沿SOTA的ML框架和实际部署环境中它们的使用率的差距

同样见图4。

• 只有318（表3中的19.1%）个模型是特制的。
• 最流行的模型：物体检测：FSSD；人脸检测：Blazeface。MobileNet是跨任务最流行的模型。
• 遇到了多次处理常见任务的模型，比如信用卡信息识别，姓名日期

模型微调

• 排除掉重复的模型，剩下模型的9.02%，与至少一个其他模型，共用至少20%的权重。4.2%只有三层不同，证明开发者只微调了一小部分
• 没有检测到on-device的微调，因为计算要求太大，且on-device上高质量标注数据集的缺少，意识到这种的开发者也太少。

比较了差了一年的GooglePlay快照的分析，考虑了疫情影响

• DNN模型在安卓App中的部署翻倍了，快速增长
• TFLite从81.6%增长到86.1%，caffe和ncnn增长了，TF下降了，因为TFLite的存在

按类别讨论

• 疫情期间通讯软件变得更加重要，开发者的重心转移到这上面来，金融也是。
• 生活方式等软件DNN减少了，因为人们在家里
• 使用DNN的App也在飞速增长，从236-377，2020.2-2021.4

• convolution layers being amongst the most popular layer types across modalities (34%, 10%, 20% for image, text and audio, respectively).

图中没说明横杠是什么

• on average the heaviest deployed vision models belong to classification, hair reconstruction, segmentation and beauty tasks.
• for NLP the heaviest tasks belong to text auto-completion.
• for audio the heaviest deployed task is sound recognition.
• 以上结论只针对被跟踪分析的模型，不是普适的结果

回答RQ2。

• 图8，延时和FLOPs非线性的，不仅受模型架构影响，也受不同设备影响（显然如此）。

• a图看出，消耗能量和负载相关，和设备无关
• b图看出，新代设备功耗更大，原因也很直接，做相近的功，但新代设备速度更快。
• c图看出，不同设备之间，推理效率（每秒*每瓦特内多少个浮点数被运算，等价于每焦耳多少个FLOPs）差不多，但新代设备稍有提升，表明更多的模型在新设备上可以运行得更有效率。

• 能耗似乎主要受模型架构的影响
• 这表明，AI开发者是优化电池寿命的最大因素，不像推理速度，可以被多个因素比如制作商来改善。

• 作者没发现自然场景下有模型使用了weight clustering方法。

• TFLite为剪枝的层打上“prune_”前缀，但inference的时候通常会移除前缀。
• 同样没有发现这种层
• 但是检查了稀疏程度，3.15%的权重接近0，可能表明，基于权重大小的剪枝前景有限

• 10.3%的模型用了dequantize层，表明部署低精度模型作为模型压缩的一种方式
• 20.27%的模型使用了int8的权重张量，10.31%使用了int8的激活函数
• 现在有的硬件可以用NPU并行计算，multiple arithmetic precisions，但是没发现它们的使用痕迹

观察结果

• 端侧AI开发者没有广泛使用这些优化方法
• 量化是最广泛使用的优化方法，但还有一些先进的混合量化方案有待支持

测试了系统外界参数对模型的影响。

• 4个线程，只考虑了TFLite
• 吞吐量的规模是线性的，表明没有遇到瓶颈
• S21推理得最快，比A20和A70更快
• 作者认为继续调高batchsize会导致内存带宽瓶颈或内存错误，但是打算以后再研究…

• 线程亲和性参数
• 发现，不同设备的最优线程数是不一样的，分别是4，2，4个线程
• 8线程表现都不好，遇到瓶颈了
• 线程数超过核心数都会导致大幅性能退化，如4a2，8a4，因为线程等待
• 线程数设置为核心数并没有提高性能，让作者意外，因为本以为可以减少数据在核心之间的迁移
• 在不同设备上调整线程数是有可能带来显著提升的

在三个后端NNAPI,XNNPACK,SNPE上测试TFLite和caffe模型，在骁龙845板上

• 71个（23.8%）使用了NNAPI，1个用了SNNPACK，3个用了SNPE。
• 很多App没有按承诺所说，针对硬件加速，或使用目标优化的核操作

• 用XNNPACK更好
• NNAPI不行，可能是厂商的NN驱动没调好
• 使用SNPE的GPU和CPU比原厂GPU和CPU要好
• 厂商提供了没有优化的CPU
• DSP运行INT8，GPU、CPU全精度
• 看不懂

• 共524个App，是2020的2.33倍；452用谷歌，72个app用亚马逊
• 开发者主要用云端API来进行图像和视频的任务

• 有相关工作分析手机上的DNN模型，但缺少对**“DNN优化技术怎么影响最新的使用DNN的App”**的动向的相关研究。
• 主要有两个工作研究了自然场景下的DNN使用。
• Xu等人分析了谁使用了DNN模型并且分析了端侧DNN的使用案例。
• 有人调查了端侧DNN的保护安全问题，发现很多安卓App没有保护它们的DNN模型，没进行性能分析。
• 以上两文为起点，本文分析了包括延时、能耗、系统和模型级别的参数及优化等，提供了更全面的理解。

• 端侧AI的激增
• 模型再使用 很多开发者使用现成的模型
• DNN和移动硬件资源 许多开发者没有使用特定硬件加速，而是把通用性当作目标，在普通CPU或者中间件上运行。
• Energy是瓶颈 预计迟早能量（就是电池和功耗）会是智能移动设备的瓶颈
• DNN共生关系 将来多个DNN并存运行？
• On-Device学习和个性化 on-device data变多，以后将在设备上在线学习

• 只分析了安卓
• 被加密的、被混淆的、在主apk文件之外的DNN模型没有被分析
• 没有调查模型的调用路径和推理频率，有些模型应该被经常调用，有的会少调用
• 在调查云端DNN的API使用时，忽略了那些使用自定义API的开发者

• 一个针对最流行的DNN支持的移动App的综合的经验研究
• 给移动程序开发者和DNN框架开发者都能提供指导