我目前正在后端系统上工作，该系统支持应用程序用户的配置文件。该系统与Android和iOS应用程序集成在一起。在移动应用程序中，有一个配置文件页面以显示用户的配置文件图像，用于更改图像的按钮以及其他详细信息。
图像必须为JPEG或PNG格式，并且最大尺寸限制为2MB。
当前，我的后端通过以下方式上传并提供图片：
multipart/form-data的形式发送图像时，图像的元数据将在SQL database中提取，插入或更新（如果已经存在），并将图像保存在资产目录中。HTTP GET中请求图像时，该图像以Base64编码的data-uri的形式发送回；在浏览器中，我可以将其显示为HTML img标签src属性的一部分。现在，移动应用程序开发人员已要求我按照（2）中所述更改服务（下载）过程。具体来说，他们要求使用服务器中静态图像的链接而不是编码的Uri进行响应。
现在，我已经阅读了data-uri的使用以及如何使图像传递更加便携的一些要点（我可以同时支持JPEG和PNG，而无需进行任何修改即可支持浏览器上的不同格式）；另一方面，我还阅读了Base64编码的图像与原始二进制图像相比如何变得更大，响应有效载荷如何变得更大，这意味着更多的飞行处理过程，并且在移动网络上证明是慢速的。
现在，我不确定哪种方法最合适。仅当单击配置文件时，移动应用程序才需要显示图像。他们可以将图像另存为应用程序数据到移动文件系统中，或者每次获取图像并显示。
很棒的是，如果有人可以帮助回答以下问题：
data-uri的形式提供图片，还是应该更改后端以提供指向静态文件的链接？data-uri相比，使用指向静态文件的链接是否更有利（我的意思是更易于在代码中实现和维护）？答案 0 :(得分：1)
我应该继续将图像作为data-uri提供，还是更改后端以提供指向静态文件的链接？
我将继续将这些图像作为data-uri提供。这意味着您可能会将数据从数据库的Blob中提取出来，然后将其发送出去。这样一来，就可以在数据库中更新数据，而不必担心在服务器端更新静态映像。
根据我的用例，两种方法之间的性能是否存在差异？
如您所说，静态图像可能更快，因为base64图像可以更大。但是，可能也不是。您可能应该将图像限制为最大大小，并且/或者在上载图像时将其调整为最大大小。我不会太担心，我编写了一些应用程序，这些应用程序可以在几秒钟内读取数百张base64图像，而没有明显的滞后。
对于移动应用程序，与data-uri相比，使用指向静态文件的链接是否更有利（我的意思是更易于在代码中实现和维护）？
使用data-uri可能更容易，因为移动应用程序需要将其转换为可与ImageView配合使用的文件格式，也可以将其显示在其中。
如果图像仅由用户在其设备上使用，您是否真的需要让他们上传图像？ （如果您希望相同的个人资料图片显示在他们拥有的每台设备上，那么您是否可以将其仅存储在应用程序数据存储区或本地SQLite数据库中？