I.はじめに
プロジェクトが比較的大きく、反復時間が比較的長い場合、コードをリファクタリングし、体系的な統合とコードの標準化された議論を行うことがよくあります。これにより、将来の開発のために繰り返しコードを作成することがなくなり、コードの保守と拡張に便利になります。 、など。コードをクリーンアップして開発仕様書を設計する、という経験をした企業も多いと思います。
資源についてはどうですか？リソース ファイル (ここで言うリソースとは主に画像リソースを指します) の保守と拡張を容易にするためにリソースを整理する方法を考える人はどれだけいるでしょうか。
2. なぜ画像リソースを管理する必要があるのか
なぜなら、私は比較的小規模なプロジェクトにも携わってきましたし、比較的大きなプロジェクトにも携わってきたからです。プロジェクトが比較的小さい場合は、参照されるリソースがそれほど多くない可能性があり、このプロセスには複数の関係者の協力が必要になる可能性があるため、以前の画像リソースの整理に余分な時間を費やすことはお勧めしません。 。
ただし、プロジェクトが比較的大きく、リソースが整理されていない場合、リソースは乱雑になります。たとえば、私が関わっているリソースの場合、このプロジェクトに携わった人は 7 ～ 8 人いて、それぞれリソースの扱い方が異なります。見ても操作方法がわかりません。これらのリソースは枯渇しており、開始する方法はありません。
実は、この点には主に 2 つの問題があり、1 つはコマンドなどの仕様の問題で、灰色の閉じるボタンがある場合、同僚はリソースに grey_close.webp という名前を付け、もう 1 つはコマンド close_grey.webp という名前を付けました。私はこの仕事に慣れていないので、ページを作成し、[閉じる] ボタンがあると、私の最初の反応は、リソース ファイルをグローバルに選択して close を検索し、次に grey_close.webp と close_grey.webp を検索することです。そして、少し大きい写真と少し小さい写真の2枚があるので、どちらを使って効果を順番に試していけばいいでしょうか？それとも 1 つだけ使用しますか?
私がより深刻だと思うもう 1 つの問題は、リソースの重複の問題です。上記の例では、閉じるボタンがありますが、このページを書くときは何が起こっても気にせず、新しいクローズ カット画像をインポートするだけなので、プロジェクトでは多くの閉じるボタンが使用されています。カットした写真をインポートする前に、重複を防ぐためにプロジェクト内に同じ写真がないか確認する人も多いと思いますが、利便性を考えて直接インポートする人も多いでしょう。プロジェクトに 12 ～ 20 枚の「クローズド」カット写真が含まれることがどのようなものか想像できますか? もちろん開発に影響はなく、最悪使いたいときに別のものをインポートすればいいだけです（難易度選択の福音）。
はい、この問題は開発プロセスには影響しませんが、ある時点で罠にはまる可能性があります。たとえば、閉じるボタンが 15 個あり、ページのうち 5 個をスキンする必要があります。この5か所で手術をしているんですか？これら 5 つの場所の最後の写真がなぜ同じに見えるのか、なぜ当時 5 枚の写真が使用されたのか、なぜ 1 枚を共有しないのか、疑問に思うでしょう。
3. リソースの管理方法
1. 命名規則
どの企業もリソースの命名規則を持つべきだと思います。できればandroid側だけの仕様ではなく、会社全体の仕様にしてほしいです 例えば、android側、ios側、フロントエンドでクローズカットの絵を使うなど、それぞれの仕様がベストです。ファイル命名基準は同じです。
もちろん、命名には細かい点で注意すべき点がいくつかありますが、まず便宜上、画像リソースに直接 close.png という名前を付けることはできません。あなたのプロジェクトがクローズドスタイルを1つだけ持つことは不可能だと私は信じているからです。切り欠きが2つあります
この時、closeだけで名前を付けると非常に恥ずかしいのでclose2しかプレイできません。
あとはスタイルの問題です。上の写真のように、さまざまな画像スタイルがあるかもしれませんが、それらはすべて意味がありません。何と名付けますか。これはテクノロジーではないかもしれませんが、芸術でもあります。たとえば、最初のクローズに close_in_round という名前を付けることはできません。
次に色の問題です。おそらく、UI デザイナーは物事を活気づけたいと考えており、プロジェクトでは閉じるボタンのすべての色が赤、オレンジ、黄、緑、青、紫、黒、グレーで構成されています。それで、名前は何にしますか。もちろん、Android の場合、ベクター グラフィックスは色を直接変更できます。しかし、異なる色の切り抜きがある場合は、それらに名前を付ける方法を真剣に考えなければなりません。
あとはサイズの問題ですね。同じカット画像でもサイズが異なる場合がありますが、どのように名前を付けますか? 実際、Android、xhdpi、xxhdpi、xxxhdpi のリソース フォルダーを学習し、いくつかのサイズ仕様のセットを作成することをお勧めします。1 つのプロジェクトに同じスタイルを 6 つまたは 7 つ以上使用できない場合は、デザインに問題があると感じます。
2. リソースの重複を防ぐ
閉じるボタンなどのリソースの重複を避けるようにします。色とサイズが同じであると仮定すると、次のようになります
他们基本就长得一个样，如果一个项目里面有个两三张，那我觉得情有可原，可能某些页面特殊要用单独的。但是这玩意长得差不多的你的项目有个七八张，那我觉得过分了，我说的是图中这种差不多的，不算上面那个带圈那种不一样的。
所以开发页面导入切图时，要先去查看有没有相同的图片，避免重复导入。查找图片导入的方法有两种，一是通过搜索资源，因为我们这些搞开发我算3年以上的，至少你命名也和图片有关的吧，比如你总不能搞一张关闭的按钮，和close这些词无关吧。第二种方法比较直观，通过Resource Managaer ,我觉得AS提供这个功能确实用处很大。
用这个肯定是能找图片，问题就在于，我上面说的，你一张关闭的切图有十几二十张，我就算用Resource Managaer找到了有关闭样式的切图，我也不知道要复用哪张。
然后上面也有说了，Android的矢量图，是能改变颜色的，所以通过这个方法，相同的尺寸和样式，不同颜色的矢量图也是能共用一张的，注意是矢量图。
对于一些样式相同但是长宽尺寸不同的图片，就是拉伸的效果相同的图，可以使用.9
3. 切图源头进行处理
其实很多切图的源头，都没处理好，如果说设计师其实知道两个地方的图片是相同的，但是他给忘记了，他也懒得找。所以重新弄了一张切图给你，导致和之前的尺寸不同。其实这里图片的源头就出了问题。所以我说这个图片资源的管理是需要多方进行努力的。
4. 图片管理系统
这一步就是做大了，你的公司有一个图片管理系统，甚至应该叫资源管理系统。当然如果要做这样的系统，也是需要额外的精力和成本。如果公司开发的项目比较小，我觉得花人力物力去做这样一个系统也不值，性价比不高。但是对于一个大公司而言，我觉得有一套这样的系统，还是挺好的，挺有用的，对于项目的迭代和维护来说。
リソースのサイズ、色、スタイルです。一意に識別したい場合は、名前ではなく ID を使用するのが確実です。そう、一意に識別したいならIDが一番信頼できるんです。
それぞれの異なるカットにそれを一意に識別するための ID がある場合、テーブルが作成され、ID を通じて対応するリソース ファイルを見つけることができます。これで、リソース ファイルを管理できるようになります。
ソース UI デザインから始まり、カットされた各画像がこのシステムに送信されますが、名前、説明、ファイルの生成元の 3 つの重要なフィールドがあると考えられます。アップロード後、システムは ID を生成し、UI デザイナーはデザイン ドラフトにアップロードするときに、この ID を使用してカット イメージに名前を付けます。その後、カット写真を作成するときに、「説明」を通じてシステムにアクセスして、対応するカット写真を検索できます。
クライアントにとって、対応するカット写真が必要な場合は、ID を介してこのシステムから写真をすぐに取得できます。画像リソースが重複しないように、コマンドには close_457762.png のように ID と説明で名前を付けることもできます。
そうすれば、スキンを変更したい場合、どの ID の写真を変更すればよいのかを直接伝えることができ、素早く明確に見つけることができます。
リソース管理システムを通じてすべての端でリソースを管理することは、間違いなく良い習慣です。ただし、システムの開発や保守に一定のコストがかかるのがデメリットです。
4. まとめ
この記事では主に、大規模プロジェクトにおけるリソースの混乱という一般的な問題について説明したいと考えています。もし誰かが画像リソースを管理するより良い方法を持っているなら、それを共有したいと思っています。